event_id que atravessa cliente e servidor, atribuição exclusiva por canal, e o CTWA sem cookie nenhum de navegador.
event_id como cola · atribuição exclusiva · CTWA via CRM · IA monta, gente verifica
É comum tratar “configurar o GTM” e “subir o CAPI” como dois projetos separados — um fica com o time de tráfego, o outro vira ticket técnico. Na prática, se eles não nascerem como a mesma pipeline, o resultado é evento duplicado, evento que nunca chega, ou os dois brigando pela mesma conversão.
O evento nasce uma vez só. O navegador manda a primeira cópia (pixel, via GTM). O servidor manda a segunda cópia (CAPI), com o MESMO identificador. Se isso não for verdade, você não tem redundância — você tem duas fontes discordando sobre o que aconteceu.
O Meta deduplica evento de pixel e evento de CAPI pelo event_id, numa janela de 48h. Se o navegador manda um ID e o servidor gera outro na hora do PATCH, os dois contam como conversões diferentes — e seu CPL cai pela metade no relatório, sem cair de verdade.
Parece óbvio escrito assim. Na prática, é o primeiro lugar onde GTM e CAPI se desconectam: o time que configura tag no GTM não sabe que existe um servidor mandando cópia, e o time que sobe o CAPI não sabe qual variável do dataLayer carrega o ID certo.
Regra: o event_id é gerado UMA vez, no cliente, e viaja junto até o servidor. Se o CAPI está gerando o próprio ID, ele não está deduplicando — está duplicando.
Configuração padrão de GTM dispara Meta Pixel E tag do Google no mesmo clique — os dois recebem crédito pela mesma conversão. Isso não é redundância, é atribuição inflada: os dois canais acham que converteram o mesmo lead, e o relatório de cada um mente pra cima.
A separação vive no NOME do evento no GTM (um evento dedicado por canal), não numa condição escondida dentro do gatilho — senão a próxima pessoa que mexer no container não vê a regra e reintroduz o disparo duplo sem perceber.
Regra: conversão é exclusiva de um canal por vez, decidida pelo parâmetro mais recente. Público/remarketing é a exceção declarada, não o padrão silencioso.
Até aqui, pixel e CAPI vivem no mesmo domínio: alguém visitou o site. Mas boa parte da nossa operação é WhatsApp-first — o clique no anúncio manda a pessoa direto pra conversa, sem passar pelo site. Esse caminho não tem cookie de navegador nenhum pra carregar. O que carrega o rastro é o CRM.
É aí que o CAPI deixa de ser “projeto de site” e vira parte do PostepTrack: o mesmo telefone e o mesmo ctwa_clid que casam o lead com o CRM são o que permite mandar o evento LeadSubmitted pro Meta depois — cada canal de entrada (site, WhatsApp direto, formulário) alimentando a mesma conta de conversão, sem duplicar e sem se esquecer de nenhum.
Regra: CAPI de site e CAPI de WhatsApp não são a mesma implementação com endpoint trocado. São dois contratos diferentes com a Meta — mesmo objetivo, exigências diferentes.
A parte mecânica do GTM — variável nova, trigger com regex, tag apontando pro dataLayer certo — é rápida de montar com IA descrevendo o comportamento esperado. Isso tira o atrito técnico de configurar container.
O que a IA não resolve sozinha: qual canal fica com qual conversão, se o event_id realmente atravessa cliente→servidor sem ser regenerado no meio do caminho, se o dataset do CTWA está mesmo vinculado à WABA certa. Isso é verificado contra o comportamento real — Dataset Quality API, teste de evento de verdade, log do servidor — não assumido porque “a IA configurou direitinho”.
Regra: IA monta o container mais rápido. A decisão de atribuição e a prova de que o dado chegou certo continuam sendo verificadas por gente, contra o sistema real — nunca por inferência.
nasce uma vez no cliente (GTM), viaja até o servidor. CAPI nunca gera um ID próprio — se gera, está duplicando, não deduplicando.
exclusiva por canal, decidida pelo parâmetro mais recente (gclid × fbclid), separada por nome de evento no GTM — nunca os dois disparando juntos.
sem cookie de navegador — o CRM (via PostepTrack) é quem carrega o rastro. LeadSubmitted + dataset por WABA, contrato diferente do CAPI de site.
monta o container GTM rápido. Não decide atribuição, não prova que o dado chegou certo — isso é verificação humana contra o sistema real.
GTM, CAPI e CRM não são três sistemas conversando por acaso — são uma pipeline de atribuição só, do clique até o painel. Trate como projetos separados e você ganha eventos duplicados; trate como uma pipeline e o dado bate com a realidade.