Taxonomía de eventos: cómo nombrar lo que mide para que sirva

Cuando auditamos una cuenta con problemas de medición, la causa rara vez es una etiqueta rota. Casi siempre es algo más aburrido y más grave: nadie decidió cómo se iban a llamar las cosas. Con el tiempo aparecen tres eventos para la misma acción, dos con el mismo nombre para acciones distintas, y un reporte que ya no se puede comparar con el de hace seis meses.

Una taxonomía de eventos es el acuerdo escrito sobre qué se mide, cómo se llama y qué información lleva cada cosa. Suena a burocracia. En la práctica es lo que decide si dentro de un año usted va a poder responder preguntas sobre este año.

Qué medir: menos de lo que cree

El primer impulso es medir todo. Es un error caro, porque cada evento que existe hay que mantenerlo, documentarlo y revisarlo cuando el sitio cambie. Un negocio típico necesita entre ocho y quince eventos, no ochenta.

El filtro es simple: un evento merece existir si su ausencia o su caída lo llevaría a hacer algo distinto. Si nadie va a actuar nunca sobre ese dato, no lo mida.

• ●Eventos de intención: vio producto, usó el buscador, abrió la calculadora de precios.
• ●Eventos de fricción: falló el pago, se envió un formulario incompleto, se abandonó el carrito.
• ●Eventos de avance: agregó al carrito, inició el pago, agendó, inició conversación por WhatsApp.
• ●Eventos de valor: compró, firmó, se desembolsó el crédito. Estos siempre llevan monto.

Cómo nombrar: una convención y ni una excepción

El nombre de un evento es un contrato con su yo del futuro. Escoja una convención y respétela con disciplina de contador.

• ●Todo en minúsculas, con guion bajo, sin tildes y sin espacios.
• ●Estructura de objeto y acción, en ese orden: formulario_enviado, cotizacion_solicitada, whatsapp_iniciado.
• ●Verbos en pasado, porque un evento describe algo que ya pasó.
• ●Nunca meta el valor en el nombre. No cree compra_plan_premium y compra_plan_basico: cree compra con un parámetro de plan.
• ●Nunca renombre un evento en producción. Si necesita cambiarlo, cree el nuevo, deje correr los dos y documente la fecha del cambio.

Esa última regla salva historiales completos. Un evento renombrado parte la serie de tiempo en dos y obliga a explicar para siempre por qué en marzo todo cayó a cero.

Los parámetros: donde vive el valor real

Un evento sin parámetros le dice que algo pasó. Un evento con parámetros le dice qué pasó, cuánto valió y a quién. La diferencia entre una medición decorativa y una que sostiene decisiones está casi siempre ahí.

• ●Valor y moneda, siempre juntos y siempre en la misma unidad. Si reporta en COP, que sea COP en todas partes.
• ●Identificador único de la transacción o del lead, para deduplicar y para reconciliar con su sistema.
• ●Categoría o tipo, que es lo que después le permite segmentar sin crear eventos nuevos.
• ●Origen o etapa, cuando el mismo evento puede ocurrir en dos puntos distintos del recorrido.

Una tienda que vendía en tres categorías tenía tres eventos de compra distintos. Al unificarlos en uno con parámetro de categoría, pasaron de un reporte imposible de sumar a poder comparar rentabilidad por línea en la misma tabla. Ningún cambio técnico grande: solo una decisión de diseño.

Valores que sirven para optimizar

Si el evento lleva monto, el algoritmo puede perseguir plata en vez de volumen. Pero el monto tiene que ser el correcto, y aquí hay dos errores comunes: mandar el precio de lista en vez del cobrado, y mandar el ingreso bruto cuando el margen varía muchísimo entre productos.

Un negocio con márgenes dispares gana mucho mandando margen estimado en vez de ingreso. Si un producto de 400.000 COP deja 60.000 y otro de 180.000 deja 90.000, optimizar por ingreso lo empuja al producto equivocado. Cambiar esa sola cifra ha movido rentabilidades enteras en cuentas que no tocaron ni un creativo.

El documento que nadie quiere hacer y todos necesitan

La taxonomía tiene que vivir en un documento vivo, no en la cabeza de quien la montó. No necesita ser elegante: una hoja de cálculo compartida basta, con una fila por evento.

• ●Nombre exacto del evento y qué acción humana lo dispara.
• ●Dónde ocurre: en qué página o en qué paso del proceso.
• ●Qué parámetros lleva, con su formato y un ejemplo real.
• ●A qué plataformas se envía y si cuenta como conversión en cada una.
• ●Fecha de creación, responsable y fecha del último cambio.

Ese documento es lo que hace que un cambio de agencia, de desarrollador o de plataforma no borre la memoria de su negocio. También es lo primero que pedimos cuando alguien llega con datos que no cuadran, y es lo que casi nunca existe.

Cómo lo resolvemos en Manu

En Manu la taxonomía se define antes de instalar la primera etiqueta, no después de que el reporte deje de cuadrar. Es una conversación de negocio, no de desarrollo: empieza preguntando qué decisiones se toman y termina en una lista de eventos.

• ●Escribimos la taxonomía con el cliente y la dejamos en un documento compartido que le pertenece a él, no a nosotros.
• ●Limitamos el número de eventos a propósito: preferimos diez bien mantenidos que cincuenta abandonados.
• ●Enviamos margen en vez de ingreso cuando los márgenes del catálogo son dispares, y lo explicamos en el tablero.
• ●Versionamos los cambios con fecha para que cualquier salto en el histórico tenga explicación escrita.

Nombrar bien no es un detalle de forma. Es la diferencia entre tener datos y tener memoria.