The IAB Europe Transparency and Consent Framework is an initiative of IAB Tech Lab — a non-profit organization made up of digital publishers, ad-tech companies, marketers, and other companies involved in interactive marketing. The board is made up of some pretty well-known brands such as Google, AppNexus, LinkedIn, Microsoft and others.
The association behind the Tech Lab — IAB Europe — is the leading industry association for the online advertising ecosystem. This association represents over 5,500 organizations at the EU-level and its mission it is to shape the regulatory environment by developing harmonized business practices in order to promote the development and ensure the sustainability of the digital advertising sector while demonstrating the value that such innovative sector brings to the EU economy.
As essentially all parties within the digital advertising ecosystem process personal data in some way (e.g collecting user data or accessing user devices), they are required to comply with the GDPR.
Under GDPR there are six possible legal bases for the processing of personal data. Of these six, three are particularly relevant to digital advertising:
Consent of the data subject
Performance of a contract
Legitimate interests of the data controller
Under the Regulation, the particulars of which legal basis can apply may differ based on the processing activities of the individual company, however, one inescapable determining factor is the applicability of other relevant laws — in this case, the ePrivacy Directive. The ePrivacy Directive or ‘Cookie Law’ requires that users be conspicuously informed of a site’s use of any cookies and that active consent be collected before running scripts related to non-exempt cookies.
IAB Europe founded the GDPR Implementation Working Group (GIG), a group consisting of parties from both the supply and demand sides of the digital advertising ecosystem, in 2017. The GIG is aimed at helping member companies, and the digital advertising industry at large, to understand EU rules on data protection and privacy in a practical way and collaborates on guidance and solutions to the GDPR.
Though GDPR is primarily a legal challenge, a technological response was also necessary to meet the transparency and control requirements that arise as a result of GDPR implementation. It was out of this necessity that the IAB Tech Lab GDPR Technical Working Group was formed within the IAB Tech Lab.
The Technical group’s efforts resulted in the development of theIAB Europe Transparency & Consent Framework (TCF). The Framework and the associated Consent Management Provider API was developed as a way to “give the publishing and advertising industries a common language with which to communicate consumer consent for the delivery of relevant online advertising and content”.
In practice, the TCF provides a standardized process for getting users’ informed consent and allows the seamless signaling of users’ s consent preferences across the advertising supply chain.
It’s made up of an ever-growing list of publishers and advertisers that have agreed to be bound by its standards and use the framework to facilitate user choice via a convenient, easy to use interface.
Who should enable the TCF / Who does it best apply to
The framework is, ideally, meant for first-party publishers who work with third-party advertisers (i.e publishers who run ads on their website). It’s highly recommended that you enable this feature if you fall within this category as some advertising networks may limit access to their network if not implemented, which could, in turn, potentially decrease your ad revenue.
Publishers further stand to benefit from this initiative in that it makes it easier to be more transparent with users and allows you as the data controller, to have more control over how your users’ data are processed and for which purposes.
If you run ads on your website it’s highly recommended that you enable this feature: some advertising networks may limit access to their network if not implemented, which could, in turn, potentially decrease your ad revenue.
Attend our “Consent management for publishers” webinar
View a live demo and have your questions answered in real time by attending our free english “Consent management for publishers” webinar. Discover in practice how you can meet both compliance and advertising industry requirements while ensuring that your ad-reach is maximized.
Online advertising is a complex ecosystem with many different players, the main actors paying within the Framework are:
Vendors: “a third party (SSPs, DSPs, ad servers, etc.) that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user’s device or browser (for setting cookies), or (2) collects personal data from the actions of the website operator’s end users”.
Publisher: website operators — in this case, operators who monetize their content via third-party advertisers.
Consent Management Providers (CMPs): “a company operating as a consent management platform, that can read and/or set the user’s consent status for the vendors chosen by a website operator”.
In the middle, helping to facilitate this process are the companies operating as Consent Management Providers (CMPs). CMPs can read and/or set a user’s consent status for the vendors, and make this information available to vendors that publishers choose to work with. CMPs must adhere to the standard Framework protocol and policies in order to register in a centralized CMPs list, where they are also assigned a unique ID.
The Framework supports both Server-specific consent and Global consent. The former is given by the consumer to a Publisher or Vendor to access their browser and/or perform the requested processing purposes where a Publisher or vendor requires consent for their site, while the latter is given by the consumer to access their browser and/or perform the requested processing purposes across the internet. It is up to the publisher to decide what type of consent should be obtained.
The collected consent and vendors signals are represented by binary values and compressed into as small a data structure possible (Base64) and are then stored in browser cookies. Global consents are stored in a global third-party cookie. Publisher’s approved vendors, purposes and consents (and per-site vendor consents) are stored in first-party cookies, under the domain of that Publisher.
The Framework’s support of global consent is intended to minimize repeated solicitations for the same parties which may be present on multiple sites.
How it behaves
Regarding the collection of consent, the Framework behaves differently according to the following variables:
GlobalScope is set to true: if GlobalScope is true, a remote consent was found. The consent is stored both in first-party cookies under the domain of that Publisher and in a third party cookie under consensu.org domain. The third-party cookie facilitates the ability to read and share consent and vendors signals from one website to another, providing a smoother user experience (consent will not need to be requested redundantly as it makes it possible to reuse it from one website to another). The consent and vendor information are transmitted throughout the online advertising ecosystem via a Daisy Chain.
GlobalScope is set to false: if GlobalScope is false, a remote consent was not found. The consent is saved on the local Publisher domain only instead of both on consensu.org and local domains. The consent and vendors information are transmitted throughout the online advertising ecosystem via a Daisy Chain.
CMPs have to resolve the conflict between Server specific consent and Global specific consent before transmitting any consent signal in the DaisyBit mechanism. The standard logic to reconcile conflicting signals is that Server-specific consent status overrules a Global consent status for that vendor.
For Example: A user gives global consent for data processing by a particular vendor on Site A. The user later visits Site B and is prompted for publisher-specific consent but refuses to grant consent on this site. As a result, the vendor has global consent except on Site B.
When comparing two like signals, for example, both conveying publisher-specific consent, then the signal with the most recent timestamp prevails.
The scripts of Vendors that are part of the GVL are automatically blocked prior to receiving user consent. Each vendor can check its consent status by first pinging the CMP and then waiting for a call back for the ID that they pass, that lets them know whether or not they have consent.
Vendors get a single consent value with possible values of:
Consent not found (0) which could include new users, users who have said no, or users who have revoked consent;
Consent found (1)
The cookie banner will be displayed any time a user visits your site for the first time or when you have decided to add a new vendor to your list of vendors (since it’s a new disclosure and potentially a consent request for that vendor may be required).
The maximum lifespan of consent is of 13 months. Consequently, a refresh or reminder will be provided to the user before that timeframe elapses. Users can at any time change their mind and resurface the User Interface on your website in order to withdraw their consent or exercise their right to object.
iubenda Cookie Solution and integrated TCF
Despite being a relatively new initiative, the IAB Framework is rapidly becoming the industry standard with many huge vendors such as Google, Adobe and AdRoll involved in its implementation.
As a registered CMP, we’ve worked hard to ensure that our Cookie Solution integrates seamlessly with and complies with the policies and specifications of this Framework, hereby giving you, our users, the additional option to easily enable and use it for your website and apps.
End-user consent options when the TCF is enabled
Now the end-user, at the banner level, has various options:
Accept or reject all vendors and purposes by first clicking the “Accept all” “Reject all” buttons at the top of the screen, then saving the expressed preferences by clicking on the “continue to browser” button on the bottom right of the screen. or
*There might be cases where the users will see all or single purposes or vendors already switched on. This is possible when Users have already expressed their consent and vendors preferences on another website that is part of the Framework and has opted for Global consent. In such cases, the consent and vendors information collected on the first website are transmitted to the second one, and as such, these preferences are displayed in their current state to the user in the user interface.
Some vendors may relay on legitimate interest instead of consent for the processing of personal data. The User Interface specifies if a specific vendor is relating on legitimate interest as legal basis, meaning that that vendor will process user’s data for the declared purposes without asking for their consent.
The presence of vendors relying on legitimate interest is the reason why within the user interface, even if a user has switched on one specific purpose, not all vendors processing data for that purpose will be displayed as switched on. In fact, those vendors processing data for that specific purpose, relying only on legitimate interest will be displayed as switched off.
The User has the right to object to such processing and may exercise that right by visiting the privacy policies of the respective vendors.
How to enable the IAB TCF in the Cookie Solution
The Cookie Solution gives you the option to allow your users to customize their advertising tracking preferences directly from your website. While this feature is optional — as hosting the actual mechanisms for toggling preferences isnot mandatory under the applicable Cookie Law— it is heavily recommended that publishers, in particular, enable this feature as failure to do so can potentially result in reduced reach and ad revenue.
Additionally, once enabled in the Cookie Solution, this feature automatically blocks the scripts of advertisers that are a part of the IAB Vendor Network (provided that the individual advertisers adhere to the standards of the network) prior to receiving user consent.
To enable this feature, head to your dashboard and click on the website that you’d like to update. Next, click the <>EMBED button in the Cookie Solution area:
This will take you to the embed section for the Cookie Solution. This feature is available on all channels.
In older versions of the Cookie Solution, this feature was available only on the beta channel. If you’re using a previous installation of the Cookie Solution, we strongly recommend that you upgrade by simply copying the new code here (Dashboard > [Your website/app] > Cookie Solution > Embed) to avoid any CSS related conflicts and to access all the new features of the latest version.
To enable, scroll to the bottom of this section and click the checkbox on the bottom left (as pictured below):
Note: you can enable this option also on the Cookie Solution customization panel (Cookie Solution > Edit).
Once enabled, your Cookie Solution embed code will go from this:
Take a look at the Cookie Solution code currently on your site and look for the stub.js snippet as can be seen in the image here. If the stub portion is not there, then you will need to update your code.
To function properly, the embed code must be added at the very beginning of the head, right after the <head> tag opening.
Cookie Solution code with stub.js snippet
Now, if you intend to serve personalized ads to users, you’ll need to ensure that explicit consent to ad personalisation is collected before you can display personalised ads for end-users (where this consent is not collected, Google will default to serving non-personalized ads, potentially impacting your ad revenue).
In order for vendors to read the consent collected, __cmp function that the CMP (iubenda) makes available must be present. This function is only available after consent has been collected. In order for vendors to read the consent properly, two methods are available:
Directly blocking the vendor scripts (using another prior blocking method), then executing them only after consent has been collected. This method requires more implementation work and it’s a bit slower in terms of execution time, but it allows personalized ads to be served from the first page view (where consent hasn’t been collected yet) and gives you more direct and solid control in regards to ensuring compliance.
Not directly blocking the vendor scripts, but rather, ensuring that the __cmp function is loaded before the vendor scripts are loaded, through some specific configuration, but this will only work from the second page view, when consent is already present on the page. This method is easier to implement and it’s very high-performing in terms of load speed, however, in this situation, you have less direct control as you must rely on the vendor’s adherence to IAB’s guidelines for compliance.
Vendors have a maximum time (generally 300ms, usually non-configurable) to wait for consent from the CMP. In cases where the CMP does not respond within a maximum of 300ms, vendors’ Sell-Side Platform uses the opt-out status of the user instead. Meaning that in such cases, your end-users will be served with non-personalized ads.
In order to make sure that the consent is read within 300ms from the vendor scripts being executed, we created an extra script (safe-tcf.js) that has the only job of reading the TCF cookie and releasing the __cmp function.
Let’s take the Cookie Solution code snippet we’ve seen before:
The safe-tcf.js script is executed synchronously at the very beginning of the page, guaranteeing for the 300ms threshold to be respected. The stub.js and safe-tcf.js can also be embedded inline or self-hosted, if necessary.
To read the consent from the __cmp function, you can open the browser console and launch these commands:
The IAB feature allows users to consent/reject cookies both on an individual basis or as a bulk action, for the convenience of your website users.
Option to apply GDPR protections to all users or EU users only
The IAB feature of the Cookie Solution also allows you to indicate whether or not you’d like to apply GDPR protections to the following.
All your users. In this case, the GDPR protections are applied to all users of your site. This is the default setting.
Only your EU users. When this global setting is selected, the parameter gdprAppliesGlobally is set to false which indicates to vendors within the network that the GDPR protections only apply to EU-based users of your site.
Current users. When this local setting is selected, the parameter gdprApplies is set to true which indicates to vendors within the network that GDPR protections apply to users visiting a particular web property (for example, the EU landing page of your website or any other specific section of your site).
If you set gdprAppliesGlobally to false, you will further need to also explicitly specify either gdprAppliestrue or false depending on whether the user is from EU or not based on whatever criteria you choose (see example below).
An e-commerce site has different sections available to users in the US and in Europe. They want to apply GDPR protections to just their EU-based users. Using the “GDPR applies to current user” checkbox, they can indicate to vendors that users of the European section of the site should have GDPR protections applied to them by passing gdprApplies=true when it is detected that users are EU based.
One simple way to set up this detection would be to add a conditional (such as an “if” statement) to the Cookie Solution code snippet that sets the gdprAppliestotrueorfalsebased on the site section indicated, such as the .eu or .co.uk landing pages of your site.
*If you’re unsure about how to set this up, we strongly suggest using the default settings.
To access these settings, simply go to Cookie Solution > Edit > Advanced View and select the desired setting under IAB Transparency and Consent Framework section:
Please note that if you are EU-based, it is mandatory that you apply the protections to all users and not just users based in the EU.
Request new consent
When enabled, return users who have accepted cookies on your site prior to the activation of the IAB feature will see the cookie banner and be asked for fresh consent, hereby allowing these users the equal opportunity to individually modify their preferences as the other users of your site. You can find this setting under the IAB Transparency and Consent Framework section indicated in the image above.
Allow users to update their TCF preferences even after closing the cookie banner
The TCF feature gives you the option to let your visitors update their advertising tracking preferences even after closing the cookie banner.
To implement, just add the iubenda-advertising-preferences-link class to a custom link or button, for example:
<a href="#" class="iubenda-advertising-preferences-link">Update your advertising tracking preferences</a>
And place anywhere on your site (typically added to the site footer). Once clicked, the link/button will trigger the opening of the advertising tracking settings modal:
Avoid sharing the TCF cookie with other publishers
If the parameter isTCFConsentGlobal is set to true (default setting), the TCF consent is saved on both consensu.org and local. If set to false, the TCF consent is saved only on the local domain, meaning the TCF cookie won’t be shared with other publishers. This value proxies the IAB CMP JS API hasGlobalScope value.
You can activate/deactivate this setting via the “Share consent with other sites” checkbox within the configurator under Advanced view > IAB TRANSPARENCY AND CONSENT FRAMEWORK.
Note: When the user indicates that they would like to manage preferences by opening the preference window, all cookies are “turned off” by default as a positive affirmative/ “Opt-in” action is legally required for valid consent.