Frameworks y tips para planificar la implementación de tu herramienta de Product Analytics
En esta guía revisamos aprendizajes después de haber trabajado con +50 startups para tener una planificación de tu herramienta de product analytics y lograr un Data Governance sustentable
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.
Cuando no realizamos esta etapa de planificación, en general terminamos teniendo problemas como:
❌ Mayores costos y dificultad para usar Mixpanel ya que al trackear TODAS las acciones que pueden realizar un usuario en su producto ensuciamos con data innecesaria.
❌ No contamos con la información necesaria para crear las métricas relevantes para el negocio. Probablemente falten eventos o propiedas claves
❌ Equipos responsables de integrar fuentes de datos no alineados (Web, Android, iOS, backend…) resultando que tengamos diferentes definiciones de eventos y sus nombres, derivando en poca confianza en los datos.
Por ello, es importante que el equipo de negocios - sea Producto, Marketing, Growth - o quién vaya a luego utilizar Mixpanel participe de una etapa minuciosa de definiciones de:
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”
Para realizar esta planificación hay múltiples frameworks y formas de hacerlas - qué no es el objetivo de este posteo entrar en detalle en ellas.
Pero acá dejamos un ejemplo de algunas preguntas típicas que cualquier negocio digital podría estar interesado en responder, y también otro link a un ejemplo del framework de “Key Entities & Activities” que nosotros recomendamos. Vamos a escribir otros posteos para entrar en detalle en ellos - stay tuned.
El resultado final de la planificación debería ser un Tracking Plan. Este es un documento *vivo* donde, en base a todo el trabajo previo, detallamos cada evento que queremos que nuestros developers trackeen; su nombre, definición, disparador, propiedades y quién lo debería trackear. Acá hay un blog que escribió Guido explicandolo.
