Ad Manager and Ad Exchange program policies

Publisher integration with the IAB TCF v2.0

IAB Europe has finalized v2.0 of its Transparency and Consent Framework developed with IAB Tech Lab and mutual member companies. Google now fully supports TCF v2.0.

Google does not require adoption of TCF v2.0. This article describes a few important implementation details that publishers should keep in mind if they choose to adopt the IAB TCF v2.0.

As a publisher, you are not required to use the IAB TCF v2.0. You can continue to use other means to comply with our EU User Consent policy.

To integrate with the IAB TCF v2.0 a publisher must implement a TCF v2.0 registered CMP on their site or app. The CMP creates and sends the TC (Transparency & Consent) string. Then, Google’s ad tags and SDKs consume the TC string they receive from the CMP.

If you do not have consent for Google for Purpose 1 (Store and/or access information on a device), you should not call Google’s ad tag.

General guidance

If you have already implemented an IAB TCF v2.0 registered CMP on your site or site or app, Ad Manager will automatically begin consuming the TC string from the CMP without the need for re-configuration.

Any CMP vendor selections in your IAB TCF v2.0 registered CMP will override Ad Technology Provider selections in the EU User Consent Controls. This includes if you have selected to serve non-personalized ads for all EEA users via the EU User Consent Controls.

If you have set NPA in your ad request, we will look at that and the consent indicated by the TC string and apply the most conservative setting.

  • Passing the TC string to tags: GPT, GPT Passbacks, AdSense, and Ad Exchange Tags will automatically communicate with the IAB CMP to forward the TC string to Ad Manager without publisher configuration. IMA SDK and Mobile Ads SDK will automatically obtain, parse, and respect the TC string from within local storage. When Ad Manager publishers use Tagless Requests in the place of an ad tag to request the raw creative code trafficked in the ad server, we do not have tags on the page that could interact with the CMP API. In this case we therefore rely on publishers sending us the TCF string in URL parameters defined by the TCF spec. To do so, publishers will need to pass the following signals manually: gdpr={0,1} and gdpr_consent={tc string}. You can also optionally pass addtl_consent={ac string}.
    Ad  Manager won't request ads until a valid TC string is received.
  • Passing the TC string to programmatic: The IAB TC string is automatically passed to Google’s programmatic channels without configuration required by publishers.
  • Passing the TC string to non-programmatic creatives: Work with your creative provider to identify whether you need additional configuration for your creatives to ensure they consume the TC string correctly. Ad Manager offers support for the IAB TCF macros (${GDPR}, ${GDPR_CONSENT_XXXX}, and ${ADDTL_CONSENT}) to enable you to manually pass the TC string to other creative vendors as needed. Learn more about IAB TCF v2.0 and reservations
  • Passing the TC string to mediation partners: The IAB TC string will be available in device local storage (NSUserDefaults for iOS or SharedPreferences for Android) and accessible to all mediation partners to obtain, parse, and respect when called in a mediation waterfall request.

Requirements: Personalized & Non-Personalized Ads

Our interoperability guidance is intended to reflect Google's existing policy requirements, in particular the requirements of Google's EU User Consent policy and our policies against fingerprinting for identification (for example, those contained in our Requirements for Third-party Ad Serving). Google’s policies continue to apply and are more restrictive than TCF v2.0 in some cases.

Publishers should review the registration settings for the vendors they choose to work with via the TCF v2.0. The following requirements apply specifically when Google is a vendor in the publishers’ CMP.

Requirements to serve personalized ads

Google will serve personalized ads when all of the following criteria are met:

  • The end user grants Google consent to:
    • Store and/or access information on a device (Purpose 1)
    • Create a personalized ads profile (Purposes 3)
    • Select personalized ads (Purposes 4)
  • Legitimate interest is established (or consent is granted, where a publisher configures their CMP to use publisher restrictions to request consent for Google) for Google to:
    • Select basic ads (Purpose 2)
    • Measure ad performance (Purpose 7)
    • Apply market research to generate audience insights (Purpose 9)
    • Develop and improve products (Purpose 10)

Requirements to serve non-personalized ads

If the requirements for personalized ads are not met, Google will serve non-personalized ads when all of the following criteria are met:

  • The end user grants Google consent to:
    • Store and/or access information on a device (Purpose 1)
  • Legitimate interest (or consent, where a publisher configures their CMP to request it) is established for Google to:
    • Select basic ads (Purpose 2)
    • Measure ad performance (Purpose 7)
    • Apply market research to generate audience insights (Purpose 9)
    • Develop and improve products (Purpose 10)
If neither set of requirements above are met, no ads will be served.

We will handle the following scenarios according to the table below:

Description Ad serving behavior

Lack of consent for Google to store and/or access information on a device (Purpose 1)

In line with our existing EU User Consent policy, consent for cookies or mobile identifiers is required for both personalized and non-personalized ads. For non-personalized ads, consent for cookies or mobile identifiers is still required because non-personalized ads still use cookies or mobile identifiers to combat fraud and abuse, for frequency capping, and for aggregated ad reporting.

Publishers should not call Google’s ad tags.

If consent is missing for Google for Purpose 1 in the TC string, Google will drop the ad request and no ads will be served.

Global scope & Out-of-band scope

Per our existing EU User Consent policy, you must clearly identify each party that may collect, receive, or use end users’ personal data as a consequence of your use of a Google product. Learn more about Scope of Legal Basis

Because it is infeasible to clearly identify each party when using global scope we do not support it. During the transition period that starts when we begin reading and passing the TC string for all ad requests, we will serve non-personalized ads to allow publishers to make adjustments. After the three month transition period, we will not serve an ad if the TC string indicates “Out-of-band” or “Global scope.”

Invalid TC string

The TC string is not parseable (for example some fields are missing).

During the transition period that starts when we begin reading and passing the TC string for all ad requests we will serve non-personalized ads to allow publishers to make adjustments. After the 3-month transition period, we will not serve an ad if the TC string is invalid.

Flexible vendor registration & publisher restrictions

TCF v2.0 affords publishers the ability to customize a variety of restrictions. These allow publishers to indicate their own preferences, which will take precedence over a vendor’s preferences, where applicable. Publishers can never cause a vendor to operate under a lawful basis or for a purpose which conflicts with the vendor’s Global Vendor List registration. Hence these are termed restrictions in that they never expand the scope of what a vendor can do but only restrict it.

Publishers should review the registration settings for the vendors they choose to work with via the TCF v2.0. If a vendor has registered flexibly with “legitimate interest” as the default lawful basis for a purpose where Google requires “consent” per our interoperability guidance, if a publisher wants to work with that vendor via Google products they should choose consent for that vendor in the publisher restrictions of their CMP.

Google is flexibly registered for purposes 2, 5, 6, 7, 9, and 10 and defaults to legitimate interest. Unless a publisher configures their CMP to restrict Google to consent for these purposes, Google will rely on legitimate interest where the CMP has established it with the user. Google is not flexibly registered for purposes 1, 3, and 4 and always requires consent for these purposes.

Funding Choices will automatically create publisher restrictions so as to choose consent for Purposes 3 and 4 if a vendor has registered flexibility.

Scope of Legal Basis

The IAB TCF v2.0 provides options for publishers to choose the scope of a legal basis for the processing of personal data as outlined below. This information is passed using the TC string. Google policies require that publishers choose either (a) service-specific scope or (b) group-specific scope.

  • Service-specific scope: A Legal Basis is applicable only on the service, for example a Publisher website or app, on which the Legal Basis is obtained and managed. (ALLOWED when working with Google)
  • Group-specific scope: A Legal Basis is applicable only on a pre-defined group of services, for example a number of Digital Properties of one or more Publishers that implement CMPs with their group’s scope, each of which allows users to manage their choices regarding Legal Bases established for the group across all the services of the group. All component digital properties must be disclosed at the consent moment. (ALLOWED when working with Google)
  • Global scope: A Legal Basis is not only applicable on the service, on which the Legal Basis is obtained and managed, but across all Publisher Digital Properties, that implement CMPs with global scope each of which allows users to manage their choices regarding globally established Legal Bases across all such Publisher Digital Properties. (NOT ALLOWED when working with Google)
  • Out-of-band (“OOB”): A Legal Basis has not been established using the Framework and is therefore not reflected in any Signals within the Framework and cannot be managed by users within the Framework. (NOT ALLOWED when working with Google)

Publishers should choose service-specific (or group-specific) scope if they want to work with Google.

Additional Consent Mode

Additional Consent Mode is a temporary technical specification 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 enables 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.

Learn more about Additional Consent Mode

Real-Time Bidding (RTB) & Open Bidding

The IAB TCF v2.0 logic will apply to bid requests, bid responses, and cookie-matching requests.

We will allow bid requests to be sent and enable cookie matching when a vendor registers with “Consent” or, in limited cases, “Not used” for Ads Personalization (Purposes 3 and 4 in the TC string). Vendors that register for “Consent” for the Personalized Ads purposes (Purposes 3 and 4 in the TC string), but have not been granted consent by the user:

  • Won’t receive bid requests.
  • Won’t receive a response to cookie match requests.

Additionally, the user must have given Google consent for Purpose 1, Purpose 3, and Purpose 4.

Reservations

We have launched a solution to support IAB TCF v2.0 for reservations, including controls to indicate the vendors you’re working with on reservations. No matter when you choose to integrate with the IAB TCF v2.0, this solution won’t start to affect reservations serving until after Google starts reading and passing the TC string for all ad requests. We have provided access to the new controls ahead of time so that publishers can become familiar with them before any impact on delivery begins.

Learn more about declaring ad technology providers for creatives in Ad Manager reservation campaigns

Mediation

If you have chosen to adopt the IAB TCF v2.0 solution, please ensure that you are surfacing all of your mediation partners in your CMP. This will ensure that Google can continue to make call outs to all partners in your mediation waterfall.

The TC and AC strings will be evaluated by serving prior to the construction of the mediation waterfall and identify whether the mediation partner is present in one of the strings.

  • If the mediation partner is present and the user has consented or legitimate interest has been established for at least one purpose, the mediation partner will be included in the mediation waterfall as it is constructed.
  • If the mediation partner is not present or the mediation partner has been fully declined by the user, the mediation partner will not be called in the mediation waterfall.

Cookie matching

We support the gdpr and gdpr_consent field to pass TCF v2.0 consent information for both in-bound and out-bound cookie sync requests. These parameters are optional.

If the &gdpr and &gdpr_consent parameters are present in the cookie match request, Ad Manager will sync cookies with third-party vendors request if all of the following criteria are met:

  • The end user grants Google consent to:
    • Store and/or access information on a device (Purpose 1)
    • Create a personalized ads profile (Purposes 3)
    • Select personalized ads (Purposes 4)
  • Legitimate interest (or consent, where a publisher configures their CMP to request it) is established for Google to:
    • Select basic ads (Purpose 2)
    • Measure ad performance (Purpose 7)
    • Apply market research to generate audience insights (Purpose 9)
    • Develop and improve products (Purpose 10)​
  • The end user does not permit the vendor to use legitimate interest for "Create a personalized ads profile" (Purpose 3).
  • The end user does not permit the vendor to use legitimate interest for "Select personalized ads" (Purpose 4).
  • Each vendor either does not register for "Actively scan device characteristics for identification" (Special Feature 2), or registers Special Feature 2, but the Transparency & Consent (TC) string indicates the user did not opt-in to Special Feature 2.
  • Each vendor needs to register for at least one purpose and have obtained a valid legal basis for that purpose.
  • The end user grants the vendor consent for “Store and/or access information on a device” (Purpose 1).
Was this helpful?
How can we improve it?