Customer MDM en retail B2C: vista única 360º

La promesa del retail omnicanal desde hace quince años es "conocer al cliente sea cual sea el canal". La realidad en la mayoría de retailers españoles medianos es que el cliente sigue siendo tres identidades distintas: el que compra en tienda con tarjeta de fidelización, el que compra online con email distinto y el que llama a atención al cliente desde un tercer número. Este post es sobre cómo se resuelve esto, con qué herramientas y qué inversión.

Por qué el cliente tiene múltiples identidades

La fragmentación de la identidad del cliente en retail es consecuencia de la arquitectura histórica: cada sistema se implantó en una década distinta con su propia clave primaria.

• POS en tienda: identifica cliente por número de tarjeta de fidelización, si la muestra; si no, la venta es anónima.
• E-commerce: identifica por email de cuenta y datos de envío.
• CRM: gestiona clientes B2B y grandes cuentas con sus propios IDs.
• Programa de fidelización: registros alimentados en tienda con datos mínimos (DNI opcional, email opcional).
• Atención al cliente: tickets por email o teléfono, sin integración automática con el resto.
• App móvil: cuenta con email propio que puede no coincidir con el e-commerce.

Cada sistema es internamente consistente. El problema surge al cruzarlos: el mismo cliente puede aparecer 3-5 veces en el conjunto consolidado si no hay una capa de identidad.

La capa clave: identity resolution

Identity resolution es el proceso de determinar qué registros de distintos sistemas corresponden al mismo individuo real. Combina tres tipos de señales:

La regla práctica: resolver con deterministas el 60-80% del volumen, aplicar probabilistas al resto con umbrales conservadores y revisar manualmente los casos dudosos. Ir directamente a matching probabilista o ML sin haber agotado los deterministas introduce errores innecesarios.

Arquitectura en tres capas

1. 1Ingesta: conectores (Fivetran, Airbyte) que traen datos de POS, e-commerce, fidelización, CRM y soporte a un data warehouse (Snowflake, BigQuery, Databricks).
2. 2Resolución: modelos dbt que unifican clientes aplicando las reglas de matching. Output: tabla dim_customer con un golden_id único y los source_ids originales.
3. 3Consumo: BI (Looker, Power BI, Tableau) sobre la vista consolidada, CDP (Segment, Tealium) para activación de campañas, servicios API que reexportan identidad al CRM y POS.

Qué herramienta encaja según tamaño

Gobierno continuo: el proyecto no termina

Un MDM funcional no se implanta y se olvida. Cada semana entran altas nuevas que pueden romper la identidad: clientes que cambian email, direcciones que se normalizan distinto, fusiones de cuentas. El proyecto debe incluir:

• Data stewards con dedicación parcial (10-20% de una persona senior) que revisan la cola de matches probabilistas con baja confianza.
• Dashboard de salud del MDM: ratio de duplicados detectados por semana, falsos positivos, cobertura por canal.
• Procedimiento de merges y unmerges: qué pasa cuando se detecta que dos golden_ids eran el mismo cliente, o al revés.
• SLA de propagación: cuánto tarda un cambio de identidad en llegar al CRM, al e-commerce y al POS.

Qué desbloquea la vista única

El MDM por sí solo no genera retorno directo. Lo que genera retorno son los casos de uso que depende de él:

• Personalización de marketing con mayor precisión: el cliente que compró en tienda recibe email relevante de e-commerce.
• Experiencia en tienda mejorada: el cajero ve histórico completo del cliente cuando muestra su tarjeta de fidelización.
• Retención y detección de churn: el modelo usa señales de todos los canales, no solo uno.
• Medición real de LTV: el cliente omnicanal deja de aparecer como tres clientes distintos con LTVs parciales.
• Cumplimiento RGPD más simple: derecho de acceso y supresión se resuelven en una única fuente, no en cinco sistemas desincronizados.

Preguntas frecuentes

¿Podemos construir esto con lo que ya tenemos de Snowflake?

Sí, en la mayoría de casos medianos. Si ya tienes Snowflake o BigQuery como warehouse y dbt para transformaciones, añadir una capa de identity resolution con Splink es viable. No reemplaza a un producto enterprise para operativa compleja, pero resuelve el 70-85% del valor en una primera versión.

¿Qué pasa con RGPD al unificar fuentes?

La consolidación es compatible con RGPD siempre que la base legal del tratamiento original cubra el uso secundario (interés legítimo para conocer al cliente omnicanal, por ejemplo). La ventaja clave es que los derechos de acceso y supresión se ejercen sobre el golden_id — elimina o exporta todos los datos del cliente de una sola vez en lugar de tener que buscarlo en cinco sistemas.