Qué va en un plan de tracking y qué no puede detectar

¿Qué es un plan de tracking?

En analítica de producto, un plan de tracking es la especificación escrita que lista cada evento que envía un producto, el momento exacto en que se dispara cada uno, las propiedades que lleva con sus tipos, la fuente que lo emite y la persona responsable, acordada antes de que nadie escriba código de instrumentación. La documentación de Protocols de Segment lo define como "a data spec outlining the events and properties you intend to collect across your Segment Sources." La versión de Amplitude añade el motivo de cada fila: "A tracking plan defines every event and property you collect, why you collect each one, and which source emits it."

El plan es el contrato y el código de tracking es la implementación. Cuando los dos no coinciden, alguien tiene que decidir cuál está mal, y sin plan no hay nada contra lo que comprobar el código. El seguimiento de eventos es la práctica de registrar lo que hicieron los usuarios. El plan de tracking es el documento que dice qué significa "hizo" en cada evento.

¿Qué columnas necesita un plan de tracking?

Un plan de tracking necesita una fila por evento y columnas suficientes para que un ingeniero pueda implementar el evento sin hacer ninguna pregunta. Las columnas de abajo son las que evitan discusiones reales más adelante. El editor de Tracking Plan de Segment usa un subconjunto de ellas, llamadas Name, Description, Status, Data Type y Permitted Values.

La lista de tipos de datos de Segment es un buen punto de partida para la columna Tipo: "any, array, object, boolean, integer, number, string, null, Date time", con las fechas y horas "required to be in ISO-8601 format." Su columna Permitted Values acepta "simple regular expressions to validate property values", y eso solo funciona con propiedades de tipo string.

¿Cómo se ve una fila rellena de un plan de tracking?

Una fila rellena se lee como una pequeña especificación. Aquí tienes un evento de un flujo de registro SaaS, escrito como lo guardaría un plan almacenado en un repositorio:

event: signup_completed
trigger: >
  Fires once, from the server, after the account row is written.
  Not on button click. Not on page load of /welcome.
answers: Signup-to-activation funnel, weekly signups by channel
source: backend
owner: growth-eng
status: live
properties:
  plan:
    type: string
    required: true
    allowed: [team, pro]
  signup_method:
    type: string
    required: true
    allowed: [email, google, github]
  invited:
    type: boolean
    required: false

El texto del disparador es la parte que la mayoría de los planes hacen mal. "Se dispara al registrarse" no dice si cuenta un envío fallido del formulario, si un reintento lo dispara dos veces ni si el evento viene del navegador o del servidor. Escribir "no al hacer clic en el botón" descarta el duplicado más habitual, en el que el clic dispara el evento y luego el servidor rechaza el formulario. El estilo de los nombres es una decisión aparte, y elegir una convención de nombres de eventos antes de la primera fila te ahorra un cambio de nombre más adelante.

¿Qué puede validar una herramienta de plan de tracking y qué no?

Una herramienta de plan de tracking valida los eventos que llegan contra los eventos que describe el plan, y no puede decirte nada de los eventos que nunca llegan. Esa segunda mitad es lo más útil que hay que saber sobre estas herramientas, y los propios proveedores lo dicen.

La documentación de Segment describe la parte de comprobación: "Violations generate when an event doesn't match the spec'd event in the Tracking Plan." Y después, en la descripción de la columna Status: "You can't require a Track call because Segment is unable to verify when a Track call should be fired." Segment puede comprobar que un evento lleva sus propiedades obligatorias, pero no tiene forma de saber que el evento debería haberse disparado y no lo hizo.

Amplitude se ocupa de la dirección contraria. Los eventos que llegan sin estar en el plan aparecen como "Unexpected", y Amplitude dice "You can add them to your plan, or delete them to stop ingestion and remove them from your data catalog." Para la dirección de los que faltan, Amplitude publica una guía aparte titulada "Planned events that never arrived: confirm the problem", que te indica "Compare your tracking plan with observed data and your planning records to find planned events that never reached Amplitude." La misma página dice "Data Assistant doesn't identify these entries" y que Observe, la vista que muestra si un evento llegó, cubre "the selected time range, up to 14 days."

Así que un panel de validación en verde significa que cada evento que llegó cumplía su especificación. No significa que esté llegando cada evento de la especificación. La solución práctica es una comprobación por release. Lista los eventos marcados como activos en el plan, consulta los datos recientes de cada nombre y marca los que tengan un recuento de cero. La guía de Amplitude añade la precaución correcta: un evento sin actividad "might belong to a rare workflow, a disabled feature, or a future release", así que pregunta al responsable antes de borrar la fila.

¿Qué límites de destino deben estar en el plan?

Los límites de cada herramienta a la que fluyen los eventos deben estar en el plan, porque una fila que rompe un límite falla sin avisar en el destino. Google Analytics lo dice claramente: "Google Analytics doesn't log events, event parameters, and user properties that exceed the following limits."

Las dos herramientas fallan de forma distinta cuando un plan las supera. GA4 descarta el elemento: su ejemplo es que "Analytics doesn't process the 26th user property nor does it process an event name with more than 40 characters." Amplitude sigue ingiriendo pero "stops indexing new values", así que los datos existen en las exportaciones pero no se pueden consultar en los gráficos. Amplitude añade que los eventos que pasan su límite de tipos de evento "still count toward the monthly event volume", lo que significa que un bug de instrumentación descontrolado cuesta dinero por datos que nadie puede representar en un gráfico.

Segment tiene su propio límite para los planes gestionados como archivos: un CSV de Tracking Plan subido "must be smaller than 15 mb", y debe "have fewer than 100,000 rows and 2,000 rules."

¿Cuántos eventos debería tener la primera versión?

La primera versión debería tener los pocos eventos que responden a las preguntas que el equipo ya se hace cada semana, y nada más. La guía de implementación de Amplitude dice "resist the urge to track everything upfront" y sugiere "starting with two important events in your product to give you initial insights." Su playbook de taxonomía ordena el trabajo así: primero los objetivos de negocio, después las métricas clave y después los eventos y propiedades que esas métricas necesitan.

Ese orden es el correcto. Parte de la métrica de la revisión semanal, como la métrica north star, escribe la pregunta que plantea y añade solo los eventos necesarios para responderla. Un flujo de registro que necesita un análisis de embudos necesita un evento por paso y una propiedad que divida el resultado, no cuarenta eventos para cada clic de la página. Si usas Flowsery, su seguimiento de objetivos "captura registros, compras, descargas y eventos personalizados en un solo lugar", y el plan es donde decides cuáles de esos objetivos vale la pena definir.

¿Cómo mantienes al día un plan de tracking?

Un plan de tracking se mantiene al día cuando un cambio en el código de tracking no puede fusionarse sin el cambio correspondiente en el plan. Todo lo demás es un recordatorio que la gente ignora.

La columna Estado hace la mayor parte del trabajo. Marcar un evento como obsoleto en lugar de borrar su fila evita que un ingeniero nuevo vuelva a introducir el nombre antiguo seis meses después. Las dos herramientas guardan historial. Segment dice que los cambios del plan hechos mediante subida quedan "reflected in the Audit Trail and Tracking Plan changelog", y su exportación CSV nombra cada archivo workspaceSlug-trackingPlanName--yyyy-mm-dd--hh-mm-utc. Un plan que vive en el repositorio junto al código obtiene el historial gratis gracias al control de versiones.

Preguntas frecuentes

¿Qué diferencia hay entre un plan de tracking y una convención de nombres de eventos?

Una convención de nombres de eventos es una regla dentro de un plan de tracking: cómo se forman los nombres, por ejemplo object_action en snake case. El plan de tracking es la lista completa de eventos que siguen esa regla, con el disparador, las propiedades, los tipos, la fuente y el responsable de cada evento.

¿Quién debería ser responsable del plan de tracking?

Una persona con nombre debería aprobar los cambios, elegida del equipo que más lee los datos, y los ingenieros deberían proponer las filas. Un plan que cualquiera puede editar sin revisión acaba en el mismo estado que no tener plan.

¿Un plan de tracking debería vivir en una hoja de cálculo o en una herramienta?

Una hoja de cálculo sirve para una primera versión con unas pocas decenas de eventos. Una herramienta como Segment Protocols o Amplitude Data añade la validación de los eventos entrantes contra el plan, y un archivo en el repositorio de código añade revisión e historial mediante pull requests.

¿Los eventos de servidor deberían ir en el mismo plan de tracking?

Sí. Mantén un solo plan con una columna Fuente, porque el mismo nombre de evento enviado desde el navegador y desde el servidor cuenta dos veces salvo que el plan diga cuál es el registro válido. La propia definición de plan de tracking de Amplitude incluye "which source emits it".

¿Cómo encuentras eventos planificados que nunca se dispararon?

Compara los eventos marcados como activos en el plan con los nombres de evento que aparecen en los datos recientes, y marca los que tengan un recuento de cero. Segment afirma que no puede exigir una llamada Track, y Amplitude dice que su Data Assistant no identifica estas entradas, así que ningún panel de validación señala el problema por sí solo.

¿El autocapture elimina la necesidad de un plan de tracking?

No. El autocapture registra clics y páginas vistas, pero no registra qué significaba un clic, como qué plan eligió un usuario o si el servidor aceptó el formulario. Los eventos que alimentan las métricas de ingresos y de activación siguen necesitando un disparador escrito y una lista de propiedades.

¿Qué debe decir la columna de trigger?

Debe nombrar el único momento en que se dispara el evento, en palabras simples, incluido lo que no cuenta. "Se dispara al registrarse" no aclara si cuenta un envío fallido o un reintento, ni si lo envía el navegador o el servidor. "Se dispara una vez, desde el servidor, tras escribir la fila de la cuenta. No al hacer clic en el botón" no deja nada por adivinar.

¿Con cuántos eventos debería empezar un plan de tracking?

Empieza con los pocos eventos que responden preguntas que el equipo hace cada semana. La guía de implementación de Amplitude dice "resist the urge to track everything upfront" y sugiere empezar con dos eventos importantes. Añade más solo cuando una métrica los necesite.

¿Qué pasa cuando un plan supera los límites de GA4 o Amplitude?

GA4 descarta el elemento, así que una propiedad de usuario número 26 o un nombre de evento de más de 40 caracteres nunca se procesa. Amplitude sigue ingiriendo datos, pero deja de indexar valores nuevos, así que aparecen en las exportaciones y no se pueden consultar en gráficos. Los eventos que superan su límite de tipos de evento siguen contando para el volumen mensual de eventos.

¿Por qué marcar un evento como deprecated en vez de borrar la fila?

Una fila deprecated evita que un ingeniero nuevo reintroduzca el nombre antiguo meses después. Además, el historial se queda en el plan. Antes de borrar la fila de un evento sin actividad, pregunta al responsable, porque el evento "might belong to a rare workflow, a disabled feature, or a future release".