The server-side container was sending email, name, country, and zip code to Meta CAPI, TikTok Events API, and Google Ads even when ad consent had been denied.
Consent Mode v2 audit across 154 tags: 128 had missing or misconfigured gates, plus a race condition in the CMP marking consent as granted before user interaction.
ad_storage and ad_user_data gates implemented on the 15 affected server-side tags, blocking publication until the gap was fully closed.
Complete elimination of PII sent outside of consent before going live. A legal risk fix under GDPR, not a tracking tweak.
Context
The container had been live for months, reporting normally — active campaigns, conversions coming in, nothing that raised a flag from the outside. The audit didn’t start from an incident; it started as a preventive compliance review ahead of a bigger ad-spend push — exactly the kind of review most accounts never run until it’s already too late.
How it was actually solved
Why 128 of 154 tags were failing and nobody noticed
The failure wasn’t concentrated in one obvious spot — it was spread out: tags configured at different times by different people, with no single standard for how to gate consent. Each one looked reasonable in isolation. Only auditing 100% of the container, tag by tag, revealed the real pattern: the missing gate was the norm, not the exception.
The race condition that made it worse
Under certain page-load conditions (slow connection, empty browser cache), the CMP marked consent as granted before the user had even seen the banner. In quick manual tests, with the page already cached, the order came out correct almost every time — which is exactly why nobody had caught it in months of normal use.
Why it got fixed before the campaign, not after
With the bigger campaign already scheduled, any fix applied after launch would have meant weeks of conversion data contaminated by the same issue, impossible to clean up retroactively. Closing the gap before turning on spend was the only way for that campaign’s data to be defensible from day one.
A container that "works" at the business level (campaigns report, dashboards fill up) says nothing about whether it respects user consent. Those are two completely different questions, and only a tag-by-tag audit answers the second one.
FAQ
How do you detect this kind of leak without full access to the container?
Partially: the browser’s Network tab shows what’s being sent to which domain and with what consent signal, no credentials needed. Fixing it does require access, but suspecting it exists doesn’t.
Can this kind of gap be prevented with a fixed checklist?
It reduces the risk, but doesn’t eliminate it — a checklist won’t catch a CMP race condition, which only shows up under specific load conditions. That’s why a real audit has to check actual Network behavior, not just static configuration.