Recolectar datos y refinarlos en métricas: los dos primeros pasos del framework

En el artículo anterior te hablé de la pirámide de cinco niveles, en este artículo bajo al sótano del framework: los niveles 1 y 2, recolectar datos limpios y refinarlos en métricas con definición compartida con los equipos.

Es la parte menos vistosa de la analítica, nadie hace presentaciones en LinkedIn o da una charla sobre instrumentar bien user_id ni sobre acordar qué significa «usuario activo». Y, sin embargo, es la parte que determina si todo lo de arriba sirve para algo o no. Casi cualquier problema en los niveles 3, 4 o 5 acaba teniendo el origen en una grieta de estos dos primeros niveles.

Si tuviera que resumir el artículo en una frase, sería esta: la calidad de tu analítica depende mucho más de cómo defines y conectas los datos que de la herramienta que uses. Los dashboards no arreglan datos ambiguos, la analítica se rompe mucho antes de llegar al dashboard, casi siempre en la definición o en la identidad.

Caso práctico de ejemplo

Para que esto sea más fácil de entender, voy a tirar de un mismo hilo durante todo el artículo: el caso de Algora (Empresa ficticia), un SaaS B2B de gestión de contratos que ha detectado una caída de retención en sus cuentas Enterprise este trimestre y necesita entender qué pasa. Vas a ver cómo cada decisión que toca este artículo (qué datos recolectar, cómo identificarlos, cómo refinarlos en métricas) afecta directamente a su capacidad de responder esa pregunta.

En este artículo te cuento qué datos hay que recolectar (de personas y de comportamiento), los tres retos típicos que aparecen, cómo refinar esos datos en métricas con las dimensiones de amplitud, profundidad y frecuencia, y cómo empezar si vienes desde cero.

Paso 1: qué datos recolectar

Cualquier sistema serio de analítica de producto se monta sobre dos familias de datos que conviene tener claras desde el primer día.

Datos de personas

Te dicen quién es cada usuario y a qué cuenta pertenece. Sin esto, los eventos son anónimos y poco útiles. Incluyen:

• Atributos del usuario: rol, plan, idioma, país, fecha de signup, dispositivo principal.
• Atributos de la cuenta: tamaño, industria, segmento, fecha de alta, owner comercial.
• Datos del CRM: ARR, fecha de fin de prueba, etapa del pipeline, salud de la cuenta.
• Datos de facturación: plan actual, próxima renovación, método de pago, descuentos aplicados.

Cruzar producto con CRM y facturación es lo que diferencia la analítica de producto de la analítica web pura. Una herramienta de analítica que no ingiere datos de CRM o de facturación se queda en la mitad del trabajo: te dice qué pasa dentro del producto, pero no a quién le está pasando ni cuánto está pagando por ello.

Aviso para productos en Europa

Si operas bajo RGPD, hay una regla que conviene tener clara antes de empezar a enviar nada: el identificador que mandas a la herramienta de analítica no puede ser un dato personal directo (correo, nombre, teléfono, DNI).

Lo correcto es usar un identificador opaco, un UUID o un hash interno, que tu sistema sí pueda mapear a la persona pero que la herramienta no. Lo mismo aplica a las propiedades de los eventos: nada de PII (información personal identificable) viajando dentro.

Y antes de mandar el primer evento, el consentimiento de cookies y tracking tiene que estar bien resuelto. Esto lo desarrollé en el artículo 2; aquí basta con recordar la idea: identidad estable e identidad anónima no son incompatibles, y ambas son posibles a la vez si lo haces bien desde el principio. Si no, te toca reprocesar histórico cuando legal te llame, y eso es carísimo, porque hay que volver a atrás.

Datos de comportamiento

Te dicen qué hace cada usuario dentro del producto. Los vimos en el artículo 2 con su modelo de eventos y propiedades.

• Eventos (title_started, report_generated, subscription_canceled) con sus propiedades de contexto.
• Cargas de página y vistas.
• Sesiones con su duración y profundidad.
• Uso por funcionalidad agregado: funcionalidades usadas por cuenta, módulos activos por usuario, acciones core por segmento, adopción de funcionalidades clave en los primeros 30 días.

Recuerda el principio clave del artículo 2: los datos de comportamiento solo tienen sentido cuando puedes asociarlos a una persona y a su cuenta con un identificador estable. Muchos equipos creen que tienen problemas de reporting cuando en realidad tienen problemas de identidad, y la diferencia importa: el problema de reporting lo arreglas en un dashboard; el de identidad te obliga a reprocesar histórico. Sin identidad estable, la analítica se convierte en analítica de fantasmas: sabes que algo pasó, pero no a quién ni cuántas veces era el mismo.

Algora vivió esto en primera persona hace dos trimestres: su MAU de Enterprise pareció desplomarse durante un mes. Tras investigar, descubrieron que un cambio en cómo se generaba el user_id estaba contando como dos usuarios distintos a una misma persona en su portátil y en su móvil. La caída no era real, era un fantasma de identidad. Hasta arreglar el user_id y reprocesar histórico, nadie en el equipo podía afirmar con certeza si había problema de producto o solo de medición.

Los tres retos típicos al recolectar datos

Cuando un equipo empieza a montar la base de la pirámide, casi siempre se choca con los mismos tres problemas, por este orden:

1. Encontrar los datos correctos: Saber qué necesitas vs qué tienes hoy. Es un trabajo de pensar antes que de instrumentar, si no sabes qué decisiones quieres tomar este año (los objetivos del artículo 5), no sabes qué datos te van a servir.

2. Tener acceso a esos datos: Los datos de producto los tiene la herramienta de analítica, los de facturación los tiene finanzas, los del CRM los tiene ventas. Cada uno con su herramienta, sus permisos y su gente. Negociar acceso a las tres fuentes es más político que técnico, y se suele subestimar.

3. Centralizarlos para poder cruzarlos: Tener los datos repartidos en tres sitios distintos casi siempre acaba en lo mismo: exportaciones manuales los viernes por la tarde, hojas de Excel cruzadas a mano y tres versiones distintas de la verdad antes de la reunión de dirección. Algora lo vive en su día a día: datos de producto en su herramienta de analítica, datos de cuenta en el CRM, datos de facturación en Stripe. ç

Para responder «¿qué cuentas Enterprise con ARR alto están bajando su uso este trimestre?» alguien tiene que exportar tres CSVs el viernes y cruzarlos a mano. La respuesta llega con dos semanas de retraso, y para entonces el churn ya está en marcha.

Si no tienes una herramienta de analítica todavía, describe los datos de personas y de comportamiento que vas a necesitar antes de elegir herramienta, no después. Eso te va a ahorrar elegir mal cuando llegues al artículo 21 del curso.

Paso 2: de datos a métricas significativas

Tener eventos limpios y datos de personas no es suficiente. Hay que convertirlos en métricas con definición compartida que el equipo entero entienda igual. Aquí es donde casi todos los equipos se atascan, según vimos en el diagnóstico del artículo anterior.

Las tres dimensiones: amplitud, profundidad, frecuencia

Casi todas las métricas de uso de producto encajan en una de estas tres dimensiones, y conviene tener al menos una de cada para no quedarse cojo:

• Amplitud (Breadth): Cuántos usuarios o cuentas están extrayendo valor. Ejemplos: MAU, cuentas activas, usuarios activos por cuenta. Responde a «¿cuánta gente lo usa?».
• Profundidad (Depth): Cuánto del producto usan. Ejemplos: número de módulos usados, número de funcionalidades clave tocadas en el mes, tickets gestionados por usuario. Responde a «¿con qué intensidad lo usan?».
• Frecuencia (Frequency): Con qué frecuencia vuelven. Ejemplos: stickiness DAU/MAU, sesiones por usuario semana, días activos por mes. Responde a «¿con qué regularidad vuelven?».

(Si te suenan estas tres, es porque son tres de los cuatro inputs B/D/F/E que ya viste en el artículo de la NSM. La cuarta, Efficiency, suele venir después y la retomaremos cuando hable de funnels.)

Un ejemplo aplicado a un CRM B2B para que se vea cómo encajan las tres:

• Amplitud: 4,2 usuarios activos por cuenta de media (sobre 8 licencias contratadas). El 52% de licencias.
• Profundidad: los usuarios activos usan 3,8 módulos del producto en el mes (contactos, deals, informes…). De 6 módulos disponibles.
• Frecuencia: stickiness DAU/MAU de 0,42. El usuario activo entra ~13 días al mes.

Las tres juntas pintan una imagen completa: cuántos, cuánto y con qué regularidad. Una sola dimensión casi siempre cuenta una historia incompleta, y aquí lo interesante no son las métricas por separado sino las combinaciones.

Algunos patrones que suelo encontrar y me han explotada en la cara:

• Mucha amplitud + poca profundidad → tu onboarding es superficial. Entra mucha gente, pero no llega al valor del producto.
• Mucha profundidad + poca amplitud → producto potente pero nicho. Lo dominan los power users y poca gente más se atreve.
• Mucha frecuencia + poca profundidad → hábito sin valor real. Vuelven, pero hacen lo mínimo.
• Mucha profundidad + poca frecuencia → uso de «una vez al mes» para algo concreto. Puede ser correcto si tu producto es estacional o fiscal, mala señal si esperas hábito diario.
• Las tres altas → producto sano. La diana, no el punto de partida.

Mirar las combinaciones, convierte estas tres métricas en una lectura rápida de la salud del producto, no solo en una clasificación de KPIs.

Volviendo a Algora: al cruzar amplitud y profundidad por cuenta Enterprise, descubren que los usuarios activos por cuenta siguen iguales (4,1 vs 4,2 hace seis meses), pero los módulos usados por usuario han caído de 3,2 a 1,8. La amplitud parece que está bien, lo que se está desplomando es la profundidad. Si solo hubieran mirado la métrica agregada de «uso del producto», la señal estaba escondida, la caída de retención no es por falta de usuarios, es porque los que entran están usando menos del producto, y eso pide una intervención muy distinta (revisar onboarding y descubrimiento, no atraer más usuarios).

La trampa de las métricas vanidosas

El error más común al refinar datos en métricas es quedarse con métricas que suben fácil pero no significan nada. MAU sin definición de actividad, signups, descargas, sesiones que duran tres segundos. Aquí hay una ley clásica de gestión que conviene tener presente, conocida como ley de Goodhart:

Cuando una métrica se convierte en objetivo, deja de ser una buena métrica.

Aterrízalo al comportamiento del equipo y se ve clarísimo. Imagina que Algora decidiera atacar la caída de retención poniendo como objetivo del trimestre «subir las sesiones de las cuentas Enterprise». Encontraría formas de fabricarlas en una semana: emails de reactivación agresivos cada lunes, notificaciones push innecesarias, banners que obligan a entrar dos veces para hacer una sola acción.

La métrica sube. El producto no mejora, y peor todavía: las cuentas Enterprise siguen cayendo, ahora ocultas detrás de una curva de sesiones más alta que disimula el problema durante un par de meses más. La métrica deja de medir lo que medía y empieza a medir el esfuerzo del equipo por moverla.

Dos reglas que ayudan a evitar la trampa, las dos del curso:

• Define «activo» como acción de valor, no como login (recordatorio del artículo 6). Si «activo» es «ha hecho login», la métrica sube cuando alguien entra a mirar y se va. Eso no es valor para el usuario.
• Mira siempre con segmentación: La media oculta historias, un MAU global plano puede esconder un Enterprise que cae al 30% compensado por un Free que sube al 60%, y eso suele ser un problema serio camuflado.

Tres retos típicos al definir métricas

Y por último, los tres tropezones más comunes al definir las métricas con el equipo:

1. Definir las métricas iniciales: Distintas personas priorizan distinto, producto quiere ver retención, ventas quiere ver demos, soporte quiere ver tickets. No es malo en sí, pero hay que decidir cuáles son las del equipo de producto sin perder de vista las de los demás.
2. Definir qué significa que la métrica vaya bien o mal: Y aquí está uno de los problemas más infratratados de producto y que he aprendido hace poco.
   Definir la métrica es el primer paso. El paso que casi nadie cierra es acordar el rango sano: a partir de qué número nos preocupamos, y a partir de cuál celebramos. Muchas discusiones de producto no son «¿cuál es el número?», son «¿debemos preocuparnos por este número?». Un MAU que sube puede ser éxito o problema, depende del segmento y de la profundidad. Si el equipo no ha acordado de antemano qué rango se considera bueno, cada reunión se discute desde cero.
3. Conseguir consenso entre equipos: Es el cuello de botella más lento, se resuelve con conversación abierta y, sobre todo, involucrando a los escépticos pronto, como ya vimos en el artículo 9.

Cómo empezar si vienes desde cero

Te dejo el orden que aplico cuando entro en un equipo nuevo o ayudo a montar la base de la pirámide:

1. Identifica a los stakeholders: Producto, ingeniería, ventas, customer success, marketing. Quién va a usar los datos y quién va a sufrir si no están bien.
2. Define los objetivos del producto del año: Vuelta al artículo 5: uno o dos objetivos, no cinco.
3. Reúne a los stakeholders y acuerda 4-6 métricas que respondan a esos objetivos. Cada una con su cálculo claro (ver artículo 7 para el filtro SMART). El acuerdo se documenta, no se memoriza.
4. Construye el plan de tracking: Qué eventos necesitas para esas métricas, cuáles ya están instrumentados, cuáles faltan y quién los instrumenta. Esta es la base del documento de estrategia analítica del artículo 9.

Cuatro pasos que parecen poco, pero hechos bien te llevan, mínimo, tres o cuatro semanas si todo va bien o si el equipo es pequeño. Recuerda que la analítica no es retroactiva, lo que no instrumentas hoy, no lo tienes mañana.

Resumen rápido

• Datos de personas + datos de comportamiento: Las dos familias que vive cualquier sistema de analítica. La diferencia con la analítica web pura es que aquí se cruzan también con CRM y Pagos.
• Tres retos al recolectar: encontrar los datos correctos, tener acceso a ellos y centralizarlos. El acceso suele ser más político que técnico.
• Amplitud, profundidad, frecuencia: Tres dimensiones complementarias para construir métricas de uso., conviene tener al menos una de cada.
• Cuidado con las métricas vanidosas: Define «activo» como acción de valor y segmenta siempre.
• Cuatro pasos para empezar: stakeholders → objetivos → métricas → plan de tracking. Tres o cuatro semanas bien invertidas pueden ahorrarte años de deuda y decisiones tomadas a ciegas, te lo digo, por que lo he sufrido mucho en mis inicios.

Siguiente paso

Con los datos limpios y métricas con definición compartida con el equipo, toca subir los siguientes tres escalones de la pirámide: construir reportes que muevan decisiones, tomar acción con ellos y aspirar a integrar la analítica en la cultura del equipo. Eso lo cuento en el siguiente artículo.

De los informes a la acción: paths, funnels, retention y cultura analítica →