O exemplo de referência
A maior parte das documentações ensina com dois registros que diferem de um jeito óbvio. Dados reais não são assim, e isto também não é.
Todo exemplo trabalhado nesta documentação é um recorte do conjunto abaixo. As pessoas são inventadas — nenhuma documentação deve carregar dados pessoais reais — mas nada mais é. Os nomes de atributo são os que o modelo de pessoa distribuído realmente define, os formatos de valor são os que a plataforma realmente armazena, e as divergências são as que ela foi construída para reconciliar.
Uma pessoa, seis sistemas
Um banco de varejo mantém o mesmo cliente em seis lugares. Nenhum registro concorda com outro.
| Sistema | Nome | Meio | Sobrenome |
|---|---|---|---|
| CRM | Jon | — | Pemberton |
| ERP | Jonathan | — | Pemberton-Hayes |
| KYC | Jonathan | Stuart | Pemberton-Hayes |
| Aplicativo | Johnny | — | PEMBERTON |
| Originação de crédito | Jonathan | — | Pemberton Hayes |
| Bureau de crédito | J | — | Pemberton-Hayes |
Seis grafias de um nome, e cada uma está correta no seu próprio sistema. O CRM guarda como ele se chama. O KYC guarda o que diz o passaporte. O aplicativo capturou um apelido. O bureau abrevia. A originação de crédito perdeu o hífen para um formulário que não o aceitava.
Só um campo concorda em todos:
date_of_birth 1979-08-22 (nos seis)
Onde a evidência realmente está
O nome é o campo mais ruidoso. A evidência está em outro lugar, e é desigual.
| CRM | ERP | KYC | Aplicativo | Crédito | Bureau | |
|---|---|---|---|---|---|---|
date_of_birth | ● | ● | ● | ● | ● | ● |
email | ● | ● | ● | ● | ● | — |
phone | ● | ● ● | — | ● | — | ● |
address | ● | ● | ● | — | ● | — |
middle_name | — | — | ● | — | — | — |
Duas coisas saltam dessa grade imediatamente.
Um telefone liga três sistemas. +15553001001 aparece no CRM como mobile,
no ERP como mobile e no registro do bureau como home. O tipo de uso diverge;
o número não. O ERP carrega um segundo número, +15553009002, do tipo work.
Ninguém tem um identificador governamental. Não há ssn em nenhum dos seis.
Isso importa mais do que parece: remove o único atalho que resolveria tudo na
hora, e força o par a ser decidido por evidência acumulada. A maioria dos
agrupamentos reais é assim.
O endereço que parece conflito e não é
Três sistemas têm endereço, e dois deles escrevem a mesma rua de formas diferentes:
| Sistema | address.line1 | address.postalCode | Tipo de uso |
|---|---|---|---|
| CRM | 12 Old Mill Road | 06103 | home |
| ERP | 12 Old Mill Rd | 06103 | home |
| KYC | 12 Old Mill Road | 06103 | home |
| Originação de crédito | 440 Asylum Avenue | 06105 | mailing |
Road e Rd são a mesma rua. A
padronização resolve isso antes de qualquer
comparação — e note a direção, porque é o oposto do que se espera: a plataforma
expande abreviações em vez de contraí-las, então ambos chegam a
old mill road e convergem.
O registro de crédito é um endereço genuinamente diferente, com outro CEP, e é do
tipo mailing em vez de home. Isso não é conflito a resolver — é um segundo
endereço verdadeiro, que a
sobrevivência mantém ao lado do primeiro.
Sem ele, 12 Old Mill Road e 440 Asylum Avenue parecem dois sistemas
discordando sobre onde ele mora. Com ele, são um endereço residencial e um
endereço de correspondência, e ambos sobrevivem.
O que levar disto
Siga este conjunto pelos guias e cada etapa tem algo real a fazer:
| Etapa | O que este agrupamento a obriga a tratar |
|---|---|
| Padronizar | a caixa de PEMBERTON, Rd versus Road |
| Comparar | seis grafias, nenhum identificador comum |
| Revisar | pares que caem entre os limiares |
| Sobrevivência | qual nome vence, e os dois endereços sobrevivendo |
| A visão 360 | um registro, com as seis entradas ainda visíveis |
Registros de origem e crosswalks
Os seis acima são registros separados porque nada os comparou ainda. Uma vez que registros estão ligados a uma entidade, o vínculo é um crosswalk — a entidade mais o identificador que cada sistema tem para ela.
Outro conjunto do mesmo pacote mostra o formato, para um cliente já resolvido em três sistemas:
Sistema Tipo de registro Identificador no sistema Confiança Primário
ERP CUSTOMER ERP-CUST-100001 100 sim
CRM CONTACT CRM-CON-A8K42P 95 não
MARKETING LEAD MK-LEAD-7842 80 não
Leia a coluna do meio. O mesmo ser humano é um cliente no ERP, um contato no CRM e um lead no marketing — três sistemas que nem sequer concordam sobre que tipo de coisa ele é. O crosswalk registra isso sem forçar nenhum deles a mudar.
A seguir
- Entidades, crosswalks e registros dourados
- Crie seu primeiro registro dourado
- Comparação e consolidação
Última verificação no commit fd13e3c0 (2026-08-03)