Google IAB TCF 2.0 Error Codes and Guidance
As of September 2021, global scope will no longer be supported per the recent TCF Policy and Technical Specifications. To view the formal notification, please refer to the IAB Europe PDF Notification and IAB Europe PDF Notification Update.
Google has joined TCF 2.0 and publishers / advertisers that use Google Ad Manager or other Google Ads products may receive error messages about their setup and implementation of the OneTrust TCF v2.0 CMP.
This explains the error codes and provides steps to help you correct the errors that could be occurring.
Google has outlined all error types here.
|
Error |
Description |
Suggested Action |
Reason for Issue in Cookie Consent |
Steps to Address in Cookie Consent |
|---|---|---|---|---|
|
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. |
The user was not likely not presented with the option to consent to Google as a vendor properly. Or the user did not accept Google as a vendor. If you have the vendor list consent model set to "Opt-In" in your geolocation rule, and the user does not take an action to "Allow All" or "Accept" through the banner or preference center, or only opts into purposes without accessing the vendor list to opt into Google, you will receive this error. |
Verify that Google is an active vendor in the CMP. If you have your vendor list consent model set to "Opt-In" in the geolocation rule, if your legal team approves, perhaps revert this to "Opt-Out". "Opt-out" is the default configuration and is in compliance for the TCF. |
|
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. |
The user has likely rejected consent for Purpose 1. Google will not operate without consent for Purpose 1. |
There is no fix for this as it is the expected functionality. The user has declined consent for Purpose 1. |
|
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. |
Google is registered as a flexible vendor for purpose 2, 6, 7, 8, 9, and 10. As a result, they will accept consent or legitimate interest for these purposes. |
If a user has given consent for Purpose 1, but denied consent or objected to legitimate interest for the other purposes, Google may not operate per their policies. There is no fix for this as this is the expected functionality. The user has declined all legal bases Google needs. |
|
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. |
Google is failing to add an event listener for tcData.eventStatus themselves thereby placing that burden on the publisher to listen and then only make the ads call after the CMP has captured consent (or not). This piece of the implementation needs to be handled by the publisher. |
Per the ePrivacy Directive and EU Google Policy, a consumer must establish a valid legal basis through the OneTrust CMP before Google ad calls can be set. The publisher site owner must prevent ad calls from being made until consent is given. Below is an example, to insert ad calls on the page when tcData.eventStatus is in an appropriate status. Depending on your additional implementation needs, the below script may require additional logic. This will be the at the responsibility of your development team.
JSON
Additional information on pausing Google Ad requests from Google can be found here. |
|
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 spec. |
This would only happen if OneTrust CMP failed to generate a consent string for a user who is in the EU. |
No reports of this error, no action. |
|
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. |
OneTrust encodes in base64 by default. |
There is no action to take. |
|
2.2b |
The TC string is not parseable because of a decoding error. Example: Includes an incorrect number of bits |
CMP should fix the TC string implementation errors. |
OneTrust has implemented the TC string as defined as part of IAB TCF v2. |
There is no action to take. |
|
2.2c |
The TC string is not parseable because of a data error. Example: Incorrect timestamp, vendor ID is too large |
CMP should fix the TC string implementation errors. |
OneTrust has implemented the TC string as defined as part of IAB TCF v2. |
There is no 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. |
OneTrust only uses the CMP ID registered by OneTrust with IAB Europe. The OneTrust CMP ID is 28. |
There is no action to take. |
|
3.2 |
The TC string creation date was more than 13 months ago. |
CMP should delete the old TC string and re-obtain consent. |
OneTrust is programmed to re-prompt users if the consent string creation date reaches 13 months of age. |
There is no action to take. |
|
3.3 |
The TC string last update date was more than 13 months ago. |
CMP should delete the old TC string and re-obtain consent. |
OneTrust is programmed to re-prompt users if the consent string creation date reaches 13 months of age. |
For more information, see IAB TC String Expiration Known Issue. |
|
4.1 |
The TC string generated using a version of the GVL in which Google is not yet listed. |
When it becomes available, re-obtain consent using a version of the GVL that includes Google. |
This error triggers if a user’s existing TCF v2 consent uses a GVL from before Google joined the TCF v2 Framework. In other words, if a user responded to a TCF v2 CMP before Google was on the GVL, then the consumer never responded to Google as a vendor.The consumer needs to be reprompted before google can operate. a reprompt can be forced by blocking any vendor on the GVL, and then quickly unblocking it. that will force a reprompt of all consumers |
|
|
5.1 |
The TC string allows Out-of-Band consent. |
Instruct your CMP to remove Out-Of-Band signals from the TC strings. |
OneTrust CMP does not send Out-of-Band signals for a service-specific or group-specific implementation. Either of these scopes are required for Google to serve ads. |
If you are getting this error, it is most likely because "Set Global EU Consent" is enabled in the Geolocation Rules associated with your TCFv2 template. Disable this setting and re-publish your script. |
|
6.1 |
TC string version is 1 or 1.1 (v1.0 string). |
CMP should send TCF v2.0 strings. |
OneTrust supported TCF v1.1 until August 15th 2020 and supports TCF v2. Both signals cannot be sent at the same time. |
Upgrade to the TCFv2 template, apply to Geolocation rules and re-publish accordingly. |
|
7.1 |
gdprApplies is undefined or set to an invalid or indecipherable value, but a valid TC string is present. |
N/A |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
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 |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
7.3 |
Some purposes, features, and/or vendors are out of range (unknown). |
N/A |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
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. |
OneTrust supports the most recent policy and GVL. |
No action to take. |
|
7.5 |
A request has gdpr=1, but doesn't have the gdpr_consent parameter in the request URL at all. |
N/A |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
7.6 |
Invalid publisher country code, but consent to Purpose 1 is present. |
CMP should fix the TC string implementation errors. |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
7.7 |
Invalid language code. |
CMP should fix the TC string implementation errors. |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
7.8 |
TC string version field is neither 1 nor 2. |
CMP should send TCF v2.0 strings. |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |
|
7.9 |
AC string version is not 1. |
CMP should set the AC string version to 1. |
OneTrust has implemented the TC string as defined by IAB TCF v2. |
No action to take. |