Connect Rate no Meta Ads: o que é e como melhorar

Connect Rate é o nome que damos ao Event Match Quality (EMQ) do Meta Ads. Veja o que move a nota de 0 a 10 e como melhorar o matching dos seus eventos.

13 de julho de 202610 min de leiturapor Vinicius Castilho

Direto ao ponto

O SHA-256 exigido pelo Meta é sensível a qualquer diferença no texto: um email em maiúsculas ou um telefone com máscara brasileira gera um hash que nunca bate com o perfil do Meta, mesmo com o evento chegando normalmente no painel. Email e telefone hasheados são os matchers mais fortes da hierarquia, mas só contam se normalizados (trim, lowercase, formato E.164) antes do hash.

Connect Rate é o nome que damos ao Event Match Quality (EMQ) do Meta: a nota de 0 a 10 que o Gerenciador de Eventos dá para cada fonte de dados, medindo o quão bem o Meta consegue casar seus eventos com perfis reais de usuário. Quanto mais alto o número, mais da sua audiência o Meta reconhece a cada evento enviado, e melhor ele otimiza a entrega dos anúncios. Este artigo explica o que move essa nota e o que você pode fazer para melhorá-la sem depender de sorte.

Uma observação antes de seguir: "Connect Rate" é o termo que usamos aqui no ecossistema Castnexo. O nome oficial dentro do Meta é Event Match Quality. Se você abrir o Gerenciador de Eventos procurando por "Connect Rate", vai encontrar a coluna com o rótulo "Qualidade da correspondência de eventos". É a mesma métrica, o mesmo número de 0 a 10.

O que é o Connect Rate (Event Match Quality)

Todo evento que sai do seu site para o Meta carrega parâmetros de identificação: email, telefone, um cookie de clique, o IP de quem navegava. O Meta usa esses parâmetros para responder uma pergunta simples: "quem é a pessoa por trás deste evento?". Quando ele consegue responder com confiança, o evento entra na otimização de campanha, alimenta o público de retargeting e conta para o aprendizado do algoritmo. Quando não consegue, o evento perde grande parte do valor.

O EMQ é a média dessa capacidade de reconhecimento na sua fonte de dados. Um evento com email e telefone bem formados dá ao Meta muito material para o match. Um evento que chega só com IP e User-Agent dá pouco. A nota que você vê no painel é o resultado agregado de todos os eventos daquele período.

Vale entender que EMQ e volume de eventos são coisas diferentes. Você pode enviar dez mil compras por mês e ainda ter um Connect Rate baixo, porque o problema não está na quantidade de eventos e sim na qualidade dos identificadores dentro deles. É por isso que auditar o EMQ costuma revelar dinheiro deixado na mesa: os eventos já estão saindo, só chegam mal identificados.

A hierarquia de match keys: nem todo identificador pesa igual

Este é o ponto que a maioria dos gestores de tráfego ignora. Os parâmetros de matching não têm o mesmo peso. O Meta reconhece a pessoa com muito mais confiança por email hasheado do que por CEP, e mais por CEP do que por IP. A ordem de força, do identificador mais forte para o mais fraco, é esta:

  • Email em hash (em): SHA-256 do email normalizado. É o matcher individual mais forte que existe.
  • Telefone em hash (ph): SHA-256 do telefone no formato E.164 (código do país + DDD + número, sem símbolos).
  • Nome em hash (fn e ln): primeiro e último nome, cada um em SHA-256.
  • FBC (_fbc): o Facebook Click ID, capturado quando o usuário chega pelo anúncio.
  • FBP (_fbp): o Facebook Browser ID, cookie persistente do navegador.
  • Localização em hash: cidade, estado, CEP e país.
  • external_id: o identificador do usuário dentro do seu próprio sistema.
  • IP e User-Agent: capturados pelo servidor e enviados junto com o evento.

A regra prática que sai dessa hierarquia é direta: envie o máximo de identificadores que você tiver, em todo evento. Não existe escolha entre email e telefone, entre _fbc e localização. Cada parâmetro adicional dá ao Meta uma chance a mais de fechar o match, e o algoritmo usa o conjunto inteiro, não o melhor de um só. Um evento de compra que leva email, telefone, nome, _fbc, _fbp e IP é o que empurra o Connect Rate para o topo da faixa.

Há um papel do _fbc que costuma ser confundido com o EMQ e merece separação. Email e telefone servem para o Meta reconhecer a pessoa. O _fbc serve para atribuir o clique ao anúncio específico que gerou a visita. São funções distintas: um evento pode ter Connect Rate alto por email e telefone e ainda assim perder a atribuição da campanha se o _fbc não for enviado. Por isso o _fbc entra na conta do matching mas não substitui o clique. O detalhe de como capturar e persistir esse cookie está no artigo sobre _fbc e _fbp na atribuição do Meta Ads.

Hashing SHA-256: normalizar antes é metade do jogo

O Meta exige que email, telefone, nome e localização sejam enviados em hash SHA-256. O hash é uma via de mão única: o [email protected] vira uma string de 64 caracteres que o Meta compara com o hash que ele já tem do mesmo email nos perfis dele. Se os dois hashes baterem, há match. Se não baterem, não há, e o evento perde esse identificador.

Aqui mora o erro mais comum e mais silencioso do traqueamento. O SHA-256 é sensível a qualquer diferença no texto de entrada. [email protected] e [email protected] geram hashes completamente diferentes. Um espaço sobrando no fim do email muda o hash inteiro. Um telefone salvo como (11) 99999-9999 gera um hash que nunca vai bater com o que o Meta tem, porque o Meta espera o número no formato E.164 (+5511999999999).

Por isso o hashing correto tem duas etapas, e a primeira é a que quase todo mundo pula: normalizar antes de hashear.

  • Email: tirar espaços das pontas (trim) e passar tudo para minúsculo (lowercase) antes de hashear.
  • Telefone: remover parênteses, traços, espaços e o sinal de mais, e montar no padrão E.164 com código do país. No Brasil, 55 + DDD + número.
  • Nome: tirar espaços das pontas e passar para minúsculo. Sem acento removido à mão, o Meta cuida disso do lado dele, mas o trim e o lowercase são responsabilidade sua.

Obs.: quem monta o payload da CAPI na mão, num container GTM Server-Side ou num script próprio, precisa fazer essa normalização em cada campo antes de aplicar o SHA-256. É um passo fácil de esquecer justamente porque o evento continua chegando ao Meta e aparecendo no painel. Ele só chega mal identificado, e o Connect Rate cai sem que nada apareça quebrado. Se quiser o contexto completo de como a API de Conversões monta esse envio, veja o artigo sobre API de Conversões do Meta.

Antes e depois: o que corrigir a normalização faz com o EMQ

Um caso que vi de perto (conta anonimizada, um infoprodutor com público majoritariamente mobile): o Connect Rate estava travado numa faixa que ficava bem abaixo da média histórica da própria conta, mesmo com volume alto de compras entrando pela CAPI. À primeira vista tudo parecia certo. Os eventos chegavam, o valor de compra estava correto, a deduplicação com o Pixel funcionava.

O problema estava no payload. O telefone vinha do checkout com máscara brasileira, (11) 9XXXX-XXXX, e ia direto para o hash sem virar E.164. O email vinha com letras maiúsculas em parte dos casos, porque o comprador digitava do jeito que queria e o formulário não normalizava. Resultado: dois dos três identificadores mais fortes da hierarquia estavam gerando hashes que nunca batiam com os perfis do Meta. Na prática, aqueles eventos estavam sendo reconhecidos quase só pelo _fbc e pelo IP, que estão na base da hierarquia.

A correção foi normalizar antes de hashear: trim e lowercase no email, E.164 no telefone. Nada mudou no volume de eventos, na estrutura da campanha ou no criativo. Só o formato dos dados dentro do payload. O Connect Rate subiu de forma consistente em relação à média histórica da conta nas semanas seguintes, e o retargeting passou a alcançar um público maior porque o Meta agora reconhecia as pessoas por trás das compras.

Não vou cravar aqui de quanto para quanto o número subiu, porque cada conta parte de uma base diferente e o ganho depende de quantos eventos estavam mal formados. O ponto que importa é o mecanismo: dados mal normalizados derrubam os matchers mais fortes da hierarquia sem quebrar nada visível. É o tipo de perda que só aparece quando você compara o EMQ com o que a sua própria conta costumava marcar.

Como subir o Connect Rate na prática

Reunindo o que move a nota, a lista de ações fica curta e clara:

  • Envie todos os identificadores disponíveis em cada evento, priorizando os do topo da hierarquia: email, telefone e nome hasheados. Se o comprador forneceu, o Meta deve receber.
  • Normalize antes de hashear: lowercase e trim no email e no nome, E.164 no telefone. Este passo sozinho resolve a maioria dos casos de EMQ baixo com volume alto.
  • Capture e envie o _fbc e o _fbp em todo evento, para somar identificadores e preservar a atribuição do clique.
  • Complete com IP e User-Agent no envio server-side. São os matchers mais fracos, mas entram de graça pelo servidor e ajudam na margem.
  • Compare o número com a média histórica da sua conta, não com um limiar universal.

Sobre esse último ponto vale insistir. Não existe um valor de corte oficial que separe "bom" de "ruim" para toda conta. O EMQ útil de ler é o seu, ao longo do tempo. Uma queda em relação ao que você costuma ver é o sinal de que algo no matching mudou (um campo parou de ser enviado, um hash saiu malformado, o checkout mudou o formato do telefone), e vale investigar antes que a otimização de campanha sofra. Para achar o número, vá em Gerenciador de Eventos, selecione sua fonte de dados, aba Visão Geral, coluna "Qualidade da correspondência de eventos".

Onde tudo isso se encaixa no traqueamento como um todo está no guia completo de traqueamento de conversões, que cobre desde o Pixel até a atribuição no checkout.

FAQ

Connect Rate e Event Match Quality são a mesma coisa?

Sim. Connect Rate é o termo que usamos no ecossistema Castnexo para o que o Meta chama de Event Match Quality (EMQ). No Gerenciador de Eventos, a coluna aparece como "Qualidade da correspondência de eventos", com nota de 0 a 10. É a mesma métrica, sob nomes diferentes.

Qual match key mais aumenta o Connect Rate?

O email em hash é o matcher individual mais forte, seguido pelo telefone. Mas a lógica não é escolher um: o Meta usa o conjunto de identificadores que você mandar. O maior ganho na prática vem de enviar email e telefone bem normalizados juntos, em vez de depender de um só ou de matchers fracos como IP.

Preciso hashear os dados eu mesmo?

Depende de como você envia os eventos. Se você monta o payload da CAPI num container GTM Server-Side ou num script próprio, sim: precisa normalizar e aplicar o SHA-256 antes de enviar. Se você usa uma ferramenta que centraliza o PII do comprador, ela cuida do hash no formato que o Meta espera, e o risco de hash malformado sai das suas mãos.

Meu Connect Rate caiu de repente. O que verificar primeiro?

Comece pelo payload dos eventos. Uma queda súbita quase sempre é um campo que parou de ser enviado ou mudou de formato: telefone que voltou a sair com máscara, email que deixou de ser normalizado, ou o _fbc que parou de ser capturado. Compare com o período em que o número estava saudável e olhe o que mudou no envio, não na campanha.

O Connect Rate não é um número que você melhora com ajuste de campanha. É reflexo direto da qualidade dos dados que saem do seu site, e na minha experiência a maior parte dos casos de EMQ baixo se resolve arrumando a normalização de email e telefone antes do hash. É esse trabalho que o Tracker faz por baixo dos panos: centraliza o PII do comprador (email, telefone, nome), normaliza cada campo e aplica o SHA-256 no formato que o Meta espera, e envia todos os identificadores da hierarquia em cada evento, sem você montar hash na mão nem arriscar telefone fora do E.164. Veja a atribuição real, as sessões e os perfis no Tracker: comece os 30 dias grátis.

Veja seus dados de traqueamento em tempo real

Atribuição cross-session, perfis identificados, sessões com origem e destino. 30 dias grátis, sem cartão de crédito.