O link da bio levou a venda que o anúncio fez: como montar a jornada no seu painel

Este é o material do JORNADA. Você viu no vídeo: a pessoa clica no anúncio, entra na página, não compra, passa uns dias consumindo o seu conteúdo e, no décimo dia, compra pelo link da bio. O anúncio fez o trabalho pesado. Quem aparece na venda é a bio.

Aqui eu te mostro por que isso acontece e como montar essa visão de jornada no seu próprio painel: o que capturar, como guardar, como ligar a compra aos toques e como exibir. No meio tem um prompt pronto para colar na sua IA e, no fim, o atalho para quem quer isso funcionando sem montar do zero.

Resposta curta

O gerenciador de anúncios só atribui a venda à campanha se ela acontecer dentro da janela de atribuição configurada. A UTM que chega com a compra conta só o último caminho. Nenhuma das duas está errada; elas respondem perguntas diferentes.

Para enxergar o anúncio que começou a venda, você precisa de três coisas: registrar cada toque (visita, clique, conversa) com a origem e o horário, reconhecer que é a mesma pessoa quando ela volta e ligar a compra a esse histórico. Com isso, o seu painel mostra a jornada inteira e permite escolher a visão: primeiro clique, último clique ou a do gerenciador.

Por que o anúncio some dessa venda

São dois motivos que se somam.

1. A janela de atribuição. No Meta Ads, cada conjunto de anúncios tem uma configuração de atribuição: quantos dias depois do clique (ou da visualização) uma conversão ainda pode ser creditada ao anúncio. Se a sua janela é de 7 dias após o clique e a pessoa compra no dia 10, o evento de compra pode até chegar à Meta pelo Pixel ou pela API de Conversões, mas não entra como resultado daquela campanha.

Vale saber o que mudou: desde 12 de janeiro de 2026 a Meta deixou de retornar na API de Insights as janelas de 7 e 28 dias após a visualização. Continuam disponíveis 1, 7 e 28 dias após o clique, 1 dia após visualização engajada e 1 dia após a visualização, além do padrão definido na configuração de cada anunciante. Não confie em número padrão de cabeça: abra o conjunto de anúncios e confira a configuração de atribuição da sua conta.

2. A última UTM. Quando a compra chega com utm_source=bio (ou o nome que você usa no link da bio), qualquer relatório que olhe só a UTM da compra vai dar o crédito para a bio. Ela foi o último caminho, mas não foi o único.

Quem mais sente isso é quem vende com ciclo longo: imóveis, high ticket, serviços com várias conversas. A pessoa clica hoje e compra daqui a 30 dias. E quem tem orgânico forte, porque o conteúdo vira a ponte entre o anúncio e a compra.

Três visões da mesma venda (nenhuma está errada)

O erro é tratar uma delas como verdade absoluta. O gerenciador alimenta a otimização da Meta. O primeiro clique mostra quem abre portas. O último clique mostra quem fecha. Ver as três lado a lado é o que permite defender a verba do anúncio sem brigar com o número do gerenciador.

Como montar a visão de jornada no seu painel

O desenho é o mesmo do MAPA: coletar e guardar no primeiro contato, escutar a venda e cruzar. A diferença é que aqui você não guarda só o primeiro toque. Guarda todos.

1. Padronize as UTMs e coloque o ID do anúncio nelas

Cruzar venda com campanha pelo nome da campanha é frágil: nome muda, se repete, tem acento. O nível mais preciso é o ID do anúncio. No Meta Ads, os parâmetros de URL aceitam variáveis dinâmicas como {{ad.id}}, {{adset.id}} e {{campaign.id}}, que a Meta preenche no clique. Exemplo:

utm_source=meta&utm_medium=pago&utm_campaign={{campaign.id}}&utm_content={{ad.id}}

No link da bio, use UTMs fixas e suas, por exemplo utm_source=instagram&utm_medium=bio. Tenho um guia só sobre isso: variáveis dinâmicas do Meta Ads para UTMs.

2. Dê um ID próprio a cada visitante

Na primeira visita, o seu script cria um identificador (um UUID, por exemplo) e salva num cookie first-party do seu domínio. Toda visita seguinte do mesmo navegador traz esse ID. É ele que costura o dia 1 com o dia 10.

Limite honesto: o cookie é por navegador. Se a pessoa clicou no anúncio pelo celular e comprou no computador, o cookie sozinho não liga as duas pontas. Quem liga é a identidade do passo 4.

3. Registre cada toque, não só o primeiro

Cada visita que chega com origem (UTM ou ID de clique) vira uma linha numa tabela de toques. Guarde, cada um em campo próprio:

• data e hora (com fuso), página de entrada e referrer;
• utm_source, utm_medium, utm_campaign, utm_content, utm_term;
• Meta: fbclid da URL e os cookies _fbc e _fbp. fbclid e fbc não são a mesma coisa: o fbc segue o formato fb.<subdomainIndex>.<creationTime>.<fbclid>, com o tempo em milissegundos, e o valor do clique é sensível a maiúsculas e minúsculas;
• Google: gclid, gbraid e wbraid, cada um no seu campo;
• WhatsApp vindo de anúncio (Click-to-WhatsApp): o ctwa_clid e o source_id que chegam no objeto referral da primeira mensagem. Aqui o toque não acontece no site; ele entra no banco pelo webhook da conversa, ligado ao telefone.

Regra de ouro: nunca sobrescreva. O primeiro toque e o último toque são consultas sobre a tabela, não campos que você atualiza.

4. Junte a identidade quando o lead se identifica

Quando a pessoa preenche um formulário, entra num chat ou chega ao checkout, você passa a ter e-mail e/ou telefone. Nesse momento, ligue o ID do visitante ao lead. Se o mesmo e-mail aparecer depois em outro navegador, os dois visitantes passam a apontar para o mesmo lead, e a jornada dos dois aparelhos se junta.

Normalize antes de comparar: e-mail em minúsculas e sem espaços, telefone em formato internacional com DDI. Se um dia for enviar esses dados à Meta pela API de Conversões, aí sim aplique hash SHA-256 depois da normalização, como pede a documentação. No seu banco, cuide do consentimento e do acesso (LGPD).

5. Ligue a compra à jornada

A venda chega pelo webhook da plataforma de venda (compra aprovada). Para encontrar a jornada, use, nesta ordem:

1. o ID do visitante, se a sua plataforma aceitar um parâmetro próprio no link do checkout e devolvê-lo no webhook (confira na documentação dela);
2. o e-mail normalizado do comprador;
3. o telefone normalizado.

Guarde a compra com o ID do pedido como chave única (assim o reenvio do webhook não duplica a venda), o valor, a moeda e a data de aprovação.

6. Exiba: linha do tempo por lead e "anúncios que participaram"

Com toques e compras ligados ao mesmo lead, o painel faz duas telas que mudam a conversa:

• Linha do tempo do lead: todos os toques em ordem, com data, hora, origem e anúncio. É o "dia 1, 14h32, clicou no anúncio X" que aparece no vídeo.
• Anúncios que participaram: para cada anúncio, quantas vendas tiveram pelo menos um toque dele numa janela que você escolhe (30, 60, 90 dias). Ao lado, as colunas de primeiro clique, último clique e o resultado do gerenciador.

Um esqueleto de banco para começar (PostgreSQL; adapte ao seu):

create table leads (
  id uuid primary key,
  email_normalizado text unique,
  telefone_e164 text unique,
  criado_em timestamptz not null default now()
);

create table visitantes (
  id uuid primary key,            -- o ID do cookie first-party
  lead_id uuid references leads(id),
  criado_em timestamptz not null default now()
);

create table toques (
  id bigserial primary key,
  visitante_id uuid references visitantes(id),
  lead_id uuid references leads(id),  -- preenchido quando há identidade (ex.: WhatsApp)
  ocorrido_em timestamptz not null,
  canal text not null,                -- site, whatsapp, formulario...
  pagina text,
  referrer text,
  utm_source text, utm_medium text, utm_campaign text, utm_content text, utm_term text,
  ad_id text,
  fbclid text, fbc text, fbp text,
  gclid text, gbraid text, wbraid text,
  ctwa_clid text, ctwa_source_id text
);

create table compras (
  id bigserial primary key,
  plataforma text not null,
  pedido_id text not null,
  lead_id uuid references leads(id),
  valor numeric(12,2) not null,
  moeda text not null default 'BRL',
  aprovada_em timestamptz not null,
  unique (plataforma, pedido_id)
);

-- Anúncios que participaram de vendas nos 30 dias anteriores à compra
with toques_do_lead as (
  select coalesce(t.lead_id, v.lead_id) as lead_id, t.ad_id, t.ocorrido_em
  from toques t
  left join visitantes v on v.id = t.visitante_id
  where t.ad_id is not null
)
select tl.ad_id,
       count(distinct c.id) as vendas_com_participacao
from compras c
join toques_do_lead tl
  on tl.lead_id = c.lead_id
 and tl.ocorrido_em <= c.aprovada_em
 and tl.ocorrido_em >= c.aprovada_em - interval '30 days'
group by tl.ad_id
order by vendas_com_participacao desc;

Cuidado na leitura: uma venda com três anúncios na jornada conta para os três. É uma visão de participação, não de divisão de receita. Se somar a receita de todos os anúncios, você vai passar do faturamento real. Para dividir crédito, escolha uma regra (primeiro clique, último clique ou divisão igual) e deixe isso escrito no painel.

Prompt para colar na sua IA

Copie o bloco inteiro e cole no ChatGPT, Claude ou na IA que você usa para programar. Ela vai te fazer perguntas antes de escrever qualquer código.

Você é um arquiteto de rastreamento e atribuição para campanhas de tráfego pago. Vou montar, no meu próprio painel, uma visão de JORNADA: registrar todos os toques de cada lead (anúncio, orgânico, link da bio, WhatsApp) e ligar a compra a esse histórico. Não escreva código antes de eu confirmar o desenho.

CONTEXTO
- Problema: a pessoa clica no anúncio, não compra, volta dias depois por outro caminho (ex.: link da bio) e compra. O gerenciador só atribui dentro da janela de atribuição configurada; a UTM da compra mostra só o último caminho.
- Objetivo: mostrar três visões lado a lado (primeiro clique, último clique e o resultado do gerenciador) e um relatório de "anúncios que participaram" com janela escolhida por mim.

SEU PROCESSO
A) Pergunte, uma pergunta por vez: onde fica meu site e como posso inserir um script; qual plataforma de venda uso e o que o webhook de compra aprovada envia; se tenho WhatsApp vindo de anúncio; qual banco de dados e ferramenta de integração uso (ex.: PostgreSQL, Supabase, n8n); qual janela de análise quero (30, 60, 90 dias); onde quero ver o painel.
B) Desenhe o fluxo em texto: script no site -> endpoint de coleta -> banco (toques) -> identidade (lead) -> webhook de compra -> cruzamento -> painel.
C) Proponha o esquema do banco com estas entidades: leads (e-mail normalizado, telefone E.164), visitantes (ID em cookie first-party, ligado ao lead), toques (uma linha por toque, nunca sobrescrever) e compras (chave única plataforma + pedido_id, valor, moeda, data de aprovação).
D) Liste o que o script deve capturar em cada visita, cada item em campo próprio: data/hora com fuso, página, referrer, utm_source, utm_medium, utm_campaign, utm_content, utm_term, ad_id, fbclid, cookies _fbc e _fbp, gclid, gbraid, wbraid. Para WhatsApp de anúncio: ctwa_clid e source_id do objeto referral do webhook da primeira mensagem, ligados ao telefone.
E) Regras que você deve respeitar:
   - fbclid e fbc são coisas diferentes; fbc segue fb.<subdomainIndex>.<creationTime em ms>.<fbclid>; não altere maiúsculas/minúsculas de IDs de clique.
   - Nunca misture IDs de plataformas diferentes num campo só.
   - Primeiro e último toque são consultas, não campos atualizados.
   - Ligue a compra ao lead pelo ID do visitante (se a plataforma devolver um parâmetro próprio no webhook), depois e-mail normalizado, depois telefone normalizado.
   - Deduplique compras pela chave única do pedido.
   - No relatório de participação, uma venda conta para todos os anúncios da jornada; não some receita entre anúncios.
   - Dados pessoais: consentimento, acesso restrito e hash SHA-256 só ao enviar para plataformas de anúncio, após normalizar.
F) Entregue, depois que eu confirmar: o script de coleta, o endpoint que grava os toques, o SQL das tabelas, o fluxo do webhook de compra, as consultas de primeiro clique, último clique e anúncios que participaram, e a especificação de duas telas (linha do tempo por lead e relatório por anúncio).
G) Aponte limites: cookie é por navegador; bloqueadores e navegação anônima perdem toques; o número do painel não vai bater com o do gerenciador, e isso é esperado.
H) Use a documentação oficial abaixo e peça que eu confira a versão vigente. Se não conseguir abrir uma página, diga que NÃO verificou. Não invente nome de campo, parâmetro ou versão de API; marque como "conferir na documentação".

DOCUMENTAÇÃO
- Meta, fbc e fbp: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
- Meta, parâmetros de informação do cliente (normalização e hash): https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/customer-information-parameters
- Meta, mensagens comerciais e ctwa_clid: https://developers.facebook.com/documentation/ads-commerce/conversions-api/business-messaging
- Meta, mudanças nas janelas de atribuição da API de Insights (12/01/2026): https://developers.facebook.com/blog/post/2025/10/16/ads-insights-api-metric-availability-updates/
- Google Ads, gclid, gbraid e wbraid em conversões otimizadas para leads: https://support.google.com/google-ads/answer/11021502

Comece pela primeira pergunta.

Quer isso pronto? Conheça o RastrackDash Info

Montar tudo isso do zero é possível, e o prompt acima te leva até lá. Mas é exatamente o problema que eu resolvi para a minha operação e transformei em produto.

O RastrackDash Info organiza essa investigação numa instalação própria: um script first-party coleta a origem de cada visita, e o painel junta campanhas, eventos, leads, checkouts e a jornada de cada pessoa. Na tela de campanhas, você alterna entre a visão da Meta e a visão RastrackDash, por primeiro ou último anúncio. Mais detalhes no artigo RastrackDash Info: qual campanha trouxe a venda que passou pelo site?.

Perguntas frequentes

A Meta está errada quando não conta a venda do dia 10?

Não. Ela segue a regra da janela de atribuição que está configurada. O que acontece é que essa regra responde "o que a campanha gerou dentro da janela", e você quer saber também "de quais vendas o anúncio participou". São perguntas diferentes.

Se eu aumentar a janela, resolvo?

Ajuda em parte, mas a janela no gerenciador tem limites e afeta como a plataforma lê os resultados. Ela também não mostra a jornada pessoa a pessoa. O seu painel não tem esse limite: a janela da análise é você quem escolhe.

O número do meu painel vai bater com o do gerenciador?

Não vai, e não deveria. Cada visão tem regras diferentes. O que importa é saber qual regra cada número segue e usar a visão certa para cada decisão.

Preciso de programador?

Para a versão do zero, alguém precisa instalar o script, criar o banco e ligar o webhook da plataforma de venda. O prompt deste material guia a IA a desenhar e escrever essas peças com você. Se preferir algo pronto, é para isso que existe o RastrackDash Info.

E quem vende pelo WhatsApp?

O toque do anúncio chega no webhook da primeira mensagem, com o ctwa_clid no objeto referral. Grave esse toque ligado ao telefone e a jornada continua funcionando. O MAPA detalha essa estrutura.

Fontes e documentação oficial

• Meta for Developers, atualização de disponibilidade de métricas da API de Insights (janelas de atribuição, 12/01/2026): https://developers.facebook.com/blog/post/2025/10/16/ads-insights-api-metric-availability-updates/
• Meta for Developers, parâmetros fbp e fbc: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/fbp-and-fbc
• Meta for Developers, parâmetros de informação do cliente: https://developers.facebook.com/documentation/ads-commerce/conversions-api/parameters/customer-information-parameters
• Meta for Developers, API de Conversões para mensagens comerciais (ctwa_clid): https://developers.facebook.com/documentation/ads-commerce/conversions-api/business-messaging
• Google Ads Ajuda, conversões otimizadas para leads (gclid, gbraid, wbraid): https://support.google.com/google-ads/answer/11021502

Fechamento

O anúncio não precisa ganhar a briga com o link da bio. Os dois fazem parte da mesma venda. O que muda o jogo é ter a jornada guardada: aí você para de discutir qual número está certo e passa a decidir com as três visões na mesa.