A diferença entre ad_user_data e ad_personalization

Todos os artigos

Eles são dois dos quatro sinais do Consent Mode v2 e controlam coisas diferentes. O ad_user_data define o consentimento para enviar dados do usuário ao Google para fins publicitários. O ad_personalization define o consentimento para publicidade personalizada, que é para o que serve um público de remarketing. Negue o primeiro e nada no nível do usuário chega; negue o segundo e os dados chegam, mas não podem ser usados para segmentar essa pessoa.

Duas perguntas, feitas em dois pontos diferentes

O Consent Mode originalmente fazia uma única pergunta sobre publicidade, e ela era sobre armazenamento: podemos guardar um identificador publicitário neste dispositivo? Esse é o ad_storage, e ele continua lá fazendo o mesmo trabalho.

A versão dois acrescentou mais dois, e o que vale notar é que nenhum deles trata de armazenamento. Eles tratam de uso. O ad_user_data pergunta se os dados do usuário podem ser enviados ao Google para fins publicitários. O ad_personalization pergunta se eles podem ser usados para publicidade personalizada. As duas formulações são do próprio Google, da sua documentação de consentimento da plataforma de tags. Então uma configuração de publicidade moderna é controlada em três pontos em vez de um, e os três são independentes: um visitante pode ser representado por qualquer combinação deles.

Essa independência é o motivo pelo qual a distinção importa. A maioria dos banners a esconde atrás de um único botão de publicidade, o que é um design razoável, mas significa que o mapeamento por baixo está fazendo um trabalho que ninguém vê. A versão simples do modelo mais amplo está em um guia direto sobre o Consent Mode v2.

Qual deles barra o seu remarketing

A resposta curta é: os dois, em pontos diferentes da cadeia. Você vai ler por aí que um dos parâmetros é o do remarketing, o que é mais arrumado do que a verdade.

O ad_personalization é o sinal que trata do uso em si. Ele define o consentimento para publicidade personalizada, e publicidade personalizada é para o que serve uma lista de público, então um visitante que o nega não é alguém que você possa alcançar dessa forma.

O ad_user_data fica antes na cadeia. Ele define o consentimento para enviar dados do usuário ao Google para fins publicitários, e se for negado não chega nenhum dado no nível do usuário a partir do qual montar um público. A lista não chega a ser bloqueada: ela simplesmente nunca é alimentada. A mesma negação tem um efeito separado na contagem das suas conversões, que destrinchamos em o que acontece com uma conversão do Google Ads quando o ad_user_data é negado.

Onde isso deixa de ser teórico é no Customer Match. Para dados de pessoas no EEE, o Google exige que os dois campos de consentimento estejam concedidos antes que a lista possa ser usada, e trata um valor ausente como não consentido. Construa em torno de apenas um dos sinais e você pode acabar com uma lista enviada que não tem permissão para usar, o que é pior do que uma lista vazia, porque parece que funcionou.

A combinação que ninguém prevê

Deixe os dois extremos de lado. Os dois concedidos se comportam como você espera, e os dois negados colocam você no território da modelagem, que é o caso que abordamos quando os visitantes recusam cookies de vez.

O estado interessante é ad_user_data concedido com ad_personalization negado. É algo totalmente coerente de uma pessoa querer: meça a minha visita, me conte nos seus números de conversão, não fique me seguindo por aí. É também o estado que mais encontramos sem representação, porque um banner com uma única categoria de publicidade não consegue produzi-lo, e um banner com várias muitas vezes mapeia todas de volta para um único sinal de qualquer jeito.

O inverso, personalização concedida enquanto os dados do usuário estão negados, é um sintoma e não um design: permissão para personalizar usando dados que não podem chegar. Se você encontra isso no ar, normalmente está olhando para um mapeamento preenchido campo a campo em vez de pensado do começo ao fim.

Como ver quais sinais o seu site realmente envia

Dá para resolver isso em um único carregamento de página, e o primeiro passo pega a maioria das pessoas desprevenida.

1. Não tente ler esses dois no gcs

   O parâmetro gcs carrega apenas ad_storage e analytics_storage. Ler um valor de gcs com cara de saudável e concluir que os sinais de publicidade estão bem é uma falsa aprovação idêntica a uma aprovação real, porque esse parâmetro nunca ia mencioná-los.

2. Olhe o gcd, como verificação cruzada

   O parâmetro gcd viaja nos hits para serviços do Google e codifica os quatro tipos de consentimento junto com a forma como cada estado foi gerado. O Google o trata como uma implementação interna que pode mudar, então use-o para confirmar o que você já acredita, e não como fonte da verdade.

3. Leia o estado de consentimento no Tag Assistant ou no preview

   Esta é a resposta que deve orientar o que você faz. Ela lista os quatro tipos de consentimento com os valores na página, em cada evento, que é a única visão que mostra um valor e o momento em que ele mudou no mesmo lugar.

4. Teste o estado misto de propósito

   Aceite a medição e recuse a personalização, se o seu banner permitir, e observe se os dois sinais realmente divergem. Se eles sempre se movem juntos, as suas categorias estão mapeadas para um único botão, não importa o que a interface sugira.

5. Verifique a atualização, não só o padrão

   Padrões negados são fáceis de acertar, e é fácil parar por aí. O que importa é a atualização disparada depois que o visitante escolhe, e se ela carrega os três sinais de publicidade ou só aquele com que a configuração foi construída originalmente. É a mesma disciplina de verificar o sinal de consentimento na requisição de saída.

O que fazer depois de saber

Se o seu banner oferece uma única categoria de publicidade, mapeie-a para os três sinais de publicidade e garanta que a atualização os envie juntos. Esse é um design defensável.

Se o seu banner oferece escolhas separadas, o mapeamento precisa respeitá-las, porque uma interface que mostra granularidade enquanto a implementação a achata é o pior dos dois mundos: você assumiu a complexidade sem ficar com nenhum benefício, e o visitante viu uma escolha que não existia.

De qualquer forma, verifique primeiro se os dois sinais do Consent Mode v2 estão sendo enviados. Uma instalação anterior a eles pode parecer saudável na tela de configurações enquanto envia apenas o par original, o que é um problema diferente de qualquer visitante recusar qualquer coisa.

O Velo envia os quatro sinais a partir de um único mapeamento de categorias que você lê em uma só tela, então o estado que o visitante escolheu é o estado que sai da página. Como isso é ligado está na página de produto.