Identidade única de cliente (Golden Record)

Por que "um cliente, uma visão" é mais difícil do que parece

Toda empresa com mais de um sistema toca o mesmo cliente em pontos diferentes — venda pelo site, atendimento por chat, e-mail de campanha, cadastro em loja física, pesquisa de satisfação por SMS. Cada sistema costuma ter seu próprio identificador, gerar seus próprios cadastros e armazenar seus próprios dados. Quando o mesmo cliente preenche um formulário no site com "[email protected]" e depois compra na loja com "[email protected]", o sistema enxerga duas pessoas — e a empresa, três (com o cadastro do call center).

O resultado prático é familiar: o mesmo cliente recebe a mesma campanha duas vezes, com nomes ligeiramente diferentes; o time de atendimento não sabe que ele é cliente desde 2018; a diretoria pergunta "qual o valor desse cliente no tempo?" e ninguém consegue responder porque a informação está fragmentada. Construir identidade única é o trabalho contínuo de reconciliar esses fragmentos em um registro coerente.

Resolução de identidade: determinística e probabilística

Resolução de identidade (em inglês, identity resolution) é o processo de decidir, dada uma observação nova ("alguém preencheu este formulário"), se ela pertence a um cliente já existente ou se é um cliente novo. Duas abordagens convivem.

Determinística: usa chaves únicas e estáveis — e-mail, CPF, número de telefone, identificador interno. Se o e-mail bate exatamente entre dois registros, são a mesma pessoa. É robusta e auditável, mas falha quando o cliente usa e-mails diferentes em momentos diferentes, ou quando o e-mail está digitado com erro de espaçamento, maiúscula ou domínio. Normalização (tudo minúsculo, sem espaços, validação de domínio) ajuda muito.

Probabilística: combina múltiplos sinais que isoladamente não são chaves — nome, endereço aproximado, dispositivo, comportamento, IP — e calcula probabilidade de serem a mesma pessoa. Útil quando não há chave única disponível (ex.: navegação anônima antes do cadastro), mas exige cuidado: é mais propensa a falsos positivos (juntar duas pessoas diferentes) e a problemas de LGPD, porque cruza dados sem consentimento explícito de cada combinação.

Operações maduras combinam as duas: começam por matching determinístico (resolve 70-90% dos casos com alta confiança) e usam probabilística como complemento controlado, com auditoria humana periódica nos casos de baixa confiança.

CDP e MDM: para que serve cada um

Duas categorias de ferramenta lidam com identidade única, com focos diferentes.

Plataforma de dados do cliente (CDP — Customer Data Platform): é orientada para marketing e operação. Ingere dados de várias fontes (CRM, site, automação, e-commerce, mobile), resolve identidade, monta o perfil consolidado e publica esse perfil para sistemas de ativação — automação de marketing, plataformas de mídia, ferramentas de personalização. Casos de uso: segmentação cross-canal, personalização entre canais, supressão coerente, controle de frequência. Players: Segment (Twilio), Treasure Data, Tealium, mParticle, Adobe Real-Time CDP, Salesforce Data Cloud.

Gestão de dados mestres (MDM — Master Data Management): é orientada para dado canônico em toda a empresa. Define qual é o registro oficial de um cliente (ou produto, ou fornecedor) e propaga essa verdade para todos os sistemas que precisam dele — financeiro, faturamento, logística, marketing. É mais voltada a integridade do dado e processos transacionais que ao marketing direto. Players: Informatica MDM, Reltio, SAP Master Data Governance, Stibo Systems.

Empresas grandes podem operar os dois lado a lado: MDM mantém o registro canônico de cliente como entidade da empresa; CDP usa esse registro canônico (mais sinais de comportamento e marketing) para ativar campanhas. Em empresas médias, costuma haver apenas um, geralmente o CDP. Em pequenas, nenhum dos dois — o CRM acumula essa função.

Processo de criação do registro mestre

Construir o registro mestre (golden record) tem quatro fases.

1. Ingestão. Conectar fontes de dados (CRM, e-commerce, automação, atendimento, app, lojas físicas) e trazer os registros para o ambiente onde a resolução acontecerá. Cada fonte traz seu próprio esquema; normalização (padronizar nomes de campo, formatos, codificações) é etapa explícita.

2. Resolução (matching). Aplicar regras determinísticas primeiro (e-mail, CPF, telefone normalizados), depois probabilísticas se necessário. O resultado é um conjunto de "grupos" — cada grupo contém todos os registros que se referem à mesma pessoa.

3. Mesclagem (merge) e definição do registro mestre. Para cada grupo, decidir qual será o registro consolidado. Aqui entram as regras de "vencedor": quando dois sistemas têm dados conflitantes para o mesmo cliente (ex.: dois endereços diferentes), qual prevalece? Critérios comuns: fonte mais recente, fonte mais confiável (call center > formulário de download de conteúdo), regra explícita por campo (endereço vem do e-commerce, telefone vem do CRM).

4. Publicação. O registro mestre é distribuído para os sistemas que vão usá-lo (automação de marketing, plataforma de personalização, dashboards, plataformas de mídia). A publicação pode ser em lote (atualização diária) ou em tempo real (eventos disparam atualização imediata).

Esse ciclo é contínuo: novas observações chegam, identidade é re-resolvida, registro é atualizado, publicação é refeita.

Governança contínua: por que a identidade nunca está "pronta"

Implantar CDP ou MDM resolve o problema técnico, não o problema organizacional. Sem governança, a qualidade do registro mestre degrada em semanas: novos sistemas são integrados sem revisão de chaves, campanhas criam cadastros descontrolados, equipes operacionais usam atalhos para criar registros sem checar duplicatas.

Governança operacional inclui:

Data steward. Papel formal — pode ser dedicação integral ou parcial conforme o porte — com responsabilidade explícita por qualidade da base, regras de matching, regras de vencedor e auditoria. Sem dono, o tema vira "responsabilidade de todos, prioridade de ninguém".

Comitê de dados de cliente. Reunião regular (mensal ou trimestral) com marketing, vendas, atendimento, dados e tecnologia. Pauta padrão: indicadores de qualidade (taxa de duplicatas, taxa de campos incompletos), incidentes do período, mudanças propostas em regras.

Auditoria. Amostragem regular de registros para validar qualidade — manual no início, automatizada conforme amadurece. Indicadores típicos: percentual de clientes únicos, percentual de duplicatas confirmadas, percentual de registros com campo crítico vazio.

Treinamento. Quem cria cadastros (vendas, atendimento, operadores de loja) precisa entender por que normalização e validação importam — caso contrário, "adicionar cliente rápido" gera o trabalho de limpeza que outros vão fazer depois.

LGPD: o que identidade única exige

Resolução de identidade implica tratamento de dados pessoais. Sob a Lei 13.709/18 (LGPD), isso exige base legal (consentimento, execução de contrato, legítimo interesse, entre outras hipóteses) e finalidade específica documentada. Três pontos críticos:

Base legal por finalidade. Unificar cadastro para faturamento (execução de contrato) é diferente de unificar para fazer marketing personalizado (que costuma exigir consentimento ou avaliação de legítimo interesse). A mesma operação pode ter bases diferentes para finalidades diferentes — e o sistema precisa registrar isso.

Direitos do titular. O cliente pode pedir acesso, correção ou exclusão. Identidade única ajuda (porque conseguimos achar tudo) e complica (porque a exclusão precisa propagar para todos os sistemas). Operações maduras automatizam o atendimento de solicitações com base no registro mestre.

Probabilística e legítimo interesse. Matching probabilístico cruza sinais sem consentimento explícito de cada combinação. A base legal típica é legítimo interesse, que exige documentar a avaliação (necessidade, expectativa do titular, salvaguardas). Sem essa documentação, a operação fica exposta. O encarregado pelo tratamento de dados pessoais (DPO) precisa estar envolvido no desenho.

Casos de uso que justificam o investimento

Identidade única não é fim em si — é meio para casos de uso de negócio. Os mais comuns:

Personalização entre canais. O cliente abandona o carrinho no app, recebe e-mail relevante, depois banner consistente na web. Sem identidade resolvida, cada canal trata o cliente como anônimo ou trata os três fragmentos como pessoas diferentes.

Supressão coerente. Cliente que comprou ontem não deve receber hoje o e-mail "ainda interessado em [produto X]?". Cliente que cancelou comunicação por SMS não deve receber por WhatsApp. Supressão depende de saber que é o mesmo cliente em diferentes canais.

Controle de frequência consolidado. Em vez de cada canal aplicar seu próprio limite, a empresa define "no máximo X contatos por semana, somando todos os canais". Sem identidade única, fica impossível medir o total real.

Atribuição entre canais. Quem realmente influenciou a compra: o anúncio que viu no Instagram, o e-mail que abriu na quarta ou a busca no Google de sexta? Modelos de atribuição multi-toque exigem rastreamento do mesmo cliente em diferentes pontos — só funcionam com identidade resolvida.

Visão consolidada para atendimento. Atendente atende o cliente sabendo todo o histórico — compras, chamados anteriores, campanhas em curso. Diferença de qualidade percebida é alta; também reduz tempo de atendimento.

Erros comuns em projetos de identidade única

Assumir que CDP é mágico. CDP resolve identidade com base no que recebe. Se as fontes a montante estão sujas (e-mails sem normalização, CPF com erros de digitação, duplicatas crônicas no CRM), o CDP vai resolver com sujeira. Limpeza das fontes é trabalho que precisa acontecer em paralelo.

Ignorar a sujeira a montante. Casos típicos: vendedor cria cliente novo porque não achou o existente; site permite cadastrar com e-mail já existente; loja física registra apenas com CPF parcial. Resolver isso exige mudar processo e ferramenta na entrada — não basta resolver depois.

Registro mestre sem governança. Implanta CDP, sai operando, dois anos depois a qualidade da base é pior que antes porque ninguém mantém as regras de matching nem as regras de vencedor. Sem data steward formal, a degradação é certa.

Confundir CDP com CRM. CDP é camada de dados, não de relacionamento. Não substitui CRM — alimenta-o. Compras de CDP feitas com expectativa de "substituir CRM" terminam frustradas.

Subestimar LGPD. Equipe técnica monta a operação tecnicamente correta, jurídico descobre meses depois que a base legal não foi avaliada, encarregado pede ajustes, projeto trava. Envolver jurídico desde o desenho evita retrabalho.