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
- 01
Requisitos y criterios de decisión acordados.
- 02
Comparativa técnica y operativa de la lista de plataformas acordada.
- 03
Factores de coste de integración, operación y propiedad.
- 04
Supuestos, riesgos y dependencias que pueden cambiar la decisión.
- 05
Recomendación argumentada y registro de la decisión.
Qué comprobar antes de elegir
Uso estas preguntas para acordar los criterios de evaluación. Ninguna respuesta decide por sí sola qué plataforma conviene.
-
Casos de uso
¿Qué necesita hacer el negocio y qué impide hacerlo hoy?
Probar el recorrido prioritario con datos representativos y un resultado esperado, no solo con una demo preparada.
-
Latencia
¿Cuánto puede esperar cada decisión desde que llega el dato?
Medir el recorrido hasta el canal, incluidos la ingesta, el cálculo y la entrega. Acordar qué retraso es aceptable.
-
Identidad y consentimiento
¿Cómo se reconoce a la persona y qué usos del dato están permitidos?
Comprobar identificadores, reglas de unión y propagación de preferencias entre sistemas y marcas.
-
Datos existentes
¿Dónde está el dato fiable y qué parte falta o se duplica?
Revisar calidad, histórico, copias e integraciones. El almacén puede ser la referencia, pero hay que comprobarlo.
-
Operación
¿Quién mantendrá el sistema y resolverá los fallos?
Identificar responsables, capacidad del equipo, dependencias del proveedor y tareas habituales de mantenimiento.
-
Coste y transición
¿Qué cuesta implantar, operar y cambiar de solución?
Comparar licencia, integración, consumo, migración y salida. Documentar restricciones y supuestos del presupuesto.
Acordamos el peso de cada criterio y contrastamos las alternativas con pruebas. La recomendación puede ser conservar lo actual, combinar capacidades o cambiar de plataforma.
Ver ejemplos de arquitecturas y conexiones
Son esquemas de referencia, no opciones excluyentes ni recomendaciones. Las capacidades y conexiones concretas se verifican para cada producto y contrato.
Ejemplo con el almacén elegido como referencia, no una regla para todos los sistemas. El centro representa Snowflake, BigQuery, Databricks o Fabric. Alrededor aparecen conexiones que evaluar: Adobe con Federated Audience Composition, Salesforce con zero-copy, Oracle con Fusion Unity y APIs, SAP con Business Data Cloud, Tealium con CloudStream, HubSpot con conectores y composable con reverse ETL. Las líneas no indican dirección, compatibilidad universal ni ausencia de copias.
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
-
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.
¿Encaja con tu problema?
Cuéntame el contexto y te diré si este alcance es el adecuado o conviene empezar por otro sitio.
Para revisar esta decisión
- ¿Qué tiene que salir del warehouse?
Ingesta, Federated Audience Composition y Data Mirror resuelven necesidades distintas. Qué se mueve y qué revisar antes de elegir.