Bloqueadores de anúncios e rastreamento: o que a sua loja perde

Os bloqueadores de anúncios impedem o rastreamento ao evitar que o script do pixel da plataforma de anúncios, ou as requisições que ele envia, seja carregado no navegador do comprador. Quando isso acontece, a plataforma nunca fica sabendo da visualização de página, do item adicionado ao carrinho nem da compra, mesmo que o pedido esteja na sua loja. As compras enviadas via server-side a partir dos dados dos seus pedidos não são afetadas, porque o navegador do comprador não participa do envio delas.

Este guia explica como funcionam os bloqueadores de anúncios e os recursos de privacidade dos navegadores, quais eventos a sua loja perde, o que o rastreamento server-side recupera e o que ele não recupera. No final, mostra uma forma simples de medir essa diferença na sua própria loja.

Como os bloqueadores de anúncios barram os pixels de rastreamento?

A maioria dos bloqueadores de anúncios trabalha com listas de filtros. Uma lista de filtros é uma longa lista de regras que correspondem a endereços da web: domínios, caminhos e nomes de arquivos de scripts de anúncios e de rastreamento conhecidos. Quando uma página pede ao navegador que carregue algo que corresponde a uma regra, o bloqueador cancela a requisição.

As listas mais conhecidas são a EasyList, para anúncios, e a EasyPrivacy, para rastreamento. Elas funcionam com extensões como Adblock Plus, AdBlock, uBlock Origin e AdGuard. O pixel de uma grande plataforma de anúncios é um alvo fácil para essas listas, porque carrega o mesmo script do mesmo domínio em muitos sites diferentes.

Navegadores com proteção integrada

Alguns navegadores bloqueiam rastreadores sem precisar de extensão. O Brave ativa os Shields em todos os sites por padrão, e os Shields bloqueiam anúncios de terceiros, rastreadores e cookies entre sites. O Firefox bloqueia o conteúdo de domínios de rastreamento entre sites conhecidos nas janelas privativas, e as pessoas podem escolher configurações mais rígidas que valem para todas as janelas. A Intelligent Tracking Prevention do Safari bloqueia todos os cookies de terceiros e encurta a vida útil dos cookies definidos por scripts. O nosso guia sobre Safari ITP e rastreamento de anúncios explica esses limites.

Bloqueadores em toda a rede

Algumas pessoas bloqueiam rastreadores em um dispositivo inteiro ou em toda a rede doméstica, com um bloqueador baseado em DNS ou uma VPN com filtro de rastreadores. Isso barra as requisições para domínios de rastreamento em todos os navegadores e apps dessa rede. Trocar de navegador não muda o resultado.

Quais eventos a sua loja perde?

Quando o pixel é bloqueado, todo evento que ele enviaria a partir desse navegador se perde. O prejuízo não é o mesmo para cada evento.

Perder eventos de navegação deixa os seus públicos de retargeting menores. Perder compras causa mais dano. A plataforma reporta menos conversões, o ROAS no relatório de anúncios cai e o algoritmo de lances aprende com menos compradores. Uma campanha lucrativa pode então parecer não lucrativa, e você pode cortá-la.

Por que os eventos server-side feitos a partir dos dados do pedido não são bloqueados

Um bloqueador de anúncios roda dentro do navegador do comprador. Ele só consegue barrar requisições que o navegador faz. Quando a compra é enviada a partir dos dados de pedido da sua loja, a requisição vai de um servidor para a API da plataforma de anúncios. O navegador do comprador não faz parte desse caminho, então não há nada para o bloqueador cancelar.

A plataforma então associa a compra a uma pessoa com os dados do evento: o e-mail e o telefone com hash do pedido, o endereço IP e o user agent, e o ID de clique, se ele foi salvo. Nada disso passa pelo bloqueador. Para conhecer o caminho completo dos dados, leia o que é rastreamento server-side.

O que o rastreamento server-side não consegue recuperar?

O ID de clique precisa do navegador

O pedido em si está seguro, mas o vínculo com o clique no anúncio é feito no navegador. Um script precisa ler o ID de clique na URL da página de destino e salvá-lo. Se um bloqueador de anúncios também bloquear esse script, o pedido chega sem ID de clique. A plataforma ainda consegue associar a compra por meio dos dados de cliente com hash, mas a correspondência é menos certa.

Duas coisas reduzem essa perda. A primeira é coletar eventos em first-party: sirva o script de rastreamento e as requisições dele a partir do seu próprio domínio, por exemplo por meio de um app proxy do Shopify ou de um subdomínio do seu site. As listas de filtros visam endereços de rastreamento de terceiros conhecidos, então um caminho first-party é muito mais difícil de bloquear, embora não impossível. A segunda é usar a página de destino que algumas plataformas de loja online, como o Shopify, guardam com cada pedido. Se essa URL ainda contiver o ID de clique ou as UTMs, o pedido pode ser atribuído sem nenhum evento do navegador.

Os eventos de navegação continuam se perdendo

Os dados de pedido contêm pedidos, não visualizações de página. Enviar compras a partir dos pedidos não recupera as visualizações de página e os eventos de adicionar ao carrinho de um visitante cujo navegador bloqueou tudo. Um coletor first-party pode encaminhar esses eventos a partir do servidor quando as próprias requisições dele passam.

Recusar o consentimento não é ser bloqueado

Um visitante que recusa os cookies de marketing no seu banner de cookies não é o mesmo que um visitante com bloqueador de anúncios. O primeiro fez uma escolha que o seu rastreamento precisa respeitar. Com Respect visitor consent ativado, o ROASaurus não define nenhum ID de visitante para esse visitante, então os cliques em anúncios e as visitas dele não ficam vinculados a ele. Os eventos do navegador dele são mantidos sem ID de visitante, endereço IP ou detalhes do navegador, e não são enviados às plataformas de anúncios. O pedido pago ainda é enviado via server-side, com os dados de cliente com hash do pedido e o endereço IP e o user agent do pedido. Mantenha os dois grupos separados ao medir a sua perda e veja consentimento e privacidade para os detalhes.

Como estimar a sua própria perda

Você não precisa de médias do setor, que dependem do público, do dispositivo e do país. Você pode medir a sua própria diferença comparando os pedidos da sua loja com as compras que o pixel do navegador reportou no mesmo período.

1. Escolha um período e uma plataforma

   Use 14 ou 30 dias e uma plataforma, por exemplo o Meta. Use o mesmo fuso horário nos dois sistemas.

2. Conte os pedidos web da sua loja

   Comece com todos os pedidos. Remova os pedidos que nunca passam pelo seu checkout online: ponto de venda, pedidos manuais e rascunhos, renovações de assinatura e pedidos de teste.

3. Conte os eventos Purchase do navegador

   Na ferramenta de eventos da plataforma, conte os eventos Purchase que o pixel do navegador enviou. Isso é mais fácil antes de você adicionar os eventos de servidor. Se os eventos de servidor já estiverem rodando, use a visualização da plataforma por método de conexão, quando ela oferecer uma. O Meta Events Manager mostra o método de conexão de cada evento e conta os eventos ali antes da deduplicação. Não use as compras atribuídas do relatório de anúncios.

4. Divida

   Compras do navegador ÷ pedidos web é a parcela que o pixel viu. O restante é a sua diferença.

5. Separe consentimento de bloqueio

   Estime os pedidos de visitantes que recusaram os cookies de marketing, com a taxa de recusa da sua ferramenta de consentimento. O que sobra são, em sua maioria, bloqueadores de anúncios, configurações de privacidade e páginas que não carregaram.

A diferença também muda o ROAS. Suponha que o Meta reporte um ROAS de 2.0 para esta loja e que o ROAS de equilíbrio dela seja 2.3. Com os dados do pixel, as campanhas dão prejuízo. Se os pedidos vindos de anúncios tivessem sido perdidos na mesma taxa de 24% de todos os pedidos web, o pixel teria visto apenas 76% da receita dos anúncios. O ROAS real seria então cerca de 2.0 ÷ 0.76 = 2.6, acima do equilíbrio. Esta é uma estimativa máxima, porque nem todo pedido ausente veio de um anúncio. O nosso guia sobre ROAS de equilíbrio explica como definir esse limite.

Como reduzir o que você perde

As correções são as mesmas para qualquer plataforma de loja online. Elas funcionam melhor em conjunto.

1. Envie as compras a partir dos dados do pedido. Isso fecha a lacuna das compras em todas as plataformas que você conectar, seja o que for que o navegador do visitante bloqueie.
2. Mantenha o pixel, com um ID de evento compartilhado. Os visitantes sem bloqueador ainda enviam eventos do navegador com cookies e contexto de página. O mesmo ID de evento nas duas cópias permite que a plataforma fique com uma só. Veja como evitar a contagem em duplicidade.
3. Colete em first-party. Sirva o script de rastreamento e os eventos dele a partir do seu próprio domínio, para que os IDs de clique sejam salvos para mais visitantes.
4. Envie dados de cliente com hash. O e-mail e o telefone do pedido permitem que a plataforma associe compras que não têm ID de clique.
5. Meça de novo. Repita a comparação um mês depois. Os eventos Purchase que a plataforma recebe agora devem coincidir com os seus pedidos web.

Como o ROASaurus lida com os bloqueadores de anúncios

O ROASaurus envia todo pedido pago via server-side para as plataformas de anúncios que você adiciona em Tracking & platforms, então um bloqueador de anúncios no navegador do comprador não impede a compra. No Shopify, os eventos da vitrine passam pelo app proxy do Shopify no domínio da sua própria loja. Você também pode servir o script e os eventos dele a partir de um subdomínio CNAME do seu site. Quando um visitante não tem toque no navegador, a atribuição do ROASaurus recorre aos IDs de clique e às UTMs da URL da página de destino do pedido, quando a loja registra uma, como o Shopify faz.

Cada envio e a resposta da plataforma aparecem no Event log, para que você confira se cada pedido chegou a cada plataforma. Veja rastreamento server-side e a integração com o Shopify para a configuração.

Fontes

1. EasyList: Overview
2. Brave: Brave Shields
3. MDN Web Docs: Firefox tracking protection
4. WebKit: Tracking Prevention in WebKit
5. Meta for Developers: Verifying Your Setup

No ROASaurus

• Rastreamento server-side no ROASaurus
• Como evitar a contagem em duplicidade
• Consentimento e privacidade

Continue lendo