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

Os bloqueadores de anúncios impedem o tracking ao evitar que o script de pixel da plataforma de anúncios, ou os pedidos que este envia, seja carregado no navegador do comprador. Quando isso acontece, a plataforma nunca fica a saber da visualização de página, da adição ao carrinho ou da compra, mesmo que a encomenda esteja na sua loja. As compras enviadas server-side a partir dos dados das suas encomendas não são afetadas, porque o navegador do comprador não participa no envio.

Este guia explica como funcionam os bloqueadores de anúncios e as funcionalidades de privacidade dos navegadores, que eventos a sua loja perde, o que o tracking server-side recupera e o que não consegue recuperar. Termina com uma forma simples de medir a diferença na sua própria loja.

Como é que os bloqueadores de anúncios travam os pixels de tracking?

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

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

Navegadores com proteção integrada

Alguns navegadores bloqueiam rastreadores sem necessidade de extensão. O Brave ativa por predefinição os seus Shields em todos os sites, e os Shields bloqueiam anúncios de terceiros, rastreadores e cookies entre sites. O Firefox bloqueia o conteúdo de domínios de tracking entre sites conhecidos nas janelas privadas, e as pessoas podem escolher definições mais rígidas que se aplicam a todas as janelas. A Intelligent Tracking Prevention do Safari bloqueia todos os cookies de terceiros e encurta a duração dos cookies definidos por scripts. O nosso guia sobre o Safari ITP e o tracking de anúncios explica esses limites.

Bloqueadores ao nível da rede

Há quem bloqueie rastreadores num dispositivo inteiro ou numa rede doméstica, com um bloqueador baseado em DNS ou uma VPN com filtro de rastreadores. Estes bloqueiam os pedidos a domínios de tracking em todos os navegadores e apps dessa rede. Mudar de navegador não altera o resultado.

Que eventos perde a sua loja?

Quando o pixel é bloqueado, perdem-se todos os eventos que ele enviaria a partir desse navegador. O prejuízo não é igual para todos os eventos.

Os eventos de navegação perdidos tornam mais pequenos os seus públicos de retargeting. As compras perdidas fazem mais estragos. A plataforma reporta menos conversões, o ROAS no relatório de anúncios desce e o algoritmo de bidding aprende com menos compradores. Uma campanha rentável pode então parecer não rentável, e pode acabar por cortá-la.

Porque é que os eventos server-side criados a partir dos dados das encomendas não são bloqueados

Um bloqueador de anúncios funciona dentro do navegador do comprador. Só consegue parar pedidos que o navegador faz. Quando a compra é enviada a partir dos dados das encomendas da sua loja, o pedido vai de um servidor para a API da plataforma de anúncios. O navegador do comprador não faz parte desse percurso, por isso o bloqueador não tem nada para cancelar.

A plataforma associa então a compra a uma pessoa com os dados do evento: o email e o telefone com hash da encomenda, o endereço IP e o user agent e, se tiver sido guardado, o ID de clique. Nada disto passa pelo bloqueador. Para conhecer o percurso completo dos dados, leia o que é o tracking server-side.

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

O ID de clique precisa do navegador

A encomenda em si está segura, mas a ligação ao clique no anúncio é feita no navegador. Um script tem de ler o ID de clique no URL de destino e guardá-lo. Se um bloqueador de anúncios também bloquear esse script, a encomenda chega sem ID de clique. A plataforma ainda consegue associar a compra através dos dados do cliente com hash, mas a correspondência é menos certa.

Duas medidas reduzem esta perda. Primeiro, recolha os eventos em first-party: sirva o script de tracking e os respetivos pedidos a partir do seu próprio domínio, por exemplo através de um proxy da app Shopify ou de um subdomínio do seu site. As listas de filtros visam endereços de tracking de terceiros conhecidos, por isso um percurso first-party é muito mais difícil de bloquear, embora não seja impossível. Segundo, use a página de destino que algumas lojas online, como o Shopify, guardam com cada encomenda. Se esse URL ainda contiver o ID de clique ou os UTM, a encomenda pode ser atribuída sem qualquer evento do navegador.

Os eventos de navegação continuam a perder-se

Os dados das encomendas contêm encomendas, não visualizações de página. Enviar compras a partir das encomendas 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 reencaminhar estes eventos a partir do servidor quando os seus próprios pedidos passam.

Recusar o consentimento não é bloquear

Um visitante que recusa os cookies de marketing no seu banner de cookies não é o mesmo que um visitante com um bloqueador de anúncios. O primeiro visitante fez uma escolha que o seu tracking tem de respeitar. Com Respect visitor consent ativado, a ROASaurus não define nenhum ID de visitante para esse visitante, por isso os seus cliques em anúncios e visitas não ficam associados a ele. Os eventos do navegador são guardados sem ID de visitante, endereço IP nem detalhes do navegador, e não são enviados às plataformas de anúncios. A encomenda paga continua a ser enviada server-side, com os dados do cliente com hash que constam da encomenda e o endereço IP e o user agent da encomenda. Mantenha os dois grupos separados ao medir a sua perda e consulte consentimento e privacidade para mais detalhes.

Como estimar a sua própria perda

Não precisa de médias do setor, que dependem do público, do dispositivo e do país. Pode medir a sua própria diferença comparando as encomendas 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 a Meta. Use o mesmo fuso horário nos dois sistemas.

2. Conte as encomendas web da sua loja

   Comece por todas as encomendas. Retire as que nunca passam pelo seu checkout online: encomendas no ponto de venda, manuais e rascunho, renovações de subscrições e encomendas 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. É mais fácil fazê-lo antes de adicionar os eventos de servidor. Se os eventos de servidor já estiverem ativos, use a vista da plataforma por método de ligação, quando existir. O Events Manager da Meta mostra o método de ligação de cada evento e conta aí os eventos antes da eliminação de duplicados. Não use as compras atribuídas do relatório de anúncios.

4. Divida

   Compras do navegador ÷ encomendas web é a percentagem que o pixel viu. O resto é a sua diferença.

5. Separe o consentimento do bloqueio

   Estime as encomendas de visitantes que recusaram os cookies de marketing, com a taxa de recusa da sua ferramenta de consentimento. O que sobra deve-se sobretudo a bloqueadores de anúncios, definições de privacidade e páginas que não carregaram.

A diferença também altera o ROAS. Imagine que a Meta reporta um ROAS de 2.0 para esta loja e que o seu ROAS de break-even é 2.3. Com os dados do pixel, as campanhas dão prejuízo. Se as encomendas geradas por anúncios tivessem falhado à mesma taxa de 24% que todas as encomendas 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 break-even. É uma estimativa máxima, porque nem todas as encomendas em falta vieram de um anúncio. O nosso guia sobre o ROAS de break-even explica como definir esse limiar.

Como reduzir o que perde

As soluções são as mesmas para qualquer plataforma de loja online. Funcionam melhor em conjunto.

1. Envie as compras a partir dos dados das encomendas. Isto elimina a perda de compras em todas as plataformas que ligar, independentemente do que o navegador do visitante bloqueie.
2. Mantenha o pixel, com um ID de evento partilhado. Os visitantes sem bloqueador continuam a enviar eventos do navegador com cookies e contexto da 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 duplicado.
3. Recolha em first-party. Sirva o script de tracking e os respetivos eventos a partir do seu próprio domínio, para que os IDs de clique sejam guardados para mais visitantes.
4. Envie dados de clientes com hash. O email e o telefone da encomenda 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 devem agora corresponder às suas encomendas web.

Como a ROASaurus lida com os bloqueadores de anúncios

A ROASaurus envia todas as encomendas pagas server-side para as plataformas de anúncios que adicionar em Tracking & platforms, por isso um bloqueador de anúncios no navegador do comprador não impede a compra. No Shopify, os eventos da loja passam pelo proxy da app do Shopify no domínio da sua própria loja. Também pode servir o script e os respetivos eventos a partir de um subdomínio CNAME do seu site. Quando um visitante não tem nenhum ponto de contacto no navegador, a atribuição da ROASaurus recorre aos IDs de clique e aos UTM do URL de destino da encomenda, quando a loja o regista, como faz o Shopify.

Cada envio e a resposta da plataforma ficam listados no Event log, para que possa confirmar que cada encomenda chegou a cada plataforma. Veja o tracking 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

Na ROASaurus

• Tracking server-side na ROASaurus
• Evitar a contagem em duplicado
• Consentimento e privacidade

Continue a ler