EU user consent policy

Ads personalisation settings in Google’s publisher ad tags

Under Google’s updated EU User Consent Policy, you must make certain disclosures to your users in the European Economic Area (EEA) and obtain their consent for the use of cookies or other local storage where legally required, and for the collection, sharing and use of personal data for ads personalisation. This policy reflects the requirements of the EU ePrivacy Directive and the General Data Protection Regulation (GDPR).

Ads personalisation settings for pages using GPT and AdSense tags

Requesting ads

By default, ad requests to Google serve personalised 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-personalised ads. Learn more about personalised and non-personalised ads

If you've met the requirements of our Consent Policy and you want to serve personalised ads to all users located in the European Economic Area who visit your site, no changes to your ad tagging are needed. You can enable non-personalised ad serving in the AdSense for content or Google Ad Manager UIs.

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

Although these ads don’t use cookies for ad personalisation, they do use cookies to allow for frequency capping, aggregated ad reporting and to combat fraud and abuse. 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-personalised ads.

For the GPT tag:

Use the method: googletag.pubads().setRequestNonPersonalizedAds(1)

For the AdSense and Ad Manager asynchronous ad tag:

Set the value: (adsbygoogle=window.adsbygoogle||[]).requestNonPersonalizedAds=1

These methods will trigger non-personalised ads requests for subsequent Google ad requests from the page issued by the following supported ad tags: GPT, GPT Light, AdSense or Ad Manager asynchronous ad tags (adsbygoogle.js), the old synchronous AdSense tag (show_ads.js) and the IMA SDK. Verify that an ad tag is requesting non-personalised ads by finding the ad request in your browser developer tools and looking for the parameter &npa=1.

Calling setRequestNonPersonalizedAds(0) or setting requestNonPersonalizedAds=0 will reactivate personalisation. If a page contains multiple types of Google ad tags (for example, both a GPT tag and an AdSense/Ad Manager asynchronous tag), it may be impossible to predict which will execute first. So, to be safe, use the non-personalised ads control for each type of tag.

Pausing ad requests

GPT and AdSense/Ad Manager 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.

When using GPT: Delaying ad requests is possible if you use async mode.

  • 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 setRequestNonPersonalizedAds(1) if needed.
  • Use the refresh() function to resume sending ad requests.
  • If you don't call refresh(), no ads will appear. It's not possible to delay requests if you use enableSyncRendering().

When using AdSense or Ad Manager 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 won't 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 don't support pausing of ad requests; you need to avoid loading them until you're ready to request either personalised or non-personalised ads.

For more help with AdSense tags, see our Ad code examples for ads personalisation settings.

Ads personalisation settings for AMP pages

Ad requests from AMP pages offer the same ads personalisation settings as the non-AMP pages previously described: publishers may choose to serve non-personalised ads to all users located in the European Economic Area (EEA), or they may choose to serve personalised/non-personalised 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-personalised ads to all EEA users

If your AMP ad tags do not use Real Time Config (RTC), you may simply enable non-personalised 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-personalised ads (i.e. those in the EEA). 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. You'll 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 the consent with 0 timeout (i.e. it doesn’t show a consent UI at all) and default 'rejected' consent state. This halts RTC callouts and signals DFP/AdSense to serve non-personalised ads. -->
<amp-consent layout='nodisplay' id='consent-element'>
  <script type='application/json'>
    {
      'consents': {
        'my_consent': {
          'promptIfUnknownForGeoGroup': 'eea'
        }
      }
      'policy': {
        'default': {
          'waitFor': {
            'my_consent': []
          }
          'timeout': {
            'seconds': 0,
            'fallbackAction': 'reject'
          }
        }
      }
    }
  </script>
</amp-consent>

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

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

Serving personalised/non-personalised ads based on consent

Since AMP does not allow custom JavaScript, the requesting of personalised or non-personalised 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 that you've 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-personalised 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-personalised ads will be requested
  • If you configure an amp-geo component such that consent isn't applicable based on the user’s geographical location, requests are sent normally.

If your <amp-ad> tags don't use data-block-on-consent, or the amp-consent component hasn't been correctly configured, requests are sent normally.

Following is an example of a configuration that prompts all users in the EEA for consent, with resulting behaviour as described above:

<!-- First we need to set up the amp-geo extension. We define a group: 'eea' which includes all European Economic Area countries. You'll 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 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 we 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>
 

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

Ads personalisation settings for other tags

GPT passback tags

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

googletag.pubads().setRequestNonPersonalizedAds(int options);

Set the options parameter to the integer value 1 to mark the ad request as NPA, and to 0 for ad requests that are eligible for personalised ads.

Omission of this setting defaults to allowing personalised ads.

Example:

<script src='https://www.googletagservices.com/tag/js/gpt.js'>
googletag.pubads().setRequestNonPersonalizedAds(1);
googletag.pubads().definePassback('123456/ad/unit', [100,200])
    .display();
</script>

Simple URLs

If you're using simple URLs, you can mark an ad request as non-personalised by adding the npa=[int] parameter directly to the tag request URL. We recommend that you specify the parameter early in the tag to avoid any risk of truncation. Specify npa=1 to mark the ad request as non-personalised. Omission of the parameter defaults to personalised ads. For example:

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

AdSense for Search

By default, ad requests to Google serve personalised 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-personalised ads. Learn more about personalised and non-personalised ads.

If you wish to serve some users personalised ads, and other users non-personalised ads, the AdSense for Search tags offer publishers a way to trigger the serving of non-personalised ads on a per-page basis. This may be useful if you give all or some of your users a choice between personalised and non-personalised 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-personalised ads requests for that particular request. This is a stateless parameter. If the parameter isn't set in subsequent requests for that user, the behaviour will revert to the default behaviour, which is to request personalised ads.

Google Mobile Ads SDK

Please see the app developer site (iOS GMA SDK, Android GMA SDK) for more information on the Google Mobile Ads SDK.

Google Interactive Media Ads SDK (for Video)

On video requests, you can indicate that you want Google to treat your video content as non-personalised 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 (HTML5 IMA SDK, iOS IMA SDK, Android IMA SDK, Google Cast IMA SDK).

If your video player uses Google 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).

Was this helpful?
How can we improve it?