A maior perda de tracking não é o adblocker

A tua loja pode estar a culpar o adblocker pelo ROAS a cair — e a ignorar a fatia maior: quem recusou cookies e mesmo assim comprou.

O painel mostra compras a menos. Concluis que «há muito bloqueador» e tratas o adblock como o buraco. Em muitas lojas o buraco maior é o consentimento: quem diz não a cookies de analytics e marketing some do pixel e pode continuar a pagar. O banco vê a encomenda. O ads não.

Este spoke continua o pilar O ROAS da loja está mentir-te e aprofunda o que o pixel do Facebook vs vendas já abre: medição no browser. Distinto do pixel partido ou do checkout a furar. Aqui o corte é proporção — cookies recusadas vs adblocker — e o que o server-side muda no ROAS que vês, não na faturação.

Porque a recusa de cookies mente o ROAS mais do que o adblocker?

Porque o consentimento corta o tracking no browser para uma fatia grande de visitantes que ainda compram. O adblocker corta outra, mais pequena.

O pixel e o GA4 no browser só veem quem deixou o script correr. Quem recusa cookies de marketing e analytics não dispara o evento Purchase no browser — e a venda pode existir na Shopify. Quem usa adblocker também some. Os dois são perda de medição. Não têm o mesmo peso.

Num caso de loja online (não é média de Portugal nem lei do mercado), a fatia de receita que o pixel deixou de ver por recusa ou ignorar cookies rondou cerca de 31%. A fatia perdida por adblockers rondou cerca de 4,4%. A ordem de grandeza importa: o consentimento foi várias vezes o adblock. Os números servem para ver o desencontro. Não são um alvo nacional.

Em Portugal o consentimento para este tipo de cookie é obrigatório. O banner não é decoração. Quem recusa continua no funil de compra. O banco e a loja registam. O painel de ads, se só olha o browser, não.

Server-side (Conversions API, Google via servidor, consent mode bem ligado) não inventa vendas. Mostra as que já tinhas e o browser não mandou. A frase que fecha o ponto: server-side não aumenta vendas. Mostra as que já tinhas. O ROAS sobe no painel porque a medição recupera atribuição — não porque a loja faturou mais naquele dia.

Facto: a maior perda de tracking numa loja online com consentimento costuma ser quem recusa cookies de analytics e marketing, não quem usa adblocker. O pixel e o GA4 no browser só contam eventos que o script conseguiu enviar. Quem recusa o consentimento pode pagar na mesma; a encomenda entra na loja e no banco, e some do painel de ads se só olhas o browser. O adblocker corta outra fatia, em geral menor. Num caso concreto — não média nacional — a receita não vista por recusa rondou cerca de 31%, contra cerca de 4,4% por adblock. Server-side e consent mode bem ligados não aumentam a faturação: recuperam no painel as compras que o browser não enviou, com deduplicação. Enquanto culpas só o adblocker pelo ROAS a cair, podes estar a medir a fatia pequena e a ignorar a grande. O número que fecha o mês é o da loja. O que o server-side muda é o ROAS que o ads vê — as vendas que já existiam.

Opinião: chamar «problema de adblock» a um buraco de consentimento é tratar o sintoma pequeno e deixar o grande a mentir o painel.

O que o painel mostra (e o que não mostra)?

O painel mostra as compras que o browser (e, se existir, o servidor) lhe enviou. Não mostra, sozinho, a fatia de quem recusou cookies e mesmo assim pagou.

Mostra: eventos Purchase, valor, e o ROAS calculado em cima disso. Se ligaste API de conversões ou server-side com o mesmo event_id, o Meta ou o Google podem juntar browser e servidor. Sem isso, contas só o que o banner deixou passar.

Não mostra: o mapa «recusa vs adblock vs checkout expresso» a menos que cries essa leitura — consent mode, relatórios de consentimento, comparação loja vs ads na mesma janela. Também não mostra se a página de produto ou o checkout furam depois do clique. Recuperar tracking numa URL partida só melhora o número errado mais depressa.

Server-side mal deduplicado inflaciona. Dois eventos para a mesma compra e o ROAS sobe sem a loja ter vendido mais. O teste não é «ligar a API e ir embora». É Purchase uma vez, valor e moeda alinhados com a encomenda.

Como vês isto na conta esta semana?

Escolhe 7 ou 14 dias fechados. Não compares ontem com ontem: o ads ainda modela.

Na loja: soma encomendas pagas (sem testes nem reembolsos). No Meta ou no Google Ads: o mesmo intervalo, a atribuição com que decides. Anota o desvio.

Se tens relatório de consentimento ou consent mode: fatia que aceitou analytics/marketing vs quem recusou. Se tens estimativa de adblock (ou uma amostragem do teu próprio diagnóstico), põe ao lado. Não declares «é o adblocker» sem essa proporção.

Confirma se a Conversions API ou o envio server-side está ligado, com o mesmo event_id no browser e no servidor. Faz uma compra de teste. Purchase uma vez. Se aparecer duas, tens duplicação. Se não aparecer e a loja tem a encomenda, o evento não está no caminho do pagamento — ou o consentimento cortou o browser e o servidor não recuperou.

O número para pausar campanhas continua a ser o da loja, como no pilar do ROAS. O pixel e o server-side alimentam o algoritmo. Não fecham o P&L.

FAQ

O adblocker é irrelevante para o tracking?

Não. Corta medição. Em muitas lojas é a fatia menor ao lado de quem recusa cookies. Mede as duas antes de culpar só uma.

Server-side aumenta as vendas da loja?

Não. Mostra no painel compras que o browser não enviou. A faturação já existia na loja. O ROAS que vês é que muda.

Qual keyword interessa aqui?

A âncora do cluster (ROAS a mentir / medição) fica no pilar. A query deste post é server-side tracking com cookies recusadas — e consent mode numa loja online em Portugal. O que decides na prática é se estás a ler o buraco grande (consentimento) ou só o pequeno (adblock).

Como distingo isto do spoke do pixel vs banco?

O spoke do pixel pergunta porque o Facebook e a loja não batem. Este aprofunda a proporção: cookies recusadas vs adblocker, e o papel do server-side no ROAS que vês. São o mesmo cluster; cortes diferentes.

A Aero Agency faz performance para lojas online em Portugal. Se o ROAS cai e só culpas o adblocker, o sítio para começar é a comunidade.