Instrumentar cada clic parece una forma de no perder información. En la práctica, suele producir esquemas difíciles de mantener, informes ruidosos y preguntas que nadie puede responder con confianza. El problema no es tener muchos datos, sino recopilar acciones sin saber qué decisión ayudarán a tomar.
Para decidir qué eventos medir en analítica de producto, empieza por una decisión real: qué harías de manera diferente si los datos mostraran un resultado u otro. Después, define qué comportamiento permitiría observarlo, qué contexto necesitas y cómo comprobarás que la medición funciona. Este orden ayuda a construir una instrumentación más pequeña y útil.
Empieza por la decisión, no por el evento
Antes de añadir un evento, concreta la decisión de producto o negocio que está pendiente. Puede ser priorizar una mejora, investigar un abandono, modificar un flujo o comprobar si una nueva experiencia se utiliza. Si ningún resultado posible cambiaría el siguiente paso, probablemente la medición no es prioritaria.
Escribe la pregunta en términos que permitan actuar. “¿La nueva función funciona?” es demasiado amplia: puede referirse a descubrimiento, uso, comprensión o impacto. Una formulación más útil sería: “¿Qué proporción de las personas que encuentran la función completa la acción principal durante su primera semana?”. La pregunta ya indica qué población, comportamiento y periodo hace falta aclarar.
También conviene anotar las posibles respuestas y sus consecuencias. Si el uso es bajo, quizá se investigue si la función es visible; si muchas personas la prueban, pero pocas terminan, quizá se revise el flujo. La analítica no decide por el equipo, pero debe distinguir escenarios que conducen a decisiones distintas.
Traduce preguntas en comportamientos observables
Una pregunta no se mide directamente. Hay que convertirla en acciones que el producto pueda registrar y que representen de forma razonable el comportamiento de interés. Para una pregunta sobre finalización de una tarea, por ejemplo, podría ser necesario registrar el inicio y la finalización, no cada movimiento del cursor o cada clic intermedio.
Define qué cuenta como cada acción. “Registro completado” podría significar que se envió un formulario, que el servidor aceptó la solicitud o que la cuenta quedó disponible. Esos momentos no son equivalentes. Elige el que represente el resultado que quieres estudiar y especifica cuándo ocurre, incluidos los casos de error o reintento.
Un evento suele ser útil cuando:
- Representa una acción o un cambio de estado con significado para el producto.
- Permite responder una pregunta priorizada, no solo describir actividad.
- Tiene un momento de activación definido y puede verificarse en una prueba.
- Su mantenimiento y uso justifican el coste de instrumentarlo.
Evita nombres ambiguos como “acción”, “interacción” o “éxito” si no tienen una definición compartida. Un nombre claro y estable, como “invitación enviada”, facilita que producto, analítica e ingeniería entiendan el dato del mismo modo.
Separa eventos, propiedades y contexto
El evento describe qué ocurrió. Las propiedades añaden detalles del hecho: por ejemplo, el tipo de elemento seleccionado o el resultado de una operación, siempre que esos valores ayuden a interpretar la pregunta. El contexto de usuario o sesión permite analizar quién realizó la acción o en qué circunstancias, pero no debería añadirse por defecto.
Para cada propiedad, pregunta qué comparación habilita y si esa comparación cambiaría una decisión. Una propiedad con valores libres, inconsistentes o casi siempre vacíos puede añadir complejidad sin aportar diagnóstico. Define tipos y valores permitidos cuando sea pertinente; aclara también si un dato puede faltar y qué significa esa ausencia.
Recopila solo el contexto necesario. Los datos personales o sensibles requieren especial cuidado: revisa la finalidad, los permisos, las políticas aplicables y quién puede acceder a ellos. No incluyas información identificable en nombres o propiedades de eventos por comodidad. Si basta con una categoría o un estado, evita capturar el valor original.
Una ficha breve por evento puede registrar el nombre, propósito, condición de activación, propiedades, excepciones, responsable y preguntas que pretende responder. No hace falta convertir cada evento en un documento extenso; sí importa que otra persona pueda interpretar su significado sin depender de quien lo implementó.
Prioriza por valor de decisión y coste de mantenimiento
El coste de un evento no termina cuando se publica. Alguien debe mantener su definición cuando cambia la interfaz, revisar que siga llegando y explicar sus límites en análisis posteriores. Por eso, conviene ordenar candidatos en lugar de instrumentarlos todos a la vez.
- Valora la decisión: identifica cuán importante es la pregunta y qué acción habilitaría la respuesta.
- Comprueba la observabilidad: confirma que el comportamiento puede detectarse de manera fiable y en el punto correcto del sistema.
- Estima el coste: considera implementación, validación, permisos, volumen de datos y mantenimiento futuro.
- Empieza por lo mínimo suficiente: registra los eventos y propiedades necesarios para distinguir los escenarios relevantes.
Si una pregunta tiene alto valor, pero no puede responderse con la instrumentación disponible, documenta la limitación y decide si conviene mejorarla. Si tiene poco valor o no existe una acción asociada, aplázala. Esta priorización evita que “quizá algún día sirva” se convierta en la razón habitual para añadir datos.
Valida recorridos completos y busca señales de ruido
Antes de usar los datos para decidir, prueba los recorridos importantes en condiciones representativas. Comprueba que el evento aparece una sola vez cuando corresponde, que se activa después del resultado previsto y que las propiedades coinciden con lo ocurrido. Incluye casos alternativos: errores, cancelaciones, reintentos, navegación atrás y cambios de estado.
Un evento que falta en determinados dispositivos o caminos produce conclusiones sesgadas. Uno que se dispara dos veces puede inflar conversiones. También es una señal de alerta que distintos equipos usen el mismo nombre para cosas diferentes o que una propiedad cambie de significado sin cambiar su definición.
Para detectar estos problemas, revisa muestras de eventos junto con recorridos reales de prueba y compara los datos con el comportamiento esperado. Cuando haya discrepancias, identifica primero dónde nace el problema: en la definición, la implementación, la transmisión o la interpretación. No corrijas una cifra en un informe sin resolver la causa, porque el mismo error puede reaparecer en otros análisis.
Revisa el esquema cuando cambia el producto
La instrumentación no es un proyecto que se completa una vez. Un cambio de flujo, permisos o modelo de negocio puede alterar lo que significa un evento. Antes de modificarlo, revisa qué análisis dependen de él y si mantener el nombre conservaría el mismo significado. Si cambia el comportamiento representado, documenta la transición y evita mezclar periodos incompatibles sin advertencia.
Programa revisiones vinculadas a cambios relevantes y a preguntas de producto. Retira eventos que ya no se usan, corrige definiciones obsoletas y asigna responsables para los que sostienen decisiones importantes. El objetivo no es tener el esquema más pequeño a cualquier precio: es conservar una medición comprensible, proporcionada y fiable.
En resumen, una buena instrumentación empieza con una decisión, registra comportamientos observables y añade solo el contexto que permita interpretarlos. Define los casos límite, prueba los recorridos y revisa el esquema al evolucionar el producto. Así, cada evento tiene una razón para existir y los datos resultan más útiles para actuar.