Saltar al contenido principal
Adrià García
Menú
← Todos los servicios

Servicio

Selección de plataforma

Comparo requisitos con capacidades reales y hago visibles las diferencias de integración, operación y propiedad antes de recomendar una opción.

Qué incluye

  1. 01

    Requisitos y criterios de decisión acordados.

  2. 02

    Comparativa técnica y operativa de la lista de plataformas acordada.

  3. 03

    Factores de coste de integración, operación y propiedad.

  4. 04

    Supuestos, riesgos y dependencias que pueden cambiar la decisión.

  5. 05

    Recomendación argumentada y registro de la decisión.

El almacén se está quedando la fuente de verdad, y cada familia tiende su puente hacia él. La pregunta ya no es si conectas, sino con qué contrato.

Diagrama de convergencia del mercado. En el centro, el almacén como fuente de verdad, con Snowflake, BigQuery, Databricks y Fabric. Desde arriba conectan las suites, cada una con su puente: Adobe con Federated Audience Composition, Salesforce con su red de socios zero-copy, Oracle con Fusion Unity y APIs, y SAP con Business Data Cloud. Desde abajo conectan las arquitecturas ágiles: Tealium con CloudStream, HubSpot con conectores y lo composable con reverse ETL. Todas las rutas terminan en el mismo almacén.

No hay un stack mejor que otro. Hay preguntas que ordenan la decisión, y el orden importa más que la respuesta a cualquiera de ellas por separado.

Árbol de decisión para elegir arquitectura. La primera pregunta es si hay presupuesto enterprise y más de doce meses. Si la respuesta es sí, la siguiente pregunta es si hay que unificar millones de perfiles repartidos entre sistemas heredados: si también es sí, la salida es una suite integrada; si es no, una arquitectura engagement-centric, propia de quien tiene canal propio y ciclos cortos. Si la primera respuesta es no, la pregunta pasa a ser si el almacén ya es la fuente de verdad: si lo es, la salida es warehouse-native, con equipo de datos propio; si no lo es, composable, que exige ingeniería dentro de casa.

La misma pregunta hecha a los cuatro. Lo que cambia se ve bajando una columna, no leyendo una fila.

Cuadro comparativo de los cuatro arquetipos de arquitectura de customer data, con cuatro preguntas iguales para todos: dónde se captura el dato, dónde vive el perfil, dónde se segmenta y se decide, y cómo se activa. Primera fila, suite integrada: captura por SDK y conectores desde web, app y batch; el perfil vive en la propia suite y en tiempo real; las audiencias y la decisión se resuelven dentro de la plataforma; y la activación sale por un catálogo de destinos de edge, streaming y fichero. Segunda fila, engagement-centric: captura por SDK y API más carga desde el almacén; el perfil de usuario vive dentro de la herramienta; los segmentos y la orquestación son del propio canal; y la activación son los canales propios, push, correo e in-app. Tercera fila, warehouse-native: la captura son cargas programadas al almacén; el almacén es la fuente de verdad; el cómputo ocurre en el propio almacén y la identidad hay que traerla aparte; y la activación es reverse ETL hacia cada herramienta. Cuarta fila, composable: idéntica a la anterior en captura, almacén y activación, y solo distinta en que las piezas van ensambladas en vez de computar en el sitio, con la identidad también aparte. Las dos últimas filas se parecen porque comparten casi todo.

Experiencia y criterio relacionados

  1. Construido 2024–2025

    Arquitectura AEP para varias líneas de negocio

    Modelo XDM, identidades, Web SDK y decisioning de ofertas para líneas de negocio distintas sobre una misma instancia. La primera línea nunca es el problema. El problema es que la segunda no obligue a rehacer el modelo de la primera.

    • XDM
    • Identidades
    • Web SDK
    • Decisioning

Preguntas frecuentes

¿Puedes ser neutral si trabajas sobre todo con Adobe?

Esa es la pregunta correcta. He implantado sobre Adobe y sobre Tealium, y esa experiencia es justo lo que permite estimar el coste real de cada opción, no solo leer su web. La recomendación llega con los criterios, los supuestos y los riesgos por escrito, para que puedas discutirla.

¿Y si la conclusión es que no cambiemos de plataforma?

Es un resultado válido y pasa. A veces el problema no es el producto sino el modelo de datos, la identidad o quién opera. Cambiar de plataforma con esos problemas sin resolver los traslada de sitio y añade una migración encima.

¿Sirve si ya hemos empezado una RFP?

Sí, y suele ser cuando más aporta. Con las propuestas encima de la mesa se puede comparar lo que promete cada una contra lo que cuesta operarla, que es donde se decide de verdad. La herramienta de briefing de esta web prepara esas preguntas.

¿Cómo defiendo la recomendación dentro de mi empresa?

El entregable incluye el registro de la decisión: qué se comparó, con qué criterios, qué supuestos se asumieron y qué riesgos quedan abiertos. Está pensado para llevarlo a un comité, no para quedarse en tu carpeta.

Herramienta gratuita

Prepara las preguntas para la próxima demo

Selecciona las afirmaciones del proveedor y genera un briefing para comprobarlas con datos, pruebas y responsabilidades concretas.

Preparar el briefing →

¿Encaja con tu problema?

Cuéntame el contexto y te diré si este alcance es el adecuado o conviene empezar por otro sitio.

Hablar del alcance