IAB TCF 2.2 vs Google Consent Mode v2: How They Differ and Work Together

Two Frameworks, Two Different Jobs

IAB Europe's Transparency & Consent Framework (TCF) 2.2 and Google Consent Mode v2 are the two consent standards almost every ad-funded website touches — and they are constantly confused for each other. They are not competitors, and choosing "one or the other" is usually the wrong question. They operate at different layers of the advertising stack and, for most publishers running programmatic ads alongside Google's products, both are needed.

In short: TCF 2.2 standardises a consent signal for the entire programmatic adtech ecosystem, while Consent Mode v2 governs how Google's own tags behave based on the consent state. This guide explains what each does, where they overlap, and how a consent management platform wires them together so the signals stay consistent.

What Is IAB TCF 2.2?

The TCF is a standardised system that lets publishers, consent platforms, and adtech vendors communicate a user's consent choices in a machine-readable way. Its core output is the TC string — an encoded value that records which purposes the user agreed to and which vendors are allowed to process their data. Any participating vendor can read that one string instead of each running its own banner. For the foundational explainer, see our guide on what TCF is.

TCF 2.2, which became mandatory across the framework in 2023, tightened the rules considerably:

• Legitimate interest removed for advertising and content personalisation purposes — these now require explicit consent, narrowing the legitimate-interest loophole.
• Clearer, plain-language purpose descriptions and standardised examples of how data is used.
• Vendor count disclosed on the first layer so users see how many companies are involved.
• Easy withdrawal — users must be able to change or revoke their choices as easily as they gave them.

TCF is governed by IAB Europe; the official framework documentation lists the registered purposes and vendors.

What Is Google Consent Mode v2?

Consent Mode is Google's API for adjusting how its tags — Google Analytics 4, Google Ads, Floodlight — behave according to a user's consent. Rather than simply blocking or allowing tags, it lets them operate in a restricted, cookieless mode when consent is absent. Version 2 added two signals on top of the original pair:

• ad_storage — cookies for advertising
• analytics_storage — cookies for analytics
• ad_user_data (v2) — whether user data may be sent to Google for advertising
• ad_personalization (v2) — whether data may be used for personalised advertising / remarketing

The two new v2 signals are required for EEA and UK traffic if you want to keep using Google's audience and remarketing features. Consent Mode also powers behavioural modelling, which estimates conversions lost to refusals. For the full setup and reporting impact, see what Consent Mode v2 is and how it affects GA4 reporting. Google's own reference lives in the Tag Platform documentation.

The Crucial Difference

The cleanest way to keep them straight:

TCF 2.2 is about who may process data. It produces a portable consent record that hundreds of registered adtech vendors can read, so a single banner can authorise (or deny) the whole programmatic supply chain.

Consent Mode v2 is about how Google's tags behave. It doesn't enumerate third-party vendors; it translates the user's choice into four signals that change whether Google's own tags use cookies, send data, and personalise ads.

Because Google participates in the TCF as a registered vendor, the two intersect — but they do not replace each other. TCF tells the broader ecosystem what's allowed; Consent Mode tells Google's tags what to do. A site running header-bidding or programmatic display generally needs TCF; almost any site using GA4 or Google Ads needs Consent Mode.

Why You Usually Need Both

Consider a typical ad-funded publisher:

• They sell programmatic display through an ad exchange with dozens of demand partners → those vendors expect a valid TC string to bid lawfully.
• They measure traffic in GA4 and run Google Ads remarketing → they need Consent Mode v2 signals to keep modelling and audiences working in the EEA/UK.

Running TCF without Consent Mode means Google's tags may not get a clean signal, degrading measurement and remarketing. Running Consent Mode without TCF leaves the programmatic supply chain without the standardised consent record it requires. The two are layers of the same compliance story, not alternatives.

Getting the relationship right also matters for whether Consent Mode is even optional for you — see is Consent Mode v2 mandatory for the EEA enforcement details.

How a CMP Wires Them Together

You should not be hand-coding TC strings or mapping purposes to Consent Mode signals — that is exactly the job of a certified consent management platform. A properly configured CMP:

1. Presents one banner that captures the user's choices across TCF purposes and vendors.
2. Generates the TC string (and AC string) and exposes it to adtech vendors via the standardised __tcfapi interface.
3. Maps those choices onto the four Consent Mode signals and pushes them to the Google tag, so the two stay consistent.
4. Defaults to denied before consent for EEA/UK visitors, then updates the signals once the user chooses.
5. Logs every choice so you can prove what was consented to and when — see consent expiry and re-consent.

The most common failure mode is signal drift: a banner that records a TCF refusal but still sends ad_storage=granted to Google, or vice versa. Because the CMP owns both outputs, it keeps them aligned. Verify the result in practice with our guide on server-side tracking validation.