Cómo el seguimiento de eventos registra lo que los usuarios hicieron de verdad

¿Qué es el seguimiento de eventos en analítica de producto?

Las herramientas de analítica de producto usan el seguimiento de eventos para registrar acciones de usuario con nombre, como signup_completed o checkout_started, junto con propiedades que describen cada acción, lo que convierte los datos de tráfico por página en un registro de lo que la gente hizo de verdad. Una página vista dice que alguien llegó a la pantalla de checkout. Un evento dice que empezó el checkout, en el plan anual de equipo, desde la página de precios, y que nunca volvió. Flowsery incluye seguimiento de objetivos y eventos junto a su analítica web integrada, así que la misma cuenta guarda las cifras de tráfico y el registro a nivel de acción.

¿Cuáles son las dos partes de un evento?

Un evento tiene un nombre y un conjunto de propiedades, y el reparto entre ambos decide si los datos siguen siendo consultables un año después. El nombre identifica la acción y se mantiene constante en cada ocurrencia. Las propiedades llevan las partes que cambian de una ocurrencia a otra: qué plan, qué fuente, cuánto, cuánto tiempo. Pon la acción en el nombre y las variables en las propiedades, y cada pregunta sobre esa acción se convierte en un filtro en lugar de en un evento nuevo.

Cinco eventos con buenas propiedades responden más preguntas que cincuenta eventos sin ninguna. Esos cinco sostienen un embudo de registro, una comparación de checkout plan por plan, un informe de cupones y una métrica de expansión de equipo sin una sola llamada de tracking adicional. Los nombres de propiedad de esa tabla siguen el patrón object_adjective que PostHog documenta en sus buenas prácticas de analítica de producto, con is_ reservado para los booleanos.

¿Cómo se ve un evento mal nombrado junto a uno bien nombrado?

Un evento mal nombrado empuja el detalle variable dentro del nombre, lo que bifurca una acción en un evento nuevo por cada combinación. Aquí está el mismo registro, medido de dos formas.

// Mal medido: el plan y la página están incrustados en el nombre
track("Clicked Signup Button On Pricing Page Annual");
track("clicked_signup_button_on_pricing_page_monthly");
track("Signup Btn - Homepage");
 
// Bien medido: un nombre estable, las variables como propiedades
track("signup_completed", {
  signup_source: "pricing_page",
  plan_slug: "team_annual",
  is_invited: false
});

El primer bloque produce tres nombres de evento para una acción, así que la respuesta a "cuánta gente se registró la semana pasada" es una suma manual que se rompe en cuanto alguien añade una cuarta página de precios. El segundo bloque produce un nombre de evento y tres filtros. Pídele a alguien de marketing que diga la acción en voz alta, y comprueba después que todo lo que dijo tras el verbo acabó en una propiedad y no en el nombre.

¿Qué convención de nomenclatura de eventos debería elegir un equipo?

La convención que funciona es la que está escrita y se aplica a todos los eventos, y las dos convenciones publicadas no coinciden en los detalles. Las buenas prácticas de analítica de producto de PostHog piden snake_case en minúsculas, verbos en presente y una estructura category:object_action, como account_settings:forgot_password_button_click. El playbook de planificación de datos de Amplitude pide Title Case, es decir mayúscula inicial en cada palabra, con una estructura [Noun] + [Past-Tense Verb] como Song Played, mantenida desde la perspectiva del usuario, de modo que Message Sent significa que el usuario lo envió.

Las dos funcionan. Mezclarlas no, porque Signup Completed, signup_completed y signup:button_click se convierten en tres filas sin relación dentro de la misma lista. Los ejemplos de este post usan snake_case con verbos en pasado, que se lee como objeto y luego acción y ordena alfabéticamente juntos todos los eventos relacionados: checkout_completed cae al lado de checkout_started.

Debajo de cualquier convención que elijas hay una restricción dura. Los límites de recogida de eventos de GA4 de Google limitan el nombre de un evento a 40 caracteres, permiten 25 parámetros de evento por evento, limitan el nombre de un parámetro a 40 caracteres y la mayoría de valores de parámetro a 100 caracteres, y no ponen límite al número de eventos con nombres distintos en los flujos de datos web, mientras que limitan los flujos de datos de app a 500 por usuario de la app. Un nombre category:object_action más un sustantivo largo choca contra ese techo de 40 caracteres antes de lo que los equipos esperan, y GA4 deja de reportar en silencio un nombre demasiado largo como evento clave.

¿En qué se diferencia el seguimiento de eventos de autocapture?

El seguimiento de eventos nombra la acción en el código de la aplicación antes de que salga, mientras que autocapture registra cada clic y cada envío de formulario de forma automática y te deja definir el significado después, a partir de la estructura de la página. Autocapture le da a un equipo un flujo funcionando el primer día y se rompe en silencio cuando un rediseño cambia el selector CSS con el que hacía coincidencia. Un evento con nombre se mueve con el código en el que vive, así que renombrar un componente arrastra consigo la llamada de tracking. La mayoría de los equipos usan ambos: autocapture para la cola larga exploratoria, eventos con nombre para las cifras que aparecen en una presentación al consejo.

¿Cómo convierten las propiedades los eventos en un embudo?

Dos eventos con una propiedad compartida se convierten en un paso de conversión, que es como se construye un embudo de conversión a partir de datos de evento en bruto. La tasa de finalización de un paso es una sola división:

step conversion rate = completed events / started events x 100

Con 4,000 eventos checkout_started y 1,240 eventos checkout_completed en una semana, el paso de checkout convierte al 31 por ciento. Añade plan_slug como desglose y ese número único se parte en una tasa por plan, que es donde aparece el problema de verdad. Las propiedades son también aquello con lo que se construyen las dimensiones personalizadas, así que el esquema que diseñas para los eventos es el mismo esquema por el que segmentarán tus informes después.

¿Cuántos eventos debería instrumentar un equipo?

Instrumenta las acciones que aparecen en una decisión, y para. Un evento que nadie ha filtrado en tres meses es deuda de esquema: consume cuota, ensucia el selector de eventos y se degrada sin que nadie se dé cuenta. Empieza por los pasos del camino hacia los ingresos, añade las acciones que separan una cuenta retenida de una que se fue, y añade después eventos nuevos cuando una pregunta concreta no tenga datos detrás.

Un esquema más pequeño también mantiene pequeña la superficie de privacidad. Flowsery funciona sin cookies y alojado en la UE por diseño, y las propiedades que un equipo decide no enviar son las que nunca necesitan una política de retención. Los equipos que sopesan ese equilibrio frente a una configuración centrada en Google pueden leer la comparativa entre analítica con privacidad y GA4.

¿Cómo compruebas que un evento se dispara correctamente?

Dispara la acción tú mismo y confirma después que el evento llegó con el nombre correcto y las propiedades correctas antes de fiarte de cualquier gráfico construido sobre él. El fallo que más cuesta es un evento que se dispara con una propiedad nula o mal escrita, ya que el recuento parece sano mientras todos los desgloses pierden filas en silencio. Ver una sesión real junto al flujo de eventos capta el desajuste de una forma que un panel no puede: Flowsery graba cada sesión de usuario y se conecta a los replays de PostHog o Amplitude ya grabados, sin reinstrumentar nada, así que el replay y el log de eventos quedan uno al lado del otro.

Repite esa comprobación después de cada release de front-end que toque un flujo medido. Un evento que dejó de dispararse produce una línea plana, y una línea plana parece un problema de producto hasta que alguien abre el código.

Preguntas frecuentes

¿Qué es un evento en analítica?

Un evento es una sola acción con nombre que hizo un usuario, registrada con una marca de tiempo y un conjunto de propiedades que la describen. checkout_started con plan_slug: team_annual es un evento. Una página vista es un tipo concreto de evento, registrado automáticamente por la mayoría de scripts de analítica.

¿Cuál es la diferencia entre el nombre de un evento y una propiedad del evento?

El nombre identifica la acción y se mantiene idéntico en cada ocurrencia, para que se pueda contar. La propiedad lleva el detalle que cambia entre ocurrencias, para que se pueda filtrar y agrupar. Cualquier cosa por la que quisieras filtrar pertenece a una propiedad, nunca al nombre.

¿Los nombres de evento deberían usar pasado o presente?

Las dos convenciones están publicadas y las dos funcionan, así que elige una y hazla cumplir. El playbook de planificación de datos de Amplitude documenta Title Case con verbos en pasado, y las buenas prácticas de PostHog documentan snake_case en minúsculas con verbos en presente. El coste de cambiar a mitad de camino son dos conjuntos de nombres describiendo las mismas acciones.

¿Cuántas propiedades debería llevar un solo evento?

Envía las propiedades por las que filtrarías o agruparías, y sáltate el resto. GA4 permite 25 parámetros de evento por evento según los límites de recogida de eventos de Google, lo que es un techo y no un objetivo. De cinco a ocho propiedades bien elegidas en un evento central cubren la mayoría de preguntas de reporting.

¿El seguimiento de eventos necesita cookies?

No. Registrar que una acción ocurrió no necesita ninguna cookie, ya que una cookie existe para persistir la identidad entre visitas y no para capturar la acción en sí. Flowsery funciona sin cookies y alojado en la UE, y aun así registra eventos con sus propiedades.

¿Qué rompe un esquema de eventos con el tiempo?

Eventos renombrados, eventos añadidos sobre la marcha sin convención, y propiedades que dejan de rellenarse tras una refactorización. Cada una deja el gráfico con buen aspecto mientras los datos de debajo se desvían. Una convención de nomenclatura escrita, más una comprobación tras cada release en los flujos medidos, previene casi todo.

¿Qué es la deuda de esquema en el seguimiento de eventos?

La deuda de esquema es un evento que nadie ha filtrado en tres meses. Consume cuota, satura el selector de eventos y se degrada sin que nadie lo note, hasta que alguien audita el esquema.

¿Puede autocapture sustituir a los eventos nombrados?

La mayoría de los equipos usan ambos en lugar de elegir uno. Autocapture cubre la cola larga exploratoria y da a un equipo un flujo funcional desde el primer día, pero se rompe en silencio cuando un rediseño cambia el selector CSS que estaba usando. Los eventos nombrados cubren las cifras que aparecen en un informe para dirección, porque renombrar un componente arrastra la llamada de tracking junto con el código en el que vive.

¿Cuál es el límite de caracteres de GA4 para el nombre de un evento?

Google limita el nombre de un evento en GA4 a 40 caracteres y también limita el nombre de un parámetro a 40 caracteres, con la mayoría de los valores de parámetro topados en 100 caracteres. Una estructura category:object_action más un sustantivo largo choca con ese límite antes de lo que los equipos esperan, y GA4 deja de reportar en silencio un nombre demasiado largo como evento clave.

¿Cómo se calcula la tasa de conversión de un funnel a partir de eventos?

Divide los eventos completados entre los eventos iniciados y multiplica por 100. Con 4.000 eventos checkout_started y 1.240 eventos checkout_completed en una semana, el paso de checkout convierte al 31 por ciento. Desglosar esa cifra por una propiedad como plan_slug convierte una tasa única en una tasa por plan.