Retail media y personalizacion: la infraestructura detras 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 Espana supero 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 personalizacion relevante al cliente. Amazon lo hace. Mercadona esta construyendo capacidades. Carrefour Links ya opera en Francia y se expande.
Pero detras de la promesa hay un problema de infraestructura de datos que la mayoria 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 asi). Es una infraestructura de datos que:
- Ingesta datos de multiples fuentes: Punto de venta, ecommerce, app movil, programa de fidelizacion, interacciones en tienda fisica (WiFi, beacons), campanas de email.
- Unifica perfiles: Resolucion de identidad. El mismo cliente que compra online con un email, en tienda con su tarjeta de fidelizacion, y navega la app con un device ID debe resolverse como un unico perfil.
- Segmenta en tiempo real: No segmentos estaticos recalculados cada noche, sino audiencias que se actualizan con cada interaccion.
- Activa en canales: Envia el segmento o la decision al canal correcto (email, push, display, retail media) con la latencia adecuada.
Resolucion de identidad
Este es el problema tecnico mas difícil y el que determina si el CDP funciona o es un data lake mas. La resolucion de identidad conecta identificadores dispares (email, phone, cookie ID, device ID, tarjeta de fidelizacion, ID de transaccion POS) en un perfil unificado.
Hay dos enfoques:
Deterministico: Conecta identificadores cuando hay un match exacto (mismo email, mismo telefono). Alta precision, bajo recall. Funciona bien para clientes registrados.
Probabilistico: Usa senales indirectas (mismo dispositivo, misma IP, patrones de comportamiento similares) para inferir que dos identificadores pertenecen al mismo usuario. Mayor recall, menor precision. Util para visitantes anonimos.
En la practica, un CDP de retail necesita ambos. El matching deterministico para la base de clientes conocidos (tipicamente el 30-40% del trafico), y el probabilistico para el resto. La clave es que el modelo probabilistico 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 resolucion de identidad out-of-the-box. Para retailers con requisitos especificos (datos de POS offline, integracion con sistemas legacy), un desarrollo custom sobre Apache Spark o Flink es mas comun de lo que los vendors admiten.
Decisiones en tiempo real
La personalizacion que importa ocurre en milisegundos: que producto recomendar cuando el cliente abre la app, que banner mostrar cuando navega la web, que 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, ubicacion, pagina que visita).
- Inventario disponible (no recomendar un producto agotado en la tienda mas cercana).
- Reglas de negocio (margenes, stock que se quiere rotar, acuerdos con proveedores).
La arquitectura tipica:
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 atencion. Es la capa que mantiene las features del cliente (media de gasto, frecuencia de compra, categorias 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 comun para latencias sub-10ms.
Por que no se puede resolver esto con una base de datos relacional y queries? Porque la personalizacion a escala retail implica miles de decisiones por segundo, cada una combinando datos de multiples fuentes. Una query SQL que haga un join de 5 tablas para calcular la recomendacion 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
Aqui 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 definicion, un sistema de tratamiento de datos personales a gran escala.
Los puntos criticos:
Base legal: Para personalizacion basada en comportamiento de navegacion, necesitas consentimiento explicito (opt-in). Para personalizacion basada en historial de compras con tu empresa, puedes argumentar interes legitimo, pero la linea es difusa y depende de la agencia de proteccion de datos nacional. La recomendacion practica: obtener consentimiento siempre que sea posible.
Minimizacion de datos: El RGPD exige recoger solo los datos necesarios para la finalidad declarada. Recoger “todo por si acaso” no es legal. Define exactamente que datos necesitas para cada caso de uso de personalizacion y descarta el resto.
Derecho de acceso y supresion: El cliente tiene derecho a saber que datos tienes sobre el y a solicitar su eliminacion. Tu CDP debe poder exportar un perfil completo y eliminarlo de forma verificable. Esto tiene implicaciones tecnicas serias: la eliminacion debe propagarse a todos los sistemas downstream, no solo a la base de datos principal.
Evaluacion de impacto (DPIA): Un CDP de retail casi seguro requiere una DPIA (evaluacion de impacto relativa a la proteccion 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 personalizacion, la segmentacion debe excluirlo inmediatamente, no en el proximo batch nocturno.
- Data retention automatizada. Datos de navegacion: 90 dias max. Historial de compras: lo que la relacion contractual justifique. Perfiles inactivos: anonimizar o eliminar tras el periodo definido.
- Encryption en reposo y transito. Pseudonimizacion de identificadores personales en el pipeline de datos.
El stack practico para retail medio
Para un retailer espanol de tamano medio (50-200 tiendas, ecommerce, app), un stack realista:
| Capa | Opcion pragmatica | Alternativa |
|---|---|---|
| Ingestion | Segment / RudderStack | Custom Kafka |
| CDP / Identity | Segment Unify / mParticle | Custom sobre Spark |
| Feature store | Redis + batch refresh | Feast |
| Decision engine | Reglas + modelo basico | Personalisation SaaS (Dynamic Yield, Bloomreach) |
| Activacion | 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/ano en software, mas el equipo de data engineering para operarlo (2-4 personas).
La alternativa mas comun para retailers que no quieren construir: plataformas de personalizacion integradas como Dynamic Yield (Mastercard), Bloomreach, o Algonomy. Cubren el CDP, el motor de decisiones y la activacion 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 esta evolucionando rapido. Dos tendencias que afectan directamente a la infraestructura:
Clean rooms de datos: Espacios donde retailers y anunciantes comparten datos anonimizados para medir campanas 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 sera un requisito en 2-3 anos.
IA generativa para contenido personalizado: No solo decidir que producto recomendar, sino generar el copy, la imagen y el layout personalizados para cada segmento. Requiere una capa adicional de generacion de contenido conectada al motor de decisiones. Todavia incipiente en retail europeo, pero los players grandes ya experimentan.
La infraestructura de datos que construyas hoy para personalizacion sera la base para retail media manana. Para una vision mas amplia de como unificar datos omnicanal, consulta nuestro articulo sobre arquitectura de datos para retail omnicanal. Invertir en resolucion de identidad, tiempo real y privacy-by-design no es opcional. Es la apuesta minima para competir en un mercado donde el dato de primera mano es el activo mas valioso.
Etiquetas
Sobre el autor
abemon engineering
Equipo de ingenieria
Equipo multidisciplinar de ingenieria, datos e IA con sede en Canarias. Construimos, desplegamos y operamos soluciones de software a medida para empresas de cualquier escala.