Marketing Analytics: el fin de la desconexión Marketing↔Producto

Tiempo estimado de lectura: 5 minutos

Introducción

¿Marketing celebra el ROI de una campaña mientras Producto ve un funnel que no convierte? Ese es exactamente el problema que las plataformas SaaS de analítica no llegan a resolver.

Marketing mide adquisición con GA4 o Matomo. Producto mide conversión con Mixpanel o Amplitude. Los dos deciden sobre el mismo usuario y sobre la misma inversión, pero desde herramientas y datos distintos que no encajan entre sí. La consecuencia: nadie responde con precisión si la captación es rentable considerando la experiencia real dentro del producto.

En Datadope resolvemos esto con Marketing Analytics basado en OpenTelemetry y el estándar W3C Baggage. La idea es simple: llevar la atribución de campaña y el funnel de conversión sobre el mismo pipeline de telemetría, hasta atarlos al pedido real en el backend transaccional.

  • Fuente única para Marketing y Producto: los dos equipos consultan el mismo dashboard sobre la misma telemetría.
  • Atribución trazable hasta el revenue: cada UTM viaja del clic en el anuncio hasta el span del pedido.
  • Funnel medido paso a paso: puntos de abandono y tiempo por fase disponibles con las mismas dimensiones que usa Marketing.

Figura 1: Overview del dashboard Marketing Analytics.

1. El problema del silo Marketing↔Producto

Cuando cada equipo mira su propia herramienta, hay tres cosas que se te escapan siempre:

  • Nadie tiene la foto cruzada. Marketing mira GA4 y las plataformas de anuncios; Producto mira Mixpanel o Amplitude. Son herramientas y datos distintos que no encajan entre sí, y las conversaciones sobre el mismo usuario ocurren sobre dos pantallas distintas: las decisiones de inversión se toman sin saber qué le pasa después al usuario dentro del producto.
  • Los números están estimados. GA4 muestrea consultas grandes y aplica su propio modelo de atribución data-driven, cuya lógica no puedes auditar. Las cifras varían entre exportaciones y no cuadran con el revenue registrado en el backend.
  • El dato sale de tu infraestructura. Con RGPD, DMA y sectores regulados (banca, salud, sector público), depender de servicios SaaS que envían telemetría a su propia infraestructura cada vez es menos aceptable.

La solución: construir una fuente de verdad anclada al backend transaccional, sobre el mismo pipeline OpenTelemetry que ya usas para observabilidad.

2. Arquitectura: el stack completo

El objetivo es conectar el clic del usuario en el anuncio con el pedido cerrado en el backend, eliminando los silos entre Marketing, Producto.

Los componentes:

  • OpenTelemetry Browser SDK: instrumenta el frontend y captura eventos de funnel y parsea los parámetros UTM al aterrizar.
  • W3C Baggage: el estándar que propaga los atributos de marketing en las cabeceras HTTP hasta el último microservicio.
  • Observability Stack (OTel Collector + Prometheus + OpenSearch + Jaeger + Grafana): el Collector enriquece y aplana la telemetría; Prometheus y Jaeger gestionan métricas y trazas, OpenSearch los logs. Grafana lo unifica todo.

Figura 2: Arquitectura con OpenTelemetry y W3C Baggage.

3. Implementación

El Baggage de OpenTelemetry es lo que hace posible todo esto. Permite inyectar los UTMs en las cabeceras HTTP y que viajen automáticamente por todos los microservicios, sin modificarlos uno a uno.

3.1. Parseo de UTMs y referrer al aterrizar

Al montar el cliente, extraemos los cinco parámetros UTM estándar de la URL y el  document.referrer  sólo si es externo. Los valores se cachean en memoria para inyectarse en cada span posterior de la sesión.

3.2. Relación del pedido con eventos en el backend de la aplicación.

Cada vez que la web realiza una petición, adjuntamos automáticamente los datos de origen del usuario (parámetros UTM como la plataforma de origen y campaña, la página de procedencia y el tipo de dispositivo). Así, cuando se completa la compra, el microservicio de checkout recoge esa información y la vincula directamente con el registro del pedido.

El span de conversión ( funnel.place_order ) se enriquece adicionalmente con el desglose de productos—nombres, cantidades y precios como tres cadenas posicionalmente alineadas—evitando la explosión de atributos indexados con carritos grandes:

El servicio Go no necesita saber nada de marketing: sólo lee del baggage lo que ya viajaba en la cabecera HTTP.

4. El Impacto Operativo

A. Marketing y Producto usando el mismo panel.

El mismo dashboard sirve a los dos equipos. Marketing lee KPIs de campaña, plataformas de origen y tasa de conversión. Producto lee el embudo desglosado, los puntos de abandono y el tiempo por fase. Todo alimentado por la misma telemetría OpenTelemetry.

El silo organizativo se resuelve técnicamente al obligar a los dos equipos a mirar la misma tabla. Marketing puede preguntar «¿qué campaña de TikTok convierte mejor en Chrome?»; Producto puede preguntar «¿en qué navegador tarda más el paso de añadir al carrito?»; ambos consultan la misma vista y las respuestas son coherentes entre sí, porque no hay dos fuentes de datos incompatibles que cruzar.

Figura 3: Fricción en la compra.

B. CAC y ROI anclados al backend transaccional

El atributo  marketing.utm_source  se inyecta en el mismo  span.SetAttributes  del microservicio de checkout que registra el importe del pedido.

Marketing y Producto miran el mismo panel. Al cruzar el revenue real con el gasto declarado por Marketing, el CAC deja de ser una estimación de la plataforma de anuncios y pasa a ser una cifra basada en nuestra instrumentación.

Figura 4: Panel de Finanzas.

5. El impacto en negocio

Más allá de los dashboards, esto tiene un impacto económico directo:

  • Menos inversión perdida en tráfico que no convierte: detectas campañas que traen tráfico interesado pero se atasca en un paso concreto del funnel antes de que el impacto en facturación sea serio.
  • Decisiones sobre datos que cuadran con el ERP: los KPIs de marketing usan la misma fuente que registra las ventas. Se acaban las discusiones sobre «¿de qué informe fiarnos?».
  • Sin vendor lock-in ni transferencia internacional: al estar basado en el estándar OpenTelemetry, el dato vive en tu infraestructura. Simplifica la política de privacidad frente a soluciones SaaS.

Figura 5: Funnel de Conversión.

Conclusión

La observabilidad moderna no consiste en acumular más herramientas: consiste en llevar sobre una única fuente de verdad los datos que hoy viven fragmentados en herramientas paralelas. Aplicar OpenTelemetry y W3C Baggage al problema del marketing digital y al del análisis de producto simultáneamente es lo que permite que Marketing y Producto dejen de mirar dashboards distintos y empiecen a decidir sobre los mismos datos.

Si tu equipo de Marketing y tu equipo de Producto todavía discuten en qué herramienta mirar antes de tomar una decisión, existe una forma mejor de hacerlo.

Alejandro Naranjo.

Imagen de Ivan Blanco

Ivan Blanco

¿Te ha resultado interesante?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas relacionadas

Marketing Analytics: el fin de la desconexión Marketing↔Producto

El coste también es una señal: FinOps integrado en tu plataforma de observabilidad

De 3 horas a menos de 10 minutos: Cómo Grupo Uvesco reduce sus tiempos de inactividad con IOMETRICS® Observability

¿Quieres saber más?