Retail media y personalización: la infraestructura detrás del dato
La promesa y la infraestructura
Retail media es el segmento publicitario de mayor crecimiento en Europa. IAB Spain estima que el gasto en retail media en España superó los 400 millones de euros en 2024, y las proyecciones para 2025 apuntan a un crecimiento del 25-30%. La promesa es irresistible: monetizar tus datos de primera mano mientras ofreces personalización relevante al cliente. Amazon lo hace. Mercadona está construyendo capacidades. Carrefour Links ya opera en Francia y se expande.
Pero detrás de la promesa hay un problema de infraestructura de datos que la mayoría de los retailers medianos subestiman. Personalizar en tiempo real requiere unificar datos de comportamiento, transacciones, inventario y preferencias en un sistema que responda en milisegundos, no en horas. Y hacerlo cumpliendo el RGPD en un entorno donde cada dato de cliente es un riesgo regulatorio.
La arquitectura CDP
El Customer Data Platform (CDP) es la pieza central. No es un CRM con esteroides (aunque muchos vendors lo vendan así). Es una infraestructura de datos que:
- Ingesta datos de múltiples fuentes: Punto de venta, ecommerce, app móvil, programa de fidelización, interacciones en tienda física (WiFi, beacons), campañas de email.
- Unifica perfiles: Resolución de identidad. El mismo cliente que compra online con un email, en tienda con su tarjeta de fidelización, y navega la app con un device ID debe resolverse como un único perfil.
- Segmenta en tiempo real: No segmentos estáticos recalculados cada noche, sino audiencias que se actualizan con cada interacción.
- Activa en canales: Envía el segmento o la decisión al canal correcto (email, push, display, retail media) con la latencia adecuada.
Resolución de identidad
Este es el problema técnico más difícil y el que determina si el CDP funciona o es un data lake más. La resolución de identidad conecta identificadores dispares (email, phone, cookie ID, device ID, tarjeta de fidelización, ID de transacción POS) en un perfil unificado.
Hay dos enfoques:
Determinístico: Conecta identificadores cuando hay un match exacto (mismo email, mismo teléfono). Alta precisión, bajo recall. Funciona bien para clientes registrados.
Probabilístico: Usa señales indirectas (mismo dispositivo, misma IP, patrones de comportamiento similares) para inferir que dos identificadores pertenecen al mismo usuario. Mayor recall, menor precisión. Útil para visitantes anónimos.
En la práctica, un CDP de retail necesita ambos. El matching determinístico para la base de clientes conocidos (típicamente el 30-40% del tráfico), y el probabilístico para el resto. La clave es que el modelo probabilístico tenga un umbral de confianza configurable: demasiado agresivo y mezclas perfiles; demasiado conservador y pierdes cobertura.
Herramientas como Segment (Twilio), mParticle, o soluciones open-source como RudderStack implementan resolución de identidad out-of-the-box. Para retailers con requisitos específicos (datos de POS offline, integración con sistemas legacy), un desarrollo custom sobre Apache Spark o Flink es más común de lo que los vendors admiten.
Decisiones en tiempo real
La personalización que importa ocurre en milisegundos: qué producto recomendar cuando el cliente abre la app, qué banner mostrar cuando navega la web, qué oferta enviar cuando abandona el carrito. Esto requiere un motor de decisiones en tiempo real que combine:
- Perfil del cliente (historial de compras, preferencias, segmento).
- Contexto actual (dispositivo, hora, ubicación, página que visita).
- Inventario disponible (no recomendar un producto agotado en la tienda más cercana).
- Reglas de negocio (márgenes, stock que se quiere rotar, acuerdos con proveedores).
La arquitectura típica:
Evento (click, pageview, compra)
→ Stream processing (Kafka + Flink/ksqlDB)
→ Feature store (perfil actualizado)
→ Decision engine (modelo ML + reglas)
→ Respuesta (< 100ms)El feature store es un componente que merece atención. Es la capa que mantiene las features del cliente (media de gasto, frecuencia de compra, categorías preferidas, recencia) actualizadas en tiempo real y disponibles para el motor de decisiones con latencia de lectura baja. Feast o Tecton son opciones open-source y SaaS respectivamente. Redis como backend de servicio es común para latencias sub-10ms.
Por qué no se puede resolver esto con una base de datos relacional y queries? Porque la personalización a escala retail implica miles de decisiones por segundo, cada una combinando datos de múltiples fuentes. Una query SQL que haga un join de 5 tablas para calcular la recomendación de un usuario no escala a 10.000 requests por segundo. El feature store precalcula y mantiene las features listas para lectura.
Privacidad bajo RGPD
Aquí es donde el retail media en Europa se complica. El RGPD establece restricciones claras sobre el tratamiento de datos personales, y un CDP que unifica perfiles de cliente es, por definición, un sistema de tratamiento de datos personales a gran escala.
Los puntos críticos:
Base legal: Para personalización basada en comportamiento de navegación, necesitas consentimiento explícito (opt-in). Para personalización basada en historial de compras con tu empresa, puedes argumentar interés legítimo, pero la línea es difusa y depende de la agencia de protección de datos nacional. La recomendación práctica: obtener consentimiento siempre que sea posible.
Minimización de datos: El RGPD exige recoger solo los datos necesarios para la finalidad declarada. Recoger “todo por si acaso” no es legal. Define exactamente qué datos necesitas para cada caso de uso de personalización y descarta el resto.
Derecho de acceso y supresión: El cliente tiene derecho a saber qué datos tienes sobre él y a solicitar su eliminación. Tu CDP debe poder exportar un perfil completo y eliminarlo de forma verificable. Esto tiene implicaciones técnicas serias: la eliminación debe propagarse a todos los sistemas downstream, no solo a la base de datos principal.
Evaluación de impacto (DPIA): Un CDP de retail casi seguro requiere una DPIA (evaluación de impacto relativa a la protección de datos). Es un requisito legal cuando el tratamiento implica perfilado a gran escala.
La arquitectura debe incorporar privacy-by-design:
- Consent management integrado. El CDP debe respetar las preferencias de consentimiento en tiempo real. Si un cliente retira su consentimiento para personalización, la segmentación debe excluirlo inmediatamente, no en el próximo batch nocturno.
- Data retention automatizada. Datos de navegación: 90 días max. Historial de compras: lo que la relación contractual justifique. Perfiles inactivos: anonimizar o eliminar tras el periodo definido.
- Encryption en reposo y tránsito. Pseudonimización de identificadores personales en el pipeline de datos.
El stack práctico para retail medio
Para un retailer español de tamaño medio (50-200 tiendas, ecommerce, app), un stack realista:
| Capa | Opción pragmática | Alternativa |
|---|---|---|
| Ingestión | Segment / RudderStack | Custom Kafka |
| CDP / Identity | Segment Unify / mParticle | Custom sobre Spark |
| Feature store | Redis + batch refresh | Feast |
| Decision engine | Reglas + modelo básico | Personalisation SaaS (Dynamic Yield, Bloomreach) |
| Activación | APIs a canales (email, push, display) | CDP nativo |
| Consent | CookieBot / OneTrust | Custom CMP |
El coste total del stack para un retailer medio ronda los 80.000-200.000 EUR/año en software, más el equipo de data engineering para operarlo (2-4 personas).
La alternativa más común para retailers que no quieren construir: plataformas de personalización integradas como Dynamic Yield (Mastercard), Bloomreach, o Algonomy. Cubren el CDP, el motor de decisiones y la activación en un solo producto. La desventaja: menor control sobre los datos, dependencia del vendor, y coste que escala con el volumen de interacciones.
Lo que viene
Retail media está evolucionando rápido. Dos tendencias que afectan directamente a la infraestructura:
Clean rooms de datos: Espacios donde retailers y anunciantes comparten datos anonimizados para medir campañas sin exponer datos individuales. AWS Clean Rooms, Google Ads Data Hub, y Snowflake Data Clean Room son las opciones principales. Para un retailer con ambiciones de retail media, la capacidad de participar en clean rooms será un requisito en 2-3 años.
IA generativa para contenido personalizado: No solo decidir qué producto recomendar, sino generar el copy, la imagen y el layout personalizados para cada segmento. Requiere una capa adicional de generación de contenido conectada al motor de decisiones. Todavía incipiente en retail europeo, pero los players grandes ya experimentan.
La infraestructura de datos que construyas hoy para personalización será la base para retail media mañana. Para una visión más amplia de cómo unificar datos omnicanal, consulta nuestro artículo sobre arquitectura de datos para retail omnicanal. Invertir en resolución de identidad, tiempo real y privacy-by-design no es opcional. Es la apuesta mínima para competir en un mercado donde el dato de primera mano es el activo más valioso.