IAB TCF v1 compliance
Note: This document is outdated, please refer to IAB TCF v2 compliance instead.
The consentmanager.net CMP is registered with the IAB TCF Policy v1 (see https://iabeurope.eu/tcf-v1/). The CMP therefore supports features in line with the IAB TCF Policy, the IAB Consent String Specification, the IAB CMP API Specification and other related specifications and policies.
ConsentManager.net IAB Registration Information
| Name | Description |
| CMP ID | 31 |
| CMP domain | consentmanager.mgr.consensu.org |
| CMP is a service | yes |
| TCF version | 1 |
Sharing consent via global consent cookies (consensu.org)
As a registered IAB CMP the consentmanger.net CMP is able to create cookies on the global IAB consent Domain consensu.org. Any CMP that is registered with the IAB can create cookies with this context. The benefit of having this common domain is that visitors who move from website A to website B do not need to be asked for consent again. Instead the CMP of website B can simply ready the pre-existing consent of website A through the global cookie domain.
IAB Policy and Design restrictions
The goal of the IAB policy is to ensure that all vendors who receive an IAB consent string are safe to trust that the consent string has been created with a common set of transparency. Therefore all CMP need to follow a certain minimum standard regarding the presentation of the consent layer. The IAB currently requires CMPs to comply with the following minimum design standards:
- The UI needs to be displayed prominently (should be min. 30% of the window)
- All used purposes need to be shown in the 1st layer of the UI
- The 1st layer of the UI needs to show a link to a vendor list ("Custom settings")
- Accept and Reject button need to have equal visual prominence
- The user needs to have the right to withdraw consent at any time and needs to be informed how to do so
- If there are consequences of not consenting, these consequences need to be explained in the 1st layer
- The user needs to be informed on the 1st layer that access to information on their device is taking place by third parties
- The user needs to be informed on the 1st layer that their personal data is processed by third parties, with examples of such data
- The user needs to be able to review the full name and description of the purposes
- The user needs to be able to review the full name and description of the features
- The user needs to be able to review the purposes for each vendor
- The user needs to be able to review the legal basis for each purpose of each vendor
- The user needs to be able to review the features for each vendor
- The user needs to be able to find a link to the privacy policy of each vendor
- The user needs to have a way to resurface the UI and change the preferences
- The UI needs to use the standard names and definitions of each feature and purpose
Example of an IAB compliant consent layer
The ConsentManager.net reference implementation (default design and default settings) therefore reflect these design standards. Here is an example how this can look:
How ConsentManager.net deals with the IAB Policy
ConsentManager allows our clients to choose between the settings they need for their business and the settings that are necessary to be compliant with the IAB policy. Therefore we highlight each setting that is relevant for IAB compliance. If one of these settings is deactivated or if a setting is activated that causes the CMP to be non-compliant with the IAB policy, a warning message will appear.
What happens if I use settings that are not compliant with the IAB policy?
If you use settings that are not compliant with the IAB policy, the system will display a warning message in order to inform you about these settings and the consequences. If a non-compliant setting is saved and the CMP is used on a website, the system will perform the following changes compared to IAB policy compliant settings:
- The CMP will no longer respond with consent information to calls to the IAB CMP JavaScript API via calls to
__cmp()with the standard commands (e.g."getVendorConsents"or"getConsentData") in order to prevent vendors from getting non-compliant consent information. - The CMP will provide new commands with the prefix
"noncompliant_"(e.g."noncompliant_getVendorConsents") in order to allow clients to be able to retrieve consent information from the CMP. - The CMP will no longer write the consent information (consent string) into the global cookie domain (consensu.org) but will store it in a cookie on consentmanager.net domain. At the same time, the naming of cookies
"euconsent"and"eupubconsent"will be changed to"nc_euconsent"and"nc_eupubconsent".
It is important to highlight, that your CMP will still continue to function as before and can still be used with tag managers or adblocking/postponing logics and so on. If you and your partners do not rely on the IAB TCF signals, the above mentioned changes will have no effect on your website.
Links
- IAB CMP Validator: https://www.iabeurope.eu/all-news/press-releases/iab-europes-cmp-validator-for-the-transparency-consent-framework-tcf/
- IAB Consent String Format Specification v1.1: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md
- IAB CMP API Specification v1.1: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/CMP%20JS%20API%20v1.1%20Final.md
- IAB CMP Mobile In-App API Specification v1.0: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Mobile%20In-App%20Consent%20APIs%20v1.0%20Final.md
- IAB TCF Policy v1: http://www.iabeurope.eu/tcfdocuments/documents/legal/currenttcfpolicyFINAL.pdf
