fbc e fbp em first-party: recuperar o clique que o bloqueador apagou

Os dois cookies que mais ajudam a atribuição do Meta são criados por um script que boa parte do público bloqueia. Os dois podem ser construídos pelo seu lado — um deles com um cuidado que não pode ser ignorado.

Depois do e-mail, os dois campos que mais movem a atribuição do Meta são cookies: o _fbc, que guarda o clique no anúncio, e o _fbp, que identifica o navegador. Os dois são criados pelo script do Meta, que é exatamente o arquivo que bloqueador de anúncio derruba primeiro.

A boa notícia é que os dois têm formato documentado e podem ser construídos em first-party, pelo seu próprio código. A má é que um deles não pode ser inventado, e confundir os dois casos gera dado falso.

Os formatos

_fbc = fb.1.<timestamp_ms>.<fbclid da URL>
_fbp = fb.1.<timestamp_ms>.<numero aleatorio>

  fb  -> prefixo fixo
  1   -> versao do subdominio (raiz do dominio)

A diferença entre eles está na última parte. O _fbc carrega um valor que veio de fora — o fbclid que o Meta colocou na URL quando a pessoa clicou no anúncio. O _fbp carrega um número aleatório, gerado localmente, cuja única função é ser estável naquele navegador.

O fbp pode ser gerado, e deveria

Como o valor é aleatório por definição, não existe nada de errado em criá-lo você mesmo. E o script do Meta respeita um _fbp que já exista: se o cookie está lá quando ele carrega, ele usa em vez de criar outro.

Isso significa que o navegador e o envio pelo servidor passam a compartilhar o mesmo identificador — que é o ponto inteiro do parâmetro. Numa base que medimos, a cobertura de _fbp nos envios estava em 44% justamente porque dependia do script; o _fbc, que já era construído a partir da URL, estava em 93%.

O _fbp só serve se for estável. Gerar um valor novo a cada carregamento de página produz cobertura de 100% e utilidade zero — cada evento vira um navegador diferente.

Na prática: gere uma vez, persista por noventa dias, escreva no domínio raiz para valer nos subdomínios, e nunca regenere se o cookie já existir.

O fbc não pode ser inventado

Aqui mora a linha que não se atravessa. O _fbc representa um clique real num anúncio, e o valor dentro dele é o identificador que o Meta emitiu para aquele clique. Se não veio fbclid na URL, não houve clique rastreável — e fabricar um valor não cria atribuição, cria ruído.

O que dá para fazer, e vale muito, é construí-lo você mesmo quando o fbclid está presente: ler o parâmetro da URL, montar o formato acima e persistir. Assim o clique sobrevive mesmo que o script do Meta nunca carregue.

• Chegou com fbclid: monte o _fbc a partir dele e persista por noventa dias.
• Não chegou com fbclid, mas já existe um _fbc de uma visita anterior: use o que existe.
• Nunca houve fbclid: não mande fbc. A ausência é a informação correta.

O detalhe do subdomínio

Os dois cookies precisam ser escritos no domínio raiz, não no host específico. Um cookie escrito em loja.exemplo.com não é lido em exemplo.com, e o resultado é que a mesma pessoa vira duas pessoas ao trocar de subdomínio no meio do funil.

É um erro que não aparece em teste, porque em desenvolvimento quase sempre se usa um host só.

O que esperar do ganho

Não espere que os cookies substituam o e-mail. Eles fazem outro trabalho: o e-mail diz quem é a pessoa, o _fbc diz por qual anúncio ela chegou e o _fbp costura as sessões dela entre si.

O ganho concreto aparece nas conversões em que o e-mail existe mas a origem não — que é a maioria delas quando a venda acontece fora do site. Sem o _fbc, essa venda entra como conversão sem clique associado, e a campanha que a trouxe não recebe crédito nenhum.

No CrazyLeads o _fbc é construído a partir do fbclid e o _fbp é gerado em first-party com o mesmo formato que o script do Meta espera, os dois persistidos por noventa dias no domínio raiz — e ambos viajam no envio pelo servidor, junto com o resto do grafo de identidade.