Qué es un plan de tracking
Un plan de tracking es un único documento que enumera cada evento que registra tu producto, las propiedades asociadas a cada uno, el momento exacto en que se dispara y la persona responsable. Es el contrato entre el código que emite los datos y los paneles que los leen. Trátalo como una especificación viva que cambia con el producto, no como un documento que escribes una vez y olvidas. Para la versión en una línea, consulta plan de tracking; esta guía explica cómo crear uno.
Por qué un plan es mejor que el tracking improvisado
Sin un plan, el tracking se va acumulando. Un desarrollador dispara signup, otro dispara Sign Up, un tercero dispara user_registered: tres nombres para una misma acción, y cada embudo que pasa por el registro se divide o se rompe sin avisar. Eso es la deriva, y es la principal razón por la que la analítica deja de inspirar confianza. Un plan fija el vocabulario antes de que se publique el código, para que las cifras que consultes dentro de seis meses sigan significando lo que crees. Los eventos limpios y coherentes también son la base de una hoja de ruta de experimentación: no puedes medir un test contra una métrica que registras de tres formas distintas.
Nombra los eventos como object_action y no te muevas de ahí
La convención que recomiendan la mayoría de las herramientas de analítica es object_action: el objeto y luego lo que le ocurrió, como subscription_started, invite_sent o checkout_completed. Segment, Amplitude y PostHog describen cada uno una variante (Segment usa “Object Action”, PostHog snake_case en minúsculas y Amplitude un sustantivo más un verbo en pasado). Las mayúsculas exactas importan mucho menos que elegir una y no romperla nunca. Dos reglas aportan casi todo el valor: mantén coherente el tiempo verbal y nunca construyas nombres de evento de forma dinámica; un evento llamado plan_${name}_upgraded crea un evento por cliente y no se puede consultar.
Los 8–10 eventos que trazan tu embudo
Resiste la tentación de registrarlo todo. Empieza con el puñado de eventos que siguen a un usuario desde el primer contacto hasta el pago —registro, activación e ingresos— y regístralos bien antes de añadir profundidad. Abajo tienes un conjunto inicial para un SaaS B2B típico; cámbiales el nombre por los sustantivos de tu producto. Cada uno se convierte en una fila de tu plan y, juntos, forman tu primer conjunto de datos first-party: la materia prima de cada embudo, cohorte y curva de retención que construyas. Dónde se registra cada evento, en el navegador o en el servidor, es una decisión aparte: tracking server-side vs. client-side explica el reparto.
| Evento | Cuándo se dispara | Por qué importa |
|---|---|---|
| account_created | El usuario termina el registro y su cuenta ya existe en la base de datos | Parte alta del embudo; el denominador de cada tasa de conversión |
| onboarding_started | El usuario entra en el flujo de primer uso | Separa a quienes empiezan la configuración de quienes abandonan |
| activation_reached | El usuario llega a tu momento aha definido (p. ej. primer proyecto compartido) | El evento temprano con más poder predictivo; valídalo, no lo des por hecho |
| feature_used | Se usa una funcionalidad clave, con una propiedad feature_name | Profundidad del engagement; input para segmentos y retención |
| invite_sent | El usuario invita a un compañero | Indicador adelantado de expansión y de enganche en B2B |
| trial_started | Empieza una prueba o un plan gratuito | Abre el embudo de ingresos; ancla la tasa de prueba a pago |
| subscription_started | El usuario pasa a un plan de pago | El momento de los ingresos; vincula el trabajo de growth con el dinero |
| subscription_cancelled | El usuario cancela un plan de pago | Señal de churn; alimenta la recuperación y el análisis de retención |
Las propiedades llevan el detalle; los responsables lo mantienen limpio
Mantén pocos eventos y genéricos; lleva los detalles a las propiedades. En lugar de un evento distinto para cada plan, dispara subscription_started con las propiedades plan_name y amount_usd: un solo evento, bien descrito, sigue siendo consultable. Mantén ligero el conjunto de propiedades de cada evento: un puñado que de verdad consultas vale más que decenas que nunca miras. Después decide quién es responsable: en la mayoría de los equipos pequeños recae en un Growth Engineer o en quien se encargue de la instrumentación, y cada evento nuevo debería pasar por esa persona para que el plan y el código nunca diverjan. Por último, ten claro dónde acaban los eventos. Enviarlos a una herramienta de analítica alojada o a un CDP es rápido, pero pone tus datos de comportamiento en los servidores de otro; mantenerlos first-party —Postgres autoalojado, tu propio data warehouse— hace que sigan siendo tuyos, y ese es el dilema central entre código abierto y SaaS en las herramientas de engagement.