Free scan
Segment / CDP · troubleshooting

Segment (or your CDP) sends data before consent

A customer data platform multiplies the problem instead of containing it. One analytics.js load can fan a single page view out to a dozen destinations — analytics, ad platforms, warehouses, email tools — and if consent is not enforced at the CDP layer, every one of those destinations receives data the visitor never agreed to send.

The short answer

The upside is that a CDP is also the best possible place to fix it. Enforce consent once, at the point where events are collected and routed, and every destination inherits the gate — including the ones marketing adds next quarter without telling you.

Segment, RudderStack, mParticle, Tealium and Snowplow all now ship consent-management features that map consent categories to destinations. The work is configuration plus a mapping decision per destination, not custom engineering.

Last reviewed: September 1, 2026Diagnostic + fix checklistGeneral information, not legal advice

What it looks like

Fresh incognito window, DevTools → Network, banner untouched. You will see the CDP's own bundle load — cdn.segment.com/analytics.js/v1/…/analytics.min.js or the equivalent for your platform — followed by a POST to the collection endpoint (api.segment.io/v1/p for a page call). Then watch what comes after: device-mode destinations load their own vendor scripts, so a single CDP load can produce requests to Google, Meta, and three tools you forgot were connected.

Server-side (cloud-mode) destinations are worse in one specific way: you will not see them in the network tab at all. The event goes to the CDP, and the CDP forwards it from its servers. The only place to see that fan-out is your destination list.

DevTools → Network — fresh incognito, banner untouched:
GET cdn.segment.com/analytics.js/v1/…/analytics.min.js ← CDP bundle loads with the page
POST api.segment.io/v1/p ← page event sent before any banner click
GET connect.facebook.net/… , clarity.ms/… , … ← device-mode destinations load their own scripts

Verify it yourself in five minutes

Half of this is in the browser and half is in your CDP's destination list — because the browser cannot see server-side forwarding.

  1. Fresh incognito window, DevTools → Network, Preserve log on. Load the site, leave the banner alone.
  2. Filter for your CDP. segment, rudder, mparticle, tealium. If the bundle loads and a collection POST follows before you click anything, events are being collected pre-consent.
  3. Open the payload. Click the collection request and read the JSON body: page URL, referrer, an anonymous ID, and whatever traits your implementation attaches. That is what left the browser.
  4. Now count the destinations. In the CDP admin, open the source's destination list. Every enabled destination receives what you just saw. Note which are device mode (they load a script in the browser) and which are cloud mode (the CDP forwards server-side, invisibly).
  5. Check the consent configuration. Look for the consent-management settings on the source: is a consent category mapped to each destination, and is there a rule for what happens when consent is unknown? "No mapping" plus "send anyway" is the default in most implementations that were never configured.
  6. Test the identify path. Submit a form or log in on a staging copy and watch for an identify call. That is the one that attaches an email address to the anonymous ID — the point at which a pseudonymous profile becomes a named one.

What a healthy result looks like: Before consent: no collection POST at all, or one that the CDP is configured to hold. After consent: events flow only to destinations mapped to the categories the visitor accepted.

Why it happens

1. The CDP was installed before consent was on anyone's mind

Implementation focused on getting events flowing. Consent mapping is a later feature that nobody went back to enable, so the default — collect and forward everything — is still in place.

2. Destinations were added by people who never saw the consent config

Adding a destination is a few clicks in an admin UI. Each new destination silently inherits whatever consent behavior the source has, which is usually none.

3. Device-mode destinations load vendor scripts directly

In device mode the destination's own SDK is loaded into the page by the CDP. So an ungated CDP does not just send one event — it injects other companies' trackers, each of which then behaves as it normally would.

4. Cloud-mode forwarding is invisible to browser testing

A network-tab check shows nothing for server-side destinations. Teams verify in the browser, see one clean request, and conclude the stack is fine while the CDP forwards to a dozen partners.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that a customer data platform collecting a visitor's page views and identity and fanning them out to third-party destinations before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

What this is called

Terminology bridge

The category is a customer data platform (CDP) and the pattern is event collection and fan-out. Destinations run in device mode (the vendor's SDK is loaded in the browser) or cloud mode (the CDP forwards server-side) — a distinction that decides whether browser testing can see them at all. The feature you are enabling is consent management or consent enforcement, and the design principle to insist on is fail closed: no mapping means no send. The call that turns an anonymous profile into a named one is identify.

What a scan can and can't tell you

A browser-based scan sees only device-mode behavior. It will tell you whether the CDP bundle and its in-page destinations load before consent — which is genuinely the part plaintiff-side scanners see too — but it cannot see server-side forwarding. For that half you need the destination list, and no external tool can substitute for reading it. And as always: a scan documents timing, not legality.

Sources

  1. Segment: consent management documentationsegment.com
  2. Google: Set up consent mode on websitesdevelopers.google.com
  3. California Civil Code § 1798.140 — definitions of sell, share, and consentleginfo.legislature.ca.gov
  4. California Penal Code § 631 (leginfo.legislature.ca.gov)leginfo.legislature.ca.gov

Check your own site

RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.

Free real-browser scan

See every pre-consent tracker on your site — free, 30 seconds, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

Does a CDP make pre-consent tracking better or worse?
Both, depending on configuration. Worse if unconfigured, because one ungated collection call fans out to every connected destination — including device-mode destinations that load other vendors' scripts into your page. Better once consent enforcement is on, because you gate once at the collection layer and every destination inherits it, including ones added later.
Why can't I see all my destinations in the network tab?
Because cloud-mode destinations are forwarded from the CDP's servers, not from the browser. Browser testing only reveals device-mode destinations. To see the full fan-out you have to read the destination list in the CDP admin.
What is the right default when consent is unknown?
Fail closed: hold the event rather than forward it. Most unconfigured implementations do the opposite, which means every destination added later without a consent mapping starts sending immediately.

Keep reading

Consent banner not blocking trackersGTM fires tags before consentSample scan reportCompliance for SaaS & technologyMonitoring plans