How PixelsCleared Works

The Big Picture

PixelsCleared sits between your website and the ad platforms (Meta, Google, TikTok, etc.). Instead of loading third-party tracking scripts directly in your visitors' browsers, a lightweight script on your site sends events to your own subdomain. PixelsCleared scrubs sensitive data and forwards only approved signals to your connected destinations.

Here is the path each event takes:

1. Website -- A visitor loads a page, submits a form, or clicks a tracked button.
2. Widget captures -- The pixelscleared.js script on your site detects the action and bundles it into an event.
3. Proxy receives -- The event is sent to your first-party subdomain (for example, track.yourdomain.com), where the PixelsCleared gateway processes it.
4. Scrubber applies rules -- Sensitive data is stripped, risky event names are remapped, and consent is verified.
5. Dispatcher forwards -- The cleaned event is sent to each connected destination (Meta CAPI, GA4, webhooks, etc.).

Your visitors' browsers never communicate directly with Facebook, Google, or any other third party. Only the PixelsCleared server does.

Consent Signal Detection

The widget does not send any data until a visitor grants consent. It reads the consent cookies set by your existing consent tool:

• Cookiebot -- reads the CookieConsent cookie
• OneTrust -- reads the OptanonConsent cookie
• CookieYes -- reads the cookieyes-consent cookie
• Complianz -- reads the cmplz_cookie_consent cookie
• Generic -- checks for cookie_consent, consent_given, or tracking_consent cookies

If no consent cookie is detected, the widget also checks for platform APIs like IAB TCF v2 (window.__tcfapi) and OneTrust callbacks.

Consent behavior:

• No consent detected -- widget stays idle, nothing is sent
• Consent granted -- widget sends new events to the gateway
• Consent rejected -- widget discards everything, sends nothing
• Consent withdrawn -- widget stops immediately and clears local state

You can also grant consent manually with window.PixelsCleared('consent', true) for custom setups.

What Gets Scrubbed

Before any event reaches a destination, the scrubbing engine removes or neutralizes sensitive fields:

• URL paths and query strings -- /medicare-plans?plan_id=123 is removed entirely
• Page titles -- stripped to avoid leaking page content
• Referrer paths -- only the domain is kept (for example, facebook.com instead of the full URL)
• Form field values -- never collected by the widget, never forwarded
• Email addresses, phone numbers, names -- detected and removed from all payloads
• IP addresses -- hashed, never stored or forwarded in plain text
• User agent strings -- removed
• Sensitive words -- fields containing terms like "medicare," "insurance," "diabetes," "loan," or other flagged words are removed entirely

Event names are also remapped. A name like medicare_quote_started becomes a neutral code like lead_start. You can configure custom mappings in the dashboard.

Where Data Is Stored

Every event processed by the gateway is recorded in the gateway_events table:

• Raw event data -- stored for 30 days, then automatically deleted
• Scrubbed event summaries -- kept indefinitely for reporting
• Consent status and timestamp -- recorded for every event
• Forwarding results -- which destinations received the event, and their responses
• Audit log -- every action (receive, scrub, forward, block) is logged with a timestamp

You can view event history, consent rates, and destination health from the Gateway section of the dashboard at any time.