Como fazer o Meta Signals Gateway respeitar o consentimento de cookies?

Todos os artigos

Dê ao pixel do Signals Gateway a sua própria verificação de consentimento. Ele é um código separado do pixel padrão da Meta, que roda na sua própria função cbq, então você não pode contar com uma chamada de consentimento ao fbq chegando até ele. No Tag Manager, adicione configurações de consentimento para ad_storage, ad_user_data e ad_personalization à tag dele e dispare-a de novo no seu evento de atualização de consentimento. Sem o Tag Manager, segure o código dele até o visitante aceitar publicidade.

A maioria das configurações de consentimento para a Meta foi feita para um pixel só. O Signals Gateway acrescenta um segundo, e é esse segundo pixel que as pessoas esquecem de condicionar. Veja por que isso acontece, como corrigir e como conferir a correção.

Por que o meu banner de cookies ainda não controla o pixel do gateway?

Porque o banner fala com outra função. O controle de consentimento da Meta para o pixel padrão é um comando no fbq: fbq('consent', 'revoke') antes do init, depois fbq('consent', 'grant') quando o visitante concorda. O guia de consentimento da Meta para o pixel descreve exatamente esse par. A maioria das plataformas de consentimento, inclusive o Velo, envia essas duas chamadas quando uma escolha entra em vigor.

O pixel do Signals Gateway é instalado com o seu próprio código base. Ele define cbq, aponta para o gateway no seu próprio subdomínio com cbq('setHost', …) e envia os eventos a partir dali. Um revoke enviado para fbq é uma chamada a outro objeto, e a documentação da Meta sobre o pixel do gateway não diz nada sobre consentimento. Não conte com a chamada de consentimento do pixel padrão cobrindo o pixel do gateway.

O Google Consent Mode também não ajuda aqui. Ele é o sinal do Google para as tags do Google. O código base da Meta não o lê sozinho, e uma tag de Custom HTML no Tag Manager não o lê de jeito nenhum. As configurações de consentimento do Tag Manager são diferentes: elas decidem se uma tag dispara, seja qual for o código dentro dela. Isso deixa dois lugares onde o pixel do gateway pode ser barrado: as configurações de consentimento da tag no Tag Manager ou a própria página.

Como configurar o pixel do gateway para esperar o consentimento?

Os passos abaixo pressupõem o Tag Manager, porque é assim que a maioria dos sites instala o pixel do gateway. O passo 4 cobre o código na página.

1. Encontre todas as cópias do pixel do gateway

   Procure no seu contêiner tags que chamam cbq, seja um template do pixel do gateway ou uma tag de Custom HTML, e confira se o mesmo código base aparece no código-fonte da página. Uma segunda cópia sem condição desfaz o trabalho feito na primeira.

2. Adicione configurações de consentimento à tag

   Na tag do pixel do gateway, abra Advanced Settings e depois Consent Settings. Escolha Require additional consent for tag to fire e adicione ad_storage, ad_user_data e ad_personalization. Uma tag bloqueada assim não dispara, então não envia nada.

3. Dispare de novo quando o visitante aceitar

   Uma visualização de página bloqueada no carregamento não volta sozinha. Adicione um gatilho no evento de atualização da sua plataforma de consentimento (com o Velo, é velo_consent_update) e defina Tag firing options como Once per page, para que um aceite dispare a visualização de página uma vez.

4. Sem o Tag Manager, segure o código

   Se o código base está na página, mude o tipo do script para text/plain e marque-o com a categoria de publicidade da sua plataforma de consentimento. Com o Velo, isso é data-velo-category="ads". O código então só roda depois que o visitante permite publicidade.

5. Dê o mesmo ID de evento aos dois pixels

   Se o pixel padrão e o pixel do gateway enviam um Purchase, a Meta pode contá-lo duas vezes. Ela remove duplicatas de forma mais confiável quando os dois compartilham o nome do evento e o ID do evento. Coloque uma única variável do Tag Manager no campo Event ID das duas tags.

6. Teste antes de publicar

   Rode as quatro verificações da próxima seção no site publicado, em uma sessão nova do navegador a cada vez.

Os templates variam, então leia o que você instalou. Alguns templates da comunidade para o pixel do gateway, entre eles o da Stape, documentam o seu próprio tratamento de consentimento com base em ad_storage. Alguns trazem um campo de consentimento próprio, chamado Consent Granted (GDPR) na versão que o nosso guia de Pixel da Meta e Signals Gateway percorre; com as configurações de consentimento do Tag Manager no lugar, o guia deixa esse campo em True, porque as configurações de consentimento já seguram a tag. Se você instala o pixel do gateway como uma tag de Custom HTML, esse campo não existe, e as configurações de consentimento são a única barreira. Elas funcionam da mesma forma seja qual for o template que você usa.

Como conferir se o pixel do gateway respeita a escolha?

Observe a rede, não a lista de tags. Uma tag pode aparecer como bloqueada no Preview do Tag Manager enquanto uma cópia fixa no código do tema continua enviando eventos.

• Antes de qualquer escolha: abra o painel de rede (Network) e filtre pelo subdomínio do seu gateway e por facebook.com/tr. Nada deve aparecer.
• Depois de aceitar publicidade: a visualização de página deve chegar ao seu gateway. Confira na atividade de eventos do gateway ou em Test events no Events Manager.
• Depois de recusar: navegue por duas páginas. Nenhuma requisição ao gateway nem à Meta.
• Depois de retirar: aceite, depois retire o consentimento pelo botão de privacidade e carregue outra página. As requisições devem parar a partir dessa página.

Depois confira no Events Manager se há avisos de desduplicação. O nosso checklist para testar um banner de cookies antes de publicar traz a rotina completa no navegador, e os mesmos cuidados de sessão valem aqui.

Um gateway no meu próprio subdomínio muda o consentimento de que preciso?

Não. A regra da UE no artigo 5(3) da Diretiva ePrivacy trata de armazenar ou ler informações no dispositivo do visitante. Ela não pergunta para o domínio de quem a requisição vai. A Meta descreve o Signals Gateway como uma forma de receber e enviar eventos na sua própria infraestrutura. Isso muda a rota dos dados, não a escolha do visitante sobre eles.

É a mesma resposta que demos para a versão do Google da mesma ideia em o Google tag gateway precisa de consentimento de cookies. Um caminho próprio (first party) é uma decisão de roteamento. O consentimento continua decidindo se a tag roda.

E os eventos que o gateway repassa para a Conversions API?

Se o pixel do navegador está condicionado, o gateway não recebe nada do navegador daquele visitante, então não há nada para encaminhar. A brecha está em outro lugar. Eventos que o seu próprio servidor envia, como uma compra enviada para a Conversions API a partir do seu checkout, nunca passam pelo banner. Aplique a escolha de publicidade do visitante a esses eventos antes de enviá-los, ou a rota do servidor ignora silenciosamente a decisão que o navegador respeitou.

Segue a mesma lógica do pixel padrão, um nível abaixo. O nosso post sobre por que o pixel do Facebook ainda carrega quando as suas tags estão bloqueadas cobre as cópias fixas no código que causam a maioria desses vazamentos.

O Velo envia grant e revoke para o pixel padrão da Meta sempre que uma escolha entra em vigor. Ele ainda não envia a escolha para o pixel do Signals Gateway, então para esse pixel use as configurações de consentimento do Tag Manager ou o bloqueio por categoria ads descrito acima.