Blog · 2026-08-30

Rastreie primeiro, escale depois: envio duplo de Pixel e CAPI com o mesmo event_id

O pixel do lado do navegador perde eventos na era de privacidade do iOS. Enviamos o mesmo evento pelos dois canais com um único event_id, deduplicamos e alimentamos chaves de correspondência limpas, o que colocou a qualidade de correspondência medida em 6 a 7.

O anúncio está gastando, mas o número de conversões do painel nunca fecha com os pedidos reais. O cliente comprou e o Pixel não reportou nada, porque a venda fechou numa página de checkout de terceiros, fora do seu site, e o código de rastreamento do navegador não enxerga esse passo. Mesmo quando a venda acontece dentro do site, a fatia de usuários iOS volta incompleta. O algoritmo sai procurando público com esse sinal quebrado e, quanto mais orçamento você joga, mais torto ele aprende.

Por que só o Pixel sempre vai perder eventos

O rastreamento pelo navegador vem sendo cortado ano após ano: a ATT do iOS deixa o usuário recusar rastreamento com um toque; a proteção contra rastreamento do Safari e do Firefox encurtou muito a vida dos cookies; bloqueadores de anúncio derrubam a requisição do pixel inteira. A estimativa comum do mercado é que esses fatores somados custam ao rastreamento puramente do navegador algo entre 20 e 30% dos eventos.

O que se perde não é só número de relatório. O algoritmo de entrega da Meta aprende quem compra a partir dos seus eventos de conversão e, se faltam duas ou três décimas do material de estudo, o público que ele monta sai torto. A direção da solução é clara: abrir um segundo canal do lado do servidor (a API de Conversões), com a requisição indo direto do servidor para a Meta, fora do alcance das extensões do navegador. Só que, com os dois canais disparando ao mesmo tempo, a mesma conversão é contada duas vezes. A deduplicação vira o primeiro problema de engenharia dessa arquitetura.

Envio duplo e deduplicação: o event_id é a única ponte

Como fazemos: o Pixel no front-end dispara o evento normalmente e, no mesmo instante, o servidor manda o mesmo evento de novo pela CAPI. O endpoint de CAPI é hospedado por nós mesmos numa Cloudflare Pages Function, então o front-end chama o nosso próprio endpoint e é ele que anexa as credenciais e repassa para a Meta. A chave nunca toca o front-end, e qualquer validação ou filtro que a gente queira acrescentar depois continua nas nossas mãos.

A deduplicação depende da regra de correspondência da Meta: mesmo nome de evento e mesmo event_id significam um evento só, contado uma vez. Por isso o event_id tem que ser gerado uma única vez no front-end e entregue ao Pixel e ao backend. Não gere um de cada lado e não encha linguiça com uma string fixa: precisa ser um valor que não se repete a cada evento. Falhar na deduplicação custa mais que um relatório feio. A mesma venda contada duas vezes faz o resultado parecer o dobro, e você vai decidir aumentar orçamento em cima de um número que não existe.

Verificar não é opcional. Antes de subir, medimos que o event_id batia exatamente nos dois lados, que o endpoint de CAPI recebia events_received:1 da Meta e que a ferramenta de Eventos de Teste mostrava os dois eventos pareados e marcados como deduplicados. Só com tudo isso passando é que liberamos.

Chaves de correspondência: normalizar primeiro, gerar o hash depois, descartar o lixo

A Meta usa as chaves de correspondência para ligar o evento a um usuário real, e a qualidade de correspondência de eventos (EMQ) mede exatamente isso. Enviamos seis chaves: email, telefone, sobrenome, nome, cidade e país, todas normalizadas no servidor antes de virarem hash SHA256. A normalização segue a especificação oficial: email em minúsculas e sem espaço nas pontas, telefone sem símbolos e sem zeros à esquerda, com o código do país na frente. As regras precisam bater, senão os dois lados não produzem o mesmo hash.

Colocar a normalização no servidor é proposital: existe uma cópia só das regras, e uma nova versão do front-end não faz o hash da mesma pessoa mudar. As regras de descarte são igualmente duras: email com formato quebrado, telefone com dígitos de menos e valor vazio não são enviados. O princípio é correção em primeiro lugar. Dado errado, depois de virar hash e subir, não casa com ninguém e ainda derruba a qualidade de correspondência geral, ou seja, você gastou esforço mandando ruído.

Com isso pronto, o EMQ medido dos eventos de intenção no site fica em 6 a 7 (escala de dez pontos da Meta). Não tem nada de místico: as chaves estão completas e estão limpas.

O upload offline não leva IP nem UA, e isso é de propósito

Para a parte da venda que acontece fora do site, subimos o evento Purchase pela CAPI com action_source marcado como system_generated, e sem IP e sem UA.

A razão é simples: aquela venda não aconteceu no navegador do usuário, então você não tem o IP nem o UA reais dele naquele momento. Usar o IP do seu próprio servidor como substituto é alimentar sinal falso: não casa com ninguém e ainda polui a qualidade de correspondência, prejuízo dobrado. Melhor mandar de menos do que mandar errado. E como o evento offline não tem os sinais de ambiente do navegador, a correspondência fica toda apoiada nas chaves, o que faz a normalização e o descarte da seção anterior decidirem diretamente se esses eventos encontram alguém. Nesse lote, 7 eventos subiram com sucesso e, pela primeira vez, o algoritmo recebeu uma lista de compradores reais fechados fora do site, em vez de só enxergar quem entrou sem saber como terminou.

Fechando: rastreamento sem verificação não recebe orçamento

A arquitetura toda são três coisas: envio duplo com o mesmo event_id e deduplicação, chaves de correspondência normalizadas e com hash, e upload offline que não inventa sinal. Feito isso, o algoritmo finalmente recebe um sinal de comprador completo e limpo, e aí escalar tem base. Ao contrário, aumentar orçamento antes de verificar o rastreamento é pagar para o algoritmo aprender a coisa errada. Antes de escalar, verifique pelo menos três pontos: event_id igual nos dois lados, Eventos de Teste marcando o par como deduplicado e EMQ numa faixa saudável.

Se o número de conversões do seu painel de anúncios nunca fecha com os pedidos reais, ou se a venda acontece inteiramente num sistema fora do site, já percorremos esse caminho de ponta a ponta, da hospedagem própria do endpoint à limpeza das chaves de correspondência e à liberação condicionada à verificação. Fale com a gente.

Rastreamento virou serviço aqui

Essa deduplicação e esse preenchimento de parâmetros rodam em toda conta nova que assumimos. É a primeira parada antes de qualquer verba de mídia.

• Envio duplo e deduplicação de eventos de conversão: Pixel e CAPI disparam juntos, alinhados pelo mesmo identificador de evento, contados uma vez
• Preenchimento de parâmetros: identificador de clique, identificador de navegador e dados do cliente com hash preenchidos nos campos que deveriam carregá-los, elevando a qualidade de correspondência
• Diagnóstico gratuito de rastreamento: primeiro olhamos se o que você tem instalado hoje está certo, depois se fala em mudar

Três tamanhos, implementação única:

As especificações e os prazos de entrega estão em configuração de rastreamento e atribuição de dados. Antes de o rastreamento estar instalado certo, não aumente orçamento. Essa é a regra que aplicamos em toda conta que assumimos.