TCF and Consent Mode: is the signal honored in the app?

The IAB’s consent framework (the TCF) and Google’s Consent Mode share a goal: encoding the user’s choice into a signal that can be passed along. It still has to be honored at the end of the chain, inside the app.

A framework that keeps tightening

Since January 2024, Google requires publishers serving personalized ads in the EEA and the UK to use a certified CMP integrated with the TCF. Otherwise, only limited ads can be served.

For its part, IAB Europe monitors integrations: a vendor that tampers with a TC string can be suspended from the global vendor list. The framework exists, and it keeps tightening.

Encoding is not honoring

A correctly encoded signal does not guarantee correct behavior. The TC string can be ignored by a badly integrated SDK, arrive after the request has already left, or be contradicted by an SDK firing too early.

The signal describes an intent. The app’s behavior describes what actually happens. The two can diverge, and it is that divergence that exposes the publisher and the vendor alike.

What the field shows

What is missing is a view of the real behavior, where the SDK runs. On a real phone, one observes what the SDK does and when, relative to the choice expressed in the banner: before, or after a refusal.

That finding stays a factual, dated map. It does not issue a TCF or Consent Mode compliance verdict: it documents what happens, and leaves the legal assessment to the publisher and its counsel.

The vendor-side check

For an adtech vendor, knowing how its SDK behaves, across a sample of real apps, once the choice is expressed, usefully complements what its documentation claims. It is a way to spot integrations where the choice has, in practice, no effect.

That is the purpose of a check for ad networks and adtech: observing the SDK’s behavior app by app, backed by evidence.