Introduction
Admiral's Consent Management Platform (CMP) provides a comprehensive, customizable, easy-to-implement standards-compliant solution for managing user consent. This tool is a critical step towards enabling your full advertising business to remain compliant with important aspects of regulations such as the General Data Protection Regulation (GDPR) in the EU and the California Consumer Privacy Act (CCPA) in California, enabling higher CPMs and greater vendor accountability on your properties.
What is a CMP
A Consent Management Platform (CMP) is a tool for publishers, used to do two things at once:
- Give users the power to control how their data is used
- Set their own limits on how their user's data is used
In many cases, these capabilities are required by law. For many businesses that do not depend on advertising and who control all data on their properties, this can be customized to be as simple or as complex as necessary to meet their legal obligations. For publishers, whose business depends on vendors and data outside of their direct control, there is an additional burden of needing to gather consent, not just for themselves, but also for vendors and their vendors' data that is used to monetize a user.
For this reason, the IAB has established privacy working groups to develop open technical standards which allow stakeholders to operate transparently and predictably, meeting the needs of vendors, publishers, and users. Today, these efforts are reflected in these the IAB Transparency & Consent Framework and the IAB CCPA Compliance Framework.
Admiral is proud to be an IAB-registered CMP, providing an approved implementation of these frameworks for our publishers.
Transparency & Consent Framework
The unique requirements of publishers, vendors, and advertisers have prompted the IAB to develop open standards for collecting, communicating, and validating user consent across the advertising ecosystem. For GDPR, the IAB has developed a standard called the Transparency & Consent Framework. This framework ties together comprehensive policy requirements, a technical standard for persisting consent, and a specification for an API that framework participants can use to retrieve user consent choices.
CCPA Compliance Framework
In the US, CCPA is the primary regulatory framework for user consent in advertising. The IAB and its member organizations have developed a technical and legal framework to ensure ecosystem compliance, which depends on a unified ecosystem contract managed by the IAB (the Limited Service Provider agreement). This agreement ensures vendors and publishers have the legal framework in place to operate legally in cases where users have opted out of the sale of personal data. Admiral's CMP provides the technical and UX capabilities required for publishers to participate in this framework, making it easy for publishers to stay compliant and maximize their CPMs.
Overview
Before we get started configuring your CMP to work with the IAB's Transparency & Consent Framework, it's worth reviewing some key aspects of the framework, and the essential components for Admiral's CMP.
Framework Overview
The IAB's Transparency & Consent Framework is a policy and technical framework designed to connect its three primary stakeholders with EU regulator organizations to ensure that the advertising ecosystem can continue to thrive while respecting European privacy regulations. To do this, it has developed several documents, including two core documents below which document the most important aspects of the framework for publishers. We highly publishers who are interested in understanding the framework to review these documents.
| Document | Summary |
|---|---|
| TCF v2.0 Policy | This document outlines the obligations of the primary framework stakeholders, specifying valid purposes and the legal basis under the framework, as well as specific UX and legal disclosure requirements any CMP must implement. Violations of these policies will generally put you and your vendors out of compliance according to GDPR. |
| CMP JS API | This document details the technical API specifications for the on-page Javascript API that vendors and publishers can use to understand user choice on a site. Many features of this API are provided through Admiral's Javascript API, which may be reflected in references to our documentation about pass-throughs to this API—especially around the core TCData object. |
Admiral's role as an IAB registered CMP is to provide a certified compliant implementation of this framework, ensuring that publishers and vendors alike are able to gather valid privacy choices from users with minimal effort and risk by publishers.
Platform Overview
Admiral's TCF CMP has three key configurable components:
| Component | Description |
|---|---|
| Bootstrap Tag | Some settings may need to be on the page before the Admiral script is loaded, including whether the CMP is configured at all, and whether GDPR should apply globally for a property. Changes to these settings will require re-installation of the admiral bootstrap to go into effect. |
| JS API Client | The Framework provides several mechanisms to control how data is used on their site, including limiting vendors, purposes, and legal bases, which are limited at the on-page JS API level. |
| User Experience | Publishers can configure settings like colors, frequency, and other options to customize the user experience to meet their brand and user experience goals. |
These components correspond to three stages of the Admiral CMP:
| Stage | Description |
|---|---|
| Initial Load | When the page initially loads, the TCF JS API will have limited functionality provided by the Admiral bootstrap tag. At this stage, vendors must wait for the full Admiral script to initialize before accessing the consent data. |
| Client Loaded | Within a few hundred milliseconds of the initial page load, the full Admiral script should be loaded, providing the complete TCF API. If user consent has already been stored, it is available to the publisher and vendors immediately. |
| UI Visible | After the Admiral script has fully loaded, it will determine the most appropriate engagement type (if any) for a user. If the user has not consented, and GDPR applies to that user, the first engagement will usually be the Consent Manager UI. |
Getting Started
Overview
Getting started using the Admiral CMP is simple. If you already have Admiral installed, its just a matter of basic configuration and of updating the Admiral tag installed on your site.
Configure the UX
Before activating Admiral's CMP, you must configure the consent UI. These settings control the frequency that visitors are engaged for their consent settings (that is, if they have not yet fully consented), as well as the styles and other settings affecting the overall appearance of the UI.
You can begin this process by clicking the "Consent" navigation link for your property in the top navigation bar in your dashboard. Once you're on the Consent page, you will see a call to action for configuring your CMP UI, as shown below:
Update your tag
Now that the CMP UX is configured for your account, the CMP client will be active on your property. To ensure that the TCF API is fully available on your site, we've updated your Admiral install script to include some additional code. This updated tag must now be installed on your site.
To see your updated tag, simply navigate to the "Install" page, using the link near the "Consent" link we used previously to get the Consent page. Your most up-to-date tag will always be available on this page.
Configure the CMP Client (Optional)
Once a UX is configured, you will be able to configure the TCF client options. These can be found by navigating to the Consent page for your property. The CMP Client Configuration UI starts with a descriptive summary view like below, which has three categories of settings to be configured.
v2.0 Migration
Overview
In the spring of 2020, IAB Europe released a major update to its Transparency & Consent Framework. This new version of the framework includes major revisions to its policies and technical specifications, taking into account two years of feedback from publishers, vendors, users, and regulators. This framework overhaul touches virtually every aspect of the framework, and therefore there is no compatibility between TCF v1.1 and TCF v2.0.
After August 2020, no new consent strings from v1.1 can be made or considered valid, and after September 2020, no v1.1 consent strings can be considered valid regardless of when they were generated.
While Admiral takes steps to simplify the transition, action is required for publishers using a CMP for TCF v1.1 to remain compliant and migrate to TCF v2.0.
To migrate to TCF v2.0, publishers must first configure their TCF 2.0 consent UI, and then update their tag.
Major Changes
For the most up to date and complete resources for understanding the Transparency & Consent Framework, We highly recommend following official IAB channels. This page will primarily focus on changes to the Admiral CMP.
TCF v2.0 For Publishers: https://iabeurope.eu/tcf-for-publishers/
TCF v2.0 Switchover Q&A: https://iabeurope.eu/uncategorized/tcf-v2-0-switchover-qa/
TCF v2.0 Policy: https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/
While the latest version of the Transparency & Consent Framework was in some ways a re-imagination of the framework from the ground up, the underlying law that it was meant to address remains. Ultimately, the goal of the framework is simple:
- Provide an open technical standard for communicating user consent signals to stakeholders
- Define a set of policies that ensure the technical signal addresses underlying legal requirements and rights for stakeholders
From this, we can say the underlying components are the same, but the specific details around these components have changed.
Policy Changes
While there were a variety of policy changes in TCF v2.0 from TCF v1.1, there are three primary changes that we like to highlight:
- Purposes
- UI requirements
- Legitimate interest control
Purposes
There is an entirely new set of purposes and disclosures, which do not directly map to TCF v1.1 purposes. Previously, there were only 5 standard purposes. In TCF v2.0, there are 10 standard purposes, as well as two additional special purposes that uses may not opt out of.
| Purpose ID | Purpose Name |
|---|---|
| 1 | Store and/or access information on a device |
| 2 | Select basic ads |
| 3 | Create a personalised ads profile |
| 4 | Select personalised ads |
| 5 | Create a personalised content profile |
| 6 | Select personalised content |
| 7 | Measure ad performance |
| 8 | Measure content performance |
| 9 | Apply market research to generate audience insights |
| 10 | Develop and improve products |
| Special 1 | Ensure security, prevent fraud, and debug |
| Special 2 | Technically deliver ads or content |
As a publisher, you will need to determine which of these purposes apply to you and use our API to get the information before processing personal data for users.
You can learn more about stacks here.
UX Requirements
Among the changes to the TCF Policy, there are much more clear and more defined requirements around user experience when configuring their consent choices. This includes new language addressing UX features such as: new actions for legitimate interest, important initial disclosures, and details about individual purposes and vendors. Additionally, this new language contains requirements on how much screen the UI must take up, the color contrast of buttons, and stringent translation requirements.
Because of these new UX requirements, there is a great deal less customization that the framework allows on a per-publisher basis than was possible in v1.1. Publishers can no longer provide their own translations, or make drastic changes to the UI. "Banner" style windows are also no longer allowed, as they typically do not take up a sufficient amount of the screen to meet the policy requirements.
Legitimate Interest
In the initial release of TCF v1.0, the only legal basis envisioned to be handled by the framework was consent. After receiving feedback from regulators and vendors who sought to be more compliant, it became apparent that it was insufficient for vendors to claim legitimate interest and not provide an easy UI for users to use to object to those claims, which is their right under GDPR.
With the release of TCF v2.0, users will have a direct way, within the CMP's consent UI, to object to specific claims of legitimate interest by vendors, or broadly by purposes. This applies to both the publisher and vendors registered in the Global Vendor List.
Technical Changes
With the launch of the new TCF version, Admiral has made a number of product changes to incorporate new requirements and improve options for publishers.
API Changes
While the official TCF JS API has changed completely, we've worked to keep our helper API consistent with previous versions where possible. That said, there are some key changes we've made with the goal of simplifying our own API's usage.
1. Underlying consent data structure has changedThis most significant API change is that the underlying TCF consent object has changed. This underlying change requires almost all publishers using any API based on TCF v1.1 to change their code to be compatible with TCF v2.0, including publishers using the admiral() API. Official documentation on this new object, referred to here has tcData or the TCData object, can be found here:
There are key fields on this object that publishers may be interested in:
The Admiral JS API returned different values to callbacks for different calls related to the CMP. For TCF v2.0, the two action calls cmp.loaded and cmp.updated both return the same response object. The main distinction between them now is when they are called. You can see the new response object in the documentation for these calls.
3. cmp.consent variable is now deprecated.
To simplify our API, we have removed the cmp.consent variable that was used to fetch consent status at a given time in favor of a fully event-based api. Information previously available for TCF v1.1 is now available using either the cmp.loaded and cmp.updated events. For example:
When migrating to TCF v2.0, publishers will need to transition API calls using the get variable API to the after-event-based API.
You can learn more about this here
Purpose Configuration
Prior to TCF v2.0 there was not a finalized standard for publishers to configure purposes and vendor configurations for their properties. The pubvendors.json spec was an attempt, but it was never finished. TCF v2.0 attempts to integrate many of the requirements that inspired that specification.
Admiral supports these new spec features as configuration for the CMP client screen, where you can control acceptable legal basis for yourself and vendors.
Custom Vendors
TCF v1.1 allowed publishers to configure custom vendors who were not part of the TCF framework, but there were no framework guidelines describing how it could be done in a compliant way since non-framework vendors could not be displayed alongside framework vendors. Many publishers ended up implementing custom vendors as custom purposes, which worked, but was not ideal.
TCF v2.0 is much more clear about custom vendors and describes how they can be included in a TCF v2.0 compliant UI.
Admiral allows customizing custom vendor settings on your property in the relevant CMP client configuration screen. We also allow publishers to configure which framework vendors will be shown and consented to by users.
Frequently Asked Questions
How do we set up 3-4 levels of cookie consent? For example, Essentials, Required, Performance, Optional, etc?
We don't offer that as there isn't a concept like that in IAB TCF, but you can configure custom purposes and key off of those custom purposes.
Does Admiral provide a user data collection request form (and management of the subsequent process for handling such responses) as well?
We do not offer this. It's outside the scope of our compliance-oriented CMP. You will need a governance solution to handle this.