Cómo integrar Mixpanel de la forma correcta: mejores prácticas y errores comunes a evitar
Después de trabajar con +50 clientes de Mixpanel en LatAm, armamos esta guía para revisar los aprendizajes de mejores prácticas y errores comunes que queremos que evites.
La idea de esta guía es que sea un complemento a la documentación de Mixpanel (por favor lee su documentación también!!! link), donde los queremos ayudar a orientarse mejor y evitar errores comunes.
Planificación previa a la implementación
El primer típico error es que el equipo técnico comience a integrarse y trackear eventos sin antes haber tenido una etapa de planificación.
En esta etapa vamos a definir las:
Qué preguntas de negocio y casos de uso les gustaría resolver con Mixpanel
A partir de estas preguntas y casos, definir “qué métricas precisan poder construir en Mixpanel para poder responderlas”
A partir de estas métricas, definir “qué eventos, propiedades de eventos y de usuario precisan trackear para poder crear esas métricas”
Estos eventos los definiremos en un Tracking Plan - documento que luego el equipo técnico usará como guía para trackear cada uno de los eventos.
Escribimos una guía detallada de frameworks y aprendizajes para realizar esta etapa de implementación - recomendamos seguirla!
Events & Event Properties
Eventos: es una interacción entre el usuario y tu producto que deseamos trackear.
→ Todos los eventos tienen un nombre, timestamp y están atados a un usuario
Por ejemplo, para trackear un evento cuando un usuario compro un café en tu app, tus developers tendrán que agregar la siguiente linea de código en la sección del código donde esta acción se ejecuta:
mixpanel.track( 'Purchased Item');* este código esta en Javascript, veremos que puede ser trackeado en distintos lenguajes de acuerdo a los lenguajes utilizados por tu equipo técnico
Propiedades de Evento: opcionalmente los eventos pueden contener propiedades para describir con mayor profundidad la acción realizada por tu usuario
Por ejemplo, si el café que compro tu usuario costó 2.50 usd podríamos sumar al evento:
mixpanel.track( 'Purchased Item', { 'item name': 'coffee', 'price': 2.50, 'currency': ‘usd’ });
Intro Arquitectura de Ingesta de Datos
Veremos que hay múltiples métodos para enviar Eventos a Mixpanel y lo más normal es combinar varios métodos a la vez.
Eligiremos uno u otro dependiendo de nuestros casos de uso que queramos resolver y tecnología disponible para hacerlo.
Arquitectura más común:
Client Side Tracking
Apps → Trackeamos eventos de usuarios en nuestras apps (Android, iOS, React Native, Flutter…)
Website → Trackeamos eventos y page views de usuarios en nuestros website (Javascript…)
Server Side Tracking:
Backend → Enviamos eventos desde nuestros servidores (Node, Python,…)
En general es data transaccional (Purchases, Transactions…) u eventos de creación de usuarios (User Sign Up)
Entraremos en detalle de cuándo conviene utilizar cada una de ellas más abajo 👇👇
Arquitecturas más avanzadas
CDP: Otra opción sería conectar a Mixpanel con su CDP (Customer Data Platform) en caso de que ya tengan la data de Eventos en uno (Segment, Rudderstack…). En este caso, esta guía no es para ustedes.
Third Party Tools: podemos conectar a Mixpanel con herramientas externas para importar ciertos datos desde ellas. Por ejemplo podemos
Data de campañas de herramientas de Marketing (OneSignal, Braze,…)
Data de clientes desde su CRM (Salesforce, Hubspot…)
Data de experimentos desde su A/B testing tool (VWO, Optimizely…)
Data Warehouse Integration: podemos conectar y sincronizar Mixpanel con su Data Warehouse (BigQuery, Snowflake, Azure…). [Docs con más info]
Por ejemplo, si ya tienes los eventos de tu backend almacenados en BigQuery, puedes sincronizar Mixpanel con una tabla del mismo para que tome esta data en real time.
También podríamos sino enriquecer con datos adicionales que tengamos en nuestro warehouse (no necesariamente eventos) por ejemplo Marketing Ad Data, CRM Data…
Proxy-Client Side: ver más abajo. Pero sería posible agregar un proxy server entre tu Client Side y Mixpanel para tener mayor control sobre los eventos ingeridos desde el frontend.
User Identification ⚠️⚠️
⚠️ Máxima atención en este paso, acá es donde vemos la mayor cantidad de errores de implementación!!
Mixpanel tiene dos componentes claves: Eventos y Usuarios
Ahora, hay muchos casos de uso que tenemos que pensar y que Mixpanel nos permite resolver si hacemos la integración de la forma correcta:
un usuario puede utilizar nuestro producto de forma anónima
luego se puede crear una cuenta
se puede logear a esa misma cuenta desde múltiples dispositivos (su celular, su computadora personal, la del trabajo…)
puede disparar eventos desde distintas fuentes de datos (client side, server side, marketing platform,…)
múltiples usuarios se pueden logear en un mismo dispositivo
etc.
Primero es importante entender cómo Mixpanel trata la identificación de usuarios:
Cuando un usuario abre tu Website u App (Client Side) por primera vez, Mixpanel crea un id de usuario random.
Este id tendrá el formato “$device:13bbf7943e584-0885c2531-5c793977-3e8000-13bbf7943e64cf”
Mixpanel guarda el id de su usuario bajo el campo ‘$distinct_id’
Este $distinct_id se guardará bajo local storage del Client Side (cookies en una website o local storage en una app mobile)
Cuando un usuario dispara cualquier evento que estamos trackeando (por ejemplo “Add to Cart”), Mixpanel buscará en el local storage el $distinct_id del usuario y luego registrará el evento asociado a este $distinct_id. En este caso, por ahora será el del usuario anónimo.
Nunca habrá que forzar y enviar un $user_id en eventos Client Side!! Esto se hará de forma nativa por el Client Side SDK.
Cuando el usuario se registra o hace log in, los desarrolladores front end (Client Side) deben incluir en su código un identity call con el user_id que utilicen internamente para identificar a los usuarios
mixpanel.identify(‘<user_id>’)Es buena práctica utilizar un identificador que no cambie en el tiempo y que sea único para cada usuario. En general los equipos técnicos ya utilizan alguno internamente - por ejemplo el campo principal que usan para identificar usuarios en sus base de datos
Al realizar el identify call, se combina en el mismo perfil de usuario la actividad del usuario anónimo y el del ahora identificado. Si estamos en Simplified ID Management, entonces este nuevo user_id pasará a ser el canónico. (más abajo de esto)
¿Y si el usuario tiene múltiples dispositivos?
Ahora, supongamos que el mismo usuario abre su app desde otro device (sea otro mobile device o su website por ejemplo) y navega por él de manera anónima.
En este caso, el Client Side SDK va a crear otro random $distinct_id con el mismo formato $device:xxx-yyyy…
Y todos los eventos que registre este usuario anónimo serán asociados a este nuevo $distinct_id
Una vez que el usuario haga log in en este segundo dispositivo con su mismo id que antes y el Client Side SDK llame al identify, entonces Mixpanel podrá combinar los eventos de ambos perfiles de usuarios anónimos bajo el mismo perfil de usuario!
¿Y si el mismo dispositivo es utilizado por múltiples usuarios?
Para prevenir que cuando otro usuario haga log-in en el mismo dispositivo se combine su actividad de usuario anónimo con el del usuario previo, tenemos que hacer la siguiente llamada en el momento que el usuario hace log-out:
mixpanel.reset()Esto hará que Mixpanel Client Side cree un nuevo $distinct_id para el segundo usuario anónimo
Luego cuando el segundo usuario se registre o haga log-in con su cuenta, estos eventos se trackearan junto a su respectivo perfil
⚡USER IDENTIFICATION TIP:
Siempre que hagamos un identify call, enviar el $user_id que seteamos también como user property. Esto nos ayudará en el futuro a realizar QA y debugging.
🔗 LINKS A DOCS MIXPANEL CLIENT-SIDE
¿Y los Eventos Server-Side?
⭐ La regla re oro es que siempre que un evento se pueda trackear desde el lado del servidor (backend) es mejor hacerlo desde allí.
Los eventos de Client Side pueden ser menos confiables que los de Server Side, algunos potenciales problemas podrían ser:
❌ En Web el usuario puede tener Ad Blockers que no permiten que Mixpanel almacene localmente la información en las cookies y por lo tanto estos eventos no serán trackeados
❌ En Web y App puede suceder que el usuario tenga problemas de conexión y cliquee múltiples veces en un botón, disparando múltiples veces un evento.
→ Generalmente los equipos de backend son quienes ejecutan eventos transaccionales (por ejemplo ‘Purchase’) y de creación de cuenta (‘Sign Up’).
Por lo tanto, es importante juntarse con este equipo, identificar cuáles son estos Eventos y agregar en el Tracking Plan que ellos serán los responsables para trackearlos.
¿Cómo trackeo un evento Server-Side?
Para trackear un evento Server-Side precisamos indicar quién realizo este evento especificando el ‘$user_id’:
mixpanel.track('Purchase', {
$user_id: 'Charlie',
price: 2.50
});—> En el 99.99% de los casos, enviaremos eventos Server-Side para usuarios que ya fueron identificados desde el Client-Side
El flujo más normal es:
Usuario abre App (o website)
Mixpanel Client-Side SDK crea usuario anónimo $device:xxx
Cualquier evento que se registre será asociado al perfil de este usuario anónimo
Usuario se registra
Client-Side hace la llamada mixpanel.identify(‘<user_id>’)
Client-Side hace llamada user property mixpanel.people.set({ "User ID": ‘<user_id’ });
Mixpanel vincula los perfiles del usuario anónimo y el identificado
Mixpanel guarda en local storage los $distinct_id del usuario
Usuario realiza eventos Client-Side - por ejemplo realiza un ‘Add to Cart’
Client-Side registra mixpanel.track(‘Add to Cart’)
Mixpanel toma del local storage el $distinct_id y registra el evento a ese usuario.
Usuario realiza eventos Server Side - por ejemplo finaliza una compra
Server-Side registra el evento asociado al usuario explicitando el $distinct_id:
Mixpanel registra estos eventos en el mismo perfil del usuario que el que contiene los eventos Client-Side
mixpanel.track('Purchase', {
$user_id: '<user_id>',
price: <price>
});🤔 ¿Qué sucede si el usuario todavía no fue identificado desde el Client Side y registramos un evento Server-Side?
En este caso, Mixpanel creará un nuevo perfil de usuario - tomando el $distinct_id indicado en el evento Server-Side.
Este comportamiento no suele ser normal y habría que revisar este caso de uso para entender si es un comportamiento esperado.
La desventaja es que si este evento en realidad pertenece a un usuario anónimo que está siendo registrado por el Client-Side SDK entonces estaremos duplicando perfiles de usuarios (un perfil de usuario anónimo y un perfil de usuario con su $user_id).
Una vez que hagamos el Identify call en el Client-Side se combinarán ambos perfiles. De vuelta, revisar este caso porque no suele ser lo habitual.
🧐 ¿Qué sucede si enviamos un evento Server-Side no asignado a ningún usuario?
Si enviamos un evento Server-Side con el campo $user_id vacio, entonces se asignará a un perfil de usuario con $user_id null.
En general esto es un error de implementación y habría que revisarlo.
Hay muy pocos particulares donde hace sentido enviar esto así. Por ejemplo si queremos importar el Ad Spend - métrica que no está asociada a ningún usuario en particular.
🤨 ¿Puedo trackear eventos de Server-Side para usuarios anónimos?
No es recomendable. Y de todos los cliente que ayudamos, nunca tuvimos un caso de uso que amerite hacerlo.
Por lo tanto, no vamos a entrar en detalle ya que no lo recomendamos. Pero en caso de que lo quieran hacer, deberían utilizar la función “get_distinct_id” desde el lado del cliente para tomar $distinct_id del usuario anónimo (en este momento el distinct_id = device_id) y luego enviar un evento server side con este identificador como $device_id. Antes de enviarlo, habrá que eliminar el prefijo de “device:” del identificador. (link a docs)
🔗 LINKS A DOCS MIXPANEL SERVER-SIDE
💡¿Hay forma de resolver los problemas de confianza en los eventos Client-Side?
→ Si! Implementando un Proxy server entre tus tracks desde el Client Side y el envío a Mixpanel
Más info en este blog y en este video de Youtube
Consideraciones a tener en cuenta:
Al no estar utilizando el SDK Client Side nativo, van a tener que reproducir sus lógicas y hacer un QA más detallado para asegurarse de que están cumpliendo con todo.
IP → Mixpanel utiliza la dirección IP para completar los datos de geolocalización (Country, City, Region). Probablemente tengan que tomarlos desde el frontend y enviarlos a mixpanel. [Docs con más info]
UTM Tags → el Client Side SDK nativo envia los UTM tags para todos los eventos. Van a tener que tomar estos y enviarlos a Mixpanel también. [Docs con más info]
Mixpanel Metadata → además Mixpanel tiene ciertas propiedades nativas que levanta desde el Client-Side, por ejemplo “browser”, “device”,etc. Tenemos que asegurarnos de estar levantandolas y enviandolas vía el Proxy