Definições de processamento de dados restrito nas etiquetas de anúncios do publicador Google

Todas as definições de processamento de dados restrito por pedido que configurar são aplicadas a nível global. Por exemplo, se adicionar parâmetros de processamento de dados restrito por pedido a um pedido para um utilizador de um Estado aplicável dos EUA, o modo de processamento de dados restrito é ativado e só são publicados anúncios não personalizados.

• Definições de processamento de dados restrito para páginas que usam etiquetas da GPT e do AdSense
• Definições de processamento de dados restrito para outras etiquetas
  • Etiquetas de passback da GPT
  • Pedido sem etiqueta
  • SDK de Anúncios para Dispositivos Móveis da Google
  • SDK para Anúncios Multimédia Interativos da Google (para vídeo)
  • Etiquetas de anúncios do publicador Google antigas
  • AdSense para pesquisa

Definições de processamento de dados restrito para páginas que usam etiquetas da GPT e do AdSense

Solicitar anúncios

Por predefinição, os pedidos de anúncios para a Google não limitam a forma como os dados são processados e como os anúncios personalizados são publicados, e a seleção de anúncios baseia-se no conteúdo da página Web e no histórico do utilizador individual que visita a página. A Google já suporta o envio de sinais através de etiquetas de anúncios por várias razões de conformidade regulamentar e privacidade, incluindo:

• Definições de anúncios não personalizados nas etiquetas de anúncios do publicador Google 
  (Ad Manager, AdMob, Android e iOS, AdSense)
• Etiquetagem de um pedido de anúncio para utilizadores no EEE com idade inferior à idade de consentimento (TFUA)
  (Ad Manager, AdMob, AdSense)
• Etiquetagem de um pedido de anúncio para tratamento dirigido a crianças (TFCD)
  (Ad Manager, AdMob, AdSense)
  Os publicadores podem optar por usar o parâmetro TFCD para etiquetar pedidos para utilizadores menores de idade. O processamento de dados restrito também será ativado após a definição do parâmetro TFCD.

Este artigo descreve como solicitar o modo de processamento de dados restrito através de etiquetas de anúncios. Quando ativa o processamento de dados restrito, a Google limita a forma como usa os dados e só publica anúncios não personalizados. Se pretender ativar o processamento de dados restrito para todos os utilizadores localizados na Califórnia que visitam a sua propriedade, não é necessário efetuar alterações à etiquetagem dos anúncios. Pode ler mais acerca do processamento de dados restrito, incluindo como ativá-lo na IU, nos Centros de Ajuda da Google Ad Manager, AdMob ou AdSense.

Se pretender ativar o processamento de dados restrito apenas para alguns utilizadores, as etiquetas da GPT e as etiquetas de anúncios assíncronas do AdSense/Ad Exchange oferecem aos publicadores uma forma de acionar a publicação do processamento de dados restrito por página. Isto pode ser útil se optar por apresentar um link para recusar "Não vender as minhas informações pessoais". Para os utilizadores que optem pela recusa, pode decidir que a transmissão deste sinal satisfaz as suas obrigações regulamentares. Consulte "Ajudar os publicadores a agir em conformidade com as leis da privacidade dos Estados Unidos" (Google Ad Manager, AdMob, AdSense) para obter mais informações acerca do modo de processamento de dados restrito.

• Para a etiqueta da GPT, use o seguinte fragmento do código:

  googletag.pubads().setPrivacySettings({
'restrictDataProcessing': true
});

• Para a etiqueta do anúncio assíncrona do AdSense e do Ad Exchange, use o seguinte fragmento do código:

  <ins class="adsbygoogle"
style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-0123456789abcdef"
data-ad-slot="0123456789"
data-restrict-data-processing="1"></ins>

Estes métodos acionam o processamento de dados restrito para pedidos de anúncios Google subsequentes na página, emitidos pelas seguintes etiquetas de anúncios suportadas: GPT, etiquetas de anúncios assíncronas (adsbygoogle.js) do AdSense ou do Ad Exchange e o SDK para IMA. Confirme se uma etiqueta do anúncio está a restringir o processamento de dados ao localizar o pedido de anúncio nas ferramentas para programadores do seu navegador e ao procurar o parâmetro &rdp=1.

Estas APIs permitem desativar o processamento de dados restrito (e a reativação da personalização) ao passar false e 0, consoante o tipo esperado pela API. Se uma página tiver vários tipos de etiquetas de anúncios Google (por exemplo, uma etiqueta da GPT e uma etiqueta assíncrona do AdSense/Ad Exchange), tem de usar o controlo de processamento de dados restrito (PDR) para cada tipo de etiqueta.

Definições de processamento de dados restrito para outras etiquetas

Etiquetas de passback da GPT

Se estiver a usar etiquetas de passback da GPT, pode marcar um pedido de anúncio como processamento de dados restrito ao usar a mesma API googletag.pubads().setPrivacySettings que a GPT tradicional usa.

Em caso de omissão desta definição, assume-se a permissão de anúncios personalizados como predefinição.

Exemplo de código:

<script async
src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<div id='gpt-passback'>
  <script>
     window.googletag = window.googletag || {cmd: []};
     googletag.cmd.push(function() {
       googletag
         .defineSlot('/123/sports', [300, 250], 'gpt-passback')
         .addService(googletag.pubads());
       googletag.pubads().setPrivacySettings({
        'restrictDataProcessing': true
       });
       googletag.enableServices();
       googletag.display('gpt-passback');
     });
  </script>
</div>

Pedido sem etiqueta

Se estiver a usar um Pedido sem etiqueta, pode marcar um pedido de anúncio como processamento de dados restrito ao adicionar o parâmetro rdp=[int] diretamente ao URL do pedido da etiqueta. Recomendamos que especifique o parâmetro no início da etiqueta para evitar qualquer risco de truncagem. Especifique rdp=1 para marcar o pedido de anúncio como processamento de dados restrito. Em caso de omissão do parâmetro, o processamento de dados restrito é desativado e são permitidos anúncios personalizados como predefinição. 

Exemplo de código:

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

SDK de Anúncios para Dispositivos Móveis da Google

Consulte o site do programador de apps para obter mais informações sobre o SDK de Anúncios para Dispositivos Móveis da Google.

• AdMob: SDK de GMA para iOS, SDK de GMA para Android
• Ad Manager: SDK de GMA para iOS, SDK de GMA para Android

SDK para Anúncios Multimédia Interativos da Google (para vídeo)

Nos pedidos de vídeo, pode indicar que pretende que a Google trate o seu conteúdo de vídeo como um processamento de dados restrito. Pode fazê-lo com uma etiqueta de vídeo principal criada manualmente (apenas no Ad Manager) ou com qualquer dos SDKs para IMA específicos da plataforma (SDK para IMA para HTML5, SDK para IMA para iOS, SDK para IMA para Android e SDK para IMA para Google Cast).

Se o seu leitor de vídeo usa a funcionalidade Inserção de anúncios dinâmicos do Ad Manager, também pode incluir o parâmetro rdp=1 com um vídeo a pedido (VOD) ou um pedido de stream em direto para passar o parâmetro para quaisquer pedidos de anúncios incluídos (SDK para DAI para HTML5, SDK para DAI para Cast, SDK para DAI para iOS, SDK para DAI para Android, SDK para DAI para Roku, SDK para DAI para tvOS).

Etiquetas de anúncios do publicador Google antigas

Outros tipos de etiquetas de anúncios Google (por exemplo, as etiquetas do GAM, as etiquetas do GUT e as etiquetas síncronas do AdSense ou do Ad Exchange (show_ads.js) antigas) não suportam pedidos de anúncios de processamento de dados restrito. Recomendamos a migração para uma das etiquetas com suporte total de funcionalidades para anúncios personalizados e o modo de processamento de dados restrito.

AdSense para pesquisa

Por predefinição, os pedidos de anúncios para a Google não limitam a forma como os dados são processados e como os anúncios personalizados são publicados, e a seleção de anúncios baseia-se na consulta de pesquisa do utilizador e no histórico do utilizador individual que efetua a pesquisa. Quando ativa o processamento de dados restrito, a Google limita a forma como usa os dados e só publica anúncios não personalizados.

Pode ativar o processamento de dados restrito por pedido, como descrito abaixo, ou ao solicitar ao seu gestor de conta que desative a personalização de propriedades específicas.

• Para a etiqueta do anúncio para a Web dos Anúncios com pesquisa personalizada, adicione o seguinte texto a pageOptions na etiqueta dos Anúncios com pesquisa personalizada:

  personalizedAds: false,

• Para a etiqueta do AdMob:

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

• Para a etiqueta do iOS:

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

Estes métodos vão acionar o processamento de dados restrito e publicar anúncios não personalizados para esse pedido específico. Este é um parâmetro sem estado. Se o parâmetro não for definido em pedidos subsequentes para o utilizador em questão, o comportamento é revertido para o comportamento predefinido, ou seja, solicitar anúncios personalizados.

Accelerated Mobile Pages (AMP)

Estas instruções só se aplicam ao Ad Manager e AdSense. Saiba como configurar cada cenário para páginas AMP que solicitam anúncios com <amp-ad type=”doubleclick”> ou <amp-ad type=”adsense”>.

Para pedidos de anúncios de páginas AMP, os publicadores podem optar por restringir o processamento de dados para todos os utilizadores localizados na Califórnia ou podem optar por restringir seletivamente o processamento de dados ao seguir as instruções abaixo para desativar a personalização. Os publicadores usam as definições de desativação da personalização existentes quando pretendem ativar o processamento de dados restrito. Estes termos são usados de forma intercambiável ao longo deste artigo.

Solicitar anúncios não personalizados para utilizadores nos estados aplicáveis dos EUA

Se usar etiquetas AMP do AdSense, ou etiquetas AMP do DoubleClick sem Real Time Config (RTC), pode simplesmente ativar o processamento de dados restrito nas IUs do Google Ad Manager ou do AdSense e não será necessário fazer mais alterações às suas páginas AMP.

Se as etiquetas de anúncios AMP usarem o Real Time Config (RTC), os pedidos do RTC só são enviados se for dado consentimento ou se este não for necessário. (Nota: pode permitir que pedidos do RTC específicos sejam enviados independentemente do estado do consentimento.) Para evitar o envio de pedidos do RTC para os utilizadores que vão receber anúncios não personalizados (ou seja, os utilizadores da Califórnia), pode usar os seguintes componentes e configurações (amp-geo e amp-consent):

<!-- Configure o componente amp-geo para detetar utilizadores finais dos EUA. Atualmente, o amp-geo só suporta a deteção geográfica ao nível do país, mas a deteção ao nível dos Estados Unidos estará disponível brevemente. Certifique-se de que processa o caso "unknown" (desconhecido) quando o país não pode ser determinado pelo amp-geo e tenha, pelo menos, um grupo que contenha o "unknown" -->
<amp-geo layout=nodisplay>
  <script type="application/json">
    {
      "ISOCountryGroups": {
        "us": ["us"],
        "eea": ["preset-eea", “unknown”]
      }
    }
  </script>
</amp-geo>

<!-- Configure o componente amp-consent para bloquear pedidos e recolher os consentimentos dos utilizadores. Mais tarde, configuramos o componente para ser rejeitado automaticamente, para que não solicite o consentimento. Isto impede pedidos do RTC e indica ao Ad Manager/AdSense que publique apenas anúncios não personalizados. -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
     “consentInstanceId”: “my_consent”,
      “consentRequire”: false,
“geoOverride”: {
  “us”: {
    “consentRequired”: “remote”,
    “checkConsentHref”: “https://your-endpoint” 
  }
}     
  </script>
</amp-consent>

Uma vez que o amp-geo não suporta atualmente a deteção de estados aplicáveis dos EUA, tem de fornecer um ponto final para informar as AMP se for necessário o consentimento do utilizador atual através da definição checkConsentHref. As AMP esperam o retorno de um objeto JSON do ponto final. Encontre mais informações sobre a resposta do ponto final no documento do site AMP.

Se a definição de um ponto final não funcionar para si, a equipa das AMP está a trabalhar numa funcionalidade futura para ajudar a detetar utilizadores dos estados aplicáveis dos EUA. Antes do lançamento dessa funcionalidade, pode optar por aplicar a definição de consentimento a todos os utilizadores dos EUA como uma solução temporária. A configuração do amp-consent tem o seguinte aspeto:

<!-- Configure o componente amp-consent para bloquear pedidos e recolher os consentimentos de todos os utilizadores dos EUA -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
     “consentInstanceId”: “my_consent”,
      “consentRequire”: false,
“geoOverride”: {
  “us”: {
    “consentRequired”: “true”
  }
}     
  </script>
</amp-consent>

Tem de adicionar o atributo data-block-on-consent a todos os componentes amp-ad existentes na página, conforme indicado abaixo. O _auto_reject dá instruções aos anúncios para não esperarem pelo pedido, mas publicarem anúncios não personalizados diretamente. 

<!-- Por fim, configuramos a etiqueta do anúncio, com instruções para rejeitar automaticamente o consentimento -->
<amp-ad data-block-on-consent="_auto_reject"
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad>

Publicar anúncios personalizados/não personalizados mediante consentimento

Uma vez que as AMP não permitem JavaScript personalizado, os pedidos de anúncios personalizados ou não personalizados baseiam-se na configuração de um componente amp-consent e nos atributos data-block-on-consent e data-npa-on-unknown-consent. Partindo do princípio que configurou um componente amp-consent e o associou a todas as etiquetas <amp-ad> da página através de data-block-on-consent:

• Se o utilizador respondeu afirmativamente ao componente amp-consent (o utilizador aceita o pedido de consentimento), os anúncios serão solicitados normalmente.
• Se o utilizador respondeu negativamente ao componente amp-consent (o utilizador rejeita o pedido de consentimento), serão solicitados anúncios não personalizados.
• Se a resposta do utilizador ao amp-consent for desconhecida (o utilizador ignora o pedido de consentimento)
  • Por predefinição, não são enviados quaisquer pedidos de anúncios.
  • Se data-npa-on-unknown-consent estiver definido como true, serão solicitados anúncios não personalizados.
• Se configurar um componente amp-geo de forma a que o consentimento não seja aplicável com base na localização geográfica do utilizador, os pedidos são enviados normalmente.

Se as suas etiquetas <amp-ad> não usarem data-block-on-consent ou se o componente amp-consent não tiver sido configurado corretamente, os pedidos são enviados normalmente.

Segue-se o exemplo de uma configuração que solicita o consentimento a todos os utilizadores nos estados aplicáveis dos EUA, o que resulta no comportamento descrito acima:

<!-- Configure o componente amp-geo para detetar utilizadores finais dos EUA. Atualmente, o amp-geo só suporta a deteção geográfica ao nível do país, mas a deteção para a Califórnia estará disponível brevemente. Certifique-se de que processa o caso "unknown" (desconhecido) quando o país não pode ser determinado pelo amp-geo e tem, pelo menos, um grupo que contém "unknown" -->

<amp-geo layout=nodisplay>
  <script type="application/json">
    {
      "ISOCountryGroups": {
        "us": ["us"],
        "unknown": ["unknown"]
      }
    }
  </script>
</amp-geo>

<!--Configure o consentimento dos utilizadores nos EUA -->

<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
    “consentInstanceId” : “my_consent”,
      “consentRequired”: false,
      “geoOverride”: {
        “us”: {
          “consentRequired”: “true”,
          “promptUI”: “myConsentFlow”
        }
      }
    }
  </script>
  <div id=”myConsentFlow”>...</div>
</amp-consent>

<!-- Por último, configuramos a etiqueta do anúncio, com instruções para aguardar o consentimento quando necessário e solicitar anúncios não personalizados se o consentimento resolvido for desconhecido -->
<amp-ad data-block-on-consent
    data-npa-on-unknown-consent=true
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad>

Pode configurar o seu próprio ponto final para solicitar o consentimento dos utilizadores de forma seletiva ao configurar a página para enviar um pedido CORS POST para um ponto final através de checkConsentHref. Pode obter mais informações com a leitura da documentação sobre amp-consent.