Eu vi uma conta de e-commerce sair de ROAS 1,8x para 2,7x em uma semana. O CMO comemorou. O CFO ficou desconfiado. Quando abri a análise, a história era outra: a equipe tinha ativado Conversion API do Meta paralelamente ao Pixel client, sem configurar event_id consistente. Cada compra virou duas conversões dentro do Meta Ads Manager. ROAS inflou 50% da noite pro dia. Receita real não subiu um centavo.

Esse post é sobre como evitar esse cenário, que é mais comum do que parece. Deduplicação de conversão não é tópico glamouroso. É infraestrutura. Mas é infraestrutura que separa relatório que sustenta investimento de relatório que sustenta demissão.

O que é deduplicação de conversão e por que isso importa

Deduplicação é o processo de fazer plataformas de anúncios entenderem que dois eventos vindos de fontes diferentes (Pixel client e CAPI server, por exemplo) na verdade representam a mesma ação. Sem dedup, cada evento conta separado. Com dedup, a plataforma compara um identificador comum e atribui crédito uma única vez.

Hoje o stack típico de uma conta razoavelmente madura roda em três camadas simultâneas. Pixel no browser via Google Tag Manager ou direto no código. Conversion API do Meta saindo do servidor da loja ou do GTM server-side. E, em casos mais avançados, uma camada de server-side tagging via GTM que recebe os eventos do client e redistribui pra Meta, Google, TikTok e outras plataformas. Três pontos de envio, mesmo evento de compra. Sem chave única amarrando os três, você multiplica conversão.

O ponto que mais escapa: cada plataforma tem sua própria lógica de dedup. Meta usa event_id combinado com fbp e fbc. Google Ads usa gclid e transaction_id. GA4 dedup interno por event_id e parametrização. São três sistemas distintos que precisam ser tratados com chaves específicas. Reusar a mesma string em todos costuma ser a estratégia mais segura, mas exige disciplina pra persistir esse ID ao longo do funil.

Como o Meta deduplica eventos (event_id + fbp + fbc)

O Meta deduplicas eventos comparando três campos: event_id, fbp (cookie de browser do Pixel) e fbc (clique do Facebook). A regra básica é que dois eventos do mesmo tipo (por exemplo, Purchase) com o mesmo event_id dentro de uma janela de 48 horas são tratados como o mesmo evento. Um vence o outro, e na prática o Meta usa o conjunto de informações dos dois (server tende a ganhar pra Conversion API, já que vem com mais dados de matching).

O detalhe importante: event_id precisa ser exatamente igual nas duas pontas. Não é case-insensitive. Não é “parecido”. É a mesma string. Se o Pixel client envia order_12345 e o CAPI server envia ORDER_12345, o Meta trata como dois eventos diferentes. Inflação dobra. Vi isso acontecer mais vezes do que gostaria.

O fbp e o fbc entram como fallback. Se event_id não está disponível ou veio inconsistente, o Meta tenta deduplicar olhando pra combinação de cookie de browser e clique. Mas isso é fraco. fbp pode não existir em CAPI puro server-side (sem chamada client), e fbc só funciona se o usuário veio de um clique no Facebook. Conversão direta ou via orgânico não tem fbc. Por isso a recomendação consistente do Meta é: gere event_id único no servidor e propague pro client.

Como o Google deduplica (gclid + transaction_id)

Google Ads e GA4 funcionam diferente. O Google Ads conversão é deduplicada principalmente por transaction_id (também chamado de Order ID em algumas docs). Se você manda duas conversões com o mesmo transaction_id dentro da janela configurada, o Google Ads sobrescreve uma sobre a outra. Não soma.

Isso é importante por dois motivos. Primeiro, se você roda Enhanced Conversions for Web no client e conversion tracking via GTM server-side simultâneo, o transaction_id idêntico evita doublecounting. Segundo, em modelos de Conversion Adjustment (ajuste pós-conversão, tipo cancelamento de pedido), o transaction_id é o que permite o Google encontrar a conversão original pra atualizar.

No GA4 a lógica é mais nuançada. GA4 dedupa eventos de e-commerce por event_id ou transaction_id dentro de uma janela de 24 horas. Se você envia o evento purchase via configuração de evento customizado tanto por gtag no client quanto via Measurement Protocol no server, e ambos usam o mesmo transaction_id, GA4 conta uma vez. Sem isso, conta duas e seu funil mostra taxa de conversão fictícia.

O que acontece quando não tem dedup configurado

Acontece coisa boa e coisa ruim simultaneamente, e isso é o que torna o problema difícil de detectar. A coisa boa: matching rate do Meta melhora, porque CAPI envia dados que o client perde (hash de e-mail, telefone, IP, user agent). Isso por si só justifica ativar CAPI. A coisa ruim: sem event_id, cada evento conta como novo. Pixel detecta a compra. CAPI detecta a mesma compra. Meta soma os dois.

O resultado no Ads Manager: você vê o número de Purchases subindo de uma semana pra outra sem nenhum aumento real de tráfego ou taxa de conversão. ROAS sobe junto. Custo por aquisição cai. Tudo parece ótimo. Aí você cruza com receita real do Shopify, Stripe ou ERP e a diferença grita. Conta pública que auditei tinha 2.400 compras no Meta e 1.450 no ERP. Inflação de 65%. Isso é coisa séria.

Como configurar event_id consistente na prática

A regra de ouro: gere o event_id no lugar que tem o identificador mais estável do evento. Pra purchase, isso é quase sempre o order_id ou transaction_id que seu sistema de checkout gera quando o pedido é confirmado. Use esse mesmo valor como event_id nas duas pontas.

No client, via dataLayer push antes do disparo do evento de purchase:

// Página de confirmação do pedido (thank you)
window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'purchase',
  event_id: 'order_12345',
  transaction_id: 'order_12345',
  ecommerce: {
    transaction_id: 'order_12345',
    value: 297.90,
    currency: 'BRL',
    items: [
      { item_id: 'SKU-998', item_name: 'Curso X', price: 297.90, quantity: 1 }
    ]
  }
});

No GTM, o tag do Meta Pixel lê {{event_id}} da camada de dados e passa pro Pixel via eventID. No CAPI server-side (rodando via GTM Server ou direto no backend), o mesmo order_id entra no payload da Conversion API como event_id dentro do objeto do evento. Mesma string, dois envios, Meta dedup ativa.

Pra Google e GA4, o mesmo princípio. transaction_id idêntico no gtag client e na chamada Measurement Protocol server. Pra CAPI Meta via GTM, garantir que o template do server tag pega o event_id da event_data e propaga pro endpoint.

Como debugar dedup (Test Events e Tag Assistant)

O Meta tem ferramenta nativa chamada Test Events dentro do Events Manager. Você gera um test_event_code, configura no Pixel e no CAPI, e dispara uma compra real (ou simulada). O painel mostra os eventos chegando em tempo real, separados por fonte (Browser, Server, etc) e indica se foram deduplicados. Se ver duas linhas de Purchase com o mesmo event_id e nenhum aviso de “Deduplicated”, você tem problema.

Pra Google Ads, o Tag Assistant Companion (extensão Chrome) mostra o disparo das tags client. Pra validar server-side, a melhor ferramenta é o Preview Mode do GTM Server. Ele intercepta cada hit que chega no container server, mostra o transaction_id de cada evento e permite comparar com o que sai pro Google Ads e GA4.

Quanto a inflação típica destrói uma análise de mídia

Trabalhei numa auditoria de conta de SaaS B2C onde a inflação por dedup quebrada estava em 38%. Toda decisão de alocação de orçamento dos últimos quatro meses tinha sido tomada em cima de ROAS distorcido. A campanha que “tava performando 3,5x” na realidade rodava 2,2x. A campanha que “tava com 1,8x e quase foi pausada” na verdade rodava 1,1x, ou seja, no prejuízo. Quando rodamos os benchmarks de mídia paga do Brasil com os números limpos, a estrutura inteira da mídia precisou ser reorganizada.

Pior: cada plataforma tinha sua própria distorção. Meta inflando 40% por CAPI sem event_id. Google Ads inflando 12% por Enhanced Conversions duplicando com conversion tracking padrão. GA4 inflando 25% por Measurement Protocol server enviando paralelo ao gtag client. Três fontes de doublecounting simultâneas. Levou três semanas pra reescrever a infraestrutura de tracking e mais duas pra ganhar confiança nos dados limpos. Mas só depois disso virou possível discutir performance real.

Erros mais comuns e como evitar

Os padrões que mais aparecem em auditoria, em ordem de frequência:

1. event_id ausente em uma das pontas. Pixel envia com event_id, CAPI envia sem. Ou vice-versa. Meta trata como dois eventos. Fix: garantir que o backend popula o campo em todas as chamadas.
2. event_id diferente entre Pixel e CAPI. Time front gera UUID aleatório no client, time backend usa order_id no server. Mesma compra, IDs diferentes. Sem dedup. Fix: padronizar, sempre order_id.
3. Pixel disparando duas vezes na mesma página. Tema do site ou plugin que injeta Pixel hardcoded, mais GTM disparando outro. Duplicação só no client. Fix: auditar source com Chrome DevTools, remover hardcoded.
4. CAPI server enviando evento duas vezes por retry. Webhook do checkout configurado com retry agressivo, evento dispara duas vezes pro Meta. Mesmo event_id salva (dedup pega), mas se ID variar (timestamp por exemplo), inflar. Fix: usar order_id imutável como event_id.
5. Test Events não rodado antes de produção. Configuração subiu, ninguém validou se dedup tá ativo. Inflação acontece silenciosa por semanas. Fix: Test Events em todo deploy de tracking.
6. Enhanced Conversions e tracking padrão coexistindo no Google. Duas implementações simultâneas sem transaction_id. Fix: padronizar, preferencialmente migrar pra stack server-side e desativar tracking redundante.

Pra checar a saúde do seu setup em 15 minutos: abra o Events Manager do Meta, vá em Diagnostics. Se aparecer aviso de “Event Deduplication Rate Low” em algum evento de purchase, você tem problema agora. Aja antes que vire trimestre inteiro tomando decisão com base em ROAS fantasma.

Pra contexto externo e validação técnica, vale conferir a documentação oficial do Meta sobre deduplicação Pixel + CAPI, o conteúdo do Simo Ahava sobre Conversion API e server-side e a análise da Search Engine Land sobre tracking server-side.

Perguntas frequentes