Desempenho e Core Web Vitals

Google Consent Mode v2 no PrestaShop: como implementá-lo corretamente?

O modo de consentimento é o mecanismo pelo qual as suas ferramentas de medição e de publicidade adaptam o comportamento ao que o visitante aceitou. A implementação tornou-se condição de acesso a certas funcionalidades publicitárias na Europa, e é muitas vezes feita a meio.

As regras gerais do bot de cookies foram tratadas à parte. Este artigo trata da articulação técnica com as ferramentas de medição.

O princípio

Sem modo de consentimento, a escolha é binária: ou o script de medição carrega, ou não carrega.

Com o modo de consentimento, o script carrega num estado restrito enquanto o visitante não aceitar. Não escreve cookie, não transmite identificador, e pode enviar sinais desprovidos de dados pessoais.

Duas consequências práticas. Mantém uma medição agregada sobre os visitantes que recusam. E a passagem da recusa à aceitação é tida em conta de imediato, sem recarregar.

Ponto a não confundir: este mecanismo não dispensa o consentimento. Define o que as suas ferramentas fazem na ausência dele. Em Portugal, a base legal continua a ser o artigo 5.º da Lei n.º 41/2004 conjugado com o RGPD, sob fiscalização da CNPD.

Os quatro sinais

O dispositivo assenta em quatro indicadores, cada um concedido ou recusado de forma independente.

Dois dizem respeito à medição de audiência: o armazenamento para fins de análise e a transmissão dos dados de medição.

Dois dizem respeito à publicidade: o armazenamento publicitário e o uso dos dados para personalização ou medição publicitária.

Três regras de implementação.

Cada sinal tem de corresponder a uma finalidade do seu bot. Se o bot propõe «medição de audiência» e «publicidade», a correspondência é simples. Se só propõe uma escolha global, não consegue preencher os sinais corretamente.

Todos os sinais têm de ser declarados, mesmo os que não usa. Um sinal ausente é tratado como não preenchido, o que não é o mesmo que recusado.

O estado por omissão é a recusa, até o visitante escolher.

A ordem de execução, ponto crítico

É o erro técnico mais frequente e torna todo o dispositivo inoperante.

O estado por omissão tem de ser declarado antes do carregamento dos scripts de medição. Se o script carrega primeiro e o estado chega depois, o primeiro evento sai com as definições por omissão da ferramenta, ou seja sem restrição.

Em concreto, a sequência é: declaração do estado por omissão, depois carregamento do gestor de etiquetas, depois atualização do estado quando o visitante escolhe.

No PrestaShop, isso pressupõe que o código de declaração seja injetado muito acima na página, antes de qualquer outro script de medição. Um módulo de consentimento que carregue depois do gestor de etiquetas não pode funcionar corretamente.

Verificação: olhe para a ordem dos scripts no código-fonte da sua página inicial. A declaração de estado tem de preceder tudo o resto.

DataFirefly Cookie Manager: Conformidade RGPD Pronta a Usar no PrestaShopO banner de cookies conforme ao RGPD, sem abdicar da medição.220,00€

O bloqueio prévio continua necessário

Confusão frequente que é preciso desfazer.

O modo de consentimento gere o comportamento das ferramentas que o suportam. Não bloqueia as outras.

Os seus scripts de chat, de mapa, de vídeo integrado, de avaliações ou de teste comportamental não o conhecem. Têm de ser bloqueados pelo seu dispositivo de consentimento, como antes.

A configuração correta combina portanto dois mecanismos: um bloqueio prévio para tudo o que deposita marcadores sem suportar o mecanismo, e o modo de consentimento para as ferramentas compatíveis.

Erro a evitar: julgar que a implementação do modo de consentimento dispensa o bloqueio. Só cobre uma parte da sua página.

A atualização no momento da escolha

Três pontos de implementação.

A atualização tem de ser imediata, sem recarregar a página. Um visitante que aceita tem de ver a medição completa ativar-se na sessão em curso.

Tem de refletir a escolha por finalidade, não aplicar um acordo global. Um visitante que aceita a medição e recusa a publicidade tem de produzir dois sinais concedidos e dois recusados.

A escolha tem de ser memorizada e reaplicada em cada visita, até expirar.

Ponto complementar: a retirada do consentimento tem igualmente de atualizar os sinais, no sentido inverso. Um dispositivo que só gere a aceitação está incompleto.

O que mede em caso de recusa

Questão legítima, e a resposta merece nuance.

Em estado restrito, as ferramentas podem transmitir sinais sem identificador nem cookie. Esses sinais permitem uma estimativa do comportamento dos visitantes que recusaram, por modelação.

Três precisões honestas.

Esta estimativa é uma modelação, não uma medição. Produz ordens de grandeza, não números exatos.

Pressupõe um volume suficiente de dados observados para ser calculada. Numa loja pequena, pode não estar disponível.

Não restabelece o que a recusa suprimiu. Atenua a perda, não a anula.

Apresentar este mecanismo como forma de «recuperar as conversões perdidas» é uma leitura excessiva que circula muito.

Verificar que funciona

Quatro controlos, todos realizáveis no navegador.

Antes de qualquer escolha, abra a consola e olhe para os pedidos de saída. As chamadas de medição podem sair, mas sem cookie e com os parâmetros a indicar o estado restrito.

Depois de uma recusa, verifique que não é depositado nenhum cookie de medição ou de publicidade.

Depois de uma aceitação, verifique que os cookies aparecem e que as chamadas levam os identificadores esperados.

Numa visita de regresso, verifique que a escolha anterior é reaplicada sem voltar a perguntar.

Acrescente um controlo na própria ferramenta de medição, que costuma expor um relatório sobre o estado dos sinais recebidos. É aí que se veem as incoerências que a consola não mostra.

Os erros frequentes

Um só sinal preenchido. Algumas configurações declaram apenas o armazenamento analítico e deixam os outros três por preencher.

O estado por omissão concedido. Erro grave: equivale a recolher antes do consentimento.

A correspondência aproximada. Uma finalidade «marketing» do seu bot mapeada nos quatro sinais ao mesmo tempo, o que não respeita a escolha do visitante.

O dispositivo ausente em certas páginas. O processo de compra ou as páginas de destino publicitárias escapam por vezes ao bot, por terem um modelo de página diferente.

Este último caso é o mais lesivo: as páginas que mais contam para a sua medição são aquelas onde o dispositivo falta.

A articulação com o envio pelo servidor

Ponto a tratar se transmite eventos a partir do seu servidor.

O envio pelo servidor não passa pelo navegador, logo ignora o estado dos sinais, a menos que lho transmita explicitamente.

Duas consequências. A sua implementação no servidor tem de conhecer o estado do consentimento do visitante, o que pressupõe guardá-lo e associá-lo à sessão.

E tem de condicionar ou restringir o envio em conformidade. Transmitir dados publicitários a partir do servidor por um visitante que os recusou no navegador é um contorno, não uma otimização.

O Cookie Manager para PrestaShop monta esta cadeia no PrestaShop 8 e 9: declaração do estado por omissão antes de qualquer script de medição, correspondência entre as finalidades do bot e os quatro sinais, atualização imediata na escolha e bloqueio prévio dos scripts de terceiros que não suportam este mecanismo.

Continuar a ler

Artigos relacionados