Troubleshooting IAB EU TCF v2.2 implementation

Google as a vendor now accepts TC strings using the IAB EU TCF v2.2.

• TCF v2.1: We'll continue accepting TCF v2.1 strings, but encourage CMPs to follow IAB guidance on implementation milestones as the industry moves over to TCF v2.2.
• Google consent management solutions: Google consent management solutions, available in Ad Manager, AdSense and AdMob's Privacy & messaging tab, supports TCF v2.2 for its European regulations messages, in alignment with the IAB's updated requirements for CMPs.

To help publishers manage errors and misconfigurations related to the launch of IAB Europe’s Transparency & Consent Framework v2.2, we provide a report of errors we’ve detected.

---

In this article, you will find more information about how to address TCF v2.2 implementation errors, including:

• Updated guidance
• Policy center
• Error report
• Troubleshooting

---

Updated guidance

Updates

• Reminder about the TCF requirement to re-obtain consent every 13 months: 

  You are required by IAB TCF policy to remind users about their consent choices at least once every 13 months. If the consent decision is more than 13 months old, the TC string will no longer be considered valid by Google and Google will not serve ads to that user. We suggest that you work with your CMP to remind users about their consent choices before the 13-month limit is reached.

• The 3.2 error type has been eliminated. TC strings that were updated in the last 13 months will remain valid.

Fixes for common errors

Troubleshoot some of the most common errors across Ad Manager, AdSense, and AdMob by taking the following actions:

Consider re-consenting users with TC strings that will not monetize
^{(Errors 1.1, 3.1, 4.1, 5.1, 5.2, and 6.1)}

Related error(s)

Error 1.1. This guidance may also be applied to errors 3.1, 4.1, 5.1, 5.2, and 6.1.

Updated guidance

Consider re-requesting consent from users.

Rationale

Publishers will benefit from re-requesting consent if they had previously used out-of-band, globally-scoped strings, invalid CMP IDs (from testing), invalid GVL IDs (from testing), or were missing Google as a vendor with proper consent at some point during their implementation.

Errors 1.1, 1.2, 1.3: It is important to check if these errors represent a significant volume of traffic. If so, consider that there might be an issue on the CMP side and make sure that Google is granted consent on the purposes needed as well as being a vendor for consent AND legitimate interest (vendor ID 755).

IAB specification

Per IAB specifications, CMPs may cache consent strings for 13 months.

Note: Some CMPs previously kept the first consent date and extended it; this isn't correct. The consent date should be the new date of a given consent string every time.

Suggested: Have your CMP return calls from AddEventHandler within 500ms
^{(Errors 2.1a, 2.1b, 2.0a, 2.0b, and 2.0c)}

Related error(s)

Error 2.1a. This guidance may also be applied to errors 2.1b, 2.0a, 2.0b, and 2.0c.

Updated guidance

While there’s no longer a timeout requirement, we suggest that CMPs closely review their implementations to ensure they immediately return calls to AddEventListener getTCData. 

If a CMP doesn’t respond, the request may go unmonetized.

Rationale

Google adheres to the IAB specification stating that a CMP should reply immediately to the AddEventListener function. If a CMP doesn’t respond immediately, then the request may go unmonetized.

Additionally, CMP responses are part of the chain of events that influence how soon an ad request can be made. Decreasing the time between page load and ad requests results in fewer lost impressions for the publisher. 

IAB specification

Applicable IAB specification: IAB AddEventListener specification (on GitHub)

Note: The AddEventListener callback should be called immediately upon registration with the current TC data, even if the CMP status is loading and the CMP has incomplete TC data. This enables the calling script to access its registered listenerId. Furthermore, on every TC string change, the callback should be called unless it is removed using RemoveEventListener.

Policy center

The Policy center notifies publishers if an app or site doesn't comply with Google consent management requirements.

Error report

We’ll notify publishers in the product user interface if we detect an issue on the TC string associated with one or more of their sites or apps. On the "EU user consent" page in their account, publishers with errors can click Download TCF error report to download a detailed report of the errors that have been detected over the last 7 days.

Tip: This report is only available if errors have been detected in the last 7 days.

To access the “EU user consent” page and the TCF error report: 

• Ad Manager: Click Admin, then EU user consent.
• AdMob and AdSense: Click Blocking controls, then EU user consent.

The report will contain the following information about each of the detected errors: 

• Domain/MobileAppID: The site or mobile app that's misconfigured.
• Ad unit path: The ad unit associated with the error.
• Error code: The code assigned to the error. 
• Error count: The number of queries containing the error that were observed during the previous week.
• Last detected date: The last date on which the error was detected. 

Publishers can use the error codes listed in the report to find the suggested actions to be taken in the following troubleshooting tables and resolve the errors.

Troubleshooting

To help publishers fix misconfigured IAB TCF v2.2 integrations, we’ve assembled the following tables of the most common TC string error types as well as corresponding troubleshooting recommendations.

Use the tables to understand the issues occurring at the ad-request level as well as the corresponding system behavior.

Limited consent scenarios

All three of these scenarios always take precedence over misconfiguration errors, even if a given request has multiple errors.

Scenario	Description	Suggested action to take
1.1	Google, as a vendor, is not allowed under consent or legitimate interest.	Confirm whether the user intentionally rejected Google as a vendor, CMP implementation errors have occurred, or there are publisher restrictions.
1.2	No consent for Purpose 1 for EEA countries and the UK.	Confirm whether the user intentionally disallowed Purpose 1 or if this is due to CMP implementation errors. Publishers in Switzerland should ensure they are setting the PublisherCC and PurposeOneTreatment fields correctly if they are not asking users for consent.    Purpose One Treatment (P1T) is an IAB TCF feature. P1T allows publishers to indicate that consent for Purpose 1 isn't required in the publisher's country, and that the publisher has established a legitimate interest as the legal basis for Purpose 1.   As of December 2021, Google only supports P1T for Switzerland. If the TCF P1T flag is set with the TCF Publisher Country Code of CH, Google won't apply scenario 1.2.
1.3	Has consent for Purpose 1, but lacks legal bases for Basic Ads.	Confirm whether the user intentionally rejected legitimate interests on the other purposes or if this is due to CMP implementation errors.

Misconfiguration

Ad requests won't be filled while misconfiguration errors exist.

Error	Description	Suggested action to take
2.1a	Tag or SDK isn’t receiving a TC string due to CMP status being stub, loading, or error.	If you're manually invoking the function to request ads, make sure the response to getTCData TCData.eventStatus = 'tcloaded' OR 'cmpuishown' + 'useractioncomplete'. These indicate the CMP is ready to provide the user with a choice regarding consent. If you’re not manually invoking the function to request ads, then work with your CMP to ensure they implement support for getTCData and return TCData.eventStatus = 'tcloaded' OR 'cmpuishown' + 'useractioncomplete' to indicate the user consent is ready for use through the API.
2.1b	Both conditions are met: CMPs set &gdpr=1 &gdpr_consent= is present in the request, but the TC string is empty.	Ask your CMP to make sure that their APIs are properly implemented based on the IAB TCF tech specification.
2.2a	The TC string is not parseable because it isn’t base64 encoded. Example: “2”	CMPs (or publishers) should only send base64 encoded data in gdpr_consent= parameters.
2.2b	The TC string isn't parseable because of a decoding error. Example: Includes an incorrect number of bits	CMP should fix the TC string implementation errors.
2.2c	The TC string isn't parseable because of a data error. Example: Incorrect timestamp, vendor ID is too large	CMP should fix the TC string implementation errors.

TC string issues

Problems with the TC string associated with an ad request. Ad requests will be dropped and unfilled.

Error	Description	Suggested action to take
3.1	Invalid CMP ID.	Make sure an IAB-validated CMP is being used and its ID is correctly set in the TC strings. If a CMP was valid when a TC string was generated but was later deleted by the IAB, you need to re-obtain consent using a valid CMP.
3.2	No longer used.	None. Previous meaning: The TC string creation date was more than 13 months ago.

Consent must be re-obtained

Consent must be obtained from the user. If you obtained consent from a user over 13 months ago or are using a version of the GVL in which Google wasn't yet listed, you should re-obtain the user's consent, otherwise ad requests will be dropped and unfilled.

Error	Description	Suggested action
3.3	The TC string last updated date was more than 13 months ago.	CMP should delete the old TC string and re-obtain consent. It is expected that a small number of these errors may occur if ad requests are sent with an expired TC string before the CMP has invalidated and re-obtained the user's consent. If you use Google consent management solutions and the UMP SDK in your app, confirm that the UMP SDK has been correctly implemented and requestConsentInfoUpdate is being called at app start every time.
4.1	The TC string was generated using a version of the GVL in which Google wasn't yet listed.	Re-obtain consent using a current version of the GVL.

Global scope and out-of-band scope

The following are issues related to global scope and out-of-band scope (Ad Manager, AdMob, AdSense). Ads will not serve if the TC string indicates "out-of-band" or "global scope".

Error	Description	Suggested action
5.1	The TC string allows out-of-band consent.	Instruct your CMP to remove out-of-band signals from the TC strings.
5.2	Globally-scoped TC string.	Instruct your CMP to update the TC strings to be service-specific.

Limited ads serving

Limited ads will serve.

Error	Description	Suggested action
6.1	TC string version is 1 or 1.1 (v1.0 string).	CMP should send TCF v2.2 strings.

Google will handle issues

When these issues occur, Google will mitigate the problem, itself, when necessary and proceed with normal TCF handling.

Error	Description	Suggested action
7.1	gdprApplies is undefined or set to an invalid or indecipherable value, but a valid TC string is present.	N/A
7.2	The TC string was generated with a GVL version newer than the current version known to Google's ad serving technology.	N/A
7.3	Some purposes, features, and/or vendors are out of range (unknown).	N/A
7.4	The TC string has an older tcf_policy_version than the newest GVL.	CMP should delete the older TC string and re-obtain consent using the newest GVL.
7.5	A request has &gdpr=1, but doesn't have the &gdpr_consent parameter in the request URL at all.	N/A
7.6	Invalid publisher country code, but consent to Purpose 1 is present.	CMP should fix the TC string implementation errors.
7.7	Invalid language code.	CMP should fix the TC string implementation errors.
7.8	TC string version field is neither 1 nor 2.	CMP should fix the TC string implementation errors by requesting fresh consent if an invalid TC string is detected. If you use Google consent management solutions and the UMP SDK in your app, confirm that the UMP SDK has been correctly implemented and requestConsentInfoUpdate is being called at app start every time.
7.9	AC string version is neither 1 nor 2.	CMP should set the AC string version to 1 or 2.

AC string issues

When these issues occur, Google will treat the Additional Consent (AC) string as invalid and no additional vendors will be considered beyond the TC string.

Error	Description	Suggested action
8.1	AC string isn't using the version separator (~).	CMP should use "~" as the second character of the AC string to separate the version number from the consented vendors list.
8.2	AC string contains a vendor list that doesn't follow the expected formatting (list of int64s separated by ".")	CMP should fix the AC string implementation errors.

CMP certification

When these issues occur, Google will attempt to serve non-personalized ads.

Error	Description	Suggested action
9.1	The TCF CMP present on the request is not certified by Google.	CMP should certify with Google.

No TCF signals on ad requests

When these issues occur, Google will attempt to serve limited ads.

Error	Description	Suggested action
10.1	Request is from EEA, UK, or Switzerland but lacks TCF signals.	Publisher should integrate with a TCF CMP that is certified by Google.