In this article
- Components of the Additional Consent
- The "Additional Consent" (AC) string format
- CMPs that support Additional Consent
- Extension to the CMP API
- How should an AC string be stored?
- How to pass the AC string through the digital advertising chain
- Related Resources
This document describes Google’s Additional Consent technical specification, which is intended only for use alongside IAB Europe’s Transparency & Consent Framework (TCF) v2 to send transparency and/or consent signals to vendors who are not yet registered on the IAB Europe Global Vendor List (GVL). This specification allows publishers, Consent Management Platforms (CMPs), and partners to gather and propagate additional consent—alongside their TCF implementation—for companies that are not yet registered with the IAB Europe Global Vendor List but are on Google's Ad Tech Partners (ATP) list.
Components of Additional Consent
Additional consent consists of a lightweight addtl_consent string (AC string), which contains a list of consented and/or disclosed Google ad technology partners (ATPs) that are not registered with the IAB’s Global Vendor List (GVL).
How to generate an "Additional Consent" version 2 (ACv2) string
What information is stored in an AC string?
An AC string contains the following components:
-
Part 1: The specification version number. The current version is "
2" -
Part 2: The separator symbol "
~" -
Part 3: A dot-separated list of user-consented Google Ad Tech Provider (ATP) IDs. Example: "
1.35.41.101" -
Part 4: A separator symbol "
~" -
Part 5: "dv." followed by a dot-separated list of disclosed Google Ad Tech Provider (ATP) IDs. Example: "
dv.9.21.81"Vendors included in Part 3 should not be included in Part 5 to reduce string length.
AC string examples
If ATP vendors with IDs 1, 2, 3, 4, and 10 are disclosed to the user:
- …and the user has seen the CMP message disclosing these vendors but has not yet made a decision of whether to consent: the corresponding ACv2 string would be
2~~dv.1.2.3.4.10. -
…and the user has provided consent to all vendors: the corresponding ACv2 string would be
2~1.2.3.4.10~dv.. Note that the "." after dv is optional in this case only, so2~1.2.3.4.10~dvis also an accepted ACv2 string. - …and the user has rejected consent for all vendors, the corresponding ACv2 string should indicate that all vendors have been disclosed but none are consented. The corresponding ACv2 string would be
2~~dv.1.2.3.4.10. - …and the user has provided consent for vendors
1and10but rejected consent for all other vendors, the corresponding ACv2 string would be2~1.10~dv.2.3.4.
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 partners must not create AC strings themselves.
Where are the Google ATPs be published?
Google maintains a list of ad technology partners 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.
Consented vendors should only be included when the user has given legally valid consent to:
-
the use of cookies or other local storage where legally required; and
-
the collection, sharing, and use of personal data for personalization of ads by an ATP, as well as complying with all other terms of Google’s EU User Consent Policy.
Disclosed vendors should only be included when appropriate transparency is provided to users on the identity of each ATP, including linking to the ATP’s privacy policy as provided in Google’s ATP list. Vendors included in the consented vendor list do not need to also be included in the disclosed vendor list.
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 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 correspondingly modified AC string alongside the TC string. Vendors other than Google may not modify the AC string.
Are Additional Consent v1 strings still supported?
Additional Consent v2 has been the standard Additional Consent version since December 2023. Additional Consent strings generated based on the v1 specification will continue to be supported. However, such strings can't indicate if transparency is established for an ATP. To support use cases that do not require consent, CMPs should migrate to the v2 specification.
Certified CMPs that support Additional Consent
This list includes certified CMPs that offer support for the Google Additional Consent technical specification, as well as the version of Additional Consent that they support.
If you are a CMP that offers Additional Consent support, and (1) you aren't included on this list or (2) the wrong Additional Consent version is listed, please go to the CMP intake form and select the "I'd like to ask a question or update my status" request type. We'll do our best to update the listing to reflect your status in a timely manner.
Guide to the information in this list
This list includes to following information about each certified CMP:
- Certified CMP: The name of the certified CMP.
- TCF CMP ID: The unique identifier assigned to a TCF-validated CMP by the IAB.
- Additional Consent: The version of Additional Consent supported by the CMP.
List of certified CMPs that support Additional Consent
Extension to the CMP API
CMPs that support Additional Consent should return the Additional Consent string as part of the existing TCF v2 CMP Javascript API JSON Objects, TCData and InAppTCData.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed 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) are used to store the AC string generated by a CMP SDK, similar to the in-app API for TCFv2. This mechanism allows:
-
Vendors to easily access the AC string
-
The AC string to persist across app sessions
-
For portability of the AC string if a publisher changes their CMP
Note: 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 Partner IDs |
How to pass the AC string through the digital advertising chain
Bid requests
Bid requests will use the ConsentedProvidersSettings to propagate the non-GVL vendors downstream.
- In OpenRTB extensions proto
- Legacy Protobuf version
message ConsentedProvidersSettings {
// Set of IDs corresponding to partners 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 partner ID to partner name is posted at providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Information about the partners 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 request, if the AC string is: 2~1.35.41.101~dv.
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=2~1.35.41.101~dv.