Um mapa não é uma decisão
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Módulo 4 de 6 do capítulo Dados mestres e identidade, capítulo 6 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Correspondência, fusão e sobrevivência · Próximo: Quando a autoridade é partilhada
A pergunta que este módulo responde: Um perfil unificado é a mesma coisa que um golden record?
O mesmo cliente está em três sistemas. O Salesforce conhece Daniel Reyes, d.reyes@example.com, Dallas. O e-commerce conhece Dan Reyes, o mesmo e-mail, Dallas, TX. O atendimento conhece Daniel Reyes, 214-555-0100, Dallas. O Data 360 decide que os três são a mesma pessoa e constrói um perfil unificado. Excelente. Temos um golden record? Não necessariamente. Sabemos que os registos pertencem uns aos outros; não decidimos que fonte é dona da verdade. Isto pode confundir as pessoas: a resolução de identidade cria um indivíduo unificado, mas não um golden record. Por isso ensino a diferença logo de frente:
Um perfil unificado é um mapa. Um golden record é uma decisão.
A resolução de identidade responde a «quem?»
Seção intitulada “A resolução de identidade responde a «quem?» ”Sem resolução de identidade, uma pessoa aparece como perfis desligados: o marketing vê um, as vendas outro, o atendimento outro. O Data 360 ingere-os e usa regras de resolução de identidade para decidir quais pertencem uns aos outros. Então podemos dizer estes registos parecem ser a mesma pessoa. Isso resolve a identidade. Não resolve a gestão de dados mestres.
E o perfil unificado mantém o mapa até às suas fontes. Na própria descrição da Salesforce, um perfil unificado não é um golden record: é um conjunto de chaves, com objetos de ligação de identidade a associar o ID de cada registo de origem ao ID do perfil unificado (Data 360 Architecture (opens in a new tab), em inglês). A pessoa unificada 10042 mapeia-se para o contacto Salesforce 003…, o cliente de e-commerce EC-48372 e o cliente de atendimento SUP-9128. Os originais não desaparecem. Isso é muito próximo do registry do módulo 2.
Um perfil unificado é um mapa de volta às identidades de origem.
Regras de correspondência: o rigor é uma decisão de risco
Seção intitulada “Regras de correspondência: o rigor é uma decisão de risco ”Como decide o Data 360 quem é unificado? Regras de correspondência (match rules). Os perfis correspondem quando todos os critérios de uma regra são cumpridos e, se tem várias regras, uma correspondência em qualquer uma cria o perfil unificado. A própria orientação da Salesforce: use mais critérios para precisão (mais perfis distintos), menos para consolidação (Identity Resolution Match Rules (opens in a new tab), em inglês). Por isso, acrescentar critérios a uma regra torna-a mais rigorosa; acrescentar regras alternativas alarga as formas de os perfis corresponderem. Configurar a resolução de identidade não é «ligar a correspondência». É definir que evidência basta para dizer que estes perfis são uma pessoa.
Fazer corresponder mais não é automaticamente melhor. Dez milhões de perfis de origem tornam-se oito milhões unificados. Afrouxe as regras, e agora são seis milhões. Melhor? Talvez tenha encontrado mais duplicados. Ou talvez tenha começado a combinar pessoas diferentes. Uma contagem menor não prova que os dados são melhores. O objetivo não é o menor número de perfis; são as identidades mais defensáveis para a finalidade. E cada critério tem um método de correspondência: Exact, Exact Normalized ou Fuzzy, com precisão alta, média ou baixa. O próprio aviso da Salesforce é o essencial: um método menos preciso aumenta a taxa de consolidação, «mas pode resultar em correspondências indesejadas». (Fuzzy não está disponível para campos de Conta, e os valores normalizados são usados apenas para comparar; não são armazenados no perfil unificado, que é a etapa de harmonização do módulo 3 em ação: Identity Resolution Match Methods (opens in a new tab), em inglês.) Quanto mais frouxo o método, mais a própria identidade se torna um juízo. Se estiver errada, só personalizamos mal uma página, ou mostramos o histórico de atendimento de uma pessoa a outra, ou deixamos um agente agir sobre os dados de duas pessoas?
Esta é a minha posição: o rigor da correspondência é uma decisão de risco. Depende de quão inequivocamente os campos de correspondência identificam uma pessoa e de quanto custa uma correspondência falsa. Onde misturar custa caro, faça correspondências a menos de propósito. Dois perfis para uma pessoa é inconveniente. Um perfil com duas pessoas pode ser perigoso.
A reconciliação continua a não ser gestão de dados mestres
Seção intitulada “A reconciliação continua a não ser gestão de dados mestres ”Depois de os perfis serem unificados, as fontes continuam a discordar: o Salesforce diz Dallas, o e-commerce Plano, o atendimento Dallas. O que mostra o perfil unificado? As regras de reconciliação decidem: Last Updated, Most Frequent ou Source Priority, definidas por objeto e substituíveis por campo (Identity Resolution Reconciliation Rules (opens in a new tab), em inglês). Isto deve lembrar a sobrevivência do módulo 3.
É aqui que as equipas se complicam. O perfil unificado mostra Dallas, e alguém diz: «Ótimo, Dallas é o nosso valor de ouro.» Calma. O e-commerce continua a dizer Plano. A Salesforce é explícita: a reconciliação não elimina nem altera os dados de origem nem atualiza os sistemas de origem, e não serve para escolher um valor «melhor» para todas as aplicações. Decide apenas o que o perfil unificado mostra (mesma fonte). Apresentação não é autoridade.
Conhecimento para o exame. Saiba como a resolução de identidade do Data 360 decide e apresenta: numa regra de correspondência, todos os critérios têm de corresponder, e basta qualquer uma das regras corresponder para unificar os perfis (mais critérios para precisão, menos para consolidação); as três regras de reconciliação são Last Updated, Most Frequent e Source Priority, definidas por objeto e substituíveis por campo; e a reconciliação não altera os dados de origem, e os pontos de contacto não são reconciliados.
Os pontos de contacto tornam isto ainda mais claro. Uma pessoa pode ter um e-mail pessoal e um de trabalho, um telemóvel e um telefone fixo, todos legítimos. O Data 360 não reconcilia pontos de contacto de todo: cada e-mail e cada telefone fica no perfil unificado (mesma fonte). Às vezes vários valores são simplesmente a verdade. «Unificado» não significa um valor para tudo.
Um golden record é uma decisão
Seção intitulada “Um golden record é uma decisão ”Compare com um requisito real de dados mestres. O negócio diz que o ERP tem autoridade sobre a denominação social, e o valor mestre é «Oakline Logistics LLC». O Salesforce, a faturação e o atendimento têm todos de o usar e, se um discorda, o processo de dados mestres devolve o valor governado. É outra arquitetura. Não estamos a escolher o que uma visão apresenta; estamos a decidir este é o valor que a empresa usa, e cada sistema participante converge para ele.
Então: um perfil unificado junta identidades e informação. Um golden record é uma decisão governada sobre que valores têm autoridade. Um perfil unificado pode ser uma excelente visão única do cliente, montada a partir de fontes com autoridade. Isso não faz dele o sistema que gere o cliente como dado mestre.
Um perfil unificado é um mapa. Um golden record é uma decisão.
Rastreabilidade
Seção intitulada “Rastreabilidade ”Se o perfil unificado diz Dallas, de onde veio isso: do Salesforce, do ERP, do e-commerce? Foi escolhido como o último atualizado, o mais frequente, por prioridade da fonte? Essa proveniência importa para auditoria, privacidade, diagnóstico de problemas, correção da qualidade dos dados e decisões de agentes e, acima de tudo, para saber onde pertence uma correção. Se Dallas está errado, editar a visão montada não corrige a fonte. Precisa dos IDs externos, das ligações de identidade e dos campos de linhagem para rastrear até ao registo que deve mudar.
Três ferramentas para três trabalhos
Seção intitulada “Três ferramentas para três trabalhos ”É assim que as separo:
- Gestão de duplicados e fusão, dentro de uma org Salesforce, quando há um vencedor claro e já não precisa dos duplicados (módulo 3).
- Resolução de identidade do Data 360, para uma identidade e uma visão única entre fontes sem as alterar: um registry.
- Uma plataforma de MDM dedicada, quando os valores têm de ser decididos uma vez e devolvidos a cada sistema participante: coexistência ou centralizado.
Três ferramentas para três trabalhos: fundir, associar, gerir como dados mestres.
Não compre MDM quando precisa de um mapa. «Queremos que o agente de atendimento veja que este cliente do Salesforce é a mesma pessoa que comprou online» pode precisar de resolução de identidade e contexto combinado, não de MDM centralizado. «O ERP, o Salesforce, o e-commerce e a faturação têm todos de usar a mesma denominação social governada, e as mudanças têm de voltar para todos eles» é diferente: isso é gestão de dados mestres. Não resolva o segundo quando tem o primeiro, e não finja que o primeiro resolveu o segundo.
Uma identidade não é uma permissão
Seção intitulada “Uma identidade não é uma permissão ”A resolução de identidade diz que estes registos são uma pessoa. Isso não significa que todos os que conseguem ver um registo de origem possam ver tudo o que está ligado à identidade unificada. Um Parceiro retalhista pode ver as entregas que enviou; as entregas de outro parceiro para o mesmo Destinatário não lhe dizem respeito, mesmo que a camada de identidade saiba que estão relacionadas. O grafo de identidade pode estar certo enquanto o design de acesso está errado. Unificar a identidade não apaga as fronteiras de segurança. É por isso que fazer corresponder demais se torna um problema de privacidade, e porque é que o checkpoint da Steve Trucking trata com tanto cuidado a unificação dos Destinatários: um mapa de quem é quem não concede propriedade, nem acesso.
Além do exame: o que a IA muda. Os agentes precisam de uma identidade sobre a qual agir, e o perfil unificado dá-lha. Isso aumenta o que está em jogo nos dois sentidos. Fazer corresponder demais é agora um incidente de privacidade: um agente a agir para uma pessoa com os dados de outra. E um agente que «atualiza o cliente» tem de gravar no sistema de registo do atributo, usando o mapa de autoridade do módulo 1, não no perfil unificado. O mapa diz ao agente quem é a pessoa; o modelo de autoridade diz onde pertence uma mudança.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Que evidência basta para unificar perfis, e como o custo de uma correspondência falsa define o rigor.
- Que regras de reconciliação decidem o que mostra o perfil unificado.
- Se a necessidade é limpar duplicados numa org, identidade entre fontes, ou uma verdadeira gestão de dados mestres empresariais.
- Que fonte continua a ter autoridade sobre cada atributo, mesmo quando o Data 360 mostra um valor reconciliado.
- Como a identidade unificada interage com segurança, privacidade, proveniência e ações de agentes.
O Data 360 consegue dizer-nos que estes perfis pertencem uns aos outros, dar-nos uma identidade unificada, reconciliar o que mostra e manter as ligações a cada fonte. Isso tem um valor enorme. Mas, se o Salesforce diz uma coisa e o ERP outra, alguém continua a ter de decidir que sistema pode alterar a verdade da empresa. Por isso, quando alguém disser «temos um perfil unificado, logo temos o nosso golden record», pergunte: unificámos os dados, ou gerimos os dados mestres?
Para saber mais
Seção intitulada “Para saber mais ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (em inglês), consultado em 2026-10-14.
- Salesforce Help, Data 360: Identity Resolution Match Rules (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) e Identity Resolution Reconciliation Rules (opens in a new tab) (em inglês), consultados em 2026-10-14.
