IAB TCF2.0 and Google Ads

Google IAB TCF v2 Error Codes 

This document is likely to change as Google changes their IAB support, and as Osano continues to work with this vendor. 

Google has joined Transparency and Consent Framework v2. 

Publishers that use Google Ad Manager or other Google Ads products may receive error messages concerning their setup and implementation of a TCF v2 CMP. Some users have reported difficulties with setting up the CMP so that Google receives consent in time and serves their ads based on the consent signal received. This document will outline some of the most common Google Ad Network error codes and provides steps to help address those.

Google has cataloged all of the possible error codes they provide HERE.

Below are some common error codes that you MAY see related to the use of a consent manager:

Error Code Google’s Description Google’s suggested action to take Reason for issue in Osano Steps to address in Osano
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 likely not presented with an option to respond to the Google Ad Platform as a vendor. This error results from the consumer having not been presented with Google as a vendor in the CMP.  

Be sure Google is added as a Vendor in the IAB tab of your Osano configuration. 
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. German publishers should ensure they are setting the PublisherCC and PurposeOneTreatment fields correctly if they are not asking users for consent. The consumer has rejected consent for Purpose 1 (storage). Google will not operate without consent for Purpose 1. There is no fix for this as the consumer 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 "purpose consent" or "legitimate interest." If a consumer 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 the consumer has declined all legal bases Google needs.
2.1a Tag or SDK isn’t receiving a TC string due to CMP status being stubloading, or error. Ask your CMP to ensure that their APIs are properly implemented based on the IAB TCF tech spec. This error occurs due to page latency or because Google tags are fired before the IAB TC string is set or before a consumer has provided a consent answer. Per the ePrivacy Directive and EU Google Policy, a consumer must establish a valid legal base through Osanobefore Google tags can be set.

Ensure that Google is categorized correctly. All Google Advertising scripts and cookies should be classified as "Marketing." For them to load in the appropriate sequence. 

If the error persists, the site owner must prevent all tags from firing until a TCF response is obtained from Osano. (See 'The 2.1a Error' below for details)

The 2.1a Error

A common issue experienced by publishers working with Google as a vendor under TCF v2.0 is an error with the code: “2.1a”. (See Description Above)

According to IAB Europe, most TCF vendors check whether or not the TC String is available before triggering their logic to determine a legal basis to process personal data. This consistency in implementation by TCF vendors causes publishers to expect Google to do the same [for example, see Scenario 1 in the diagram below]. This is NOT the case with Google. 

Scenario 1: (Supported by most IAB vendors but NOT supported by Google)

  1. Publisher sends a Request Ads Call to Google
  2. Google adds an event listener and listens for the event tcData.eventStatus 'tcLoaded' from the CMP
  3. CMP sends a callback to Google/Publisher indicating 'tcLoaded'
  4. Google Serves Ads to Publisher

Scenario 1 is NOT supported by Google.

Google expects the publisher to make sure the TC String is available via the CMP before requesting ads; see Scenario 2 below:

Scenario 2: (Google ONLY supports this scenario) 

  1. Publisher adds an event listener and listens for the event tcData.eventStatus 'tcLoaded' from the CMP
  2. CMP sends a callback to Publisher indicating 'tcLoaded'
  3. Publisher sends a Request Ads Call to Google
  4. Google Serves Ads to Publisher

What Does This Mean?

When working with Google, it’s the publisher’s responsibility to ensure that the TC String is available before making the Google ads call. If the ads call is made before the TC String is available, this results in a “2.1a” error.

This means that publishers should include conditional logic on the ads call to ensure that the TC String is available before the request for ads is made.

You can review the documentation on adding event listeners HERE.

The IAB Europe has reached out to Google to emphasize the importance of this issue for publishers. In the meantime, it is encouraged that all publishers who have experienced this issue to contact Google directly and request that they support Scenario 1.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.