Resolución de identidad de clientes entre canales: reglas y arquitectura
Respuesta breve
La resolución de identidad conecta registros que probablemente representan a la misma persona entre tienda, ecommerce, app y otros canales. Debe distinguir coincidencia determinista, coincidencia probabilística y evidencia insuficiente. El objetivo no es maximizar fusiones, sino crear una vista útil sin mezclar personas, permisos o saldos.
Por qué aparece el problema
Una persona puede usar correos distintos, cambiar de teléfono, comprar como invitada o compartir un identificador doméstico. Los sistemas también pueden crear cuentas duplicadas por errores o latencia. Sin reglas, la organización fragmenta la relación; con reglas agresivas, fusiona clientes distintos.
Tres niveles de decisión
- Match determinista: identificador verificado y estable bajo reglas aprobadas.
- Match probabilístico: varias señales sugieren relación, pero requieren umbral y control.
- Sin resolver: evidencia insuficiente; se mantienen registros separados o en revisión.
Fuente, confianza y propósito
Registre qué señal originó el vínculo, nivel de confianza, fecha y uso permitido. Un match suficiente para análisis agregado puede no ser suficiente para transferir saldo o mostrar datos personales. La resolución debe ser proporcional al impacto.
Merge, link y reversión
No toda coincidencia requiere fusionar. Puede vincular registros bajo una identidad común conservando origen e historia. Si se fusionan, defina supervivencia de campos, conflictos, permisos, saldos y reversión. Google Cloud define entity resolution como matching de registros cuando no existe identificador común; la lógica concreta depende del proveedor y los datos preparados.
Privacidad y control del cliente
Explique mecanismos de verificación y corrección. No use atributos sensibles para matching sin autoridad y necesidad. Una persona debe poder actualizar datos o disputar una unión incorrecta. La identidad omnicanal no justifica acceso ilimitado entre sistemas.
Pruebas antes de producción
Use pares conocidos, duplicados reales y casos límite. Mida falsos positivos, falsos negativos, registros sin resolver y efecto sobre procesos críticos. Pruebe devoluciones, redención y baja. Un porcentaje alto de match no demuestra calidad si mezcla identidades.
Cómo encaja Lealto
Lealto puede integrarse con POS, ecommerce, CRM y otros sistemas, y operar perfiles, transacciones y beneficios según alcance. La fuente maestra, identificadores y reglas de resolución deben acordarse en discovery. No se promete una resolución universal automática.
Cómo gobernar el grafo de identidad
Versione reglas y registre quién aprobó cada cambio. Una nueva señal puede mejorar cobertura y al mismo tiempo elevar falsos positivos; pruebe ambos efectos. Limite el acceso al vínculo de identidad y separe el uso analítico de acciones que mueven valor o exponen información. Audite merges, unmerges y perfiles compartidos. Cuando la confianza sea insuficiente, solicite verificación en un momento relevante en lugar de completar el grafo con una suposición.
Preguntas frecuentes
¿Correo electrónico basta como ID?
No siempre; puede cambiar, compartirse o duplicarse.
¿Conviene fusionar todos los duplicados?
No. Primero se evalúa evidencia, impacto y reversibilidad.
¿Quién decide el match?
Reglas aprobadas con ownership de negocio, datos y tecnología.
Lecturas relacionadas
Conecte esta decisión con su operación
La mecánica correcta depende de audiencia, datos, sistemas, economía, mercado y capacidad operativa. Revise el alcance aplicable sin asumir integraciones o resultados no documentados.
>
Contáctenos
Construyamos su estrategia de lealtad