IAB TCF 2.2 Implementation Guide for Publishers

1. What is TCF 2.2?

The IAB Europe Transparency and Consent Framework (TCF) is the digital advertising industry's standardized mechanism for communicating user consent and legal basis preferences across the programmatic supply chain. TCF 2.2, released in May 2023, is the current version and represents a significant evolution from its predecessors.

TCF 2.2 serves three critical functions in the programmatic ecosystem:

• Transparency: It provides a standardized way for publishers to inform users about which vendors process their data and for what purposes, fulfilling GDPR's transparency requirements.
• Consent capture: It enables users to grant or withhold consent for specific purposes and specific vendors, creating a granular, auditable consent record.
• Signal propagation: It encodes consent and legitimate interest signals into a compact TC String that travels through the bid stream, allowing every downstream vendor to know exactly what the user has consented to.

For publishers operating in the EU/EEA, TCF 2.2 is effectively the industry standard for GDPR compliance in programmatic advertising. Most SSPs, ad exchanges, and DSPs require a valid TCF consent string before processing EU user data for personalized advertising.

2. Step-by-Step CMP Integration

A Consent Management Platform (CMP) is the user-facing interface that collects, stores, and communicates consent preferences. Here is how to integrate a TCF 2.2-compliant CMP on your publisher properties:

Step 1: Select a Certified CMP

Choose a CMP that is registered with IAB Europe and listed in the official CMP registry. Popular certified CMPs include OneTrust, Cookiebot (by Usercentrics), Quantcast Choice, Sourcepoint, and Usercentrics. Verify that the CMP supports TCF v2.2 specifically — some older CMPs only support v2.0.

Step 2: Configure the Vendor List

The CMP must be configured with the IAB's Global Vendor List (GVL) or a publisher-specific vendor list. Each vendor entry includes the vendor's name, purposes they process data for, legal basis they rely on, and cookie expiry information. You should audit this list and only include vendors you actually work with — presenting users with hundreds of unfamiliar vendors reduces consent rates and creates regulatory risk.

Step 3: Configure Purposes and Legal Basis

Decide which of the 12 TCF purposes you want to present to users and which legal basis (consent or legitimate interest) to use for each. Most publishers require consent for Purposes 1–4 (device storage, personalization, ad selection/delivery/measurement) and may rely on legitimate interest for Purposes 7–11 (measurement, social interaction, market research).

Step 4: Deploy the CMP Script

Deploy the CMP's JavaScript tag in the <head> of every page, before any ad tags or tracking scripts load. The CMP must have the opportunity to block cookies and trackers until the user makes a consent choice. This is typically implemented using a blocking or "prior consent" mode where the CMP script intercepts all script execution until consent is resolved.

Step 5: Wire Up the CMP API

Integrate with the CMP's __tcfapi JavaScript function, which is the TCF-standardized interface for querying consent state. Your ad tags and scripts should call __tcfapi('getTCData', 2, callback) to retrieve the current consent state before firing tracking pixels or making ad requests.

Step 6: Test End-to-End

Verify that the consent string is correctly generated, passed through your SSP to the ad exchange, and visible in bid requests received by DSPs. Test all user choices: accept all, reject all, granular purpose-level selections, and vendor-level selections.

3. Consent String Structure

The TC String (Transparency and Consent String) is a base64url-encoded binary string that encodes the user's consent and legitimate interest preferences. The string is compact enough to be included in OpenRTB bid requests (typically in the user.ext.consent field) and HTTP cookies.

Core Segment Structure

The TC String consists of a core segment and optional disclosed vendor/publisher segments:

The string uses two encoding methods for variable-length fields: bitfield (one bit per vendor, suitable for dense vendor selections) and range (start/end pairs, more efficient for sparse selections). The encoder automatically selects the more compact representation.

4. Vendor List Management

The Global Vendor List (GVL) is a JSON file maintained by IAB Europe that contains all registered vendors participating in the TCF. It is updated weekly and hosted at vendor-list.consensu.org.

Key GVL Components

• Vendor entry: Each vendor has a unique ID, name, privacy policy URL, declared purposes, declared legal bases, data retention periods, and cookie information (max age, domain, and whether the cookie is first-party or third-party).
• Purpose definitions: The GVL references the standard TCF purposes (1–12) and special purposes (1–2). Special purposes (security/fraud prevention and technical delivery) do not require user consent as they are always legitimate.
• Features and special features: Features (1–3) describe technical capabilities (matching to offline data, linking devices). Special features (1–2) involve precise geolocation and active device scanning, which require explicit consent.
• Stacks: Pre-defined bundles of purposes and features that simplify the consent UI by grouping related processing activities into a single disclosure element.

Publisher-Specific Vendor Lists

Publishers can create a restricted vendor list that only includes vendors they actually work with. This is strongly recommended: presenting 800+ vendors from the full GVL overwhelms users and degrades consent rates. A curated list of 30–80 vendors relevant to the publisher's ad stack provides better user experience and higher-quality consent.

5. Purpose Definitions & Legal Basis

TCF 2.2 defines 12 standard purposes plus 2 special purposes. Understanding each purpose is essential for correct CMP configuration:

6. TCF v2.0 vs v2.2 Changes

TCF 2.2 introduced several important changes from the previous v2.0 specification. Publishers migrating or building new implementations should understand these differences:

• Recognition of legitimate interest objections: TCF 2.2 explicitly separates the right to object to legitimate interest processing from consent withdrawal. Users can now object to legitimate interest-based processing for specific vendors or purposes independently.
• Enhanced purpose descriptions: Purpose descriptions were rewritten in plain language to improve user comprehension. CMP interfaces must display these updated descriptions.
• Vendor data retention periods: Vendors must now declare specific data retention periods for each purpose, and CMPs must display this information to users.
• Removal of legitimate interest as default for Purposes 2–6: TCF 2.2 removed the ability for vendors to declare legitimate interest as the default legal basis for Purposes 2 through 6 without publisher override. Publishers must explicitly configure the legal basis for each purpose.
• Updated policy version number: The TCF Policy Version field changed from 3 (v2.0) to 4 (v2.2), allowing downstream systems to identify which specification the consent string was generated under.
• Improved GVL structure: The Global Vendor List format was updated to include data retention periods, data declaration URLs, and environment information for each vendor.

7. Validation & Testing

Before deploying a TCF implementation to production, validate the following:

1. Consent string generation: Use the IAB's official TC String decoder tool to verify that generated strings are well-formed and decode to the expected consent values.
2. CMP API responses: Verify that __tcfapi calls return correct TCData objects with proper event status, consent signals, and vendor consent vectors.
3. Bid request propagation: Confirm that the TC String appears correctly in OpenRTB bid requests as user.ext.consent and that the regs.ext.gdpr flag is set to 1 for EU users.
4. Cookie persistence: Verify that the euconsent-v2 cookie is set correctly, persists across sessions, and updates when the user changes preferences.
5. Vendor filtering: Test that vendors without consent are correctly excluded from ad processing on the demand side.
6. Withdrawal handling: Verify that consent withdrawal is captured, the cookie is updated, and the new signal propagates to all downstream partners within the required timeframe.
7. Geo-detection: Confirm that the CMP only displays for EU/EEA users and that non-EU users are served appropriate regional consent interfaces (or none, if not required).
8. Mobile testing: Test CMP behavior on mobile web and in-app environments (using the CMP SDK for mobile), ensuring consent signals are correctly stored and passed in mobile bid requests.

8. Common Implementation Mistakes

Based on industry audits and regulatory enforcement actions, these are the most frequent TCF implementation errors:

1. Loading ads before consent resolution: Firing ad tags or tracking pixels before the user has made a consent choice. This is a GDPR violation and renders the entire consent string retroactive (invalid). Always implement blocking mode.
2. Pre-checked consent boxes: Presenting purposes or vendors with consent pre-ticked. GDPR requires affirmative action; pre-checked boxes constitute invalid consent.
3. Cookie walls without alternatives: Blocking access to content unless users consent to all purposes. The EDPB has clarified that cookie walls are generally non-compliant unless the publisher offers a genuine, equivalent alternative (e.g., a paid ad-free subscription).
4. Incomplete vendor disclosure: Failing to list all vendors that process user data, or listing vendors with incorrect purpose declarations. The consent obtained is only valid for disclosed processing.
5. Not propagating consent to server-side: The CMP captures consent client-side but the ad server or header bidding wrapper doesn't read the consent string, resulting in ad requests being sent without TCF signals.
6. Ignoring consent withdrawal: The CMP captures initial consent but does not provide an easily accessible mechanism for users to change their preferences later. GDPR requires that withdrawal be as easy as giving consent.
7. Stale vendor list: Using an outdated GVL version where vendor IDs don't match the current registry. DSPs validate vendor consent against the latest GVL, and mismatches cause valid consent to be ignored.
8. Soft opt-out dark patterns: Making the "reject all" button less prominent than "accept all," using misleading colors, or burying granular controls behind multiple clicks. Regulators have increasingly penalized these practices.

Implementing TCF 2.2 correctly is a technical and legal exercise that requires collaboration between your engineering team, your CMP provider, your ad operations team, and your legal counsel. Done well, it creates a transparent, compliant, and revenue-optimized consent infrastructure that supports the full programmatic ecosystem. Done poorly, it exposes the publisher to regulatory enforcement, reduced demand access, and reputational damage.