Un evento es una decisión que tomaste, no algo que ocurrió
Todo producto emite una cantidad ilimitada de cosas que ocurren: clics, desplazamientos, pasos del cursor, cambios de ruta. Un evento es el pequeño subconjunto que decidiste que merecía un nombre, porque te dice algo sobre lo que actuarías. Esa decisión, y no la instrumentación, es todo el trabajo.
La consecuencia práctica es que un plan de medición es un documento de producto antes que de ingeniería. Si no puedes decir qué harías distinto según si un evento se dispara o no, todavía no necesita existir.
Nombra los eventos por resultados, no por interfaces
clicked_blue_button deja de ser cierto en cuanto diseño publica un rediseño. report_exported lo sobrevive, porque nombra lo que el usuario consiguió y no lo que tocó.
Elige una convención y mantenla: objeto primero, acción en pasado, minúsculas con guiones bajos — invite_sent, project_created, payment_failed. La consistencia importa más que cuál elegiste, porque los nombres inconsistentes son lo que vuelve inservible un catálogo de eventos dos trimestres después.
De diez a veinte eventos, no doscientos
El fallo habitual es registrarlo todo con la teoría de que los datos podrían servir más adelante. Lo que obtienes es un catálogo por el que nadie sabe moverse, tres eventos que significan casi lo mismo y ningún acuerdo sobre cuál manda.
Parte de las preguntas que ya haces en las revisiones — ¿la gente termina de configurarse, vuelve, dónde se rinde? — e instrumenta solo lo que las responde. Un plan de medición que cabe en una pantalla se mantiene. Uno que cabe en una hoja de cálculo, no.
Las propiedades llevan el detalle; el evento lleva el verbo
Resístete a crear un evento por variante. report_exported_csv, report_exported_pdf y report_exported_xlsx deberían ser un solo evento, report_exported, con una propiedad format. La regla práctica: si alguna vez querrías ver las cifras sumadas, es un evento con una propiedad.
Mantén los valores de las propiedades con baja cardinalidad y estables. Una propiedad que guarda una URL en bruto o texto libre es una columna que no puedes agrupar, y eso la convierte en decoración en vez de en dato.
La autocaptura y los eventos explícitos responden preguntas distintas
La autocaptura registra interacciones de interfaz sin pedirte que planifiques, lo que resulta genuinamente útil al principio: significa que los datos de una pregunta que aún no se te había ocurrido ya están ahí, y saca el despliegue del bucle. Lo que no puede hacer es conocer tu dominio. Nada en un flujo de clics sabe que se mejoró una suscripción.
El arreglo que funciona es tener ambos: autocaptura para explorar y para las preguntas que aún no has hecho, y una lista corta de eventos explícitos y bien nombrados para las cifras sobre las que informas y fijas objetivos.
Por dónde empezar esta semana
Escribe los cinco momentos que más importan en tu producto, nómbralos con la convención de arriba e instrumenta solo esos. Comprueba una semana después que cada uno se dispara cuando esperas y que sus propiedades vienen rellenas — un evento que se dispara en una ruta de código que nadie usa es peor que ningún evento, porque se confiará en él.
Si quieres ver cómo se comportan los eventos que ya envías antes de añadir más, el seguimiento de eventos en PulsePanda muestra cada evento, su volumen y sus propiedades en un solo lugar, y lleva esos mismos datos directamente a los embudos y las rutas.