IAB TCF Framework Overview
Why a standardized consent string exists at all
Before IAB's Transparency & Consent Framework (TCF), every ad tech vendor in a programmatic bidstream had to independently determine whether a user had consented to their specific processing purpose — an unworkable problem when a single ad auction can involve dozens of vendors in milliseconds. TCF solves this by standardizing consent into a single encoded string (the Transparency and Consent string, or TC string) that a CMP generates once and every vendor in the supply chain can decode and respect, without each vendor needing its own consent collection mechanism.
Purposes, legal bases, and vendor lists
TCF defines a fixed set of standardized processing purposes (currently 11, including 'Store and/or access information on a device,' 'Select basic ads,' 'Create a personalised ads profile,' and others), each of which a vendor can rely on either via explicit consent or via legitimate interest as its legal basis, depending on the purpose and jurisdiction. The Global Vendor List (GVL), maintained by IAB Europe, is the registry of every vendor permitted to participate, each declaring which purposes they process data for. A CMP's consent UI is essentially a front-end for collecting per-purpose (and sometimes per-vendor) choices against this list.
// TCF v2.2 exposes a standardized __tcfapi() function on window for any script
// (including GTM, ad tags, or custom code) to query current consent state.
window.__tcfapi('addEventListener', 2, function(tcData, success) {
if (success && tcData.eventStatus === 'tcloaded') {
var purpose1Consent = tcData.purpose.consents['1']; // storage/access purpose
if (purpose1Consent) {
// Safe to initialize storage-dependent tags
}
}
});TCF is a transport mechanism, not a legal compliance guarantee
How TCF relates to Google Consent Mode
Google participates in the IAB framework as a registered vendor for certain products and also maintains its own, separately-structured Consent Mode signal set (ad_storage, analytics_storage, etc.) used specifically by Google's own tags and GTM. A CMP serving both needs to generate a TC string for the broader programmatic ecosystem *and* call Google's gtag('consent', 'update', ...) for Google-specific tags — these are two separate consent signal systems that most CMPs bridge automatically, but a custom integration has to explicitly wire both.
TCF vs. Google Consent Mode
| Dimension | IAB TCF | Google Consent Mode |
|---|---|---|
| Scope | Entire programmatic ad tech vendor ecosystem | Google's own tags (Ads, Analytics, Floodlight) |
| Format | Encoded TC string, decodable by any TCF-aware vendor | Named consent-type signals (granted/denied) read by Google tags/GTM |
| Governed by | IAB Europe, via the Global Vendor List | Google's own product requirements |
| Required for | Programmatic/RTB bidstream participation in applicable regions | Any site using Google Ads, GA4, or Floodlight that wants compliant tag gating |
Vendor list updates can silently break consent coverage
What's Next?
TCF and Consent Mode are both pieces of the same underlying discipline — treating consent as structured, machine-readable state rather than a UI afterthought — which becomes even more important as first-party data strategies lean harder on every signal a user has actually agreed to share.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.