IAB Europe Transparency and Consent Framework Implementation Guidelines
This document provides technical implementation guidelines related to the IAB Europe Transparency and Consent Framework (TCF) v2 technical specs. The IAB Tech Lab GDPR Technical Working Group has collaborated on the following implementation guidelines, and will continue to produce resources supporting industry adoption of the Framework. The intended audience of this document includes product and engineering teams who are building technology based on this framework, and who are looking for guidance on implementation strategies such as questions to ask your platform partners or avoiding common pitfalls.
Policy FAQ, webinars, and other resources are available at https://www.iabeurope.eu/tcf
Do I need to read the Policy?
What changed in v2?
Within the Transparency and Consent String (TC String)
Within the Global Vendor List (GVL) Format
Within the Consent Management Platform API
What is legitimate interest, and what’s new for vendor registration?
Is v2 backwards compatible?
How do I evaluate the details provided in the TC String?
How should I handle multiple signals with different information?
What is OOB?
Are cookies required for working with the CMP API?
What is the long-term plan for consent storage?
Can I also use the API for CCPA or other laws?
Will these FAQ be updated?
How can I learn more?
The Transparency and Consent Framework (TCF) was created to help all parties who display and manage digital advertising and develop targeted content comply with the European Union’s General Data Protection Regulation (GDPR) and ePrivacy Directive (ePD) when processing personal data and/or accessing and/or storing information on a user’s device.
It allows publishers and website operators to communicate to vendors, in a standardized way, what preferences users have expressed when it comes to their personal data. A vendor is a company that participates in the delivery of digital advertising within a publisher’s website, app, or other digital content, that either accesses an end user’s device or browser or processes personal data about end users visiting the publishers content.
The TCF was first introduced in April 2018. This document refers to version 2 of the TCF, announced in August 2019, which introduces significant changes and is not backward-compatible with the earlier version.
The communication between publishers and vendors must pass through a Consent Management Platform (CMP). A CMP can be operated by anyone, as long as the entity that operates it has completed registration on the CMP list and is approved by IAB Europe . A list of all approved CMPs is available here.
CMPs centralise and manage transparency for and consent and objections of the end users, acting as an intermediary between the Publisher, end user and vendors,using information distributed via the Global Vendor List (GVL), which contains the updated list of vendors adhering to the framework. Please refer to the Policy for complete definition of a CMP. Only CMPs can write and read the Transparency and Consent string, where consent is stored. Their role is to make this information available to vendors within the technical specifications that the framework states.
When configuring their CMP, publishers can make a number of decisions:
- Consent can be shared with all other publishers adhering to the framework or kept local to the specific publisher;
- A number of restrictions can be applied, including allowing only a selected list of vendors to process data through their properties. A current list of vendors adhering to the framework can be found here.
Any party considering adoption of the TCF must read and follow the TCF Policies, outlined in the IAB Europe Transparency & Consent Framework Policies. Correct implementation of the framework is impossible without following the requirements in the TCF Policy.
Who should read this document?
Publishers, Vendors (DMP, AdServer, Advertisers, …) and registered CMPs who want to work within the TCF can use this document as guidance to implement the technology to support their efforts. This document addresses common (technical) questions and makes it easier for companies to understand the coherences of the TCF policy and technical specifications.
How can I submit my questions?
You can learn more about IAB Tech Lab support of the TCF and involvement with IAB Europe at the following URL:
Yes, the technical specifications for the TC String and CMP API were developed to support policies outlined in the Transparency and Consent Framework (TCF) Policies for version 2. Implementing the technology requires adherence to these policies.
If you have not yet read tech specs or policy, you can access these documents here:
- IAB Europe Transparency and Consent Framework Policies
- Transparency and Consent String, Version 2
- Consent Management Platform API, Version 2
All definitions in the implementation guidelines should reflect definitions provided in the Policy.
Version 2 of the policy and technical specification marks significant updates to better support GDPR legislation and enhance the user experience, while remaining flexible to account for unique scenarios within the framework.
Changes across the Framework are listed below and grouped according to supporting documentation for: the TC String, the Global Vendor List, and the CMP API.
- Special jurisdiction handling using publisher country code
- Publisher TC String for publisher legal basis establishment*
- Publisher restrictions added
- Legitimate interest establishment signals added
- “Right to object” to legitimate interests support added
- Out-of-Band (OOB) legal basis support
- Created Allowed Vendors TC String segment
- Created Disclosed Vendors TC String segment
- Enhanced TC String Encoding
- TC String segmentation (core, publisher, oob segments)
- Revised Macro support
- Text revisions based on requests for clarification/consistency
- Includes recent policy updates
- Better wording to distinguish between “policy version” and “GVL version”
Within the Consent Management Platform API
- Event Listeners, Support for CMP status change, such as when a user makes an active choice, and a new TC string is generated
- New parameter order
- New function signature name
- Inclusion of passing “version” argument
- Addition of in-app “command” for in-app specific values
- Updates to support special jurisdiction, handling Out-of-Band (OOB) , and publisher restrictions
Under the GDPR, a legal basis is required for processing a user’s data. While consent is the most common legal basis for processing a user’s data, legitimate interest is another legal basis that a vendor may use. For more information legitimate interest and when it can be used as a legal basis, please visit gdpr-info.eu where the regulation is posted. Chapter 2, article 6, describes legal bases under the GDPR.
No. The changes in v2 are substantial enough that a completely new implementation is required. With the list of features, purposes, stacks, new structure for the TC String, and a number of other changes, none of the updates map to anything in previous versions. After an initial transition phase in v2 adoption, older versions will be deprecated.
The TC String includes four (4) segments of information: the core string, publisher restrictions, publisher-approved vendors, and out-of-band (OOB) signaling. The technical specs describing the TC String provide details on specific information provided in each segment. These details may change from the start of the transaction to the end of the transaction. Vendors must evaluate the four segments of a string as it relates to a given transaction, determine the intent of the information provided, and proceed accordingly.
Sometimes two or more TC Strings might contain different preferences for different vendors. For example, one String includes consent signals for vendors 1, 2, and 3. Later, the user is asked for consent on vendors 3, 4, and 5, but rejects all three. In this example, the most recent signal received for vendor 3 is that of no consent and should be recorded as such despite previous signals. However, we cannot anticipate and provide guidance for all scenarios. Vendors should update the TC String, where applicable, with details that reflect the intent of the user and meets the requirements of the TCF.
OOB is an abbreviation for Out-of-Band legal basis and represents a signal that transparency & consent was achieved for a vendor outside of the TCF, which is an in-band establishment. Publishers can choose whether to support OOB or not, and if they do, they may provide a list of approved vendors allowed to claim OOB. Look for details outlined in documentation for the TC String.
A Consent Management Platform (CMP) is operated by a controller and is used to manage transparency and consent (TC) preferences signaled by the end user. The CMP installs a user dialogue on the publisher’s digital properties to capture and manage TC information from a user. This installed user dialogue software also surfaces TC information to vendor technologies operating as part of the publisher’s digital property and supply chain. The CMP acts as an intermediary between the publisher, end user, and vendors.
Please refer to TCF Policy for a complete definition of a CMP. A registered CMP is required if the publisher or website operator wishes to work under the Policies of the TCF.
The publisher may implement a CMP in one of two ways:
- Build: Develop an in-house CMP that meets the technical requirements specified by IAB Europe and register as an official CMP using this form.
- Outsource: Rely on the service of a CMP registered with IAB Europe and listed here as an official CMP.
The goal of pubvendors.json was to enable publisher control over their vendor relationships and data purposes but was ultimately found to be an incomplete and error-prone solution.
In v2 of the TC String, a segment of information enables publishers to define restrictions. Another segment defines their vendor relationships in a list of allowed vendors. These publisher controls replace the pubvendors.json solutions and is to be deprecated after a transition phase for v2 implementation.
Publishers should ask their partners (advertising vendors, DMPs, analytics vendors, etc.) to register on the Global Vendor List (GVL), if not already registered. The Global Vendor List is maintained with current registered vendors here.
Vendors must support the withdrawal of consent. Since consent is transmitted from publisher or CMPs to partners and vendors on each request, the publisher or CMP should provide a mechanism for users to withdraw consent. This mechanism may be as simple as collecting consent at each user session, or providing an option that enables the user to withdraw consent later. The UI for withdrawing consent should be the same as the UI by which consent was given.
For vendors or media buyers registered in the Global Vendor List, these guidelines help you understand how to check for consent, in accordance with the Framework.
- Vendors should be listed as vendor if they want to read or process user data in compliance with TCFor store and/or access information on a user’s device in compliance with the TCF. Any company is recommended tobe listed as a vendor in the Global Vendor List if they want to process personal data based on TCF signals.
- Vendors should check consent for users from the EEA (EU + Norway + Island + Liechtenstein).
- Vendors should be able to identify traffic that falls under the GDPR.
The OpenRTB GDPR Advisory should be used to communicate user consent. Vendors can use the two extension fields, GDPR and CONSENT, in OpenRTB to determine action.
If an impression is received server side (through openRTB for example), you should read the information from the TC data payload. For openRTB, technical specifications were updated to provide information on where and how the information is passed. For other non-standard server side delivery, clarify with the partner on how the TC data payload is passed.
When the impression is received client side (redirect, prebid, etc.), leverage the CMP to request and read the TC data. This information can be collected whether you are in the top parent page (using the __tcfapi method) or from an iframe (using postMessage method as defined by the CMP API technical specifications).
For any server side call, if using openRTB, the consent payload should be sent accordingly to the openRTB specs. For any client side call, once the consent payload has been obtained leveraging the CMP, you should pass it in the ad call using the URL-passing macro solution detailed in documentation for the TC String.
According to policies of the Transparency and Consent Framework, a vendor may choose not to transmit data to another vendor for any reason, but a vendor must not transmit data to another vendor without a justified basis for relying on that vendor’s legal basis for processing the personal data. If a vendor has or obtains personal data and has no legal basis for the access to and processing of that data, the vendor should quickly cease collection and storage of the data and refrain from passing the data on to other parties, even if those parties have a legal basis.
In addition to the vendor guidelines, agencies may want to consider the following details:
- If you're handling any personal data, register as a vendor in the Global Vendor List.
- Become familiar with the capabilities of your DSP partner(s) so that you only work with personal data when you have a legal basis to do so. Some of the following questions may help you get started:
- Are your DSPs working with the TCF?
- Are your DSPs reading the TC String passed through OpenRTB?
- How are your DSP partners communicating transparency and consent and are they passing personal data only when there is a legal basis? How do they track these practices?
In addition to vendor guidelines, DSPs should consider the following points:
- If you're handling any personal data, register as a vendor in the Global Vendor List.
- Support ingesting transparency and consent signals on openRTB bid requests.
- Decide how to handle bidding based on these signals, ensuring that processing of user data only occurs when there is a legal basis.
DMP in this document refers to enterprise software that can be used by publishers, marketers, agencies and third-party vendors to centralize marketing information associated with pseudonymous IDs. To take advantage of the Framework, DMPs should be registered to the Global Vendor List. For simplicity sake, we will assume the same guidelines apply for both buy-side focused and sell-side focused DMPs. While oriented towards different buyers, buy-side and sell-side DMPs centralize this data, enable forecasting and reporting, and often enable syndication to take-action systems (e.g., Publishers, DSPs, DCO vendors, and Site Optimization/Personalization vendors).
- Many requests for ad serving will include the TC String.
- Some requests will be sent to vendors without a TC String, such as: publishers not implementing a CMP, server-initiated server-to-server data transfers such as syndication or CRM onboarding, and consumer opt-outs from centralized privacy pages such as AboutAds.info.
- Tag management containers should integrate CMP code. In addition to enriching ad calls, a CMP should also support calling a third-party tag management container that will handle robust tag logic already implemented on behalf of the publisher.
- Syndication for buy-side DMPs centralizes marketing information associated with pseudonymous IDs, which enables marketers to improve their media planning, syndication and cross-vendor reporting.
- Syndication of audience segments is often initiated by a marketer ruleset to send information from the DMP to take-action systems (DSP, DCO, Site Optimization, etc.).
- For GDPR purposes, the DMP maintains a server-side consent store that maintains the most recent consent state associated with its pseudonymous IDs. This server-side store is also useful for maintaining the audit log of signals received.
- Because the TC String maintains the current consent state for all vendors, the DMP can send only pseudonymous IDs with consent state=1 to recipient vendors.
This section outlines implementation guidelines for CMPs to be compliant with the TCF technical specification when collecting, storing and sharing user consent.
Register to be on the CMP list: https://register.consensu.org/ This step is required to be a TCF recognised CMP trusted by vendors receiving the consents that you collect. Upon registration a CMP is assigned an ID, which is passed with each request, and granted access to the “consensu.org” domain for accessing and modifying the global consent cookie.
The TCF defines a set of common purposes and features that vendors can act on. Vendors are responsible for providing up-to-date information on the purposes they support and the legal basis under which they wish to operate these purposes. This information is captured in the Global Vendor List (GVL).
For a given publisher, a CMP must (at least) collect the user consent for all purposes and vendors declared by the publisher. With the publisher agreement, a CMP can also collect consent for all purposes and vendors in the GVL.
A range of requirements on how consent must be presented, collected and stored can be found in the TCF policy document.
The TCF defines standard APIs and formats for communicating between CMPs collecting consent from end users and vendors embedded on a website or in a mobile application. This API provides a unified interface for seamless interaction between the parties in the advertising industry.
As a CMP, you will need to:
- Collect consent from the end user that is compliant with the TCF Technical Specifications and Policy.
- Generate an encoded data string, the TC String, containing the set of preferences expressed by the user
- Share the TC String with vendors through the available APIs.
Depending on the publisher preference and on the policy requirements, consent can be stored either locally or globally. When storing the consent globally, the consent will be stored in a shared cookie with the “TC String” format on the “consensu.org” domain.
CMPs are free to also store consent separately and with a different format if they need to (first-party cookies, long term proof of consent storage, etc.) provided that – if consent is being stored globally – they keep the shared cookie up-to-date with their local changes.
For long-term storage, the following methods are common across CMPs:
|Cookies||Easy to use and cheap. Fast and provide a good user experience.||Short-lived. Cannot be used as proof of consent. Third-party cookies might be blocked by browsers so web-wide consent can be hard to implement|
|Mobile: internal data storage / shared preferences||Easy to use and cheap. Fast and provide a good user experience||Cannot be used as proof of consent. Cannot be shared across apps so device-wide consent can be hard to achieve|
You’ll usually want to go with a combination of server-side storage – for being able to store consent for a long time and share it across websites/apps – and a client-side storage like cookies or shared preferences – for a local fast-to-access cache.
Signals sent through the IAB Europe framework should only indicate what the user status is at the time of the signal creation and nothing else. While the CMP should also enable users to withdraw consent, the minimum requirement is to record the user's preference at the time the signal is created. Certain GDPR policy, such as portability and the right to be forgotten, is not covered in the IAB Europe TCF. CMPs and vendors should address other GDPR rights outside the TCF separately and on their own.
Please refer to the policies for the minimal information / functionality that needs to be shown on the first screen of the UI and the information that must be present on second/additional layers of the UI.
At a high level, all vendors need to query the CMP on the page to get access to consent information in the TC String, parse the consent data in the String, and gate usage of user data based on user consent. This lookup needs to be executed as close as possible to using the user data so that the latest value of consent is used.
- GVL registration: Before you can work with a CMP, you need to be registered as a vendor. You can sign up to be added to the GVL on IAB Europe's registration site.
- Query CMP: Once added, you can query the CMP for consent information. Details about how to query the CMP are provided in the documentation for CMP API v2. Initiate consent query before applying workflow to reduce latency.
- Determine data usage: Parse the TC String for details on whether GDPR applies and the user's consent status for allowing the use of user's data. This consent can differ by purpose and by vendor.
What if I don’t receive the TC string?
Unfortunately, if transparency or consent information is unavailable, you may not be able to process the user's data.
Does the policy make a difference between functional and marketing cookies? Do I need consent for functional cookies?
You may or may not depending on whether the scenario is covered by special features or special purposes. Review the policy documentation to learn more.
Yes, v2 depends on the consent data being stored in cookies.
Discussion on future iterations have led to proposals about storage mechanisms like a central registry that stores user IDs and their associated information. At that time the implementation could be updated to retrieve data from a defined source without having to change the interface. Until such mechanism exist, cookies are required for working with the CMP API.
A third-party cookie isn’t a long-term solution to auditable, permanent, user-keyed consent storage, and doesn’t work with browsers that block 3rd-party cookies or mobile apps. CMP’s should work towards standardizing a more future-looking server-side consent retrieval mechanism so that cookies might be used as more of a “consent caching” in the future.
At this time, the IAB Europe Transparency and Consent Framework is designed for compliance with GDPR. The CMP API was designed to only support a special use case of the GDPR, which involves the use of user data in the context of digital advertising. Consult your local IAB or the IAB Tech Lab to learn more about other ongoing projects for privacy tool development.
A “cookie workshop” page is available at http://gdpr-demo.labs.quantcast.com/user-examples/cookie-workshop.html. This little activity was built to support v1 and has not yet been updated with details for v2.
Yes, these guidelines will be updated as questions arise. A wiki with more dynamic content has been proposed, but timelines have not yet been determined.
Join the working group, or stay tuned for build out of a wiki to support dynamic responses to questions from implementers.