Cuando un equipo de marketing enterprise describe su problema de herramientas, casi siempre lo hace en términos de cantidad. Demasiados sistemas, demasiados logins, demasiadas integraciones que alguien tiene que mantener con scripts caseros. La conclusión habitual es que hay que consolidar proveedores.
Esa lectura pasa por alto lo que realmente está roto. El problema no es cuántas herramientas hay. Es que el CMS, la plataforma de automatización de marketing y el sistema de analítica suelen guardar, cada uno por su cuenta, una versión distinta de la misma persona.
Tres empleados que nunca se pasan el reporte
La situación se entiende mejor con una comparación simple. Imagina tres personas del mismo equipo trabajando sobre el mismo cliente, cada una con su propio cuaderno de notas, sin pasarse la información entre sí.
La primera lleva el registro de lo que el visitante hizo en el sitio: qué páginas vio, qué formulario llenó, qué contenido descargó. Es el CMS. La segunda lleva el historial de campañas: qué correos abrió, en qué secuencia de nutrición está, qué le interesó según sus clics. Es la plataforma de marketing automation. La tercera lleva las métricas agregadas: de dónde vino el tráfico, qué convierte mejor, qué segmento crece. Es el sistema de analítica.
Cada una hace bien su trabajo. El problema aparece cuando alguien necesita la historia completa. El equipo de campañas envía una oferta de un programa que la persona ya completó, porque esa información vive en el cuaderno del CMS y nadie se la pasó a marketing. El sitio le muestra contenido genérico a alguien que ya está en la mitad de una conversación con ventas, porque el CMS no sabe lo que sabe la plataforma de automatización. Y el reporte de fin de mes cuenta tres historias distintas de la misma campaña, porque cada sistema mide la conversión a su manera.
Ese es el costo real de operar con tres cuadernos separados: no es visible en la factura de licencias, aparece en las decisiones equivocadas que se toman con datos incompletos.
Qué significa técnicamente compartir un solo perfil
La alternativa técnica a los tres cuadernos separados tiene un nombre y una definición precisa, y vale la pena usarla con exactitud en vez de hablar en abstracto de "integración".
Apache Unomi, el proyecto open source que actúa como capa de datos de cliente en la arquitectura de Dropsolid, se define a sí mismo como un servidor que agrega información de distintas fuentes (CMS, CRM, sistemas de marketing) y la unifica en un perfil centralizado por persona. Cuando dos sistemas comparten un identificador, como un correo electrónico, los perfiles se fusionan automáticamente en uno solo.
Eso es lo que cambia frente al escenario de los tres cuadernos. El sitio deja de preguntarle al visitante quién es cada vez que interactúa, porque ya tiene la respuesta guardada en el perfil compartido. La plataforma de marketing automation deja de decidir a ciegas cuándo enviar una campaña, porque puede leer el comportamiento reciente en el sitio antes de disparar el siguiente correo. Y el reporte de analítica deja de reconciliar tres fuentes a mano, porque las tres parten del mismo dato base.
Qué es Dropsolid Open DXP, en términos verificables
Dropsolid llama a esta combinación Open DXP, y conviene ser preciso sobre qué componentes reúne exactamente, en vez de tratarlo como una caja negra.
La arquitectura combina tres proyectos open source con roles distintos y complementarios: Drupal como capa de contenido y CMS, Mautic como plataforma de automatización de marketing, y Apache Unomi como la capa que unifica el perfil de cliente entre ambos. Ninguno de los tres depende de licencia propietaria, lo que significa que una institución puede auditar el código de la pieza que unifica sus datos de cliente en vez de confiar en una caja cerrada.
Sobre esa base, Dropsolid AI suma una capa de inteligencia artificial construida encima de los mismos tres componentes: asistencia de IA dentro del flujo editorial de Drupal, búsqueda con IA, personalización apoyada en el perfil que administra Unomi, y una puerta de conexión de modelos que permite elegir, cambiar o alojar el modelo de lenguaje según la política de datos de cada institución. Esa última pieza importa para instituciones de salud y gobierno en la región, donde la ubicación de los datos y el proveedor del modelo de IA suelen ser parte de la conversación de cumplimiento antes que de la conversación técnica.
esinergia opera esta arquitectura como el remitido exclusivo de Dropsolid en la región: cuando un cliente potencial en LATAM llega a Dropsolid, lo remiten a esinergia. No es una certificación de partners por niveles, algo que Dropsolid no ofrece a diferencia de Acquia, es un acuerdo comercial de referidos.
Cuándo esta arquitectura tiene sentido
No toda institución necesita resolver este problema con una plataforma compuesta como Open DXP, y vale la pena ser honesto sobre eso antes de entrar en la conversación comercial.
Una universidad que gestiona el ciclo completo del estudiante, desde el primer contacto en el sitio de admisiones hasta la comunicación con el egresado, es un ejemplo claro de este escenario. El mismo aspirante interactúa con el sitio, recibe correos de nutrición, y termina en un tablero de analítica que el equipo de mercadeo revisa cada semana. Si esas tres capas no comparten perfil, la universidad termina tratando a un aspirante avanzado como si fuera un visitante nuevo, con la fricción y el costo de oportunidad que eso implica.
Una red de salud con varias líneas de servicio enfrenta una versión parecida: el paciente que agenda una cita, el que recibe recordatorios y el que aparece en el reporte de conversión de campañas de prevención pueden ser la misma persona vista por tres sistemas que no se hablan.
Una entidad de gobierno que opera trámites en línea y campañas de comunicación pública tiene el mismo patrón con otro nombre. El ciudadano que inicia un trámite en el portal, el que recibe el recordatorio de un plazo por correo, y el que aparece en la medición de una campaña de difusión de un nuevo servicio, son con frecuencia la misma persona registrada tres veces en tres sistemas distintos. La diferencia frente al sector privado es que ahí el costo de la fragmentación no se mide solo en conversión, se mide en la cantidad de contactos duplicados que recibe un ciudadano por el mismo trámite.
El framing agnóstico que aplica esinergia en esta decisión importa aquí. Drupal nativo puede resolver buena parte de la capa de contenido sin agregar piezas adicionales, y para una institución con una operación de marketing más simple esa ruta puede bastar. Acquia plantea su propia composición del mismo problema, con su propio conjunto de productos de datos y campañas. La pregunta que ordena la decisión pasa por cuántos sistemas de marketing ya opera la institución y qué tan crítico es que compartan un perfil único del mismo visitante.
Qué preguntar antes de decidir
Tres preguntas que ayudan a diagnosticar si el problema de los tres cuadernos separados existe en tu organización, sin necesidad de contratar nada para responderlas.
¿Cuántos sistemas distintos guardan información sobre el mismo visitante o paciente? Si la respuesta pasa de dos, ya hay terreno fértil para el problema.
¿Alguien tiene que exportar y cruzar reportes a mano para tener una vista completa de una campaña? Ese trabajo manual es exactamente lo que el perfil compartido elimina, y es medible en horas de equipo cada mes.
¿El sitio le puede mostrar contenido distinto a un visitante que ya está en medio de una conversación con otro canal? Si la respuesta es no, el sitio está operando ciego a lo que el resto de la organización ya sabe.
Si las tres respuestas muestran fragmentación real, el caso de negocio para consolidar en una capa de datos compartida se sostiene solo. Si la operación de marketing todavía es pequeña, la inversión en unificar perfiles puede esperar a que el problema sea más grande que el costo de resolverlo.
Lo que viene
La fragmentación de datos entre CMS y marketing automation no es un problema nuevo, pero el costo de dejarla sin resolver crece a medida que las instituciones suman canales: chat, WhatsApp, portales de autoservicio, agentes de IA que responden preguntas de primer contacto. Cada canal nuevo que no comparte el mismo perfil de cliente es otro cuaderno separado sumado a los tres que ya existían.
Para 2028, la expectativa de que una institución enterprise reconozca al mismo visitante sin importar el canal por el que llegue va a dejar de ser una ventaja diferenciadora y va a convertirse en la base mínima de operación. Las organizaciones que resuelvan la capa de datos compartida ahora, mientras el número de canales todavía es manejable, van a llegar a esa fecha con una arquitectura. Las que lo dejen para cuando el problema ya sea inmanejable van a tener que resolver a la vez la unificación de datos y la multiplicación de canales.
Si la conversación en tu organización todavía es qué significa operar sobre una capa de experiencia digital antes de decidir cómo componerla, ese marco está en ¿Qué es un DXP y su empresa realmente necesita uno?. Y si el ángulo que te interesa es cómo se ve esta misma pregunta de integración de contenido resuelta desde otro proveedor del ecosistema, la cubrimos en Cómo Drupal y Acquia transforman la gestión de contenido en plataformas digitales.