IAB Europe Transparency and Consent Framework Implementation Guidelines
|Last update||September 2021|
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 happened to Global Scope and Out of Band?
How do I find the TC String?
How do I send the TC string?
How to determine legal bases from the TC String?
How to determine if data may be transmited?
How does the TC String apply to non-OpenRTB situations?
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
- Enhanced TC String Encoding
- TC String segmentation (core, publisher)
- 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”
- 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, 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 returned by the CMP API can include (2) segments of information : the core string and the publisher TC segment. 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.
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.
The TCF Policy previously allowed legal bases in the Framework to be established with global scope, which means a legal basis is not only applicable on the service or group of services (service-specific and group-specific scopes) where it is obtained and managed, but all services implementing global scope preferences. In the context of global scope, TC Strings were stored in a 3rd party cookie associated with the “consensu.org” domain that enabled Consent Management Providers (CMPs) to read the “TC strings from their subdomains
[cmp-name].mgr.consensu.org across different services. Deprecation of global-scope support was announced on June 22nd 2021. Alongside the deprecation of global scope, support for Out-of-Band (OOB) - which refers to instances where a legal basis has not been established using the TCF in a global-scope context - was also deprecated. Since Sept 1st 2021, TC strings established with global-scope are considered invalid.
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 determine whether you have the necessary legal bases to process a user's personal data for the purposes you've disclosed in the GVL, based on the information contained in the TC String.
- In order to read or process user data in compliance with the TCF or store and/or access information on a user’s device in compliance with the TCF, vendors must be registered in the Global Vendor List.
- 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 according to the openRTB specs.
For any client side call, once the consent payload has been obtained leveraging the CMP, you can validate that it reflects user-intentful consent by checking the status of certain fields. For example:
- the field
- the field
The status of these two fields as indicated above show that the CMP has been loaded and the user has engaged. After validating the TC data payload is suitable for your case, you should pass it in the ad call using the URL-passing macro solution detailed in documentation for the TC String.
In order to determine if they have the necessary legal basis to process a user’s personal data for a specific purpose registered in the GVL, vendors must follow all relevant signals from the TC String in accordance with what they disclose in the GVL. The relevant signals in the TC string are the GVL version, the publisher restrictions signal, the purpose legal basis signal and the vendor legal basis signal.
Prior to processing a user’s personal data for a purpose registered in the GVL, for each purpose vendors must:
Evaluate publisher restrictions prior to any other signal:
- Check if the publisher completely disallowed processing based on this purpose using a purpose restriction
- Check if the publisher restricted the applicable legal basis for this purpose using a legal basis restriction (e.g. the publisher only allows "consent" as legal basis for this purpose, or only allows "legitimate interest" as legal basis for this purpose):
- In the absence of a legal basis restriction, vendors must apply their default legal basis
- If there is a legal basis restriction vendors must apply the publisher defined legal basis, which is only allowed if that purpose is either declared with the allowed legal basis as default legal basis, or if that purpose was declared as flexible
In case the publisher disallows processing or in case the acceptable legal basis defined by the publisher in the restrictions is not registered by the vendor as default purpose nor is the vendor declaring that purpose as flexible, the vendor may not process personal data based on that purpose. For example, if a vendor registered legitimate interest as legal basis for a purpose and is not declaring legal basis for that purpose as flexible, it may not process in the presence of a legal basis restriction that requires consent.
Evaluate purpose and vendor legal basis
After determining the applicable legal basis, vendors must then check:
- the presence of a purpose legal basis signal for each purpose
- the presence of a vendor legal basis signal
Only if both signals are positive for the applicable legal basis in the TC String may the vendor process for that purpose.
According to the 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. To determine if a vendor has at least one legal basis to process a user’s personal data see "How to determine legal bases from the TC String?".
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. Since September 1st 2021, new registering CMPs are no longer granted access to the “consensu.org” domain. CMPs who have been registered with the TCF before September 1st 2021 can continue to host their tags at
Note: it is the intention of the managing organisation at some point in the future to retire "consensu.org".
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.
In version 2 of the TCF Specifications, the storage mechanism used for service-specific and group-specific TC Strings is up to a CMP, including any non-cookie storage mechanism.
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.
In order to reduce the size of the TC string, CMPs are advised to store/provide publisher restrictions only when necessary to reflect the publisher's choice to restrict a vendor's processing of personal data. In terms of reflecting a publisher’s choice:
In case a vendor has not been disclosed to the user via the CMP UI, there is no need to store restrictions for that vendor in the TC String. Given the vendor was not disclosed both vendor consent and vendor legitimate interest signals in the TC String can be left undefined which suffices to signal that the vendor may not process personal data.
Purpose restrictions that disallow a vendor from processing personal data for a specific purpose only need to be stored in case the vendor was disclosed by the CMP (reflecting the restriction in the UI) and registered for that purpose in the GVL.
Legal Basis restrictions are only needed in situations where the vendor was disclosed by the CMP (reflecting the restriction in the UI) and is declaring flexibility in the GVL for the corresponding purpose, meaning that:
- The vendor registered a purpose as legitimate interest (default legal basis), but also registered this purpose as flexible (i.e. also accepts consent as a legal basis). In this case a "require consent" restriction is needed to signal that the vendor may only process using consent as legal basis.
- The vendor registered a purpose as consent (default legal basis), but also registered this purpose as flexible (i.e. also accepts legitimate interest as a legal basis). In this case a "require legitimate interest" restriction is needed to signal that the vendor may only process using legitimate interest as legal basis.
Note that the above does not preclude the use of efficient encoding/decoding schemes in certain scenarios. For example, in cases where a publisher wants to restrict a purpose for all vendors to consent, it might be more efficient to encode a small number of range restriction segments using a specific encoding scheme.
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.
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 v2 consent string encoder/decoder can be found here: https://iabtcf.com/#/ as well as links to further implementation libraries.
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.