Customer Match e identity resolution: como ligar a conversão à pessoa certa com dados próprios

A pergunta que sustenta toda a mensuração é aparentemente banal: quem fez isso? Ligar um evento — uma visita, um carrinho, uma compra — à pessoa certa é o que permite atribuir, otimizar e remarketar. Durante anos, o cookie de terceiro respondeu a essa pergunta de graça, acompanhando a mesma pessoa entre sites. Com o fim do cookie de terceiro, a resposta passou a exigir trabalho: montar, com dados próprios, uma identidade estável que sobreviva ao navegador. Esse trabalho tem nome — identity resolution — e uma de suas aplicações mais diretas na mídia é o Customer Match.

Entender os dois é entender como a mensuração pós-cookie realmente funciona por dentro. Não é magia da plataforma; é o resultado de você fornecer sinais de identidade bem tratados para que a correspondência aconteça.

O problema de identidade sem cookie de terceiro#

O cookie de terceiro era um identificador compartilhado entre domínios: um mesmo valor reconhecível em vários sites, o que permitia costurar o comportamento de uma pessoa ao longo da jornada. Sem ele, cada domínio só enxerga o que acontece dentro de si, e os identificadores ficam fragmentados: um cookie de primeira parte aqui, um click ID ali, um e-mail no cadastro, um id de usuário logado no aplicativo, um dispositivo no meio.

O desafio da identity resolution é justamente unificar esses fragmentos numa identidade única e estável. Quando você consegue reconhecer que o click ID do anúncio, o e-mail do checkout e o id do cliente no CRM pertencem à mesma pessoa, você reconstrói a jornada que o cookie de terceiro costurava — só que com dados que são seus e sob consentimento.

O que é identity resolution#

Identity resolution é o processo de consolidar múltiplos identificadores de uma pessoa em um perfil único. Os identificadores entram fragmentados — e-mails, telefones, ids de dispositivo, click IDs, id interno de usuário — e saem ligados a uma única entidade, com uma chave estável que os representa.

ID interno imutável vs. e-mail como chave#

Um princípio de projeto importante: o e-mail não deve ser a chave primária da identidade. E-mails mudam, uma pessoa pode ter vários, e usar um deles como identificador central quebra quando ele é trocado. A identidade estável é um ID interno imutável — gerado por você, que nunca muda — ao qual se associam os vários e-mails, telefones e demais sinais. Assim, quando alguém troca de e-mail, você não perde o histórico: apenas adiciona mais um sinal ao mesmo perfil.

``json { "internal_id": "usr_01H9Z...", "emails": ["fulano@exemplo.com", "fulano.antigo@exemplo.com"], "phones": ["+5511999998888"], "click_ids": { "gclid": "...", "fbclid": "..." }, "device_ids": ["..."], "consent": { "ads": true, "analytics": true } } ``

Esse perfil resolvido é a base para enriquecer eventos: quando uma conversão chega com apenas um dos sinais, você a associa ao perfil completo e envia às plataformas os identificadores mais fortes disponíveis, elevando a correspondência.

Matching determinístico vs. probabilístico#

Há duas formas de decidir que dois identificadores são a mesma pessoa. O matching determinístico usa uma coincidência exata e confiável — o mesmo e-mail hasheado, o mesmo telefone, o mesmo id de login. É preciso e é o preferido. O matching probabilístico infere a ligação a partir de sinais indiretos (mesmo dispositivo, mesma rede, padrão de comportamento) e traz uma margem de erro. Para mensuração de conversão, priorize o determinístico: ele é o que dá correspondência de alta qualidade sem introduzir ruído.

Customer Match: a aplicação na mídia#

O Customer Match do Google é o recurso que leva seus dados de identidade próprios para dentro da plataforma de anúncios. Você fornece listas de clientes — e-mails, telefones, endereços — de forma hasheada, e o Google as corresponde aos usuários da sua base para permitir segmentação, exclusão e correspondência de conversão.

As outras plataformas têm análogos com nomes diferentes — listas de público baseadas em dados de clientes, os "Custom Audiences" por lista —, mas a mecânica é a mesma: você sobe uma lista hasheada, a plataforma corresponde internamente, e você ganha a capacidade de mirar (ou excluir) esses usuários e de creditar conversões a eles.

Requisitos de hashing e normalização#

O upload nunca leva dado em texto puro. Cada campo é normalizado e hasheado em SHA-256 antes de sair:

• E-mail — minúsculas, sem espaços em branco nas pontas.
• Telefone — formato E.164 (código de país, só dígitos, sem símbolos), depois SHA-256.
• Nome, sobrenome, CEP, país — normalização própria (minúsculas, sem espaços) quando usados como reforço de correspondência.

A normalização prévia é o detalhe que faz ou quebra o Customer Match: um telefone gravado de três jeitos diferentes gera três hashes diferentes e falha na correspondência. Um pipeline único e consistente de normalização é pré-requisito.

Como isso melhora a mensuração server-side#

Identity resolution e Customer Match não vivem separados do envio de eventos — eles o potencializam. Quando sua camada de conversão recebe um evento com apenas um click ID, ela pode consultar o perfil resolvido e enriquecer o user_data com e-mail e telefone hasheados antes de enviar à plataforma. O efeito é direto sobre o match rate e sobre o EMQ: mais sinais fortes e bem normalizados significam correspondência melhor, o que por sua vez melhora a otimização e a atribuição.

É também o que viabiliza a conversão offline com qualidade: um negócio que fecha no CRM carrega o ID interno do cliente, e a partir dele você recupera os identificadores hasheados que permitem correspondê-lo ao clique original na plataforma. Sem uma identidade resolvida, a conversão offline não tem por onde ser ligada à mídia.

Consentimento e base legal#

Usar dados próprios para segmentação e correspondência exige base legal e consentimento adequados. A lista de Customer Match é composta por dados pessoais dos seus clientes, e o consentimento para uso em publicidade precisa existir e ser respeitado — inclusive para remover uma pessoa da base quando ela retira o consentimento. O ID interno imutável ajuda também aqui: ele permite propagar a decisão de consentimento de forma consistente por todos os sinais associados àquela pessoa. Identidade resolvida sem governança de consentimento é passivo, não ativo.

Montando a identity graph na prática#

A estrutura que sustenta a identity resolution é um grafo de identidade (identity graph): uma representação de quais identificadores pertencem à mesma pessoa. Na prática, ele costuma viver numa tabela ou num conjunto de tabelas no seu back-end, com uma linha central por pessoa — o ID interno imutável — e associações para cada sinal conhecido.

O grafo cresce por eventos de reconhecimento. Quando alguém faz login, você liga a sessão ao ID interno. Quando informa um novo e-mail, você o associa ao mesmo ID. Quando chega uma conversão com um click ID, você tenta ligá-la a uma sessão conhecida e, por ela, ao ID interno. Cada um desses momentos é uma oportunidade de costurar mais um fragmento ao perfil. O princípio de projeto é acrescentar, nunca sobrescrever: um e-mail novo não substitui o antigo, ambos ficam associados, porque a pessoa pode voltar a usar qualquer um.

Uma regra de higiene importante é a precedência de sinais. Nem todos os identificadores têm a mesma confiança: um login autenticado é mais forte que uma coincidência de dispositivo. Ao resolver conflitos — quando dois sinais parecem apontar para pessoas diferentes —, o grafo deve favorecer o sinal determinístico mais forte e tratar o probabilístico com cautela, para não fundir por engano duas pessoas distintas nem partir uma pessoa em dois perfis.

Medindo o impacto na correspondência#

O valor da identity resolution não é abstrato: ele aparece em métricas. Antes de enriquecer os eventos com o perfil resolvido, você tem um determinado match rate e uma determinada nota de qualidade de correspondência. Depois de passar a incluir e-mail e telefone hasheados recuperados do grafo, essas métricas sobem — e o quanto sobem é a medida concreta do retorno do investimento em identidade.

Vale acompanhar a evolução ao longo do tempo e por fonte de tráfego, porque a cobertura do grafo varia: usuários logados têm identidade rica, visitantes anônimos têm identidade pobre. Saber onde a correspondência é fraca aponta onde vale a pena capturar mais sinais — um incentivo para login, uma captura de e-mail mais cedo no funil — para fortalecer a resolução justamente nos pontos que hoje escapam.

Erros comuns#

Alguns problemas recorrentes minam a identity resolution:

• Normalização inconsistente. O mesmo telefone ou e-mail tratado de formas diferentes em pontos diferentes do sistema, gerando hashes que não coincidem e destruindo a correspondência.
• E-mail como chave. Usar o e-mail como identificador central e perder o histórico quando ele muda, em vez de ancorar tudo em um ID interno imutável.
• Duplicidade de perfis. Falhar em unir fragmentos que pertencem à mesma pessoa, criando dois perfis parciais que competem e diluem o sinal.
• Matching probabilístico onde cabia determinístico. Aceitar inferências frágeis quando havia um identificador exato disponível, introduzindo ruído na base.
• Ignorar o consentimento. Subir listas ou enriquecer eventos sem respeitar a decisão do usuário, o que é risco legal e não torna a coleta legítima.

Síntese#

A pergunta "quem fez isso?" deixou de ter resposta gratuita com o fim do cookie de terceiro, e a identity resolution é o trabalho de reconstruí-la com dados próprios: unificar e-mails, telefones, click IDs e ids de dispositivo em um perfil único, ancorado num ID interno imutável — nunca no e-mail, que muda. O Customer Match é a ponte que leva essa identidade para dentro da mídia, por listas hasheadas em SHA-256 sobre dados normalizados, permitindo segmentar e creditar conversão à pessoa certa. Aplicada à mensuração server-side, a identidade resolvida enriquece cada evento com os sinais mais fortes disponíveis, elevando match rate e EMQ e viabilizando a conversão offline. Feito com normalização consistente e consentimento respeitado, esse é o alicerce da mensuração que não depende de cookie.