Antes de elegir entre Mixpanel, Amplitude, PostHog, Pendo u otra herramienta, conviene entender qué hacen por dentro todas ellas. Si te conformas con una demo bonita y unas gráficas de colores, vas a confundir lo que hace la herramienta con lo que te vende la marca.
En este artículo no voy a entrar en cuál te conviene a ti (eso es más adelante en el curso). Voy a abrir la caja: qué capturan, cómo organizan los datos y dónde están los puntos de decisión que importan al elegir.
Las dos cosas que captura cualquier herramienta de analítica de producto
El modelo conceptual común a todas las herramientas es ridículamente simple: capturan eventos y propiedades. Lo importante es eso, luego vienen capas importantes (UI, integraciones, gobernanza del dato, privacidad, permisos, sampling y precio), pero si no entiendes estas dos cosas, todo lo demás te va a parecer magia, y no tiene nada de mágico.
Si lo entiendes bien, ya entiendes cómo funcionan casi todas las herramientas del mercado. Y, lo que es más útil, vas a poder instrumentar tu producto sin atarte a ninguna herramienta en concreto, en un futuro quizás por precio, tengas que cambiarla como me pasó a mi.
Eventos: lo que el usuario hace
Un evento es cualquier acción que un usuario realiza dentro de tu producto. Clics, navegaciones, descargas, formularios enviados, vídeos reproducidos, gestos en móvil, un evento es cualquier interacción medible.
Te dejo algunos ejemplos concretos por tipo de producto:
- En e-commerce:
product_added_to_cart,checkout_completed,coupon_applied. - En SaaS B2B:
report_generated,tour_duplicated,user_invited. - En app móvil:
video_played,subscription_canceled,notification_opened.
Un buen evento es significativo, no detallado hasta lo absurdo. click_button_3_in_navbar posiblemente no le sirve a nadie, navigation_opened con propiedades sí.
El error típico al empezar es trackear todo lo que se mueve y así acabas con miles de eventos huérfanos, sin que nadie recuerde por qué se instrumentaron, y un dato que ensucia que nadie consulta. La regla práctica: instrumenta lo que mueve una decisión, si no eres capaz de explicar qué decisión dependerá de un evento, no lo midas todavía.
Propiedades: el contexto del evento
Las propiedades son los metadatos que viajan con cada evento y le dan contexto. Sin ellas, un evento te dice «esto pasó N veces». Con ellas, te dice quién, dónde, cómo y en qué condiciones.
Mira report_generated. Las propiedades básicas que le añadirías, algunas herramientas añaden por defecto propiedades:
device: «desktop» / «mobile» / «tablet»plan: «free» / «pro» / «enterprise»role: «admin» / «editor» / «viewer»report_type: «monthly» / «custom» / «scheduled»
Sin propiedades, report_generated te dice «se generaron 1.230 informes esta semana». Con propiedades te dice «se generaron 1.230 informes, el 62% de plan Enterprise, el 18% desde móvil, y los admins generan 4 veces más informes que los viewers». La diferencia entre las dos lecturas es la diferencia entre datos y producto, como ves, las propiedades te dan el contexto de lo que ocurre.
Las propiedades son la inversión que mejor se paga a largo plazo. Cuesta pensarlas al instrumentar un evento, pero luego se rentabilizan durante años. Una herramienta sin propiedades ricas se queda en nada, una con propiedades bien diseñadas te deja explorar el problema.
Autocaptura vs instrumentación: dos formas de capturar datos
Más que dividir las herramientas en dos bandos cerrados, conviene pensar en dos formas de capturar datos: autocaptura (codeless) e instrumentación explícita. Algunas herramientas nacieron más cerca de un enfoque, otras del otro, pero cada vez más productos mezclan ambos modelos.
Autocaptura, la herramienta se instala una vez en tu app y captura automáticamente clics, vistas de página y navegaciones. Después etiquetas (tag) lo que te interesa desde la propia interfaz, sin tocar código.
- Lo bueno: rapidez para arrancar. No dependes de ingeniería para añadir un evento nuevo.
- Lo malo: los eventos puramente de negocio (
subscription_renewed,payout_processed) suelen seguir necesitando código. Y la profundidad de propiedades es limitada.
Instrumentación explícita, para cada evento que quieres trackear, alguien escribe una línea de código que llama a la SDK de la herramienta cuando el evento ocurre.
- Lo bueno: control total. Eventos limpios, semánticos y con todas las propiedades que decidas.
- Lo malo: dependes de ingeniería. Cada evento nuevo entra en el backlog.
¿Y dónde encaja cada herramienta? Heap y Pendo han sido tradicionalmente fuertes en captura automática y etiquetado visual. Mixpanel y Amplitude se han usado mucho con eventos definidos desde código, aunque hoy ofrecen también capacidades de autocaptura. PostHog combina autocaptura con eventos instrumentados desde el principio, la frontera entre los dos enfoques se va difuminando, así que cuidado con leer comparativas antiguas como si fueran biblia.
La elección no es religiosa, si tu producto cambia rápido y producto pelea por cada nuevo evento, la autocaptura te ahorra fricción inicial. Si tu producto es más estable y necesitas datos quirúrgicos, la instrumentación explícita escala mejor. La mayoría de equipos acaba combinando los dos enfoque, lo importante es que la decisión esté tomada con criterio, no por inercia.
El pegamento invisible: identificar usuarios
Capturar eventos no basta, la herramienta necesita saber quién ha hecho cada cosa.
Eso se resuelve enviando un identificador, normalmente user_id, cada vez que un usuario inicia sesión. La SDK lo guarda y, a partir de ese momento, todos los eventos se asocian a esa persona, no al dispositivo o al navegador anónimo en el que esté.
Hacerlo bien es más sutil de lo que parece. Si lo haces mal, la misma persona desde su portátil y desde su móvil aparece como dos usuarios distintos, las métricas de retención se van al garete y los eventos anónimos del periodo previo al login no coincidirán con la sesión autenticada. Una identidad mal montada te ensucia los datos durante años, y arreglarla luego es «carísimo»: hay que reprocesar histórico y casi siempre quedan flecos.
Aviso para productos en Europa, aquí el RGPD hay que cumplir. El user_id que envías a la herramienta de analítica no debe ser un dato personal directo (correo, nombre, teléfono, DNI). Lo que mandas tiene que ser un identificador opaco (un ID o un hash interno) que tu sistema sí pueda mapear a la persona, pero que la herramienta no. Tampoco mandes datos sensibles como propiedades del evento. No estás identificando «quién es» el usuario en términos personales, le estás dando a la herramienta una etiqueta estable para reconocerlo entre sesiones. Y antes de empezar a enviar nada, asegúrate de que el consentimiento de cookies y tracking está bien resuelto, porque sin él el envío no es legal.
En B2B hay un segundo identificador igual de importante: el account_id (o company_id, según cómo lo llames en tu modelo de datos). Lo mandas junto con el user_id y permite que la herramienta sepa qué usuario pertenece a qué cuenta. Sin esa pieza, no puedes calcular ninguna métrica a nivel cuenta y la próxima sección de este artículo se queda en teoría.
Usuario vs cuenta: por qué importa (sobre todo en B2B)
En B2C cada persona = un usuario, sencillo. En B2B cada cuenta tiene 5, 50 o 500 usuarios, y la herramienta tiene que mirar los datos en los dos niveles a la vez.
Imagina tu SaaS de gestión de viajes a medida. La cuenta es la agencia «Viajes Trúmbala». Dentro hay 12 usuarios: 2 admins, 5 agentes de reservas, 5 guías. Esta semana:
- 8 de los 12 usuarios han entrado al producto.
- Se han creado 156 reservas y se han generado 4 informes.
- Una sola agente, Marta, ha hecho el 40% de las reservas.
Si miras solo a nivel usuario, no entiendes el negocio, no sabes si la cuenta como tal está adoptando o no. Si miras solo a nivel cuenta, pierdes que Marta está sosteniendo toda la métrica y que el resto del equipo apenas usa el producto. La cuenta parece sana, pero por dentro depende de una sola persona. Si Marta se va de vacaciones o de la empresa, te enterarás al ver caer la curva.
Lo que tu herramienta de analítica tiene que hacer:
- Asociar cada evento a un usuario y a su cuenta.
- Permitir agrupar y filtrar por ambas dimensiones.
- Calcular métricas a nivel cuenta, no solo a nivel usuario (NPS por cuenta, retención por cuenta, MAU por cuenta).
Si estás evaluando una herramienta y no maneja bien el nivel cuenta, descártala para B2B. Es criterio eliminatorio, no negociable. Vuelvo a esto cuando hable de cómo elegir herramienta.
Qué es un dashboard y por qué es donde vivirás
Un dashboard es una página con varios gráficos y tablas que responden a una pregunta o monitorizan un objetivo. Es el «cuartel general» del equipo de producto, lo que se mira cada lunes, cada día, lo que enseñas a un stakeholder cuando pregunta cómo va una feature.
Tipos de dashboards básicos:
- Salud del producto: NSM, MAU, retención, adopción de las features clave.
- Release: métricas de la última funcioanlidad lanzada (adopción, errores, drop-offs).
- Por equipo o por área del producto: cada equipo con sus propias métricas.
El problema con los dashboards no es construirlos, es que se construyen y luego nadie los mira. Una organización típica tiene veinte dashboards y consulta tres. Los otros diecisiete cogen polvo, despistan al que llega nuevo y dan la falsa sensación de que el equipo es muy data-driven.
Consejo: si nadie ha mirado un dashboard en 1 mes, lo archivas o lo borras. Pocos dashboards vivos pesan más que muchos muertos.
Resumen rápido
- Toda herramienta de analítica de producto captura eventos (lo que el usuario hace) y propiedades (el contexto de cada evento). El resto son capas: UI, integraciones, gobernanza, privacidad, permisos y precio.
- Hay dos formas de capturar datos: autocaptura (rápido, automático, menos control) e instrumentación explícita (con código, control total). La mayoría de tools combinan las dos hoy.
- Identifica bien a tus usuarios y a sus cuentas (
user_id+account_id). Mal montado, te ensucia los datos durante años. - En B2B mide a nivel usuario y a nivel cuenta. Si la herramienta no lo soporta bien, descártala.
- Los dashboards son donde vivirás. Mejor pocos y vivos que muchos abandonados.
Siguiente paso
Si los términos eventos, segmentos, cohortes, retención o stickiness te suenan a chino, en el siguiente artículo los aterrizamos uno a uno con ejemplos. Es el glosario que vas a usar de verdad, no el de Wikipedia.
