Como trocar de plataforma de gestão de consentimento sem quebrar o seu rastreamento

Todos os artigos

Faça a troca nesta ordem: instale a plataforma nova ao lado da antiga, reaponte cada condição de consentimento para o novo sinal e só então remova a plataforma antiga, por último. O que quebra uma migração raramente é o banner novo. É o que o antigo deixa para trás no seu gerenciador de tags: variáveis lendo cookies que já não existem e as exceções construídas sobre elas.

Por que o banner novo é a metade fácil?

As páginas de migração publicadas pelos fornecedores de consentimento concordam, em linhas gerais, com a sequência: auditar, exportar os seus registros de consentimento, implantar o novo script, entrar no ar. Essas páginas costumam falar em três a dez dias para isso. A sequência está correta, e é a metade do trabalho que se anuncia quando dá errado.

A metade sobre a qual ninguém escreve é o que a plataforma que está saindo deixa dentro do contêiner. Uma ferramenta de consentimento instalada em um gerenciador de tags nunca é uma tag só. É um template, variáveis que leem os cookies dela, acionadores que escutam os eventos dela e, o que pesa mais, as exceções que outras pessoas construíram sobre essas variáveis nos anos seguintes. Apague a tag e tudo isso continua exatamente onde está, ainda ativado, ainda avaliado a cada carregamento de página.

O que uma variável morta faz com uma regra de bloqueio?

Uma variável que lê um cookie de consentimento devolve o valor desse cookie. Quando a plataforma que o gravava vai embora, o cookie vai junto, e a variável devolve undefined em todas as páginas.

Agora considere a regra construída sobre ela. Condições de bloqueio são escritas na negativa: bloquear esta tag quando a variável de consentimento não contém a categoria de que ela precisa. Diante de um cookie real, isso é falso sempre que o consentimento foi dado, e a tag dispara. Diante de undefined, é verdadeiro. Sempre, para todo visitante, inclusive os que aceitaram tudo.

Uma exceção que é sempre verdadeira é uma tag que nunca mais dispara.

Em uma configuração em produção que auditamos depois de uma troca de plataforma, quatro tags tinham sido bloqueadas silenciosamente desse jeito, incluindo a principal conversão de publicidade, por cerca de oito meses. Ninguém tinha mexido nessas tags. O contêiner era válido, o banner novo funcionava e o sinal do Consent Mode estava correto. As regras de bloqueio simplesmente apontavam para uma plataforma que já tinha ido embora.

Como trocar de plataforma sem um buraco no rastreamento?

1. Faça o inventário do que pertence à plataforma antiga

   Exporte o contêiner em JSON e procure nele o nome do fornecedor antigo. Você está procurando quatro coisas, não uma: o template de tag dele, as variáveis que leem os cookies dele, os acionadores que escutam os eventos dele e todas as exceções construídas sobre essas variáveis.

2. Anote qual sinal controla cada tag, agora e depois

   Uma linha por tag condicionada: a condição que a controla hoje e a condição que vai controlá-la quando a plataforma nova estiver instalada. Faça isso enquanto a configuração antiga ainda está no ar e pode ser lida. É isso que permite verificar a troca depois.

3. Deixe os padrões por conta da plataforma nova

   A plataforma nova vai em Consent Initialization e define os padrões negados para ad_storage, analytics_storage, ad_user_data e ad_personalization. O guia de consent mode do Google pede esses padrões antes que qualquer tag envie dados de medição. Aposente os padrões antigos na mesma versão: dois comandos de padrão concorrendo entre si são um risco real, não uma camada extra de segurança.

4. Reconstrua as exceções antes de apagar qualquer coisa

   Toda regra de bloqueio construída sobre as variáveis da plataforma antiga é reescrita primeiro com base no novo estado de consentimento, enquanto as variáveis antigas ainda retornam valores reais e você consegue comparar o comportamento. Este é o passo que as migrações pulam, porque as exceções ficam em outro lugar do contêiner.

5. Apague as variáveis e os templates antigos por último

   Só quando nada mais fizer referência a elas. O gerenciador de tags mostra o que ainda aponta para uma variável, então trabalhe até essa lista ficar vazia e só então remova as variáveis e o template do fornecedor. Um template órfão continua registrado.

6. Verifique pelo que dispara, não só pelo que vaza

   Em um perfil limpo, rejeite tudo e confirme que nenhum cookie de publicidade ou de análise foi gravado. Depois aceite e percorra a sua lista do passo dois, confirmando que cada tag realmente dispara. Por fim, compare as conversões desta semana com as da semana anterior à troca.

Vale a pena fazer o lado da rejeição dessa verificação com calma, e não às pressas: a sequência completa de pré-lançamento está aqui, e as duas leituras que confirmam o sinal do Consent Mode estão aqui.

O que sobrevive a uma migração e não deveria?

Templates de variáveis órfãos. Apagar as tags de um fornecedor não desinstala os templates dele. Eles continuam no contêiner, sem uso mas registrados, e passam despercebidos com facilidade. Remova-os junto com as variáveis.

Mapeamentos de consentimento do tipo tudo ou nada. Configurações mais antigas muitas vezes condicionam tudo a um único evento de “aceitou tudo” em vez de categorias. Se é isso que você está migrando, todo visitante que aceitou algumas categorias e recusou outras já estava invisível, independentemente da troca. Você vai mexer em todas as tags condicionadas de qualquer jeito, então passe para condições por categoria em vez de reproduzir o formato antigo em uma ferramenta nova.

Scripts que nunca estiveram no contêiner. Um script de fornecedor colado direto no head do site também não era controlado pela plataforma antiga, e a nova não vai alcançá-lo a menos que você o leve para o contêiner ou o envolva. Se um script específico pode ser movido é algo que vale resolver um script de cada vez, e uma migração é o momento natural para isso.

O que acontece com o consentimento que os visitantes já deram?

Planeje que os visitantes recebam a pergunta de novo. Uma plataforma lê a sua própria 'decisão armazenada', então, a menos que a nova esteja configurada para ler o cookie da antiga, os visitantes que voltam veem o banner mais uma vez depois da troca.

Guarde os registros antigos. Pelo artigo 7(1) do GDPR, quando o tratamento se baseia no consentimento, o controlador tem que conseguir demonstrar que o visitante o deu. Essa obrigação não termina quando a ferramenta que o registrou é removida. Exporte o 'log de consentimento' da plataforma antiga antes do fim do contrato e anote a data em que a nova plataforma assumiu. O que um registro de consentimento utilizável contém está explicado aqui.

Como saber se isso já aconteceu com você?

Se você trocou de plataforma no passado e nunca fez o passo seis, duas leituras vão dizer em que pé você está.

No contêiner, procure o nome do fornecedor anterior. Tudo o que aparecer é resíduo. Qualquer exceção construída sobre uma variável que lê um cookie que nenhuma plataforma grava mais está bloqueando a sua tag agora mesmo. E está assim desde o dia em que a ferramenta antiga saiu.

Nos dados, escolha a sua conversão mais importante e olhe a tendência de doze meses, não a de trinta dias. Um bloqueio silencioso não parece uma queda. Parece um degrau limpo até perto de zero em uma única data, que depois fica estável, um formato que nenhuma mudança de público ou de mercado produz. Compare essa data com o momento em que a plataforma mudou. As outras causas de uma queda de um dia para o outro estão aqui; esta é a que mais demora a ser notada, porque as tags que perderam a sua condição são só uma parte e o total cai sem desaparecer.

O Velo costuma ser a plataforma para a qual as pessoas migram, então este é um conselho interessado. Ainda assim, é o conselho: o resíduo pertence à ferramenta que você está deixando, e nenhum banner novo consegue limpá-lo por você. Reserve orçamento para o trabalho no contêiner, não só para a instalação.