IAB TCF v2.2 implementation with OneTrust
What it is
The IAB Transparency & Consent Framework (TCF) v2.2 is the standardized way programmatic advertising vendors read a visitor's consent choices without each one needing a direct integration with your CMP. OneTrust's TCF implementation generates the encoded euconsent-v2 consent string and exposes the __tcfapi command-queue interface that IAB Global Vendor List-registered vendors read from - the mechanism that turns one banner's choices into a signal dozens of ad-tech vendors can all consume the same way.
When you need it
Your site runs programmatic or header-bidding advertising and the vendors involved are IAB Global Vendor List participants.
You need to demonstrate TCF compliance specifically - distinct from general GDPR consent - as a condition of continuing to serve ads through certain exchanges or SSPs.
An ad-tech vendor has reported they aren't receiving a valid consent signal from your CMP, and you need to isolate whether TCF is actually configured and running.
How to implement it
- 1
Confirm TCF support is actually enabled in your configuration
Not every OneTrust configuration ships the __tcfapi stub by default - a site can run a fully functional cookie banner with TCF switched off entirely. See this site's own tcfapi-undefined QA page for the most common symptom of this being missed.
- 2
Configure the Global Vendor List scope to match your actual ad vendors
An incomplete vendor list means those specific vendors' scripts won't see a valid signal even with TCF otherwise working correctly for everyone else.
- 3
Confirm purposes and legal bases match what your ad partners actually require
Some vendors require consent, specifically, rather than legitimate interest, for certain purposes - a mismatch here is a common source of "vendor reports no consent" complaints even when TCF is technically running.
- 4
Verify the stub loads before any ad-tech script that depends on it
Use the same synchronous-placement discipline as any other consent-default script - a script that checks for __tcfapi before the stub has executed will see it as missing, the same failure mode covered on this site's tcfapi QA page.
- 5
Re-verify after any change to the vendor list or purpose mapping
It's easy to update one and not re-check the other - a stale purpose mapping against an updated vendor list is a gap that won't show up until a specific vendor flags it.
How to verify it worked
In the browser console, call window.__tcfapi('ping', 2, console.log) and confirm it returns a valid PingReturn-shaped object rather than being undefined.
Decode the resulting euconsent-v2 string with the IAB's own reference decoder and confirm the purposes and vendors match what the banner UI actually showed and what was actually chosen.
Check with at least one real ad-tech vendor's own debug or testing tool (most major SSPs and DSPs publish one) that they report receiving a valid, current consent string rather than a stale or missing one.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.