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

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

• Definições de tratamento de dados restrito para páginas que utilizam etiquetas da GPT e do AdSense
• Definições de tratamento 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 tratamento de dados restrito para páginas que utilizam 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 tratados 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 utilizar o parâmetro TFCD para etiquetar pedidos para utilizadores menores de idade. O tratamento de dados restrito também será ativado após a definição do parâmetro TFCD.

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

Se pretender ativar o tratamento de dados restrito apenas para alguns utilizadores, as etiquetas de anúncios 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 tratamento 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 de privacidade de estados dos EUA" (Google Ad Manager, AdMob, AdSense) para obter mais informações acerca do modo de tratamento de dados restrito.

• Para a etiqueta da GPT, utilize 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, utilize 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 tratamento 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 tratamento 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 tratamento 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 utilizar o controlo de tratamento de dados restrito (TDR) para cada tipo de etiqueta.

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

Etiquetas de passback da GPT

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

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 utilizar um Pedido sem etiqueta, pode marcar um pedido de anúncio como tratamento 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 tratamento de dados restrito. Em caso de omissão do parâmetro, o tratamento 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 tratamento 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 utiliza 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 tratamento de dados restrito. Recomendamos a migração para uma das etiquetas com suporte total de funcionalidades para anúncios personalizados e o modo de tratamento 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 tratados 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 tratamento de dados restrito, a Google limita a forma como utiliza os dados e só publica anúncios não personalizados.

Pode ativar o tratamento 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 tratamento 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 tratamento de dados para todos os utilizadores localizados nos estados aplicáveis dos EUA ou podem optar por restringir seletivamente o tratamento de dados ao seguir as instruções abaixo para desativar a personalização. Os publicadores utilizam as definições de desativação da personalização existentes quando pretendem ativar o tratamento 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 utilizar etiquetas AMP do AdSense, ou etiquetas AMP do DoubleClick sem Real Time Config (RTC), pode simplesmente ativar o tratamento de dados restrito nas IUs do Google Ad Manager ou do AdSense e não será necessário efetuar mais alterações às suas páginas AMP.

Se as etiquetas de anúncios AMP utilizarem 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 de 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 dos estados aplicáveis dos EUA), pode utilizar 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 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 utilizarem 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 ao nível dos estados 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"],
        "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.