La redacción publica, la campaña corre y, al cerrar el mes, nadie sabe decir qué pieza trajo a un lector valioso y cuál solo generó clics. Para una dirección de datos o de ingresos digitales en una editorial o una agencia esto es el día a día: la analítica de medios se fragmenta entre la plataforma de analítica, el CMS, el ad server y el CRM, y ninguna de esas fuentes conoce la historia completa de una sola persona de la audiencia.
Por nuestra experiencia, el problema rara vez es la falta de herramientas; casi siempre es la capa que falta para unirlas en un modelo de datos coherente y mantenerlo vivo en el tiempo. Esa es la capacidad que aportamos. RITS Group tiene competencia real en datos y Big Data (nuestros equipos de LLM/IA/datos), y nuestros ingenieros han trabajado procesando grandes volúmenes de eventos en publicidad. Eso lo llevamos a los proyectos de medios como refuerzo de equipo o equipo dedicado.
¿Por qué están hoy tan fragmentados los datos de audiencia?
Porque cada herramienta se creó para resolver un problema distinto y cada una guarda su propia verdad sobre la misma persona. La plataforma de analítica ve una sesión de navegador, el ad server una impresión y un clic, el CRM a una persona suscrita, y la app móvil emite otro flujo de eventos más. Nadie los cose, porque coserlos no es el trabajo de nadie en concreto.
A eso se suma un cambio de mercado: las cookies de terceros desaparecen y la regulación obliga a pedir consentimiento. Un editor que se apoyaba en datos externos se queda con un hueco que solo puede llenar la telemetría de audiencia propia y un modelo first-party sólido.
¿Cómo se construye un pipeline de eventos y la telemetría de audiencia?
La base es un flujo de eventos: cada interacción (una vista de página, un scroll, una reproducción de vídeo, un alta en la newsletter) llega como evento con un esquema estable a un único bus. Aquí solemos montar una capa de colas y procesamiento en streaming, por ejemplo Kafka para el transporte de eventos y Flink o Spark Streaming para la agregación al vuelo.
Los datos aterrizan en dos sitios a la vez: una capa cruda (data lake o lakehouse) donde no se pierde nada, y un modelo analítico en el almacén (BigQuery, Snowflake, Redshift) ya calculado para reporting, de modo que podemos cambiar la definición de una métrica y recalcular todo el histórico desde cero.
- capa de recogida - un colector de eventos ligero, en servidor y en cliente, resistente a bloqueadores,
- transporte y buffer - una cola de eventos que aguanta el pico cuando sale una pieza grande,
- procesamiento en streaming - sesionización, deduplicación, enriquecimiento con contexto,
- capa de consulta - un almacén alimentado en batch y casi en tiempo real.
¿Cómo se diseñan dashboards de rendimiento de contenidos que la gente use de verdad?
Un dashboard que solo enseña páginas vistas no cambia ninguna decisión editorial. Por eso partimos de quién lo mira y cuándo, y construimos una vista distinta para cada rol (la persona que edita, la que escribe, la dirección) apoyada en métricas de engagement y no en tráfico bruto: tiempo de lectura atenta, profundidad de scroll, aportación de una pieza a la captación de una suscripción.
Por debajo imponemos una única definición compartida de cada métrica, para que «lector activo» signifique lo mismo en el panel editorial y en el informe para el anunciante. La capa de presentación la ponemos en una herramienta de BI, o construimos un panel dedicado cuando el BI estándar no da la talla frente a las particularidades del contenido.
¿Cómo se calculan la atribución de marketing y los informes de embudo?
Aquí empieza el valor real de negocio. No basta con «de dónde vino el tráfico»; hay que conectar los puntos de contacto en un único recorrido de audiencia y asignar a cada uno su parte del efecto. Lo modelamos por etapas:
- atribución last touch y first touch como punto de partida y referencia,
- atribución basada en posición y con decaimiento temporal cuando los recorridos se alargan,
- atribución data-driven que reparte el crédito según conversiones reales,
- informes de embudo que unen campaña, contenido e ingreso (suscripción, lead, venta publicitaria).
La clave es que la atribución de marketing corra sobre el mismo modelo de eventos que el resto de la analítica, y no en una herramienta aparte con su propia verdad. Si no, la dirección de ingresos digitales recibe dos cifras que se contradicen.
¿Qué son los modelos de churn y de engagement y por qué construirlos?
Para un editor de suscripción y para una agencia, retener a la audiencia suele importar más que la siguiente visita, así que sobre el pipeline colocamos modelos que predicen el riesgo de baja y ordenan a la audiencia por engagement. Solemos empezar por un esquema de scoring legible (RFM, señales de recencia y frecuencia) y solo recurrimos a modelos de machine learning que estiman la probabilidad de churn en una ventana temporal cuando los datos lo soportan. Esta capa la desarrollamos junto a la competencia de IA del RITS Group, cuando un proyecto madura hacia la recomendación de contenido. Mantenemos el modelo fuera del terreno de la caja negra: marketing tiene que entender por qué un lector concreto aparece marcado como en riesgo.
¿Cómo se concilia la analítica con la privacidad y el consentimiento?
La privacidad no es un añadido al final; es la condición de entrada. Integramos el consentimiento en el propio pipeline: un evento sin base adecuada sencillamente no llega adonde no debe. Integramos la capa de gestión del consentimiento (CMP) con el flujo de eventos, separamos los datos identificativos de los analíticos y aplicamos seudonimización. Así la analítica queda lista para un mundo sin cookies de terceros: un modelo first-party fuerte, medición en servidor y modelado de conversiones en lugar de seguimiento uno a uno.
¿Por qué la calidad del dato decide si la gente confía en los informes?
El dashboard más fino pierde su sentido el día en que alguien lo pilla en un error. Por eso tratamos la calidad del dato como parte del producto: incorporamos tests y contratos de datos, vigilamos la frescura y la completitud del flujo y documentamos cada métrica en un catálogo.
- contratos de esquema - un campo cambiado en el origen no rompe los informes en silencio,
- tests y alertas - huecos, duplicados y valores raros salen a la luz al momento, no una semana después,
- catálogo y linaje de datos - sabes de dónde salió cada número,
- definiciones de métrica versionadas - el histórico se sostiene incluso tras cambiar una regla.
¿Qué competencias ponemos en un proyecto de analítica de medios?
Formamos el equipo alrededor de la etapa concreta, no «por si acaso»: al principio hace falta quien diseñe el modelo de datos y el pipeline, y más tarde gente para la capa de visualización y los modelos.
- un data engineer que construye el pipeline de eventos, el almacén y las transformaciones,
- un arquitecto de datos que define el modelo y la capa de calidad,
- un analista / especialista en BI que convierte los datos en dashboards y definiciones de métricas,
- un ML engineer / data scientist responsable de los modelos de atribución y churn,
- un DevOps / platform engineer que mantiene en pie la infraestructura de procesamiento en la nube.
Cubrimos estos roles de uno en uno, o como equipo completo cuando la analítica hay que levantarla desde cero.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia, con una base real de datos dentro del RITS Group:
- anclamos la capa de datos en la competencia de Big Data e IA del Grupo y en la experiencia de nuestros equipos procesando grandes volúmenes de eventos publicitarios,
- verificamos las competencias antes de empezar y formamos el equipo según la etapa del proyecto, del pipeline a los modelos,
- trabajamos en una zona horaria cercana, así que los ingenieros entran en las revisiones de código sin una rampa larga,
- unimos la recogida de eventos, el almacén, los dashboards y la atribución en un todo mantenible.
Lo más habitual es que lo entreguemos como software a medida construido por nuestro equipo y, cuando hay que reforzar rápido las competencias de datos, como refuerzo de equipo.
¿Por dónde empezar con la analítica de audiencia?
Empieza por una decisión que hoy tomas por instinto y querrías respaldar con datos: qué contenido promocionar en pago, o a qué persona suscrita salvar. Esa pregunta define qué eventos recoger, qué modelo de datos construir y qué roles cubrir primero. Las diferencias entre modelos de colaboración las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir analítica de audiencia y de rendimiento de contenidos? Hablemos - ajustamos equipo y arquitectura de datos a tu redacción o a tu agencia.
Construye tu analítica de audiencia y contenidos con nosotros