Sua API de Conversões está instalada e com nota 4. A Meta está enxergando menos da metade dos seus clientes.

Tem uma frase que aparece em quase toda reunião de diagnóstico: "a API de Conversões já está instalada". Em geral está mesmo. Os eventos chegam, o painel mostra número, o desenvolvedor entregou o que foi pedido.

Aí a gente abre o Gerenciador de Eventos, clica no evento de compra e olha uma nota que quase ninguém olha. Ela vai de 0 a 10 e se chama qualidade de correspondência de eventos. Costuma estar entre 3 e 5.

O que essa nota diz, em português: de cada dez pessoas que compraram de você, a Meta conseguiu reconhecer três ou quatro.

O que a nota mede de verdade

Não é se o evento chegou. É se a Meta conseguiu ligar aquele evento a uma pessoa.

Quando alguém compra no seu site, o seu servidor manda para a Meta um aviso: aconteceu uma compra, de tal valor, com tais informações de contato. A Meta pega essas informações, compara com a base dela e tenta descobrir de quem é. Se consegue, aquela conversão vira aprendizado: o sistema passa a saber que aquele tipo de pessoa compra, e vai procurar gente parecida.

Se não consegue, o evento entra no relatório e não serve para mais nada. Você vê a venda. O algoritmo não.

A faixa saudável começa em 7. Acima de 8 é excelente. Abaixo de 5 existe problema de implementação, e não de ajuste fino.

Onde ver

No Gerenciador de Eventos, selecione o conjunto de dados, abra o evento que interessa (compra, cadastro, contato) e procure a qualidade de correspondência. A Meta mostra a nota e, ao lado, quais parâmetros estão sendo enviados e qual a cobertura de cada um.

Essa segunda parte é a que interessa. A nota diz que tem problema. A lista de parâmetros diz qual é.

Os parâmetros, em ordem de peso

Nem toda informação vale o mesmo. Enviar mais campos ajuda, mas existe uma hierarquia clara.

O fbc é o que mais pesa, e por um motivo lógico: ele não identifica só a pessoa, identifica o clique específico no anúncio específico que levou àquela compra. É a diferença entre a Meta saber que fulano comprou e saber que fulano comprou depois de clicar naquele anúncio.

Por que o seu fbc some

Como ele é o mais importante, vale entender os três jeitos de perdê-lo. Vemos os três com frequência.

1. Alguém limpou a URL. O fbc nasce do parâmetro fbclid, que a Meta gruda no link do anúncio. Se o seu site redireciona, normaliza URL, corta parâmetros por SEO ou passa por um encurtador que não preserva query string, o fbclid se perde antes de virar cookie. O sintoma clássico: eventos de navegação com fbc e eventos de compra sem.

2. O consentimento não foi dado, e está tudo certo assim. Se a pessoa recusou cookies de marketing, o fbc não deve existir mesmo. Isso não é defeito, é o banner funcionando. O erro seria tentar contornar. O que dá para fazer é medir quanto da sua nota vem dessa recusa, para não caçar um problema técnico que não existe.

3. O evento de servidor não recebeu o dado. Muito comum quando o pixel está no site e a API está no servidor, e ninguém passou o fbc do navegador para o backend na hora de fechar o pedido. O evento de servidor sai tecnicamente perfeito e cego.

Essa terceira é a mais frequente e a mais invisível, porque tudo indica sucesso: o evento chega, o status fica verde, a nota fica baixa.

Duplicação: o problema que aparece quando você resolve o outro

Quando o pixel e a API mandam o mesmo evento, a Meta precisa entender que é a mesma compra e não duas. Isso se faz com o event_id: o mesmo identificador nos dois envios, e ela descarta a cópia.

Sem isso, a conta infla. Com duas fontes reportando, o número de conversões sobe, o custo por resultado aparente cai, e o time comemora um resultado que não existe.

Vale dizer o incômodo inteiro: melhorar a correspondência costuma piorar os números do painel no curto prazo. Quando a Meta para de contar a mesma venda duas vezes, o custo por aquisição sobe na tela. Ele não subiu. Ele só parou de estar errado para menos.

E a LGPD nisso tudo

A dúvida é legítima e a resposta é mais simples do que parece.

Os dados de contato não saem em texto puro. Eles são transformados em hash, uma sequência que não volta atrás, antes de sair do seu servidor. A Meta compara hash com hash. Isso reduz risco, e não elimina a obrigação: você continua sendo o controlador desses dados e continua precisando de base legal para tratá-los.

Na prática, três coisas:

• Consentimento antes. Se o visitante recusou marketing, esses eventos não devem ser enviados com dado de identificação. Menos nota, e é o certo.
• Diga na política. A política de privacidade e a de cookies precisam descrever que dados de contato em forma de hash são compartilhados com a plataforma de anúncios, e para quê.
• Normalize antes de gerar o hash. Minúsculas, sem espaço, telefone com código do país. Isso é técnico e afeta a nota: hash de dado mal formatado não corresponde a nada, e vira exatamente o mesmo resultado de não ter enviado.

A ordem de correção que costuma funcionar

1. Confira se o fbc chega no evento de servidor. É o maior ganho isolado e o erro mais comum.
2. Confirme a deduplicação por event_id. Antes de melhorar qualquer coisa, garanta que você não está contando duas vezes.
3. Normalize e-mail e telefone. Ganho grande, custo baixo, e ninguém precisa de dado novo para isso.
4. Acrescente o ID externo. Se você tem cadastro de cliente, esse campo é gratuito em termos de privacidade e ajuda.
5. Complete o que falta no checkout. Cidade e CEP, quando você já pede, somam. Não vale criar campo novo só para isso.

O que não fazer

Não persiga nota 10. Acima de 8 o ganho marginal é pequeno e o custo de coletar mais dado é real. Nota 8 com coleta enxuta é melhor que 9 com um formulário que afugenta gente.

Não colete dado novo só para melhorar a métrica. Pedir CPF no checkout para subir a nota é trocar conversão por medição, e ainda cria obrigação de proteger um dado sensível que você não precisava ter.

Não ignore a queda de nota depois do banner de consentimento. Ela é esperada. O erro seria interpretar como falha técnica e sair mexendo no que estava certo.

Não confie no status verde. Evento recebido com sucesso quer dizer que chegou, não que serviu. São duas telas diferentes e só a segunda importa para custo.

Instalar a API de Conversões é o começo do trabalho, não o fim. A diferença entre uma implementação que existe e uma que funciona está numa nota que leva trinta segundos para conferir, e que quase ninguém abre depois que o desenvolvedor disse que terminou.

Perguntas frequentes

O que é qualidade de correspondência de eventos no Meta?

É uma nota de 0 a 10 que mede a capacidade da Meta de associar os eventos que você envia a perfis reais de pessoas. Ela não mede se o evento chegou, e sim se ele pôde ser atribuído a alguém. Eventos sem correspondência aparecem no relatório mas não alimentam a otimização.

Qual é uma boa nota de correspondência?

A faixa saudável começa em 7, e acima de 8 é considerada excelente. Abaixo de 5 normalmente existe um problema de implementação, e não de ajuste fino, geralmente relacionado a parâmetros que não estão chegando ao servidor.

Qual parâmetro mais aumenta a nota de correspondência?

O fbc, que carrega o identificador do clique no anúncio. Ele é o mais forte porque não identifica apenas a pessoa, identifica também a interação com o anúncio que antecedeu a conversão. O fbp e os hashes de e-mail e telefone vêm em seguida.

Enviar e-mail e telefone para a Meta fere a LGPD?

Os dados são transformados em hash antes do envio, o que reduz o risco, mas não elimina suas obrigações como controlador. É preciso ter base legal, respeitar a recusa de consentimento para marketing e descrever esse compartilhamento na política de privacidade e na de cookies.

Por que meu custo por conversão piorou depois que arrumei a medição?

Porque provavelmente ele estava errado para menos. Quando a deduplicação passa a funcionar, a mesma venda deixa de ser contada duas vezes e o custo real aparece. O número na tela piorou, o resultado do negócio não mudou.