
O mapa que monta qualquer trackeamento: 4 passos e um prompt para sua IA
Mapear, guardar, escutar e devolver: a lógica que serve para WhatsApp, Lead Ads, site com CRM e checkout. Com exemplos, limites reais e um prompt para ensinar sua IA a desenhar cada trackeamento.
Este é o material do MAPA: um guia para você entender como se monta o trackeamento de qualquer campanha e um prompt pronto para colar na sua IA, para ela reconhecer cada estrutura, perguntar o que falta e desenhar o esquema com você.
A ideia central cabe em uma frase: muda a ferramenta, muda o identificador, mas o desenho é sempre o mesmo. Mapear, guardar, escutar, devolver.
Antes de começar, uma distinção que vou usar no texto inteiro:
- Rastreamento é coletar e guardar os dados na sua base: de onde veio a pessoa, o que ela preencheu, o que aconteceu depois.
- Trackeamento é devolver esses dados para a plataforma de tráfego, para ela aprender com o resultado.
O rastreamento deixa a pessoa inteligente. O trackeamento deixa a plataforma inteligente. Um sem o outro vira planilha bonita ou campanha cega.
Rastreamento e trackeamento não são a mesma coisa
Resposta curta
Para montar o trackeamento de qualquer campanha, você precisa responder quatro perguntas, nesta ordem:
- Mapear: que tipo de campanha é esta e o que a plataforma precisa receber de volta para saber quem converteu?
- Coletar e guardar: quais dados chegam no primeiro contato e onde eles ficam guardados, com qual chave de busca?
- Escutar: onde acontece o momento em que o lead qualifica ou compra, e como sua integração fica sabendo?
- Devolver: qual pacote a integração monta a partir do banco, para qual plataforma ele vai e em qual formato?
Se você consegue responder as quatro para uma campanha, você tem o desenho do trackeamento. O resto é implementar e testar.
Os 4 passos do mapa
1. Mapear
Tipo de campanha e dados que a plataforma precisa receber de volta.
2. Coletar e guardar
Identificadores e dados de contato salvos no banco no primeiro contato.
3. Escutar
Perceber o lead qualificado e a compra onde elas realmente acontecem.
4. Devolver
A integração busca no banco, monta o pacote e envia à plataforma.
Os 4 passos em detalhe
1. Mapear
Antes de abrir qualquer ferramenta, desenhe numa folha duas colunas: campanha e o que a plataforma precisa receber.
Cada tipo de campanha entrega um identificador diferente no clique. Anúncio que leva ao WhatsApp entrega um. Formulário instantâneo entrega outro. Site entrega parâmetros na URL e cookies. Checkout entrega e-mail e telefone no momento da compra. Se você mapear errado, vai coletar o dado errado e descobrir só depois, quando o evento não casar com ninguém.
O mapa responde também qual resultado você quer devolver: lead, lead qualificado, compra com valor. Cada um é uma conversão diferente e acontece em lugar diferente.
2. Coletar e guardar
Os dados precisam ser guardados no primeiro contato. O clique acontece uma vez. Se o identificador não foi salvo naquele momento, você não consegue reconstruí-lo meses depois, quando o lead virar cliente.
Para cada lead, o banco precisa ter:
- os identificadores do canal (cada um no seu próprio campo, sem misturar);
- os dados de contato disponíveis (telefone, e-mail, nome);
- uma chave de busca para reencontrar esse lead depois;
- a data do primeiro contato e a origem (UTMs, anúncio, formulário).
Sobre quais dados ajudam a Meta a reconhecer a pessoa: as boas práticas da Conversions API citam e-mail, telefone e outros dados entre os parâmetros de alta qualidade. Para Click-to-WhatsApp, o guia específico recomenda preservar e enviar ctwa_clid sempre que disponível, pois ele identifica diretamente o clique. Priorize os identificadores pertinentes ao canal e complemente com dados de contato coletados de forma adequada. Isso não significa que exista um ranking único de parâmetros para todas as integrações.
Guarde também um ID interno do contato e a relação com cada conversa, oportunidade e pedido. Uma pessoa pode clicar em mais de um anúncio: preserve os pontos de contato com data, sem sobrescrever todo o histórico pelo último clique. Registre o contato original e o normalizado. Telefone internacional precisa de país/DDI definido; não acrescente +55 por suposição. Colete apenas o necessário e registre as permissões de uso aplicáveis.
3. Escutar
Esse é o passo que quase todo mundo esquece. Guardar os dados não manda nada para a plataforma. Alguém precisa perceber que o lead virou lead qualificado ou comprou.
A escuta pode vir de lugares diferentes:
- o CRM, quando alguém move o card de etapa;
- o webhook do checkout ou do gateway de pagamento, quando a compra é aprovada;
- uma conversa, quando o atendente escreve algo que sua regra reconhece.
A terceira fonte é a mais frágil, e eu volto a ela no exemplo do WhatsApp. Prefira sempre uma fonte onde o fato fica registrado de forma estruturada.
4. Devolver
Quando a escuta dispara, a integração faz quatro coisas:
- recebe o aviso ("lead 123 qualificou", "pedido 456 aprovado");
- busca no banco o que você guardou lá atrás, usando a chave;
- monta o pacote no formato que aquela plataforma exige;
- envia e registra o resultado, para não enviar duas vezes.
Esse registro importa. A Meta avisa, no guia da Conversions API para mensagens, que não ajuda na deduplicação desses eventos e recomenda que você deduplique antes de enviar. Guarde no banco que o evento já foi enviado.
Exemplo 1: WhatsApp (Click-to-WhatsApp) no Meta Ads
Situação: o anúncio leva a pessoa direto para uma conversa no WhatsApp. Exemplo sintético: uma clínica que agenda consultas e recebe pagamento por Pix.
- O que coletar: o webhook de mensagem do WhatsApp traz um objeto
referralquando a conversa vem de um anúncio. Ali estãoctwa_clidesource_id, além desource_type,source_urleheadline. Guarde também o telefone e o nome de perfil. Se quiser o e-mail, um chatbot pode pedir. - Onde guardar: uma tabela de leads de WhatsApp, com telefone,
ctwa_clid, ID do anúncio, e-mail (se houver), data da primeira mensagem e etapa atual. - Chave de busca: ID interno do lead e da conversa, vinculados ao telefone normalizado. O telefone ajuda a localizar; confirme qual conversa/oportunidade gerou a conversão antes de escolher o clique.
- O que escutar: a etapa em que a pessoa virou lead qualificado (consulta agendada) e a etapa da compra (pagamento confirmado).
- Evento:
QualifiedLeadpara a qualificação definida pela operação ePurchasepara a compra confirmada, ambos listados no guia de mensagens. Para compra, mande valor e moeda. A página de Conversions API para mensagens comerciais lista os eventos aceitos para esse canal. Confira os nomes exatos lá: nome de evento customizado pode ser rejeitado nesse canal. - Envio: requisição para a Conversions API com
action_source: business_messagingemessaging_channel: whatsapp. Octwa_clidvai emuser_data, sem hash, junto da identificação da conta WhatsApp Business (whatsapp_business_account_id) no caminho documentado com clique. O token precisa das permissões de gerenciamento do WhatsApp Business descritas no guia. - Destino: Meta, no conjunto de dados que o guia de integração indica.
source_id e ctwa_clid não são a mesma coisa
source_ididentifica a origem do anúncio (o ID do anúncio, quando osource_typeindica anúncio). Serve para você saber *qual anúncio* trouxe a conversa.ctwa_clidé o identificador do clique gerado pela Meta nesse anúncio. Serve para devolver a conversão *associada àquele clique*.
Guarde os dois, em campos diferentes. Um responde "qual anúncio?", o outro "qual clique?". Nem toda entrada de conversa contém esses campos. Confira o payload recebido pela sua integração e trate explicitamente a ausência do identificador; nunca o invente.
Dois limites que quase ninguém conta
"Pix recebido R$ 2.000" não comprova pagamento. Quando a integração reconhece uma frase escrita pelo atendente, ela está lendo um texto digitado. O atendente pode escrever errado, antes da compensação, no valor errado, ou o pagamento pode ser estornado depois. Uma regra por palavra-chave como "consulta agendada" ou "Pix recebido" funciona como gatilho de demonstração, não como prova financeira.
No exemplo da clínica, a regra identifica “consulta agendada” numa mensagem de saída do atendente, confirma o agendamento no CRM e registra a qualificação. Depois, ao ler “Pix recebido R$ 2.000”, pode extrair 2000.00 como valor candidato. Ela confirma o pagamento no registro financeiro ou no CRM conciliado e só então prepara Purchase, valor 2000.00, moeda BRL e o ID da transação. Se o valor não bater, separa o caso para revisão. A extração do texto ajuda a automatizar; não substitui a confirmação. Envie somente o resultado comercial necessário, sem conteúdo da consulta nem informações clínicas.
Nem toda integração entrega o que o atendente escreve. Antes de montar a regra de frases, teste se o sistema de atendimento expõe as mensagens de saída e identifica seu autor. Não suponha que um webhook de mensagens recebidas inclua tudo que foi enviado pelo aplicativo ou por outra ferramenta. Se essa informação não chegar, escute a mudança de etapa no CRM ou a confirmação do pagamento.
Exemplo 2: Formulário instantâneo (Lead Ads) com CRM
Situação: a pessoa preenche um formulário dentro do Facebook ou do Instagram. Exemplo sintético: captação de interessados em um serviço, com time comercial usando um kanban.
- O que coletar: o webhook
leadgentraz umleadgen_id, não o lead completo. Com ele, sua integração faz uma segunda chamada autenticada e recebe os dados do formulário. O guia de recuperação de leads descreve o processo e as permissões necessárias (entre elasleads_retrieval). - Onde guardar: uma tabela de leads da Meta, com o ID do lead, os campos do formulário (nome, e-mail, telefone), o formulário e o anúncio quando o retorno trouxer.
- Chave de busca: o ID do lead. Guarde como texto: ele tem 15 a 17 dígitos.
- O que escutar: a mudança de etapa no kanban do CRM (por exemplo, de "novo" para "qualificado" e depois "vendido"), via webhook ou automação do CRM.
- Evento: o estágio do lead. A integração de leads de CRM descreve como representar estágios do funil. Escolha nomes estáveis e não os mude depois.
- Envio: Conversions API com o
lead_idemuser_data, seguindo a especificação de payload da integração de CRM. - Destino: Meta, como resultado do lead que veio do formulário.
Limite: a Meta guarda os leads por tempo limitado para consulta pela API. Baixe e salve no banco assim que o lead chega. Quem depende de buscar o lead só depois, na hora de converter, pode descobrir que ele já não está acessível.
Exemplo 3: Site com formulário, CRM, Meta e Google Ads offline
Situação: a pessoa clica no anúncio, cai numa página, preenche um formulário e o lead vai para o CRM. O time comercial trabalha o lead por dias.
- O que coletar na página: os parâmetros de clique da URL e os cookies, cada um em seu campo:
- Google: gclid, gbraid e wbraid, quando presentes; - Meta: fbclid (da URL), cookies _fbc e _fbp quando disponíveis; seus valores são enviados como fbc e fbp; - UTMs, página de entrada, data e hora; - e-mail e telefone digitados no formulário; - o consentimento dado.
- Onde guardar: o CRM e/ou o seu banco, com esses campos gravados junto ao lead.
- Chave de busca: o ID interno do lead, com e-mail normalizado e telefone em formato internacional como apoio.
- O que escutar: a mudança de etapa no CRM (qualificado, proposta, ganho).
- Evento: lead qualificado e/ou venda, com valor e moeda quando for venda.
- Envio para a Meta: Conversions API com e-mail e telefone com hash, mais
fbcefbpsem hash, conforme a página de parâmetros de informação do cliente. - Envio para o Google: conversão offline ou conversão otimizada para leads, preservando os identificadores de clique disponíveis e complementando com e-mail e telefone normalizados e com hash, conforme os requisitos da integração, mais valor, moeda, momento da conversão e consentimento. Detalhes abaixo.
- Destino: Meta e Google Ads, cada um com seu próprio pacote.
fbclid não é fbc, e gclid não é fbc
fbclidé o parâmetro que a Meta coloca na URL quando alguém clica no anúncio.fbcé o valor que você envia à Conversions API. A documentação de `fbp` e `fbc` descreve o formatofb.{subdomainIndex}.{creationTime}.{fbclid}(tempo de criação em milissegundos), diferencia maiúsculas de minúsculas e diz que não deve ser alterado. Se o cookie_fbcnão existir, mas a URL tiverfbclid, você monta ofbccom ele. Não fabriquefbcquando não houver um clique ou cookie válido; use a especificação vigente da Meta.gclid,gbraidewbraidsão identificadores do Google, para contextos de medição diferentes. Nunca vão para a Meta, e os da Meta nunca vão para o Google.
Não existe "o ID de clique" único. Existe o ID de clique de cada plataforma, e cada um segue para o seu destino. Preserve os valores como chegaram, sem converter um no outro.
Google Ads: o que mudou na importação offline
O caminho clássico (UploadClickConversions, da Google Ads API) está migrando para a Data Manager API. A página atual de conversões offline restringe o caminho legado para integrações sem histórico elegível e orienta a nova API. Para conta nova, comece pela Data Manager API, que usa destinos, eventos, normalização e hash dos dados do usuário, modo de validação (validateOnly) e consulta assíncrona do diagnóstico. Quem já tem integração antiga deve conferir o prazo e a elegibilidade na documentação e planejar a migração.
A ajuda do Google sobre conversões otimizadas para leads recomenda preservar o identificador de clique quando ele existe e complementar com os dados que você coletou (e-mail, telefone), com valor, moeda, identificação da conversão e consentimento. Os campos e esquemas não são idênticos entre a API antiga e a nova: não copie um payload de uma para a outra.
Conversões otimizadas para leads não são apenas “mandar um e-mail com hash”. Exigem configurar a medição e a importação para esse objetivo, aceitar os termos de dados aplicáveis e verificar os requisitos da tag, dos identificadores e do destino escolhido. Acompanhe separadamente envio aceito, processamento e atribuição: receber a requisição não garante que a conversão será atribuída.
Exemplo 4: Plataforma de venda (checkout) com webhook
Situação: o lead recebe o link do checkout, paga e a plataforma de vendas envia um webhook de compra aprovada.
- O que coletar: no primeiro contato, os mesmos dados dos exemplos anteriores (identificadores do canal, e-mail, telefone). No webhook do checkout: ID do pedido, status, valor, moeda, e-mail e telefone usados na compra, data.
- Onde guardar: o banco do lead (que já existia) mais uma tabela de pedidos.
- Chave de busca: preferencialmente o ID interno do lead/oportunidade passado ao checkout como metadado. E-mail normalizado e/ou telefone são alternativas, com checagem de coincidências e dados divergentes. O ID do pedido serve para não enviar a mesma compra duas vezes.
- O que escutar: o webhook de compra aprovada. Valide a assinatura do webhook e o status: pedido gerado, Pix pendente ou boleto não pago não é compra.
- Evento: compra, com valor e moeda.
- Envio: a integração busca o lead no banco pelo telefone ou e-mail do checkout, encontra a origem salva e monta o pacote com o identificador daquela origem: para Meta, o evento de compra com os dados do cliente; para o Google, a conversão com o identificador de clique ou com os dados com hash.
- Destino: Meta e/ou Google, conforme os vínculos efetivamente armazenados e a configuração de medição. Uma pessoa pode ter pontos de contato nas duas plataformas. Envie cada pacote elegível ao seu destino, sem fabricar uma origem exclusiva nem somar relatórios das plataformas como se fossem vendas únicas.
Limites:
- Se você não encontra o lead no banco, não invente atribuição. Registre como origem desconhecida.
- A origem do clique e o local da conversão são coisas diferentes. Uma compra concluída no checkout não vira "conversão de conversa" só porque o lead um dia teve um
ctwa_clid. Escolha o tipo de origem do evento (action_source) conforme onde a conversão aconteceu e confira as regras do guia correspondente. - Estorno e reembolso: a conversão já enviada fica lá. Registre a mudança na sua base e confira o mecanismo de ajuste ou retração no caminho de envio utilizado; não reenvie a compra como nova.
Prompt para colar na sua IA
Copie o bloco inteiro. Ele é autossuficiente: já traz as estruturas, as regras e as fontes. Cole numa conversa nova e responda as perguntas que ela fizer.
Você é um arquiteto de trackeamento de campanhas de tráfego pago. Vou te descrever uma campanha e você vai me ajudar a desenhar o sistema, sem escrever código antes de eu confirmar o desenho.
DEFINIÇÕES (use sempre assim)
- Rastreamento: coletar e guardar, no meu banco, os dados do lead (origem, identificadores, contato, o que aconteceu depois).
- Trackeamento: devolver conversões (lead, lead qualificado, compra com valor) à plataforma de tráfego, a partir desses dados.
LÓGICA UNIVERSAL (4 passos, para qualquer estrutura)
1. MAPEAR: tipo de campanha -> quais dados a plataforma precisa receber de volta.
2. COLETAR E GUARDAR: salvar no banco, no primeiro contato, os identificadores do canal (cada um em campo próprio), contato, UTMs, data e consentimento, com uma chave de busca.
3. ESCUTAR: detectar onde o lead qualifica ou compra (CRM, webhook de checkout/gateway, conversa).
4. DEVOLVER: a integração recebe o aviso, busca no banco pela chave, monta o pacote no formato da plataforma, envia, e registra o envio para não duplicar.
SEU PROCESSO
A) Pergunte, uma pergunta por vez: qual plataforma de anúncio? qual o destino do clique (WhatsApp, formulário instantâneo, site, checkout)? onde o lead é trabalhado (CRM, atendimento no WhatsApp, planilha)? onde a venda é confirmada (gateway, CRM, conversa)? quais ferramentas (n8n, banco, CRM)?
B) Identifique qual das 4 estruturas abaixo se aplica (pode ser mais de uma).
C) Liste os parâmetros a coletar, o banco (campos), a chave de busca, o que escutar, o evento, o envio e o destino.
D) Desenhe o esquema em texto: coleta -> banco -> escuta -> pacote -> plataforma.
E) Aponte os limites e riscos da estrutura.
F) Aponte a documentação oficial correspondente (links abaixo) e peça que eu confira a versão vigente antes de implementar. Se você não conseguir abrir uma página, diga que NÃO verificou. Não invente nome de campo, evento ou versão de API: se não tiver certeza, marque como "conferir na documentação".
ESTRUTURA 1: WhatsApp (Click-to-WhatsApp) no Meta Ads
- Coletar: do webhook de mensagem, o objeto referral: ctwa_clid (identificador do clique) e source_id (origem do anúncio; é o ID do anúncio quando source_type indica anúncio). São campos DIFERENTES. Também telefone e nome de perfil. E-mail só se eu pedir por chatbot.
- Banco: leads, conversas e pontos de contato com data. Chave: ID interno do lead/conversa, associado ao telefone normalizado com DDI confirmado. Não escolha um clique apenas porque o telefone coincide.
- Escutar: etapa no CRM ou confirmação de pagamento. Exemplo: "consulta agendada" sinaliza qualificação; "Pix recebido R$ 2.000" permite extrair 2000.00 como valor candidato. Confirme o agendamento/pagamento e valor no registro estruturado antes de enviar QualifiedLead ou Purchase com currency BRL. Texto digitado NÃO comprova pagamento.
- Limite: verificar se a integração expõe as mensagens de saída e identifica seu autor. Se não, usar evento do CRM/pagamento. Verificar se referral e ctwa_clid estão realmente presentes; não inventar valores ausentes.
- Enviar: Conversions API para mensagens comerciais com action_source business_messaging e messaging_channel whatsapp; no caminho com clique, ctwa_clid e whatsapp_business_account_id em user_data, sem hash no ctwa_clid; QualifiedLead ou Purchase conforme o fato; valor e moeda na compra; deduplicação feita por mim.
- Docs: https://developers.facebook.com/documentation/ads-commerce/conversions-api/business-messaging ; https://developers.facebook.com/documentation/ads-commerce/conversions-api/business-messaging
ESTRUTURA 2: Formulário instantâneo (Lead Ads) da Meta + CRM
- Coletar: o webhook leadgen traz leadgen_id; uma segunda chamada autenticada (permissão leads_retrieval) busca os dados do formulário. Salvar o lead no banco assim que chegar.
- Chave: ID do lead (texto, 15 a 17 dígitos).
- Escutar: mudança de etapa no kanban do CRM.
- Enviar: Conversions API com lead_id em user_data, conforme a integração de leads de CRM; nomes de estágio estáveis.
- Docs: https://developers.facebook.com/documentation/ads-commerce/marketing-api/guides/lead-ads/retrieving ; https://developers.facebook.com/documentation/ads-commerce/conversions-api/conversion-leads-integration
ESTRUTURA 3: Site com formulário -> CRM -> Meta e Google Ads
- Coletar: gclid, gbraid, wbraid (Google, cada um em campo próprio); fbclid (parâmetro da URL), cookies _fbc e _fbp (enviados como fbc e fbp); se houver fbclid real e não houver _fbc, consultar a formatação oficial de fbc, com creationTime em milissegundos, sem inventar um clique; preservar maiúsculas/minúsculas desses valores; UTMs; e-mail; telefone; consentimento. fbclid e fbc NÃO são a mesma coisa. Nunca enviar o ID de uma plataforma para a outra e nunca tratar todos os IDs de clique como um só.
- Chave: ID do lead + e-mail normalizado + telefone em formato internacional.
- Escutar: etapa no CRM.
- Enviar à Meta: Conversions API; e-mail e telefone com hash SHA-256 após normalização; fbc, fbp, IP e user agent SEM hash.
- Enviar ao Google: conversão offline / conversão otimizada para leads. A importação via Google Ads API (UploadClickConversions) está sendo migrada para a Data Manager API; para integração nova, usar a Data Manager API. Conferir elegibilidade e prazo antes de implementar. Campos diferem entre as duas APIs.
- Docs Meta: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/customer-information-parameters ; https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
- Docs Google: https://developers.google.com/data-manager/api/devguides/events/google-ads/offline ; https://developers.google.com/google-ads/api/docs/conversions/upload-offline ; https://support.google.com/google-ads/answer/11021502
ESTRUTURA 4: Plataforma de venda / checkout com webhook
- Coletar no primeiro contato os identificadores do canal; no webhook, ID do pedido, status, valor, moeda, e-mail, telefone, data.
- Chave: ID interno do lead/oportunidade em metadado do checkout, se disponível; e-mail/telefone normalizados como alternativa, com checagem de ambiguidades; ID do pedido para idempotência.
- Escutar: webhook de compra APROVADA (validar assinatura e status; pedido gerado ou Pix pendente não é compra).
- Enviar: buscar o lead no banco, achar a origem, e enviar a compra com valor ao destino correspondente (Meta e/ou Google conforme os vínculos válidos), cada um com seu pacote e identificadores. Se o lead não for encontrado, registrar origem desconhecida; não inventar atribuição.
- Limite: a origem do clique e o local da conversão são diferentes; escolher action_source conforme onde a conversão aconteceu.
VALIDAÇÃO OBRIGATÓRIA
- Diferencie dados ausentes, inválidos e não aplicáveis. Preserve original e normalizado, DDI explícito e histórico dos pontos de contato.
- Faça um caso sintético ponta a ponta e repita o mesmo webhook: a segunda entrega não pode gerar outra compra. Registre ID do evento/pedido, estado do envio, tentativas e erros; reenvie falhas de forma controlada.
- Deduplicação entre Pixel e CAPI precisa do mesmo event_name e event_id quando representam o mesmo evento; isso é diferente de controlar retries do webhook no meu banco.
- Confirme pré-requisitos de conversões otimizadas para leads (tag/importação, termos de dados, consentimento e identificadores exigidos). Sem clique, não prometa que só enviar um hash basta.
- Verifique diagnóstico e atribuição além do HTTP de aceite. A API pode aceitar o pacote sem atribuir a conversão.
REGRAS DE SEGURANÇA
- Use dados fictícios nos exemplos. Nunca peça nem escreva tokens, senhas ou endpoints reais.
- Não prometa atribuição perfeita nem resultado de campanha.
- Se algo depender da minha conta, plano ou ferramenta, diga o que eu devo conferir.
Comece agora perguntando qual é a minha plataforma de anúncio.Perguntas frequentes
Preciso mandar todos os identificadores de clique para todas as plataformas? Não. Cada plataforma tem os seus. Os da Meta (ctwa_clid, fbc, fbp, lead_id) vão para a Meta; os do Google (gclid, gbraid, wbraid) vão para o Google. Guarde cada um em campo próprio e envie cada um ao seu destino.
fbclid e fbc são a mesma coisa? Não. fbclid é o parâmetro da URL. fbc é o valor formatado que você envia à Conversions API, e inclui o fbclid. Se o cookie _fbc não existir, você monta o fbc a partir do fbclid da URL, seguindo o formato da documentação.
source_id e ctwa_clid são a mesma coisa? Não. source_id aponta a origem do anúncio; ctwa_clid identifica o clique gerado pela Meta. Um diz *qual anúncio*, o outro *qual clique*.
E-mail e identificador de clique são os mais importantes para a Meta? E-mail está entre os parâmetros de alta qualidade citados nas boas práticas gerais. No CTWA, a Meta recomenda enviar ctwa_clid quando disponível por identificar diretamente o clique. Isso não estabelece um ranking único para todos os canais: use o contrato específico da integração.
Posso deixar uma regra de frase decidir que houve compra no WhatsApp? Pode servir de gatilho, mas não como prova. Texto de atendente não comprova pagamento. Confirme no gateway ou no CRM, e use o valor desse registro.
Toda API do WhatsApp me entrega o que o atendente escreveu? Não. Depende de como o número foi integrado e da ferramenta. Teste antes. Se as mensagens de saída não chegarem, escute o CRM.
Posso usar a antiga importação de conversões offline do Google? Depende da sua integração. O caminho antigo está sendo migrado para a Data Manager API e é restrito para integrações sem histórico elegível. Para um projeto novo, comece pela Data Manager API e confira a elegibilidade na documentação.
Isso garante atribuição perfeita? Não. Esse desenho melhora a chance de a plataforma reconhecer quem converteu, mas depende de consentimento, de o identificador existir, de o dado chegar correto e de a plataforma conseguir casar o evento. Teste com um caso real e confira os diagnósticos.
Como conferir se o mapa funcionou
Crie um lead sintético identificável, confirme que os dados foram salvos e avance uma etapa no CRM. Confira o vínculo da conversão com a oportunidade certa, o momento real do evento e o destino. Depois repita o mesmo webhook: deve continuar existindo uma única conversão lógica. Se houver erro temporário, o reenvio deve reutilizar o identificador original.
Quando Pixel e CAPI reportarem o mesmo evento web, mantenha event_name e event_id consistentes conforme as boas práticas da Meta. Isso complementa o controle de duplicidade no seu banco; não o substitui. Verifique os diagnósticos das plataformas e registre o que foi recebido, processado e atribuído separadamente.
Checklist antes de implementar
Confira antes de ligar o trackeamento
Fontes e documentação oficial
Datei este material em 11/11/2026. APIs e páginas de ajuda mudam: a versão vigente na documentação é a que vale.
Meta
- Conversions API para mensagens comerciais
- Parâmetros de informação do cliente
- `fbp` e `fbc`
- Boas práticas da Conversions API
- Integração de leads de CRM
- Lead Ads: recuperação de leads
- WhatsApp: campos de referral e exemplo de mensagem no guia de mensagens comerciais
- Conversões offline na Google Ads API
- Data Manager API: conversões offline
- Ajuda: conversões otimizadas para leads
Neste blog
- Para o passo a passo do WhatsApp com n8n, veja Conversões do WhatsApp com n8n: webhook, ctwa_clid e API da Meta.
- Preciso criar outro Pixel para testar outra oferta?
Fechamento
Mapear, guardar, escutar, devolver. Esse é o desenho de qualquer trackeamento. Sem promessa de atribuição perfeita: é o caminho para a plataforma receber o resultado real, e não só o clique.
Se este material ajudou, me segue para mais conteúdo como este. O rastreamento deixa a pessoa inteligente. O trackeamento deixa a plataforma inteligente.















