A plataforma não vai dizer o que deu errado
A documentação da API do Google enuncia a falha sem rodeios: dados formatados incorretamente ainda são aceitos – "but it can't be matched with a customer." Aceito e sem correspondência é exatamente igual a enviado e ignorado. Ou seja, o diagnóstico é com você, e as causas abaixo estão ordenadas pelo quão barato é verificá-las.
1. Você reaproveitou uma coluna com hash entre plataformas (30 segundos)
O Google Ads documenta telefones em E.164 com o +; a Meta documenta apenas dígitos com código do país – o exemplo dela é 16505551212. O mesmo número, com hash pelos dois caminhos, gera dois digests sem relação, e cada plataforma só consegue corresponder um deles. Se uma plataforma corresponde bem e a outra quase nada, é quase certamente isto.
2. Você aplicou hash no valor exibido (1 minuto)
(650) 555-1212 não é 16505551212, e John@Example.com – com maiúsculas e espaço no fim – não é john@example.com. Ambas as plataformas documentam minúsculas e sem espaços; confira o conteúdo real de uma célula contra o que você acha que passou pelo hash. Atenção ao espaço não separável: TRIM() não o remove, e exportações CSV o plantam de forma invisível.
3. Hash duplo ou truncamento (1 minuto)
Um digest SHA-256 em hexadecimal tem exatamente 64 caracteres. =LEN(B2)=64 arrastado pela coluna pega, de uma só vez, uma fórmula executada sobre valores que já tinham hash (128 caracteres sem sentido na entrada, digest de um digest na saída) e células truncadas.
4. Codificação errada (5 minutos)
Saída em Base64, ou hexadecimal em maiúsculas onde se especificam minúsculas – a Meta documenta hex minúsculo explicitamente. O teste limpo: aplique hash no valor de teste publicado pela Meta, john_smith@gmail.com, e compare com o digest publicado (62a14e44…f62f). Formato ou caixa errados nesse teste significam que o problema é a ferramenta, não a lista.
5. A planilha destruiu os dados antes (10 minutos)
Zeros à esquerda perdidos, números longos em notação científica, células +44 interpretadas como fórmula – tudo silencioso, tudo antes do hash. Percorra a coluna bruta procurando E+ e números suspeitosamente curtos. Este caso não tem conserto no lugar: reimporte para uma coluna de texto simples e reconstrua.
6. Regras específicas da plataforma ignoradas (10 minutos)
O Google documenta uma limpeza de e-mail específica do Gmail – pontos e sufixos com + removidos apenas em endereços gmail.com/googlemail.com. Uma lista com muitos endereços Gmail, normalizada de forma genérica, tem desempenho ruim exatamente nessas linhas.
7. Nunca foi um problema de formatação
A última seção, honesta: a correspondência acontece contra usuários conectados à plataforma. Uma lista antiga, uma lista pequena ou uma lista de endereços institucionais (info@, financeiro@) corresponde mal por mais perfeito que seja o hashing. Se os passos 1 a 6 passaram todos, o conserto é a qualidade da lista – atualidade e endereços pessoais reais – e não mais uma rodada de formatação.
Onde o Hash Data se encaixa
A maioria das falhas acima acontece na lacuna entre "normalizar corretamente" e "aplicar hash corretamente". O Hash Data fecha essa lacuna dentro da planilha: o =HASHPHONE() normaliza um número para E.164 e aplica o hash em uma única etapa, e as funções de algoritmo produzem o formato hexadecimal padrão que as plataformas esperam.
Fontes
- Google Ads API – Get started with Customer Match – lido em 20/08/2026
- Ajuda do Google Ads – Formatar o arquivo de dados do cliente – lido em 20/08/2026
- Meta – Conversions API customer information parameters – lido em 20/08/2026