Um banner de cookies à frente do tagging do lado do servidor: o que muda e o que não muda

Um nome de anfitrião de primeira parte é uma propriedade técnica de um pedido. Não é uma permissão. Se ontem precisava de consentimento para definir um cookie de análise, hoje também precisa, e o facto de o cookie ser agora definido por metrics.oseusite.com em vez de google-analytics.com não entra na equação. A pergunta do regulador é o que recolhe e porquê, não que servidor o pacote visitou pelo caminho.

O que muda é para onde vai um pedido bloqueado. Os bloqueadores de anúncios e as funcionalidades de privacidade dos navegadores bloqueiam por nome de anfitrião e por padrão de URL, e bloqueiam googletagmanager.com. Não bloqueiam o seu próprio domínio. Por isso, um visitante que consentiu e que uma lista de filtros teria descartado em silêncio é agora contado. É esse todo o benefício, e só é um benefício para os visitantes que consentiram.

As etiquetas do Google leem um estado de consentimento com um punhado de permissões nomeadas — analytics_storage, ad_storage, ad_user_data, ad_personalization — e ajustam o que enviam. Antes de o visitante decidir, um gestor de consentimento envia uma predefinição de denied; quando ele escolhe, envia uma atualização. No estado denied a etiqueta do Google dispara na mesma, mas envia um ping sem cookies: sem ID de cliente, sem cookie, um sinal de que uma página foi vista e nada mais. Assim que analytics_storage passa a granted, envia o hit completo. O contentor de servidor recebe o que foi enviado, e os sinais de consentimento viajam com o hit, por isso a etiqueta do GA4 do lado do servidor comporta-se da mesma forma.

O gestor de consentimento tem de carregar antes da etiqueta do Google, para que a sua predefinição esteja no lugar quando a etiqueta avalia pela primeira vez. A maioria dos gestores oferece um valor wait_for_update exatamente para isto — algumas centenas de milissegundos em que a etiqueta espera por um estado de consentimento antes de assumir denied.

As entidades que a SignalHost cria no seu contentor não têm condições de consentimento. É deliberado. As próprias etiquetas do Google respeitam o Consent Mode; uma verificação de consentimento acrescentada à mão na etiqueta do Google, sem nenhuma nas etiquetas de evento do GA4 por baixo, é o primeiro dos dois erros abaixo.

A etiqueta do Google é o que encaminha a medição pelo contentor de servidor. Uma etiqueta de evento do GA4 — uma etiqueta de compra, por exemplo — pode enviar por conta própria. Se a etiqueta do Google espera pelo consentimento e as etiquetas de evento não, as etiquetas de evento disparam antes do consentimento e enviam diretamente para o Google, a partir de uma página cujo banner ainda está aberto. A página do contentor não mostra nada de errado, porque os hits nunca passaram pelo contentor.

Ou não condiciona nada à mão e deixa o Consent Mode fazê-lo, ou condiciona todas as etiquetas que podem enviar. Não há meio-termo coerente.

Alguns gestores de consentimento funcionam bloqueando scripts até o consentimento ser dado — intercetam as etiquetas script por URL e retêm-nas. As suas listas conhecem googletagmanager.com. Não conhecem exxz2gdaz1jz.oseusite.com, porque nenhuma lista poderia: o nome de anfitrião e o nome de ficheiro do loader são únicos do seu contentor. Por isso, em modo de bloqueio, o loader pode ser deixado passar incondicionalmente, e se depende do bloqueio em vez do Consent Mode, isso é uma etiqueta a disparar antes do consentimento.

Duas saídas. Acrescente à mão o URL do loader às regras de bloqueio do gestor, na categoria a que a sua análise pertence. Ou — melhor, porque também trata corretamente o ping sem cookies — confie no Consent Mode para as etiquetas do Google e use o bloqueio só para scripts que não o suportam. O nosso próprio site corre um gestor de consentimento em modo de bloqueio automático com o Consent Mode ao lado; a etiqueta do Google está colocada depois do script do gestor, e um teste no repositório falha se alguém trocar a ordem.

O estado de consentimento chega ao contentor de servidor dentro de cada hit, e a etiqueta do GA4 do lado do servidor lê-o como a do navegador o faria. Nada do nosso lado concede ou amplia um consentimento; um ping sem cookies continua a ser um ping sem cookies.

Se ligar um destino Meta ou TikTok, os mesmos hits alimentam-nos. Se o consentimento de marketing negado de um visitante deve travar esses reencaminhamentos é uma decisão que o seu gestor de consentimento exprime — através da categoria em que o loader está, e de a sua configuração respeitar ou não o ad_storage do Consent Mode. Verifique-o como verificaria qualquer coisa aqui: abra o site com o banner sem resposta, observe o separador de rede e veja o que sai.

• O script do gestor de consentimento está acima da etiqueta do Google na página.
• Um estado de consentimento predefinido denied é enviado antes de a etiqueta carregar, com um wait_for_update.
• Nenhuma etiqueta no contentor tem uma condição de consentimento acrescentada à mão — ou todas as etiquetas que podem enviar têm uma.
• Com o banner sem resposta, o separador de rede mostra um ping sem cookies (gcs=G100 no pedido) e nenhum hit completo.
• Depois de aceitar, a mesma página mostra um hit completo e a página do contentor conta-o.
• Se o gestor bloqueia por URL, o URL do loader está nas suas regras.