Ads personalization settings in Google’s publisher ad tags

Publishers with users in the EEA, the UK, and Switzerland should refer to Publisher integration with the IAB TCF. Publishers interested in providing users with enhanced privacy treatments can learn more about the Publisher Privacy Treatment API.

Ads personalization settings in Google’s publisher ad tags can be set in any region globally. 

Ads personalization settings for pages using GPT and AdSense tags

Requesting ads

By default, ad requests to Google serve personalized ads, with ad selection based on both the content of the web page and the history of the individual user visiting the page. Google also supports serving non-personalized ads. Learn more about personalized and non-personalized ads. 

If you wish to serve some users personalized ads, and other users non-personalized ads, GPT and AdSense/Ad Exchange asynchronous ad tags offer publishers a way to trigger the serving of non-personalized ads on a per-page basis. This may be useful if you give all or some of your users a choice between personalized and non-personalized ads.

Although these ads don’t use cookies for ad personalization, they do use cookies to allow for frequency capping and aggregated ad reporting. Consent is therefore required to use cookies for those purposes from users in countries to which the ePrivacy Directive’s cookie provisions apply. Learn more about non-personalized ads

Set NPA=1 using the GPT tag

Use the following method:

googletag.pubads().setPrivacySettings({nonPersonalizedAds: true})

The setCookieOptions() call does not apply to GDPR.

Learn more on Google Developers

Set PPT=1 using the GPT tag

Use the following method:

googletag.setConfig({privacyTreatments: { treatments: ["disablePersonalization"]}})

Learn more on Google Developers

Set NPA=1 using the AdSense and Ad Exchange asynchronous ad tag

Set the following value:

(adsbygoogle=window.adsbygoogle||[]).requestNonPersonalizedAds=1

Verify that an ad tag is requesting non-personalized ads by finding the ad request in your browser developer tools and looking for the parameter &npa=1.

Calling setPrivacySettings({nonPersonalizedAds: false}) or setting requestNonPersonalizedAds=0 will re-activate personalization.

Set PPT=1 using the AdSense and Ad Exchange asynchronous ad tag

  • Option 1: Push API

    Use the push method:

    (adsbygoogle=window.adsbygoogle||[]).push({ params: {google_privacy_treatments: 'disablePersonalization'}})

    Verify that an ad tag is requesting non-personalized ads by finding the ad request in your browser developer tools and looking for the parameter &ppt=1.
     
  • Option 2: Header tag API

    Set the data-privacy-treatments on the adsbygoogle script tag. For example:

    <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js" data-privacy-treatments='disablePersonalization'></script>

Pausing ad requests

GPT and AdSense/Ad Exchange asynchronous tags support techniques to load your page but wait for an explicit signal before beginning to issue ad requests. This may be useful if you need to wait for the user to interact with a consent request UI before issuing ad requests.

Pause GPT ad requests

  • Use the disableInitialLoad() function to prevent the tag from sending ad requests on initial page load. You must do this before triggering any ad requests using display().
  • Set up your ad slots using calls to googletag.cmd.push(...) as usual.
  • After the user has made their consent choice, call setPrivacySettings({nonPersonalizedAds: true}) if needed.
  • Use the refresh() function to resume sending ad requests.
  • If you don't call refresh(), no ads will appear.

Pause AdSense or Ad Exchange asynchronous ad code

  • Use (adsbygoogle=window.adsbygoogle||[]).pauseAdRequests=1 to prevent the tag from sending ad requests. You must do this before triggering any ad requests by using adsbygoogle.push(...).
  • Set up your ad slots using calls to adsbygoogle.push(...) as usual.
  • After the user has made their consent choice, set requestNonPersonalizedAds=1 if needed.
  • Use (adsbygoogle=window.adsbygoogle||[]).pauseAdRequests=0 to resume sending ad requests.
  • If you don't set pauseAdRequests=0, no ads will appear.

This technique blocks ad requests from being sent, but various scripts are still loaded. While existing cookies on Google’s domains may be read, no new cookies will be set. Any data associated with existing cookies will not be used for ad serving or measurement.

If your consent management solution offers a way to defer loading scripts until the user has exercised a choice, then another option is to defer loading gpt.js and adsbygoogle.js. Other types of Google ad tags do not support pausing of ad requests; you need to avoid loading them until you are ready to request either personalized or non-personalized ads.

Ads personalization settings for AMP pages

Ad requests from AMP pages offer the same ads personalization settings as the non-AMP pages previously described: publishers may choose to serve non-personalized ads to all users within a location, or they may choose to serve personalized/non-personalized ads selectively based on consent.

Following are directions on how to configure each scenario for AMP pages that request ads with <amp-ad type="doubleclick"> or <amp-ad type="adsense">.

Serving non-personalized ads to users within a location

If your AMP ad tags do not use Real Time Config (RTC), you may simply activate non-personalized ad serving in the Google Ad Manager or AdSense UIs, and no further changes to your AMP pages are needed.

If your AMP ad tags do use Real Time Config (RTC), your page can be configured to avoid sending RTC requests for users who will receive non-personalized ads (for example, those in the EEA, the UK, and Switzerland). Following are the necessary components and configurations (amp-geo and amp-consent) to do that. 

<!-- First we need to set up the amp-geo extension. We define a group: `eea` which includes all European Economic Area countries and the UK. You will need to keep this list up-to-date as membership in the EEA may change over time. -->
<amp-geo layout="nodisplay">
  <script type="application/json"
    {
      "ISOCountryGroups": {
        "eea": [ "at", "be", "bg", "cy", "cz", "de", "dk", "ee", "es", "fi", "fr",
        "gb", "gr", "hr", "hu", "ie", "is", "it", "li", "lt", "lu", "lv", "mt", "nl",
        "no", "pl", "pt", "ro", "se", "si", "sk"]
      }
    }
  </script>
</amp-geo


<!-- Next we need to set up a consent component for end users in EEA countries. We'll later configure it to be auto-rejected, so it doesn't actually prompt for consent. This halts RTC callouts and signals Ad Manager/AdSense to serve non-personalized ads. -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
      "consents": {
        "my_consent": {
          "promptIfUnknownForGeoGroup": "eea"
        }
      }
    }
  </script>
</amp-consent

You must add the attribute data-block-on-consent to any existing amp-ad components on the page as indicated in the following code sample:

<!-- Finally we set up the ad tag, directing it to automatically reject consent -->
<amp-ad data-block-on-consent="_auto_reject"
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad

Serving personalized/non-personalized ads based on consent

Since AMP does not allow custom JavaScript, the requesting of personalized or non-personalized ads is based on the configuration of an amp-consent component, and the attributes data-block-on-consent and data-npa-on-unknown-consent. Assuming you have configured an amp-consent component and linked it to all <amp-ad> tags on the page using data-block-on-consent:

  • If the user has responded affirmatively to the amp-consent component (user accepts the consent prompt), ads will be requested normally.
  • If the user has responded negatively to the amp-consent component (user rejects the consent prompt), non-personalized ads will be requested.
  • If the user’s response to the amp-consent is unknown (user dismisses the consent prompt):
    • By default, no ad requests are sent at all.
    • If data-npa-on-unknown-consent is set to true, non-personalized ads will be requested.
  • If you configure an amp-geo component such that consent is not applicable based on the user’s geographical location, requests are sent normally.

If your <amp-ad> tags do not use data-block-on-consent, or the amp-consent component has not been correctly configured, requests are sent normally.

The following code sample is an example of a configuration that prompts all users in the EEA for consent, with resulting behavior as described above:

<!-- First, set up the amp-geo extension. We define a group: `eea` which includes all European Economic Area countries. You must keep this list up-to-date as membership in the EEA may change over time. -->
<amp-geo layout="nodisplay">
  <script type="application/json">
    {
      "ISOCountryGroups": {
        "eea": [ "at", "be", "bg", "cy", "cz", "de", "dk", "ee", "es", "fi", "fr",
        "gb", "gr", "hr", "hu", "ie", "is", "it", "li", "lt", "lu", "lv", "mt", "nl",
        "no", "pl", "pt", "ro", "se", "si", "sk"]
      }
    }
  </script>
</amp-geo>
 
<!-- Next, set up the consent for users in the `eea` country group -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
      "consents": {
        "my_consent": {
          "promptIfUnknownForGeoGroup": "eea",
          "promptUI": "myConsentFlow"
        }
      }
    }
  </script> 
</amp-consent


<!-- Finally, set up the ad tag, directing it to wait for consent when necessary -->
<amp-ad data-block-on-consent
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad>

There are other ways to selectively prompt users for consent, including configuring the page to send a CORS POST request to an endpoint you configure via checkConsentHref. You can learn more by reading the amp-consent documentation.

Ads personalization settings for other tags

GPT passback tags

If you're using GPT passback tags, you can mark an ad request as non-personalized by including the following in your API call:

googletag.pubads().setPrivacySettings({nonPersonalizedAds: boolean})

Set the boolean value to true to mark the ad request as NPA, and to false for ad requests that are eligible for personalized ads.

Omission of this setting defaults to allowing personalized ads.

Tagless Request

if you're using Tagless Request, you can mark an ad request as non-personalized by adding the npa=[int] parameter directly to the tag request URL. We recommend you specify the parameter early in the tag to avoid any risk of truncation. Specify npa=1 to mark the ad request as non-personalized. Omission of the parameter defaults to personalized ads.

For example:

https://securepubads.g.doubleclick.net/gampad/ad?iu=/12345/adunit&sz=728x90&npa=1&c=12345

AdSense for Search

By default, ad requests to Google serve personalized ads, with ad selection based on both the user’s search query and the history of the individual user doing the search. Google also supports serving non-personalized ads. Learn more about personalized and non-personalized ads

If you wish to serve some users personalized ads, and other users non-personalized ads, the AdSense for Search tags offer publishers a way to trigger the serving of non-personalized ads on a per-page basis. This may be useful if you give all or some of your users a choice between personalized and non-personalized ads.

For the Custom Search Ads web ad tag

Add the following to the pageOptions in the Custom Search Ads tag:

personalizedAds: false,

For the AdMob tag

builder.setAdvancedOptionValue("personalizedAds", "false");

For the iOS tag

[request setAdvancedOptionValue:@"false" forKey:@"personalizedAds"];

These methods will trigger non-personalized ads requests for that particular request. This is a stateless parameter. If the parameter is not set in subsequent requests for that user, the behavior will revert to the default behavior, which is to request personalized ads.

Google User Messaging Platform (UMP) SDK

Review the Google Developers documentation (iOS UMP SDK, Android UMP SDK) for more information on how the User Messaging Platform SDK can help your app comply with Google’s EU user consent policy.

Google Interactive Media Ads SDK (for Video)

On video requests, you can indicate that you want Google to treat your video content as non-personalized when you append the npa=1 parameter to your ad tag. You can do this with a manually constructed master video tag or using any of the platform-specific IMA SDKs (HTML 5 IMA SDK, iOS IMA SDK, Android IMA SDK, Google Cast IMA SDK).

If your video player uses Ad Manager's Dynamic Ad Insertion feature, it can also include the npa=1 parameter with a video on demand (VOD) or live stream request to pass the parameter to any included ad requests (DAI HTML5 SDK, DAI Cast SDK, DAI iOS SDK, DAI Android SDK, DAI Roku SDK, DAI tvOS SDK).

Legacy Google publisher ad tags

Other types of Google ad tags (for example, the legacy GAM tag, GUT tag, and AdSense or Ad Exchange synchronous tag (show_ads.js)) do not support issuing non-personalized ad requests. Avoid loading these tags until you are ready to request personalized ads.

Alternatively, you may find that it's easier to maintain compliance with the EU User Consent Policy by migrating to one of the tags that has full-feature support for both personalized and non-personalized ads, and pausing requests to collect any required consent.

Was this helpful?

How can we improve it?

Need more help?

Try these next steps:

Post to the help community Get answers from community members
Contact us Tell us more and we’ll help you get there
true
Release notes

Read about the latest Ad Manager features and Help Center updates.

See what's new

Search
Clear search
Close search
Main menu
3206595161571721275
true
Search Help Center
true
true
true
true
true
148
false
false