O que o Meta vê quando o lead não tem cookie: external_id, fbc e fbp explicados
Bloqueador de anúncio, Safari, aba anônima, dois dispositivos: o cookie do Meta falta em quase metade das visitas. O que sobra para casar o evento com a pessoa são três campos que quase ninguém preenche direito. Este artigo diz o que cada um é, de onde vem e por que o external_id deveria ser o id do seu lead.
Os termos de busca que mais trazem gente para este blog são "_fbp cookie", "fbc fbp" e "fbclid decode". Não é coincidência: são as três coisas que o Meta usa para casar um evento com uma pessoa quando não há e-mail, e são as três que somem quando o navegador bloqueia o script do pixel. Este artigo é a resposta longa.
Os três identificadores, em uma frase cada
| Campo | O que é | De onde vem | Quando falta |
|---|---|---|---|
| fbc | O clique no anúncio: fb.1.{ms}.{fbclid} | Do parâmetro fbclid da URL quando a pessoa chega do anúncio | Visita orgânica, link copiado, fbclid removido por redirecionamento |
| fbp | O navegador: fb.1.{ms}.{aleatório} | Gerado pelo script do Meta e gravado em cookie | Bloqueador, Safari com limite de cookie, script não carregou |
| external_id | A pessoa, no SEU sistema | Você define; hasheado com SHA-256 | Quase sempre — ninguém preenche |
O ponto que muda tudo: fbc e fbp podem ser construídos do SEU lado, no seu domínio, sem depender do script do Meta. O fbc é derivado do fbclid e persistido por 90 dias; o fbp pode nascer com o mesmo formato que o script do Meta usaria — e o script, quando carrega, respeita o cookie que já existe. Contamos a medição em fbc e fbp em first-party: fbp foi de 44% para perto de 100% dos eventos.
external_id: o campo que ninguém preenche
O external_id é o identificador da pessoa no seu sistema. O Meta o usa para ligar eventos da mesma pessoa entre dispositivos e ao longo do tempo — e para casar com perfis quando você já enviou esse mesmo id antes com e-mail junto. A maioria das integrações deixa vazio, ou manda o id da sessão (que muda a cada visita e não liga nada).
O valor certo é o id do lead no seu CDP: estável, único por pessoa, o mesmo no pageView de hoje e na compra de amanhã. Numa base centralizada ele existe para 100% dos eventos — inclusive os anônimos, porque o visitante anônimo também é um lead com id. É por isso que, numa conta que medimos, o external_id era o único campo com cobertura total no pageView, enquanto o e-mail cobria 11%.
Quando duas pessoas são fundidas no seu CDP, o external_id que vai ao Meta tem de ser o da pessoa canônica. Senão o Meta continua vendo duas.
Cobertura medida, por tipo de evento
| Campo | pageView (site) | Compra (Hotmart) |
|---|---|---|
| external_id | 100% | 100% |
| fbc | 92% | 97% |
| fbp | 53% (antes do first-party) | 98% |
| e-mail / telefone | 11% / 10% | 100% / 100% |
| cidade / estado / CEP (por IP) | 97% | ~11% (declarado, sem IP) |
A leitura importante: no evento de site, quem sustenta a correspondência é a geolocalização por IP mais os cookies; na compra, é e-mail e telefone. O evento que sai do servidor tem de escolher a fonte certa para cada campo — a cidade declarada no checkout quando existe, a do IP da visita quando não. Essa cadeia é o que faz a qualidade de correspondência subir.
Erros que zeram o campo em silêncio
- Mandar o fbclid cru como fbc. O formato é fb.1.{timestamp em ms}.{fbclid}; sem o prefixo o Meta descarta.
- Gerar fbp a cada pageView. Ele identifica o NAVEGADOR; se muda, cada visita é um navegador novo.
- Mandar external_id sem hash, ou hasheado com normalização diferente entre eventos. O hash tem de ser igual hoje e amanhã.
- Deixar o IP do servidor no client_ip_address. O IP tem de ser o do navegador da pessoa — e pode ser IPv6.
- Tratar "não tem cookie" como "não mande nada". Sem cookie ainda há e-mail, telefone, external_id, IP e user agent — e é aí que o servidor ganha do pixel.
No CrazyLeads o pixel constrói fbc e fbp em first-party, o resolvedor grava os dois como atributo do lead (então a compra vinda da Hotmart, que não tem cookie próprio, herda o último conhecido da pessoa), e o external_id de todo evento é o id canônico do lead — o mesmo que aparece na ficha.