Cada vez que aparece un nuevo stack, también aparece una promesa: simplificar lo complejo. El Customer Data Platform fue (y sigue siendo) una de las más fuertes. ¿Quién no quiere unificar datos de clientes, activar mensajes personalizados en tiempo real y medir resultados en una sola plataforma? El problema es que esa promesa, si no se diseña con criterio, se vuelve otro silo más. Uno caro, además.

En estos meses, con varios CDOs de la región venimos compartiendo aprendizajes reales sobre CDPs. Implementaciones en diferentes industrias, con vendors distintos, y en estadíos de madurez muy diversos. Y siempre volvemos a las mismas tres preguntas:

• ¿Dónde debería estar el CDP en la arquitectura?

• ¿Cómo se justifica el retorno?

• ¿Cuál es el modelo de CDP que mejor se adapta a mi organización?

El lugar correcto no es un diagrama, es un modelo operativo

Un error común es pensar al CDP como una caja mágica que se conecta al CRM, al Datalake, a las audiencias y ya. Pero eso es sólo integración, no arquitectura. La arquitectura verdadera define quién orquesta qué cosa, desde dónde, con qué latencia, con qué reglas y con qué ownership.

Ahí aparece el debate actual entre CDP monolítico vs composable CDP. Mientras que el modelo tradicional concentra la ingesta, unificación, segmentación y activación en un único producto, el modelo composable separa componentes: datos en BigQuery o Snowflake, transformación con dbt, modelos en Vertex AI o SageMaker, activación con un campaign tool liviano, y reglas de negocio en una capa tipo Rudderstack, Hightouch o Salesforce Data Cloud.

No es sólo una cuestión técnica. Es una forma distinta de pensar el control: desacoplar para escalar, mantener ownership desde el equipo de datos y evitar lock-in de plataformas que después no podemos mover.

El ROI no es de la herramienta, es del modelo

Medir el ROI de un CDP como si fuera un canal más es un error conceptual. No es un canal, es una plataforma de decisión distribuida. Su valor está en cuánto acelera una activación, cuánto reduce la fricción entre áreas, cuánto mejora la calidad de las hipótesis que se testean, o cuánto baja el costo de oportunidad de no actuar en tiempo.

Si el CDP no habilita más y mejores decisiones, más rápidas y con menos fricción, entonces es caro. Si lo hace, entonces probablemente sea la inversión más estratégica del stack.

Modern Data Stack, ¿o ya estamos en el Post-Modern?

Durante años la discusión fue entre el stack legacy y el Modern Data Stack. Hoy, la tensión es otra: ¿cómo se articula ese stack moderno con las plataformas de activación y canales comerciales?

Ahí entra el concepto emergente de Post-Modern Data Stack: donde los datos no sólo fluyen bien, sino que se convierten en decisiones ejecutables en múltiples puntos del journey. No alcanza con tener un buen pipeline. Hay que tener capacidad de decisioning. Y para eso, el CDP (monolítico o composable) se convierte en el runtime donde esa inteligencia se orquesta.

En nuestro caso, lo estamos viviendo con Data Cloud, combinando modelos de propensión generados en el datalake, eventos digitales en tiempo real y activación a través de campañas, reglas personalizadas y motores de recomendaciones. ¿Funciona perfecto? No. ¿Estamos más cerca del valor? Sí.

El futuro del CDP es dejar de pensarlo como CDP

Quizás el mejor CDP del futuro no se llame CDP. Será una combinación de un motor de reglas, una capa semántica, un runtime de decisión y una interfaz de orquestación. Capaz de absorber señales digitales, ejecutar reglas, testear hipótesis y derivar acciones en canales en tiempo real o batch.

Para quienes trabajamos en marketing analítico, inteligencia comercial o customer experience, la pregunta ya no es si usar un CDP, sino qué tipo de inteligencia queremos habilitar, con qué datos, con qué reglas y con qué latencia.

Todo lo demás, el proveedor, el stack, el roadmap, vendrá después.