The consent-mode audit for publishers: checking your ad stack actually respects the signals
Consent Mode is a signaling system, not an enforcement system. It tells Google's tags what the visitor chose; it does not make the rest of your ad stack behave. Publishers running programmatic ads often have ten or more vendors on the page, and the audit question is simple: under "reject all," does every one of them actually stop? The consent-mode audit checks the signals at the point of transmission, vendor by vendor, state by state.
What Consent Mode does and does not do
Consent Mode translates the visitor's choice into a set of signals that Google tags understand: ad storage granted or denied, analytics storage granted or denied, and the newer signals for personalization and security storage. Google's own tags adapt their behavior accordingly, sending cookieless pings instead of full measurement hits when storage is denied. That part works well and is well documented.
What it does not do is reach the prebid wrapper, the three SSPs, the viewability vendor, and the identity graph that piggybacks on the page. Those vendors receive the consent state through other channels: the TCF string, their own consent APIs, or nothing at all. A publisher can have a perfect Consent Mode implementation and still leak data through a vendor that never integrated with the consent framework. The audit exists to find those vendors.
The state-by-state test matrix
Run the page under each consent state and record what each vendor transmits. The matrix has one row per vendor and one column per state: all-accept, all-reject, and the mixed states your banner actually offers. Under all-reject, the passing bar is strict: no identifiers, no bid requests carrying user IDs, no syncs to data brokers. Under mixed states, the bar is that each vendor's behavior matches the specific categories the visitor granted.
Do this in a clean browser with the network inspector recording, and again with a dedicated scanner for the vendors you cannot easily attribute by hand. The scanner gives you the vendor inventory; the manual pass gives you the behavior detail. Both matter because vendors change behavior with their own release cycles. A vendor that behaved under reject-all in March may have shipped a new sync pixel in August.
Reading the TCF string in the wild
For vendors in the Transparency and Consent Framework, the consent string is the contract. The audit should decode the actual TCF string your CMP generates under each state and check it against what the banner promised. Common failures: the string claims a legal basis the banner never disclosed, purposes are granted by default in the string while the banner shows them as off, or vendor lists in the string do not match the vendor list in the policy.
Decode the string with a public TCF decoder rather than trusting the CMP's own reporting. The CMP reports what it configured; the decoder reports what the browser actually received. When those two disagree, the browser's version is the one a regulator will read.
What to do with the failures
Most audit failures sort into three buckets. Vendor misconfiguration: the vendor supports consent signals but your tag passes the wrong parameters; fix the integration. Vendor indifference: the vendor ignores consent signals entirely; escalate to the vendor and start the clock on replacing them. And contract gaps: the vendor's terms never promised consent-aware behavior in the first place, which is a procurement failure that the next contract cycle has to fix.
Document the matrix and re-run it quarterly, or after any ad stack change. New vendors are the main source of regressions: every added SSP, every new identity partner, every viewability script needs its own row in the matrix before it touches production. The audit is not a one-time project. It is the price of running a programmatic stack under consent law.