Voltar ao blog

Blog

CookiePass e o Google Consent Mode: o que um banner de consentimento faz ao seu tráfego

Publicado · Atualizado · 4 min de leitura

Neste site usamos o CookiePass. É um serviço de consentimento de cookies que implementa o Google Consent Mode v2 tal como a Google o especifica, e essa propriedade acaba por importar mais do que as cores do banner: decide o que a sua etiqueta Google envia em cada visualização de página antes de o visitante responder, depois de dizer sim e depois de dizer não. É assim que isso se vê do lado do servidor, onde cada um desses hits passa pelo seu contentor.

O que o Consent Mode muda realmente

Escolha o modo adequado à política da organização. Não desative um bloqueio deliberado apenas para fazer aparecer eventos. **Basic:** bloqueie o snippet de seguimento até ao consentimento adequado. Não são esperados eventos de seguimento no SignalHost antes disso. **Advanced:** carregue as etiquetas Google com valores iniciais `denied`. A Google pode receber medições sem cookies antes da escolha ou após a recusa. Um sinal não é consentimento.

O campo `gcs` descreve apenas o armazenamento para publicidade e Analytics. Não comprova as duas permissões de consentimento mais recentes. Verifique as quatro no Google Tag Assistant; os campos codificados das solicitações podem mudar.

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   storage summary missing; our current storage gate permits it, not proof of consent

Defina `analytics_storage`, `ad_storage`, `ad_user_data` e `ad_personalization` como `denied` antes de executar o snippet SignalHost. Depois, o banner atualiza cada autorização conforme a escolha do visitante.

Como o CookiePass o liga

O Consent Mode v2 exige uma sequência, não uma definição. O estado predefinido tem de ser declarado antes de a etiqueta Google carregar — negado para quem ainda não escolheu —, uma atualização tem de seguir no momento em que o visitante decide, e esse estado tem de ser reposto em cada visita seguinte. Com a ordem errada, a primeira visualização de página de cada sessão sai como consentida antes de o banner sequer aparecer.

Esta é a sequência que o CookiePass produz a partir do seu próprio script, pelo que nada disto vai parar ao seu contentor do Tag Manager:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts all four purposes…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

É esta a integração toda. As etiquetas da própria Google respeitam o estado de consentimento automaticamente, incluindo as que o SignalHost publica no seu contentor web. Nada no seu contentor de servidor precisa de uma condição de consentimento; adicioná-la à mão é como uma etiqueta Google bloqueada acaba ao lado de etiquetas de evento desbloqueadas a enviar dados diretamente para a Google.

O que o seu contentor de servidor vê antes e depois da escolha

**Basic:** bloqueie o snippet de seguimento até ao consentimento adequado. Não são esperados eventos de seguimento no SignalHost antes disso. **Advanced:** carregue as etiquetas Google com valores iniciais `denied`. A Google pode receber medições sem cookies antes da escolha ou após a recusa. Um sinal não é consentimento.

  • Antes da escolha e após Recusar: as autorizações relevantes mantêm-se em `denied`.
  • Apenas estatísticas: `analytics_storage` pode ser concedido; as autorizações publicitárias continuam recusadas.
  • Publicidade permitida: conceda apenas as finalidades realmente aceites pelo visitante.
  • Retirada: os valores afetados voltam a `denied`. Recarregue e confirme a escolha guardada.

Ver um evento prova que o consentimento está correto? Não. Os eventos em direto mostram a chegada ao SignalHost, não as quatro autorizações nem a entrega a uma plataforma. Verifique o consentimento no Tag Assistant e o destino separadamente.

O que isto significa para os seus números de tráfego

Ver um evento prova que o consentimento está correto? Não. Os eventos em direto mostram a chegada ao SignalHost, não as quatro autorizações nem a entrega a uma plataforma. Verifique o consentimento no Tag Assistant e o destino separadamente.

  • **Basic:** bloqueie o snippet de seguimento até ao consentimento adequado. Não são esperados eventos de seguimento no SignalHost antes disso.
  • **Advanced:** carregue as etiquetas Google com valores iniciais `denied`. A Google pode receber medições sem cookies antes da escolha ou após a recusa. Um sinal não é consentimento.

Uma lista de verificação

  • Antes de começar o rastreamento, o banner deve definir as permissões como negadas. Após a escolha, atualize apenas as finalidades permitidas pelo visitante, memorize essa escolha e trate de uma eventual retirada do consentimento.
  • Abra uma nova janela privada para cada teste. No Google Tag Assistant, introduza o URL do site e consulte os primeiros e últimos eventos Consent.
  • Antes da escolha e após Recusar: as autorizações relevantes mantêm-se em `denied`.
  • Apenas estatísticas: `analytics_storage` pode ser concedido; as autorizações publicitárias continuam recusadas.
  • Publicidade permitida: conceda apenas as finalidades realmente aceites pelo visitante.
  • Retirada: os valores afetados voltam a `denied`. Recarregue e confirme a escolha guardada.
  • Adicione o URL exato do carregador do snippet de instalação SignalHost às regras de bloqueio do banner. O seu domínio pode não corresponder às regras Google habituais. Liberte-o apenas após o consentimento necessário.

[Guia de configuração do banner de cookies](/pt/blog/banner-cookies-consent-mode-servidor)

Deixa de perder dados para bloqueadores

Comece gratuitamente. O primeiro contentor fica pronto em poucos minutos.