Três portas de entrada, quatro passos no motor, dois destinos — e o retry que não deixa lead pra trás. A mecânica completa da atribuição.
ctwa_clid · leadgen_id · utm_* → Graph API → CRM + banco · retry a cada 5 min · R$ por anúncio
O PostepTrack grava em cada lead, no momento em que ele entra no CRM, a origem exata do clique: campanha, conjunto e anúncio — nome e ID. Não é “veio do Meta”. É “veio do anúncio X, do conjunto Y, da campanha Z”.
Já contamos aqui por que cada cliente tem a própria instância e quais armadilhas esse pipeline esconde. Esse post é a peça que faltava: a mecânica. O que acontece, na ordem em que acontece, do clique ao lead carimbado.
Todo lead chega por um de três caminhos, e cada um solta um identificador diferente. O resto do sistema existe pra transformar esse identificador em atribuição.
o cliente clica no anúncio e cai direto no WhatsApp. A primeira mensagem chega com o identificador do clique embutido, entregue pelo webhook do WhatsApp Business
o cliente preenche o formulário nativo sem sair do Instagram/Facebook. O webhook de leadgen entrega o ID do lead gerado
o clique chega ao site com os parâmetros de rastreio na URL, que seguem junto quando o lead é enviado
→ Três formatos diferentes, um mesmo destino: o webhook chega em tempo real na Edge Function do cliente.
Cada cliente tem uma Edge Function dedicada rodando no Supabase (Deno). Ela responde ao Meta em milissegundos e processa em background. O trabalho real são quatro passos:
O passo b é o coração: é a Graph API do Meta que responde de qual anúncio aquele clique veio. O PostepTrack só faz a pergunta certa, com o token certo, na hora certa — e guarda a resposta onde ela vale dinheiro.
A mesma atribuição é gravada em dois lugares, porque ela serve dois públicos diferentes:
E tem a corrida de timing: às vezes o webhook do Meta chega ANTES de o CRM criar o lead. Se o passo c não encontra ninguém, o evento não é descartado — vai pra uma fila de recuperação e um retry automático roda a cada 5 minutos até casar.
Nenhum clique se perde porque o CRM demorou dez segundos. Essa fila (recovery_pending) nasceu de caso real — não de paranoia.
Quando o CRM do cliente suporta webhook de saída, o PostepTrack vai além do lead: fecha a malha até a receita.
→ A pergunta muda de “quantos leads esse anúncio trouxe” pra “quantos reais em venda esse anúncio gerou”. ROI por anúncio, não por canal.
Cada cliente roda uma instância dedicada e isolada — nada compartilhado. São quatro peças:
Aplicativo próprio do cliente na Meta, com token de System User (não expira). Recebe os webhooks de CTWA e Lead Ads e autentica as consultas à Graph API.
Função serverless (Supabase/Deno) exclusiva do cliente. Responde ao webhook em milissegundos e faz o trabalho pesado em background.
Postgres com ~30 colunas de atribuição, protegida por RLS. É a base dos dashboards e das análises de custo por lead.
Kommo (API v4), Clint ou Ploomes (OData, com webhook de saída pra receita). Campos custom criados no lead do CRM do cliente.
campanha · conjunto · anúncio (nome + id) · origem do evento · utm_source/medium/campaign/content · ctwa_clid / leadgen_id / fbclid · telefone normalizado · timestamps · deal_id (p/ receita)