Medir en productos digitales no consiste simplemente en colocar varias herramientas de analítica en las pantallas. Una estructura sólida define conjuntamente qué comportamiento se monitoriza y por qué, cómo se estandarizan los datos y qué decisiones deben activar. De lo contrario, los equipos generan grandes volúmenes de datos, pero no logran identificar con claridad qué parte del producto debe mejorarse.
¿POR QUÉ LA ARQUITECTURA DE MEDICIÓN ES MÁS QUE UNA LISTA DE EVENTOS?
La arquitectura de medición es el diseño del flujo de datos que conecta el comportamiento de los usuarios con los resultados del negocio. Un evento representa una acción realizada por el usuario o por el sistema. Sin embargo, recopilar eventos por sí solo no equivale a construir un sistema de medición. Antes de implementarlo, deben definirse su nombre, contexto, condiciones de activación, responsable y decisión a la que contribuirá.
Por ejemplo, en un producto de comercio electrónico, el evento «se hizo clic en el botón» es una señal débil por sí sola. Si no sabemos en qué botón se hizo clic, en qué página de producto y como parte de qué recorrido del usuario, ese dato no puede interpretarse. Una estructura más útil analiza el evento «producto añadido al carrito» junto con el identificador del producto, la categoría, el rango de precio, la sesión y la fuente de adquisición.
Una buena arquitectura responde a tres preguntas: ¿qué ocurrió?, ¿en qué contexto ocurrió y para quién?, y ¿qué decisión ayudará a tomar esta información? Si no se responden estas preguntas, la herramienta elegida solo permitirá acumular datos más rápido.
¿CÓMO SE DISEÑA UNA TAXONOMÍA DE EVENTOS?
La taxonomía de eventos organiza las acciones del producto en un vocabulario común. Los nombres, las propiedades y los formatos de valores son sus elementos fundamentales. La taxonomía debe construirse a partir del ciclo de vida del usuario y los objetivos del producto, no según las pantallas o los equipos.
Primero se identifican los objetos principales: usuario, cuenta, sesión, contenido, producto, transacción o suscripción, entre otros. Después se definen las acciones relacionadas con esos objetos. «Producto visualizado», «búsqueda realizada», «solicitud iniciada» y «solicitud completada» son eventos diferentes. Cada uno debe seguir la misma convención de escritura y el mismo conjunto de propiedades obligatorias.
Imaginemos que un equipo de tres personas está desarrollando una plataforma educativa. En el evento «lección abierta» pueden establecerse como obligatorios el identificador de la lección, el identificador del curso, el tipo de usuario y la posición de reproducción. El evento «lección completada» no se enviará simplemente cuando se cierre el vídeo, sino cuando se cumpla la regla de finalización definida por el producto. Así, las decisiones de diseño y medición quedan alineadas.
El documento de taxonomía es un activo técnico vivo. Cuando se añade una nueva funcionalidad, se actualiza el diccionario de eventos y los eventos que ya no se utilizan se archivan. Que distintos equipos empleen nombres como «signup», «registration» y «account_created» para el mismo comportamiento genera una fragmentación innecesaria en la capa de datos.
¿CÓMO HACE MÁS FIABLES LOS DATOS LA CAPA DE MEDICIÓN?
La capa de medición es una estructura intermedia y controlada entre el código del producto y los sistemas de analítica y reporting. Enviar los eventos directamente a cada herramienta puede parecer rápido a corto plazo, pero amplía las diferencias de nombres y formatos de datos. Un esquema centralizado, reglas de transformación y controles de validación ayudan a reducir esta dispersión.
En esta capa se gestionan conjuntamente el esquema de eventos, el diccionario de datos, la resolución de identidades, la gestión de permisos, el seguimiento de errores y los controles de calidad. Antes de pasar a producción, se comprueba que el evento se active en el momento correcto, incluya los campos obligatorios y no se envíe varias veces. La relación entre los datos de identidad y los datos de comportamiento también debe limitarse mediante permisos de acceso y principios de privacidad.
Por ejemplo, si el evento «pago completado» se envía dos veces, los informes de ingresos crecerán artificialmente. Por eso se utiliza el identificador de la transacción para deduplicar los registros, se diferencian los pagos fallidos de los pagos completados y se evita que los datos del entorno de pruebas se mezclen con los informes de producción. Una arquitectura de medición no produce un montón de datos sin procesar que el analista tendrá que limpiar después, sino un flujo validado desde el principio.
La elección de herramientas también es una consecuencia de esta capa. Se pueden utilizar varios sistemas de analítica, publicidad o experiencia del cliente, pero todos deben basarse en el mismo vocabulario fundamental. Aumentar el número de herramientas no mejora por sí solo la calidad de las decisiones.
¿CÓMO SE CONVIERTEN LAS MÉTRICAS EN UN SISTEMA DE DECISIÓN?
Una métrica solo adquiere valor cuando está vinculada a una decisión. Primero se define el objetivo de negocio; después, el comportamiento del usuario; y, por último, la señal medible. Si se invierte este orden, los equipos tienden a centrarse en indicadores fáciles de medir, pero poco relevantes.
Si un equipo de producto quiere aumentar la activación, no basta con observar únicamente el número de usuarios diarios. Es necesario analizar por separado si el usuario alcanza su primer momento de valor, utiliza la funcionalidad principal y regresa en un plazo determinado. Para cada métrica deben definirse un responsable, una periodicidad, un umbral y una acción.
Por ejemplo, si en el informe mensual cae la tasa de finalización de solicitudes, el sistema de decisión debe mostrar primero en qué paso se produce la caída. El equipo de producto analizará los campos del formulario, el equipo de contenidos revisará las explicaciones y el equipo de operaciones estudiará el proceso posterior a la solicitud. De este modo, el informe no se limita a decir «hay una caída», sino que también define qué equipo debe investigar cada cuestión.
Se pueden utilizar conjuntamente una métrica norte, métricas del embudo, retención, conversión, ingresos e indicadores operativos. Sin embargo, las relaciones causales entre ellas no deben darse por supuestas. Hay que comprobar si el aumento de una métrica se debe a un mayor valor para el usuario, a un cambio en la medición o al efecto de una campaña.
¿CÓMO SE ITERA Y GESTIONA UN SISTEMA DE MEDICIÓN?
La arquitectura de medición no es un proyecto que se completa una sola vez. A medida que cambia el producto, también cambian los eventos, los recorridos de los usuarios y las necesidades de decisión. Por ello, el plan de medición debe integrarse en el ciclo de desarrollo del producto y los requisitos de medición deben incorporarse a los criterios de aceptación de las nuevas funcionalidades.
Para la gobernanza, deben diferenciarse el responsable del evento, el responsable de los datos y el responsable de la decisión. El equipo técnico se encarga de que los datos se envíen correctamente; el equipo de producto, de preservar su significado; y el área de negocio, de tomar las medidas correspondientes. Las revisiones periódicas de calidad deben controlar los campos incompletos, los retrasos, los duplicados, las desviaciones en la nomenclatura y los cambios inesperados en el volumen.
Imaginemos que una aplicación móvil acaba de publicar un nuevo flujo de onboarding. Durante la primera semana no basta con comprobar si los eventos están llegando. También deben revisarse la comparabilidad con el flujo anterior, la correcta separación del grupo experimental, el registro de los errores y la lectura conjunta de las solicitudes de soporte y los datos de comportamiento. Si es necesario, se revisa el esquema y se documenta el cambio.
El enfoque que está ganando protagonismo en el sector consiste en dejar de considerar la medición como una herramienta exclusiva de los informes de marketing y convertirla en una infraestructura compartida para las decisiones de producto, operaciones e ingresos. La privacidad, la propiedad de los datos, el diseño de experimentos y las señales en tiempo real deben abordarse como partes de una misma arquitectura. Lo más recomendable es empezar con un alcance reducido y ampliar la estructura a nuevos recorridos a medida que se demuestre la calidad de la medición.
La forma más saludable de empezar es desarrollar un pequeño piloto centrado en un recorrido crítico del usuario, con su diccionario de eventos y su conexión con las decisiones.
Preguntas frecuentes
¿Cuál es la diferencia entre una taxonomía de eventos y un plan de medición?
La taxonomía de eventos define qué acciones se monitorizan dentro del producto, con qué nombres y propiedades. El plan de medición explica qué objetivo, métrica y decisión respalda cada una de esas acciones.
¿Debe definirse un evento para cada comportamiento del usuario?
No. Solo deben medirse los comportamientos relacionados con los objetivos del producto, la experiencia del usuario, las operaciones o las decisiones de negocio. Los eventos innecesarios reducen la calidad de los datos y ralentizan el análisis.
¿Cómo se controla la calidad de los datos en una arquitectura de medición?
El esquema de eventos se prueba antes de pasar a producción; además, se revisan periódicamente los campos obligatorios, los registros duplicados, las activaciones incorrectas y la correspondencia de identidades. Los cambios se documentan en el diccionario y en los registros de versiones.
