This document provides technical implementation guidelines related to the IAB Europe Transparency and Consent Framework v1.1 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 http://advertisingconsent.eu/#resources.
- Publisher guidelines
- Buyer guidelines
- Agency guidelines
- DSP guidelines
- DMP guidelines
- Consent Management Provider guidelines
- CMP-User guidelines (Vendors using CMPs)
- Other Common Questions
What is a Consent Management Provider (CMP) and why do I (as a Publisher) need one?
A Consent Management Provider can read and/or set the user?s consent status for the vendors chosen by a website operator (either Publisher-specific through a first-party cookie or global through a third-party cookie). A CMP for the purpose of this document is not necessarily synonymous with a Content Management Platform which is a company that surfaces the content and interface to a user (although a Content Management Platform could provide the Consent functionality).
In order for downstream partners such as a DSP, SSP or DMP to continue working properly where the GDPR applies on a site for EU users and be in compliance with the GDPR, they will rely on publishers to provide transparency and gain user?s consent. This consent will then be passed via a consent string within the CMP. This string will only provide consent information about vendors who have registered with the IAB Europe and are on the Global Vendor List.
There are 2 ways in which the publisher can ensure there is an active CMP on their site.
1.Develop an in-house CMP that achieves the criteria below:
a. Matches the technical specifications outlined in CMP JS API v1.1
b. Register as a CMP with IAB Europe. To register,submit this form.
2.Implement a CMP on the registered list.
In the event you already have a CMP implemented and the company is not found on the IAB Europe?s registered list, it is the publisher?s responsibility to work with their provider to meet the criteria outlined in Option 1?s sub-bullets. Provided below is template language to help communication efforts with your preferred cookie consent vendor.
"We are currently in the process of ensuring compliance with the GDPR and ePrivacy Directive. In order for us to continue our current business practices, we will need an IAB Europe Registered Consent Management Provider. This CMP will allow us to manage consent on behalf of our downstream programmatic and data partners.
It?s my understanding you currently serve this function by being our cookie consent mechanism. In looking at the IAB Europe?s approved CMP list, I noticed you are not currently registered.
Can you please advise if there are plans to register your CMP with IAB Europe?"
Global Vendor List
Publishers should ask their partners to register on the Global Vendor List, if the partners are not already registered. Current Global Vendor List is available here.
Publisher Controls
Upcoming Framework releases will provide additional publisher controls. More details to follow
Other Considerations
Publishers may have additional GDPR requirements that are handled outside of the Transparency and Consent framework. The "withdrawal of consent" requires to not process data *going forward on the basis of that consent. *
Withdrawal of consent publisher considerations
-
Since consent is transmitted via publisher and CMP to monetization partners/ vendors on each request - it is the responsibility of the publisher/CMP to provide a mechanism for users to withdraw consent.
-
User interface for consent must manage consent withdrawal.
-
The mechanism/UI for withdrawing consent should be the same as the mechanism/UI by which consent was given to begin with.
-
It may likely be the case that publishers (as many EU pubs do with cookies today) gather consent at each user session.
-
It is also possible that this UI/mechanism is provided by a 3rd party (CMP). (E.g. if the CMP provides the consent UI, then the CMP will provide the UI function for user to withdraw consent.)
Agency and DSP guidelines are further detailed in the following sections. These buyer guidelines help media buyers understand how to check for consent, in accordance with the Framework.
-
Buyers should be listed as vendor if they want to use user data in compliance with GDPR or store and/or access information on an user?s device in compliance with the ePrivacy Directive. Any European buyer should be listed as a vendor in the Global Vendor List.
-
Buyers should check consent for European users.
-
Buyer should be able to identify traffic that falls under the GDPR.
The OpenRTB GDPR Advisory should be used to communicate user consent. Buyers can use these two extension fields in OpenRTB to determine action.
GDPR- if 0 then no gdpr restriction or guideline is applied
If missing then you may use user IP address to identify if user belongs to EU/EEA region. If the IP address indicates the request is coming from part of the EU/EEA then GDPR guidelines and restriction should be assumed and the consent string must be parsed to take any action. Absence of a consent string should be interpreted as absence of consent.
If 1 then GDPR guidelines and restriction are applied and look at consent string to take any action
Consent- The binary encoding scheme that is passed in base64 url/web safe format known as (daisybit). The Buyer should use the consent array information to know if the user gave consent and for which vendors it gave consent and for which purposes.
-
If user does not give consent then don?t respond with any ad which uses user information and don?t store any user information and don?t access and/or store information (cookies, IDFA, AAID, fingerprints) on a user?s device.
-
If user gives consent then identify all vendors and related purpose who have received consent from the user. Buyer should also only use and store user data if user has given consent to the buyer and for the purposes for which the user has given consent. Buyer should only allow third party direct or redirect links who have received consent from user.
-
If no consent is given, you cannot use personal data, and may not have the right to use cookies. Each party is responsible to determine what that means for their business.If user consent shows that user has not given consent, then don?t respond with any ad which uses user data, don?t store any user information, and don?t access and/or store information (cookies, IDFA, AAID, fingerprints) on a user?s device.
The aforementioned fields describing gdpr and consent will be passed through a bid request as follows (as per the OpenRTB GDPR Advisory);
- OpenRTB version 2.2 - 2.5
Regs.ext.gdpr
User.ext.consent
- OpenRTB Version 2.0 - 2.1
User.ext.gdpr
User.ext.consent
- OpenRTB Version 3.0
Regs.gdpr
User.consent
-
If Buyer is not using OpenRTB then it should work with SSP to provide same information
-
Buyer can always respond with a Ad which is not using User data and not storing User data and for which no information is stored and/or accessed from the user?s device.
As a buyer, How do I find the consent string?
-
In case the impression is received server side (through openRTB for example), you should read the information from the consent payload. For openRTB, technical specifications were updated to provide information on where and how the information is passed. For other non standard server side, you should clarify with the partner how the consent payload will be passed.
-
In case the impression is received client side (redirect, prebid, etc.) you should read the information by leveraging CMP on page. This information can be collected whether you are in top parent page (using __cmp("getConsentData") method) or from an iframe (using postMessage method as defined by the CMp technical specifications)
How do I send the consent string?
-
For any server side call, if using openRTB, the consent payload should be sent accordingly to the openRTB specs (https://iabtechlab.com/wp-content/uploads/2018/02/OpenRTB_Advisory_GDPR_2018-02.pdf).
-
For any client side call, once the consent payload has been obtained leveraging the CMP, you should pass it in the ad call as per below documentation in "URL-based Consent Passing"
What do I do with the consent string as a buyer?
As per 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 having a 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 buyer guidelines above, agencies may want to consider the following points, relative to the Transparency and Consent Framework.
-
Understand if you're handling any personal data, and decide if you should register as a vendor with IAB.
-
European-based agencies should register on the Global Vendor List.
-
Register here: https://register.consensu.org/
-
-
Understand the capabilities of your DSP partner(s) to ensure you only get personal data when you have a legal basis to handle. Some of the following questions may be helpful to get conversations started:
-
Are your DSPs working with the Transparency and Consent Framework?
-
Are your DSPs reading the consent string passed through OpenRTB?
-
How are your DSP partners communicating consent and passing personal data only when there is a legal basis
-
In addition to the buyer guidelines above, DSPs should consider the following points, relative to the Transparency and Consent Framework.
-
Register with IAB to be on the global vendor list
- Register here: https://register.consensu.org/
-
Support ingesting consent signals on openrtb bid requests (details in the Buyer guidelines section)
-
Decide how to handle bidding based on these signals, ensuring that processing of user data only occurs when there is a legal basis
Although the term DMP is fluid, 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. 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).
How does the daisybit apply to non-OpenRTB situations?
-
Many requests for ad serving will be decorated with the consent daisybit.
-
However, other requests will be sent to vendors without a daisybit (e.g., from publishers not implementing the IAB Europe Consent Manager solution, 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.)
-
When a visitor visits a publisher, who has implemented a IAB Europe Consent Manager-compliant CMP, the first javascript that loads should be the CMP.js library.
-
The CMP will inspect the consumer?s cookie and on first instance display the enhanced notice and choices required by GDPR.
-
For a consumer that has previously visited the publisher the CMP within a recent period of time, which is publisher configurable, does not redisplay the enhanced notice and choices required by GDPR.
-
Tag Managers. Tag management containers should integrate this CMP code.
- In addition to enriching ad calls, 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. A primary purpose of a (buy-side) DMPs is to centralize marketing information associated with pseudonymous IDs to enable 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 (e.g., DSP, DCO, Site Optimization, etc.).
-
For GDPR purposes, the DMP will maintain a server-side consent store that maintains the most recent consent state associated with its pseudonymous IDs. This server-side consent store will also be useful for maintaining the necessary audit log of what signals it received, from which CMPs, from which domain, at which time for each pseudonymous ID.
-
Because the daisybit maintains the current consent state for all vendors, the DMP can send only pseudonymous ID with consent state=1 to recipient vendors.
-
This section outlines implementation guidelines for consent management platforms to be compliant with the IAB Europe 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 an official CMP trusted by vendors and third-parties receiving the consents that you collect. Upon registration a CMP is assigned an ID identifying it, which is to be passed with each request.It also gives access to the shared "consensu.org" domain for accessing and modifying the global cookie
Registration guide: http://advertisingconsent.eu/wp-content/uploads/2018/03/Registration_CMP_formatted_Development_v1.1_190318.pdf
- Collecting consent from users
What does the framework say?
The IAB Europe framework defines a set of common purposes and vendors for the ad tech industry. Vendors are responsible for providing up-to-date information on their purposes and privacy policies in a standardized format (the "Global vendor list"). The framework also defines general guidelines on collecting consent and sharing information with users that CMPs need to adhere to, in order to register with the IAB Europe.
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 collect consent for all purposes and vendors in the "Global vendor list".
How to collect consent under the IAB Europe Framework?
How each CMP collects consent, what their UI looks like, how it behaves, etc. are questions that are left to each CMP to decide provided that they meet the guidelines from the IAB Europe.
- Sharing consent with vendors: the IAB Europe Transparency and Consent framework
What does the framework say?
The IAB Europe Transparency and Consent framework defines standard APIs and formats for communicating between Consent Management Platforms (CMPs) collecting consents from end users and vendors embedded on a website or in a mobile application.
It provides a unified interface for a seamless integration where CMPs and vendors do not have to integrate manually with hundreds of partners.
What do I need to do as a CMP?
As a CMP, you will need to:
-
Collect consent from the end user in a way that is compliant with the IAB Europe recommendations and guidelines
-
Generate an encoded list of purposes and consents by vendor (aka the "daisy bit") from the GDPR consent information collected from the user
-
Share that daisy bit with vendors through the following APIs:
-
Websites: implement the CMP JS API specification
-
URL-based services and emails: implement the CMP API for URL-based services
-
Mobile app support to be released April 2018
-
- Storing Consent
What does the framework say?
The consent state of the user must be stored in a shared cookie with the "daisybit" format on the ?consensu.org? domain or a shared memory space in mobile apps to allow for device-wide consent sharing between CMPs.
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 they keep the shared cookie up-to-date with their local changes.
Where should a CMP store the user consent information for long-term storage?
The following methods of storing consent are common across CMPs:
| Method | Pros | Cons |
| 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 |
| Server-side storage | Long-lived Can be used as proof of consent | Can be slow (use cookies/local storage as client-side cache) Requires a long-term ID (cookie ID or email or similar user ID) |
| 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.
- Revoking consent and other user rights (proof, opt-out, portability, right to be forgotten, etc.)
What does the framework say?
The IAB Europe Framework only expresses user consent at a given point in time. A state change (for example, revoked consent) can be determined by comparing user consent records. The Framework does not deal with other GDPR rights like portability, the right to be forgotten, etc.
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. The CMPs and vendors should deal with other GDPR rights separately and on their own for now.
Future iterations of the framework might include specifications for other rights and operations.
This section outlines implementation guidelines for vendors that are outside the bidstream. At a high level, all vendors need to query the CMP on the page to get access to consent information, parse the consent data (DaisyBit) to determine consent 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 to ensure that the latest value of consent is used.
Register to be a Vendor:
- Sign up to be on Global Vendor List as outlined in the guide at http://advertisingconsent.eu/ and record your alloted vendor ID
CMP Lookup:
-
First check if a CMP is available, as outlined in the CMP Javascript API Specification v1.1.
-
To look up consent, make a call to CMP on the page to invoke the method getVendorConsents as outlined in the CMP Javascript API Specification v1.1. If your technology is delivered within an iFrame, make sure to use SafeFrames or postMessage to proxy calls as described in the CMP Javascript API Specification v1.1.
Note : getVendorConsents is designed for on-page javascript to determine their own consent. getConsentData is for vendors that need to complete consent string to pass-down to downstream vendors (like, SSP's and Ad Exchanges).
- If lookup times out or returns failure, the recommended option is to assume no consent. Depending on your business use case, it may be possible to optimize these scenarios to fall back to a cached value of data for the user. CMP failure handling will be addressed in v1.2.
Feature Workflow:
Use the consent information to decide if user data can be used in your feature workflow. The workflow for looking up consent could be initiated before it is applied to reduce latencies in the feature workflow.
-
Parse the consent string
-
If gdprApplies is TRUE, extract out consent for your vendor ID and purpose. Different workflows for the same vendor may be gated by different purposes.
-
If consent evaluation is determined to be FALSE, disable use of user data in your feature workflow.
Sample Implementation: (includes a CMP Stub)
For the current version: Yes
For future versions: Not necessarily.
The current version does depend on the the consent data being stored in cookies. In the future, the solution could be moved to use other consent storage mechanisms like central registries storing user id and their consent information. At that time the implementation will need to be updated to retrieve consent data from the other source. However the API interface itself need not change.
A third-party cookie isn?t a long-term solution to auditable, permanent, user-keyed consent storage, and doesn?t work today for browsers that block 3rd-party cookies or mobile apps. CMP?s should work towards standardizing a more future-looking server-side consent retrieval mechanism as well, and can use this cookie as "consent caching" for that future implementation.
These Framework implementation guidelines will continue to expand with the growing knowledge base of the GDPR Technical Working Group.