¿Qué va en un plan de tracking?
Como mínimo, una fila por evento: el nombre del evento, las propiedades que lleva, el momento exacto en que se dispara y la persona responsable. Los buenos planes también registran qué herramientas reciben el evento y qué pregunta existe para responder: un evento que nadie consulta es mantenimiento sin recompensa. El formato importa menos que el hábito: una hoja de cálculo, un archivo versionado en el repositorio o una herramienta de esquemas como Segment Protocols o Amplitude Data sirven, siempre que el plan se actualice en el mismo pull request que el código de tracking.
¿Cómo deberías nombrar los eventos?
Elige una convención y aplícala en todas partes. La más común es objeto_acción en snake_case: subscription_started, invoice_paid, report_exported. Primero el objeto, para que los eventos relacionados aparezcan juntos al ordenarlos; la acción en pasado, porque el evento registra algo que ya pasó. La convención que elijas importa menos que su uniformidad: Sign Up, signup y user_signed_up en un mismo conjunto de datos son tres eventos que tu herramienta de analítica trata como desconocidos entre sí, y cada gráfico construido sobre ellos está mal.
¿Qué es la deriva del tracking y por qué arruina la analítica?
La deriva es la distancia que se abre entre el plan y lo que el código envía de verdad: un evento cambia de nombre sin que se actualice el plan, una propiedad cambia de tipo, aparece un duplicado con un segundo nombre. Cada cambio es pequeño; juntos hacen que los embudos cuenten de menos, que los segmentos dinámicos dejen de incluir a los usuarios que deberían y que los paneles se conviertan en ficción, y en ese punto el equipo deja de confiar del todo en los datos. La solución es de proceso, no técnica: ningún evento se publica sin una entrada en el plan, y revisar esa entrada forma parte de la revisión de código.
Por qué importa para un equipo de dos personas
Los equipos con poca gente se saltan el plan porque les suena a procesos de una empresa que todavía no son. La lógica va al revés: con dos personas, nadie recuerda en octubre por qué existen a la vez checkout_completed y order_completed. Un plan de una página escrito antes del primer evento cuesta una tarde; es el primer trabajo que hace un growth engineer. Para ver cómo encaja el plan en una configuración completa, del SDK al consentimiento, consulta la guía de datos first-party y tracking.