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.
Una convención de nombres que puedes copiar
La mayoría de los equipos no necesitan inventar una convención, solo ponerla por escrito. Esta es lo bastante corta para recordarla y lo bastante estricta para que el catálogo siga siendo fácil de buscar:
| Regla | Sí | No |
|---|---|---|
| Primero el objeto, después la acción | invite_sent | sent_invite |
| En pasado, porque ya ocurrió | project_created | create_project |
| En minúsculas con guiones bajos | plan_upgraded | PlanUpgraded, plan-upgraded |
| Nombra el resultado, no el control | report_exported | export_button_clicked |
| Las variantes van en propiedades | report_exported con format: csv | report_exported_csv |
| Nada de datos personales en nombres ni valores | plan: team | email: ana@acme.com |
Pon la convención al principio del plan de tracking y revisa cada evento nuevo con ella, igual que revisas el código con una guía de estilo. Un mal nombre se paga cada vez que alguien busca el evento y no lo encuentra.
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.
Un ejemplo práctico: un plan de tracking para una aplicación SaaS B2B
Así se ven doce eventos en un producto SaaS típico basado en equipos. Cada uno existe porque responde a una pregunta que alguien ya hace en una revisión semanal.
| Evento | Se dispara cuando | Propiedades clave | La pregunta que responde |
|---|---|---|---|
signup_completed | La cuenta existe, no cuando se envía el formulario | source | ¿Qué canales traen a gente que de verdad termina? |
workspace_created | Se guarda el primer espacio de trabajo | team_size | ¿Cuántos registros llegan a configurar algo? |
teammate_invited | Se envía una invitación | role | ¿La cuenta se extiende más allá de una persona? |
invite_accepted | La persona invitada se une | role | ¿Las invitaciones se convierten en compañeros? |
integration_connected | Una conexión se completa con éxito | integration | ¿Qué integraciones usan los equipos que se quedan? |
project_created | Se guarda un proyecto | template | ¿Se está creando siquiera el objeto principal? |
report_viewed | Un informe termina de renderizarse | report_type | ¿Qué vuelve la gente a consultar? |
report_exported | Se genera el archivo | format | ¿El resultado sale del producto? |
plan_upgraded | La facturación confirma el cambio | from_plan, to_plan | ¿Qué pasa justo antes de que la gente pague más? |
payment_failed | El proveedor de pagos informa de un fallo | reason | ¿Cuánto churn es involuntario? |
subscription_cancelled | La cancelación se hace efectiva | reason | ¿Por qué se van los equipos? |
feedback_submitted | Se envía el formulario de feedback | category | ¿Qué piden los usuarios, con sus propias palabras? |
Hay dos cosas que merece la pena notar. La mayoría de estos eventos se disparan con un resultado, no con un clic: una invitación puede recibir un clic y aun así fallar. Y los eventos de facturación no ocurren en el navegador. Llegan desde los webhooks de tu proveedor de pagos, así que una analítica que solo mira el navegador nunca los verá. No pasa nada mientras nadie trate un clic en «Mejorar plan» como ingresos.
La activación suele ser una combinación de estos eventos y no uno solo, por ejemplo un espacio de trabajo creado y un compañero invitado durante la primera semana. Elige esa definición a propósito; benchmarks del embudo de activación explica cómo.
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.
Errores de seguimiento de eventos que rompen los informes sin avisar
- Disparar con el clic en lugar de con el resultado. Un clic en «Exportar» no es una exportación. Si la petición falla, el evento ya ha mentido. Envía los eventos de resultado cuando la acción haya tenido éxito.
- Disparos dobles en aplicaciones de una sola página. Un componente que se vuelve a renderizar o una ruta que se monta dos veces puede enviar el mismo evento dos veces. Revisa algunas sesiones a mano antes de fiarte de un recuento.
- Datos personales en las propiedades. Los emails, los nombres y las URL con tokens en la query string acaban en cada informe y cada exportación. Envía un ID o una categoría en su lugar.
- Rastrear antes del consentimiento. Donde se aplica el RGPD, la analítica no debería empezar hasta que el visitante acepte. Es una propiedad de tu configuración y no de cada evento, así que resuélvelo una vez, con un gestor de consentimiento de cookies que retenga el seguimiento hasta entonces.
- Cambiar lo que significa un evento sin renombrarlo. Si
project_createdempieza a contar proyectos duplicados, todos los gráficos de antes y después del cambio discrepan y nadie sabe por qué. Un significado nuevo lleva un nombre nuevo, o una propiedad que distinga ambos. - Eventos sin responsable. Cada evento del plan necesita una persona que note cuándo deja de dispararse. Los eventos sin responsable son los primeros en degradarse y los que más tiempo siguen pareciendo fiables.
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.
Definir eventos a posteriori
La captura automática cambia la pregunta de «¿nos acordamos de instrumentar esto?» a «¿podemos encontrarlo en lo que se capturó?». PulsePanda registra cada clic con el id del elemento, sus clases, su texto visible, su etiqueta y su posición en la página, así que un evento se puede definir más tarde a partir de esos datos, y la definición se aplica a los clics capturados antes de que existiera. Una pregunta hecha el jueves se puede responder con los datos del lunes.
Lo que lo hace fiable es un punto de enganche estable en el marcado. Las clases cambian con cada rediseño y el texto visible con cada ajuste de copy y cada traducción. Un id en el puñado de controles que importan solo cambia cuando alguien decide que debe cambiar:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/es/billing">Upgrade</a>Un evento definido como los clics en #export-report sobrevive a un rediseño, y un clic en el icono o la etiqueta dentro del botón sigue contando, porque la ruta registrada sube hasta el elemento más cercano con id.
Un evento definido sigue siendo un clic, con el límite descrito antes: te dice que alguien lo intentó, no que funcionara. Para los resultados, la señal más honesta suele ser la página a la que lleva el éxito. Un paso de embudo «llegó a /onboarding» después de «llegó a /signup» cuenta los registros completados sin ningún evento.
Cómo comprobar un evento antes de fiarte de él
- Dispáralo tú mismo y busca tu propia sesión. El evento debería aparecer una vez, con todas las propiedades rellenas.
- Compara el recuento con una fuente de verdad. Si la base de datos dice que la semana pasada se crearon 140 proyectos y la analítica dice 95, encuentra la diferencia antes de que alguien construya un gráfico con ella. Los bloqueadores de anuncios, el consentimiento y las peticiones fallidas hacen que los recuentos del navegador sean menores que los del servidor. La diferencia debería ser estable, no una sorpresa.
- Mira una repetición de sesión en la que se disparó. Un número te dice que ocurrió; una grabación te dice que ocurrió cuando crees que ocurrió.
- Ponlo en un embudo. Un evento que aparece sin el paso que debe precederlo se está disparando desde el sitio equivocado.
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.