Cómo integrar Mixpanel correctamente: mejores prácticas y errores a evitar

Después de implementar Mixpanel con +80 clientes en LatAm, recopilamos los aprendizajes clave: planificación, arquitectura de ingesta, user identification y el tracking server-side que la mayoría de los equipos hacen mal.

Esta guía es un complemento de la documentación oficial de Mixpanel —que por favor también leas (link). Acá compartimos los aprendizajes que recopilamos después de implementar Mixpanel con más de 80 clientes en LatAm: cómo orientarse mejor, qué decisiones evitan errores caros, y dónde la mayoría de los equipos se traba.

Planificación previa a la implementación

El error más común que vemos es que el equipo técnico arranca a integrar y trackear eventos sin haber pasado por una etapa de planificación. Saltearse ese paso siempre se paga: termina en tracking plans inconsistentes, métricas que no responden las preguntas del negocio, y meses de re-trabajo.

En la etapa de planificación definimos, en orden:

— Qué preguntas de negocio y casos de uso queremos resolver con Mixpanel.

— A partir de esas preguntas, qué métricas necesitamos poder construir para responderlas.

— A partir de esas métricas, qué eventos, propiedades de evento y propiedades de usuario necesitamos trackear.

Todo esto se documenta en un Tracking Plan, que después el equipo técnico usa como guía para implementar cada evento. Escribimos una guía detallada con frameworks y aprendizajes para esta etapa — recomendamos seguirla.

Eventos y propiedades de evento

Eventos

Un evento es una interacción entre el usuario y tu producto que decidimos trackear. Todos los eventos tienen un nombre, un timestamp, y están atados a un usuario.

Por ejemplo, para trackear cuando un usuario compra un café en tu app, los developers tienen que agregar esta línea en la sección del código donde se ejecuta la acción:

mixpanel.track('Purchased Item');

Este snippet está en JavaScript; el evento se puede trackear en distintos lenguajes según las tecnologías que use tu equipo técnico.

Propiedades de evento

Opcionalmente, los eventos pueden tener propiedades que describen con mayor profundidad la acción del usuario. Por ejemplo, si el café costó 2.50 USD:

mixpanel.track('Purchased Item', {
'item name': 'coffee',
'price': 2.50,
'currency': 'usd'
});

Arquitectura de ingesta de datos

Hay múltiples métodos para enviar eventos a Mixpanel, y lo normal es combinar varios. Cuál elegir depende de los casos de uso a resolver y de la tecnología disponible en tu equipo.

Arquitectura más común

Client Side Tracking:

— Apps: trackeamos eventos de usuarios en apps nativas (Android, iOS, React Native, Flutter).

— Website: trackeamos eventos y page views en el sitio (JavaScript).

Server Side Tracking:

— Backend: enviamos eventos desde nuestros servidores (Node, Python, etc.). Suele ser data transaccional (Purchase, Transaction) o de creación de cuenta (User Sign Up).

Arquitecturas más avanzadas

CDP: si ya tenés la data de eventos en una Customer Data Platform (Segment, Rudderstack), podés conectar Mixpanel directamente. En ese caso, esta guía no aplica.

Herramientas externas: podés conectar Mixpanel con tools de marketing (OneSignal, Braze), CRMs (Salesforce, HubSpot) o herramientas de A/B testing (VWO, Optimizely) para importar data de campañas, clientes o experimentos.

Data Warehouse: podés conectar y sincronizar Mixpanel con tu warehouse (BigQuery, Snowflake, Azure). Por ejemplo, si los eventos del backend ya están en BigQuery, podés sincronizar Mixpanel con una tabla en real time. También podés enriquecer con datos adicionales que no sean eventos —marketing ad data, CRM data, etc. (docs).

Proxy Client-Side: se puede agregar un proxy server entre el frontend y Mixpanel para ganar control sobre los eventos del client. Lo desarrollamos al final.

User Identification (la sección donde más errores vemos)

Máxima atención acá. Es la parte donde la mayoría de las implementaciones se rompen.

Mixpanel tiene dos componentes clave: eventos y usuarios. Y hay muchos casos de uso que vas a querer resolver bien desde el día uno:

— Un usuario puede usar tu producto de forma anónima antes de crear cuenta.

— Después puede registrarse.

— Puede loguearse desde múltiples dispositivos (celular, computadora personal, computadora del trabajo).

— Puede disparar eventos desde distintas fuentes (client side, server side, plataforma de marketing).

— Múltiples usuarios pueden loguearse en el mismo dispositivo.

Cómo Mixpanel identifica usuarios

Cuando un usuario abre tu website o app por primera vez (client side), Mixpanel le crea un ID aleatorio con formato $device:13bbf7943e584-0885c2531-5c793977-3e8000-13bbf7943e64cf y lo guarda bajo el campo $distinct_id. Este $distinct_id se persiste en el local storage del cliente (cookies en web, local storage en mobile).

Cuando ese usuario dispara un evento (por ejemplo 'Add to Cart'), Mixpanel busca el $distinct_id en el local storage y asocia el evento a ese ID. Por ahora, el del usuario anónimo.

Nunca fuerces ni envíes un $user_id en eventos client-side. El SDK lo maneja nativamente.

Cuando el usuario se registra o se loguea, los developers del client side tienen que llamar al identify con el user_id que usan internamente:

mixpanel.identify('<user_id>')

Buena práctica: usá un identificador que no cambie en el tiempo y que sea único por usuario. En general los equipos técnicos ya tienen uno —el campo principal con que identifican usuarios en su base de datos.

Al hacer el identify call, Mixpanel combina la actividad del usuario anónimo y la del identificado en el mismo perfil. Si estás en Simplified ID Management, este nuevo user_id pasa a ser el canónico.

¿Y si el usuario tiene múltiples dispositivos?

Supongamos que el mismo usuario abre la app desde otro device y navega anónimamente. El client side SDK le crea un nuevo $distinct_id ($device:xxx-yyy...) y todos los eventos anónimos se asocian a ese ID.

Cuando el usuario hace log in en este segundo dispositivo con el mismo user_id de antes, el identify call combina los eventos de ambos perfiles anónimos bajo el mismo perfil de usuario.

¿Y si el mismo dispositivo lo usan múltiples usuarios?

Para que cuando otro usuario haga log-in en el mismo dispositivo no se mezcle su actividad anónima con la del usuario anterior, hay que llamar al reset en el momento del log-out:

mixpanel.reset()

Esto hace que el client side cree un nuevo $distinct_id para el segundo usuario anónimo. Cuando ese segundo usuario se registre o se loguee, sus eventos quedan correctamente atados a su perfil.

Tip clave de user identification

Cada vez que hagas un identify call, mandá también el $user_id como user property. Esto te va a salvar la vida en QA y debugging más adelante.

Links a docs de Mixpanel Client-Side: JavaScript, React Native, Android, iOS.

Eventos Server-Side

Regla de oro: siempre que un evento se pueda trackear desde el server, hacelo desde el server.

Los eventos client-side son menos confiables que los server-side. Algunos problemas típicos:

— En web, el usuario puede tener ad blockers que impiden que Mixpanel almacene la info en cookies, y esos eventos no se trackean.

— En web y app, problemas de conexión pueden hacer que el usuario clickee múltiples veces y dispare el mismo evento varias veces.

Los eventos transaccionales (Purchase) y los de creación de cuenta (Sign Up) los suele ejecutar el backend. Es importante sentarse con ese equipo, identificar cuáles son esos eventos, y dejar documentado en el Tracking Plan que ellos los trackean.

¿Cómo trackeo un evento server-side?

Hay que indicar quién hizo el evento especificando el $user_id:

mixpanel.track('Purchase', {
$user_id: 'Charlie',
price: 2.50
});

En el 99.99% de los casos, los eventos server-side se mandan para usuarios que ya fueron identificados desde el client-side.

El flujo end-to-end normal

1. El usuario abre la app o el website.

2. El client-side SDK crea un usuario anónimo con $device:xxx.

3. Cualquier evento que registre antes de identificarse queda asociado a ese perfil anónimo.

4. El usuario se registra. El client-side llama a mixpanel.identify('<user_id>') y manda el user_id también como user property con mixpanel.people.set({ 'User ID': '<user_id>' }).

5. Mixpanel combina el perfil anónimo con el identificado y guarda el $distinct_id en el local storage.

6. El usuario hace un evento client-side (por ejemplo 'Add to Cart'). El client-side llama a mixpanel.track('Add to Cart'), Mixpanel toma el $distinct_id del local storage y registra el evento.

7. El usuario finaliza una compra. El server-side registra el evento explicitando el $user_id:

mixpanel.track('Purchase', {
$user_id: '<user_id>',
price: <price>
});

Mixpanel guarda este evento en el mismo perfil del usuario que ya contiene los eventos client-side.

Casos edge a tener en cuenta

¿Qué pasa si registro un evento server-side antes de que el usuario haya sido identificado en el client-side? Mixpanel crea un nuevo perfil con el $distinct_id del evento server-side. Esto duplica perfiles (uno anónimo + uno identificado). Cuando el identify call llegue desde el cliente, se combinan. Revisá este caso porque no suele ser el comportamiento esperado.

¿Qué pasa si mando un evento server-side sin asignarlo a ningún usuario? Se asigna a un perfil con $user_id null. En general es un error de implementación. Hay muy pocos casos válidos —por ejemplo importar Ad Spend, que no está atado a un usuario en particular.

¿Puedo trackear eventos server-side para usuarios anónimos? No lo recomendamos, y en +50 implementaciones nunca tuvimos un caso de uso que lo amerite. Si tenés que hacerlo, podés usar get_distinct_id desde el client para obtener el $distinct_id del usuario anónimo y mandarlo como $device_id en el evento server-side (sacándole el prefijo 'device:'). Pero revisá primero si realmente lo necesitás.

Links a docs de Mixpanel Server-Side: Python, Node.js, Ruby.

Proxy server: ¿hay forma de resolver los problemas del client-side?

Sí. Implementando un proxy server entre tus tracks del client-side y Mixpanel. La idea es que tu frontend mande los eventos a tu propio server, y ese server los reenvía a Mixpanel.

Consideraciones a tener en cuenta:

Al no usar el SDK nativo del client-side, vas a tener que reproducir su lógica y hacer un QA más detallado. Hay tres puntos en particular que el SDK nativo resuelve solo y que vas a tener que replicar:

— IP: Mixpanel usa la IP para completar la geolocalización (country, city, region). Probablemente tengas que capturarla en el frontend y reenviarla. Docs.

— UTM Tags: el SDK nativo manda los UTM en todos los eventos. Vas a tener que capturarlos y reenviarlos vos. Docs.

— Mixpanel metadata: el SDK levanta propiedades nativas del client-side (browser, device, OS, etc.). Asegurate de capturarlas y mandarlas vía el proxy.

Cierre

Si llegaste hasta acá, tenés casi todo lo que necesitás para que tu implementación de Mixpanel no se rompa los primeros tres meses. La planificación, el user identification y la decisión client vs server son los tres lugares donde más vemos romperse equipos —y son evitables.

Si querés que revisemos tu implementación o te acompañemos en una migración, escribinos.