AdMob & AdSense program policies

Google’s Additional Consent Mode technical specification

This document defines a technical specification (called "Additional Consent Mode") intended only for use alongside IAB Europe’s Transparency & Consent Framework (TCF) v2.0 to serve as a bridge for vendors who are not yet registered on the IAB Europe Global Vendor List (GVL). This specification allows publishers, Consent Management Providers (CMPs), and partners to gather and propagate additional consent—alongside their TCF v2.0 implementation—for companies that are not yet registered with the IAB Europe Global Vendor List but are on Google's Ad Tech Providers (ATP) list.

Related resources

Components of the Additional Consent Mode

In "Additional Consent Mode", we support both:

The Transparency & Consent String (TC string) as defined by the IAB TCF v2.0 spec, which contains the transparency and consent established for vendors on IAB’s Global Vendor List (GVL). AND,
A lightweight addtl_consent string (AC string), which contains a list of consented Google Ad Tech Providers that are not registered with IAB.

This specification defines the following:

The AC string format
The extension to the TCF v2.0 CMP API to support the AC string
How an AC string should be stored
How to pass the AC string through the digital advertising chain

The "Additional Consent" (AC) string format

What information is stored in an AC string?

An AC string contains the following three components:

Part 1: A specification version number, such as "1"
Part 2: A separator symbol "~"
Part 3: A dot-separated list of user-consented Google Ad Tech Provider (ATP) IDs. Example: "1.35.41.101"

For example, the AC string 1~1.35.41.101 means that the user has consented to ATPs with IDs 1, 35, 41 and 101, and the string is created using the format defined in the v1.0 specification.

Who should create an AC string?

An AC string may only be created by an IAB Europe TCF-registered CMP using its assigned CMP ID number in accordance with the IAB Policies. Vendors or any other third-party service providers must not create AC strings themselves.

Where will the Google ATPs be published?

Google will publish the list of ad technology providers not registered with the IAB and their IDs at the following location:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

When should an AC string be created?

In all cases, an AC string may only be created where the publisher is in compliance with Google’s EU User Consent Policy. In particular, an AC string must not be created before the user has given legally valid consent to: 1) the use of cookies or other local storage where legally required; and 2) the collection, sharing, and use of personal data for personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.

An AC string must only be created as a supplemental string to the TC string, and not in place of the TC string. Google will not process the request and will discard the AC string on a request received by Google if a TC string is not available for the same request.

CMPs implementing this spec must make sure that the AC string they create contains only the IDs from the published Google ATP file (that is, non-GVL vendors). When Google receives a TC string, it will check the version of the GVL that is listed in that TC string. If that version of the GVL has a registration for a vendor, the TC string controls for that vendor and any AC string entries for that vendor will be ignored. In this circumstance, Google reserves the right to remove such “duplicate” entries from the AC string and pass on such modified AC string alongside the TC string. Vendors other than Google may not modify the AC string.

Extension to the CMP API

We propose to extend the existing TCF v2.0 CMP JavaScript API to allow for returning the AC string. More specifically, we propose to extend the TCData and InAppTCData JSON objects to return this data.

TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

How should an AC string be stored?

Web

Storage mechanism is up to the CMP’s choice.

In-app

NSUserDefaults (iOS) or SharedPreferences (Android) shall be used to store the AC string by a CMP SDK. It allows:

Vendors to easily access the AC string
AC string to persist across app sessions
AC string to be portable between CMPs to provide flexibility for a publisher to exchange one CMP SDK for another

If a publisher chooses to remove a CMP SDK from their app, they are responsible for clearing AddtlConsent values for users so that vendors do not continue to use the included AC string.

Storage and Lookup Key in NSUserDefaults and SharedPreferences	Value
`IABTCF_AddtlConsent`	String: AC string with spec version and consented Ad Technology Provider IDs

How to pass the AC string through the digital advertising chain

Bid request

We will reuse the ConsentedProvidersSettings to propagate the non-GVL vendors downstream.

In OpenRTB extensions proto
Legacy Protobuf version

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

URL-based services

When a creative is rendered, it may contain a number of pixels under <img> tags. For example, <img src="http://vendor-a.com/key1=val1&key2=val2">, which sends an HTTP GET request from the browser to the vendor's domain.

Since the pixel is in an <img> tag without the ability to execute JavaScript, the CMP API cannot be used to obtain the TC string. Similar to the support for TC string, we provide a standard URL parameter and a macro in the pixel URLs where the AC string should be inserted.

URL parameter	Corresponding Macro	Representation in URL
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Example 1

For Vendor A to receive an AC string, an image URL must include a key-value pair with the URL parameter and macro &addtl_consent=${ADDTL_CONSENT}. The resulting URL is:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

Example 2

On a given request, if the AC string is: 1~1.35.41.101

The caller or the renderer of the creative replaces the macro in the URL with the actual AC string so that the originally placed pixel containing the macro is modified as follows when making the call to the specified server:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Was this helpful?

How can we improve it?