Guía completa para taxonomía de eventos y propiedades

Cómo nombrar eventos, propiedades de evento y propiedades de usuario de forma consistente — y los errores a evitar para que tu data sea confiable.

Antes de empezar, si necesitás ayuda con la taxonomía de tu producto, escribime a guido@bildungdata.com

Recomendaciones Generales

• Taxonomía consistente: elegir una taxonomía para tus eventos y propiedades, y mantenerla. Esto es mucho más importante que el tipo de taxonomía que elijas (camelCase, snakecase, etc).
• Usar la misma taxonomía cross plataformas: usar la misma taxonomía en todas tus plataformas — Android, iOS, Web, Server-Side, etc.
• Usar la misma taxonomía en todas las herramientas donde trackees eventos: si enviás un evento a múltiples herramientas de MarTech (Mixpanel, OneSignal, Appsflyer, etc), usar la misma taxonomía en todas ellas.
• No trackear datos privados de los usuarios: no envíes datos personales a ninguna herramienta. Ej: tarjeta de crédito, saldos, etc.

→ TLDR: ser consistentes y usar la misma taxonomía en todos lados.

Taxonomía — EVENTOS

• Eventos: los Eventos son (1) acciones que realizan los usuarios (ej: realizar una compra), o (2) acciones que le suceden a los usuarios (ej: actualizar un saldo a través de un proceso de backend).
• Taxonomía recomendada: queremos una taxonomía que sea fácil de entender para el ojo humano. Por ende, la taxonomía que recomendamos es "objeto + verbo en pasado". Ej: Item Viewed, Item Purchased, Video Played.
• Usar espacios para separar las palabras. Esto facilita la lectura para cualquiera.
• Usar mayúsculas y minúsculas de forma adecuada (Ej: Video Played).
• Evitar usar taxonomías como camelCase, o snakecase, simplemente porque son más difíciles de leer, y por ende menos comprensibles para el ojo humano (si preferís alguna de estas, usala, pero sé consistente).
• Usar tags para identificar a qué flujo corresponde cada evento: si tu plataforma tiene muchos flujos (onboarding, checkout, etc), es conveniente identificar a qué flujo corresponde cada evento para que sea más fácil encontrarlos a la hora de armar un reporte. Para eso, podés usar Tags desde Mixpanel.
• No usar nombres muy específicos: por ejemplo, no usar "User Signed Up With Facebook". Usar: "User Signed Up", y usar propiedades de evento para detallar el método (signupmethod = Facebook).
• Idioma: elegir un idioma que se entienda por todos. A igualdad de condiciones, recomendamos usar inglés.

→ TLDR: usar una taxonomía fácil de entender: Objeto + Verbo en Pasado. Separar las palabras por espacios. Usar mayúsculas y minúsculas. Ej: Item Viewed, Video Watched.

Taxonomía — PROPIEDADES DE EVENTOS

• Propiedades de evento: las propiedades de evento sirven para enriquecer la data de un evento. Por ejemplo, para el evento "Item Purchased", podemos enviar el tipo de producto comprado (type = 'Coffee'), o el precio del item (price = 3.14).
• Taxonomía: recomendamos usar una taxonomía diferente a la de los eventos, simplemente para que sea fácil de diferenciar una propiedad de un evento.
• Recomendamos usar snakecase con todas las palabras en minúsculas.
• Ejemplos: signupmethod, errortype, amountpurchased, itemprice, itemcategory.
• Hay distintos tipos de propiedades de eventos: (1) String — valor alfanumérico (ej: userid = "abc123"); (2) Numeric — enteros o decimales (ej: price = 3.14); (3) Boolean — true o false (ej: completedonboarding = true); (4) Timestamp — fechas en formato ISO 8601 (ej: lastlogin = "2025-06-12T14:23:00Z"); (5) List — lista de valores (ej: favoriteditems = ["milk", "bread"]).
• Taxonomía consistente cross eventos: si trackeás una misma propiedad en diferentes eventos, es muy importante que uses el mismo nombre en todos los casos.
• Ej: cuando un usuario mira un producto (Item Viewed), y cuando un usuario compra un producto (Item Purchased), queremos guardar la categoría del mismo (propiedad: itemcategory). Enviar itemcategory en los dos eventos sin ningún tipo de variación (espacios, mayúsculas, etc).
• Evento específico vs Evento + Propiedad: un mismo dato lo podemos guardar como parte del evento o como una propiedad. Por ejemplo: hay acciones que se pueden hacer desde múltiples pantallas — es posible agregar un item al carrito desde Categorías, o desde resultados de búsqueda:
• Opción 1 — crear dos eventos específicos: Item Added From Category, Item Added From Search.
• Opción 2 — crear un único evento con una propiedad: Item Added (property: from; values: Category, Search).

→ Para elegir la mejor opción, pensar cómo / con qué frecuencia vamos a usarlo; armar un reporte filtrando por una propiedad lleva más tiempo. Si vas a hacer ese reporte frecuentemente, tal vez sea mejor la Opción 1.

• Propiedades trackeadas automáticamente: el SDK client-side de Mixpanel trackea automáticamente ciertas propiedades en todos los eventos. Tienen la siguiente taxonomía: $browser, $device, $screenwidth.

→ TLDR: las propiedades enriquecen a los eventos. Hay 5 tipos de propiedades. Usar una taxonomía diferente a la de Eventos para diferenciarlos fácilmente.

Taxonomía — PROPIEDADES DE USUARIOS

• Usuarios: individuos específicos que completan acciones dentro de tu producto.
• Propiedades de usuario: las propiedades de usuario sirven para enriquecer el perfil del usuario. Por ejemplo: name, city, currentplan, numberoftransactions.
• Hay distintos tipos de propiedades de usuarios: en general, los tipos son iguales a los de propiedades de eventos: (1) String, (2) Numeric, (3) Boolean, (4) Timestamp, (5) List.
• Taxonomía: recomendamos usar la misma taxonomía que para propiedades de eventos, para diferenciarlas fácilmente de los eventos.
• Usar snakecase con todas las palabras en minúsculas.
• Ejemplos: firstname, plantype, city, signupmethod.
• Son mutables — pueden cambiar en el tiempo: las propiedades de usuario pueden cambiar en el tiempo (mutables), pero no todas lo hacen. Por ejemplo: el name o userid son dos propiedades que no van a cambiar; mientras que plantype, o totalpurchases se irán actualizando para siempre mostrar el último estado.
• Propiedades incrementales: las propiedades incrementales sirven para trackear el valor histórico de propiedades clave. Por ejemplo: si nos interesa conocer el total histórico de compras de cada usuario, podemos trackear la propiedad incremental totalpurchases, que irá sumando +1 con cada nueva compra.
• Propiedades trackeadas automáticamente: el SDK client-side de Mixpanel trackea automáticamente ciertas propiedades en todos los usuarios. Tienen la siguiente taxonomía: $city, $region, $countrycode.

→ TLDR: las propiedades de usuario enriquecen el perfil de los usuarios. Son mutables — pueden cambiar en el tiempo.