Un dashboard puede mostrar un aumento de registros mientras los equipos que se dieron de alta el mes pasado dejan de utilizar el producto. Ambas cifras pueden ser correctas. La dificultad está en decidir qué resultado necesita atención, qué comportamiento podría explicarlo y si los datos respaldan la respuesta propuesta. Un framework de métricas de producto relaciona esas preguntas para que una revisión permita iniciar una investigación o tomar una decisión.
El marco recoge qué intenta conseguir el producto, cómo se medirá el progreso y qué otras señales podrían revelar un efecto no deseado. Su utilidad depende de las definiciones y de las decisiones que lo sostienen. Una North Star Metric, un funnel del ciclo de vida y un dashboard de ingresos pueden contribuir si el equipo entiende qué permite concluir cada medida y qué sigue siendo incierto.
Partir de un resultado y una unidad de análisis
Consideremos una aplicación ficticia de gestión de proyectos que se vende a equipos. La empresa quiere que más clientes sigan utilizándola después de la configuración inicial. Los ingresos importan para el negocio, pero una renovación llega demasiado tarde para explicar todas las dificultades de las primeras semanas. La pregunta inmediata de producto es si los equipos nuevos empiezan a colaborar y mantienen esa actividad.
La unidad es el equipo, no la persona. Un equipo puede reunir a varios usuarios y quien crea la cuenta puede no llegar a ser su miembro más activo. Mezclar registros individuales en el denominador con organizaciones activas en el numerador produciría una tasa engañosa. El marco necesita un identificador de equipo acordado y reglas para las cuentas de prueba, las organizaciones duplicadas y los clientes que pertenecen a varios equipos.
Una métrica mide una cantidad definida; un KPI es una métrica elegida para evaluar el avance hacia un objetivo. El objetivo describe el resultado buscado, como mejorar el uso continuado entre los equipos recién adquiridos. Mantener esa distinción permite explicar por qué una medida debe revisarse con regularidad y otra se reserva para investigar un problema.
Elegir una estructura que responda a la pregunta
El North Star Framework descrito por Amplitude se organiza alrededor de una medida del valor recibido por el cliente y de las métricas de entrada que contribuyen a ella. En la aplicación de proyectos, una candidata sería el número de equipos que completan trabajo colaborativo cada semana. Aun así, habría que comprobar si la actividad elegida representa valor para esos clientes y se relaciona con el uso continuado.
La perspectiva del ciclo de vida ayuda a localizar dónde dejan de avanzar los equipos: adquisición, activación, uso repetido, retención o pago. HEART, presentado en la investigación de Google sobre métricas centradas en el usuario, examina satisfacción, interacción, adopción, retención y éxito en las tareas, mediante un proceso que conecta objetivos, señales y métricas. Estas estructuras atienden necesidades distintas; se pueden aprovechar sus elementos pertinentes sin completar todas las categorías.
En este ejemplo, el equipo elige una métrica de resultado para la retención de equipos nuevos, un conjunto reducido de métricas de entrada del onboarding y guardrails de fiabilidad. El número de equipos que colaboran semanalmente aporta contexto sobre el producto. La retención de suscripciones se mantiene como KPI de negocio independiente, porque conservar una suscripción y seguir utilizando la aplicación son resultados diferentes.
Definir la actividad útil antes de contarla
Abrir la aplicación puede indicar que una persona ha vuelto, pero no demuestra que un equipo haya completado trabajo útil. Para este producto ficticio, la actividad colaborativa requiere que al menos dos miembros distintos creen, actualicen o completen tareas en el mismo proyecto compartido durante el periodo observado. Es una definición propuesta para el ejemplo, no una definición universal de interacción.
El hito de activación utiliza esa actividad durante los primeros siete días desde la creación del equipo. El cálculo es equipos que alcanzan el hito en siete días / equipos nuevos elegibles cuyo periodo de observación de siete días ha terminado × 100. Si lo alcanzan 420 de 1.000 equipos elegibles, la activación es del 42 %. Son cifras hipotéticas. Los equipos creados ayer todavía no pueden clasificarse como casos que han fallado un hito de siete días.
Un funnel permite localizar los pasos previos a ese hito: crear un proyecto, invitar a otra persona y completar trabajo compartido. Especifica la unidad, el orden y el tiempo permitido entre eventos, y elimina duplicados producidos por reintentos o eventos repetidos. Enviar una invitación y aceptarla son comportamientos distintos; ambos pueden medirse, pero responden a preguntas diferentes sobre las dificultades del onboarding.
Escribir definiciones que otro equipo pueda reproducir
El nombre de la métrica resume un cálculo. Una definición reproducible identifica la población, el evento válido, el denominador, el periodo, las exclusiones y la fuente de datos. También señala quién resolverá las ambigüedades. En la aplicación de proyectos, el marco de trabajo podría quedar así:
| Medida | Definición | Decisión que informa |
|---|---|---|
| Equipos que colaboran semanalmente | Equipos distintos que cumplen la definición de trabajo compartido durante una semana completa de lunes a domingo, en la zona horaria acordada. | Si crece la población que obtiene valor de la colaboración. |
| Activación en siete días | Equipos elegibles que alcanzan el trabajo compartido en siete días desde su creación, divididos por los equipos elegibles cuyo periodo completo de siete días ha terminado. | Qué partes de la colaboración inicial conviene investigar. |
| Retención en la cuarta semana | Equipos elegibles con trabajo compartido entre los días 21 y 27 desde su creación, divididos por los equipos elegibles cuyo periodo completo de la cuarta semana ha terminado. | Si una cohorte de equipos nuevos mantiene el uso del producto. |
| Tasa de fallo al crear proyectos | Operaciones distintas de creación fallidas divididas por todas las operaciones elegibles, agrupando los reintentos mediante un identificador de operación. | Si un cambio reduce la fiabilidad del flujo principal. |
En esta definición de retención, la fecha de creación determina el periodo de cada equipo; no se utilizan semanas del calendario. Con 200 equipos elegibles y 70 que vuelven en la cuarta semana, la retención sería del 35 %. Esa cohorte debe haber terminado el periodo antes de compararse con otra cohorte completa. También hay que indicar cómo se tratan los equipos eliminados: retirar del denominador a los clientes que no continuaron inflaría el resultado.
Separar una señal útil de una explicación causal
Supongamos que los equipos que alcanzan la activación colaborativa también presentan mayor retención en la cuarta semana. Esa asociación justifica investigar la activación, pero no demuestra que conseguir que más personas ejecuten el evento medido hará que permanezcan. Los equipos con una necesidad previa más fuerte pueden tener mayor probabilidad tanto de colaborar pronto como de volver después.
Producto e Ingeniería podrían probar un cambio del onboarding que facilite la primera tarea compartida. Antes del lanzamiento acordarían los participantes elegibles, la asignación, los criterios de éxito y el periodo de observación, incluido el resultado posterior de retención. Una mejora de la activación en siete días aporta evidencia temprana sobre el onboarding; para afirmar que existe un efecto duradero todavía hacen falta la retención de cohortes completas y un análisis adecuado al experimento.
Las métricas de entrada describen comportamientos o condiciones que el equipo considera relacionados con un resultado. Un indicador anticipado ofrece una señal temprana de un resultado posterior cuando existe evidencia de esa relación. Una métrica de resultado registra el efecto que se quiere evaluar. Estas funciones dependen de la pregunta: la activación es un resultado para un experimento de onboarding y puede servir como entrada al investigar la retención. Llamar «anticipado» a un indicador no valida su capacidad predictiva.
Los guardrails son métricas de control de efectos que el equipo no quiere empeorar al perseguir su objetivo principal. En este cambio podrían observarse los fallos al crear proyectos y las consultas de soporte sobre invitaciones. Conviene acordar cómo se interpretarán y quién podrá detener la ampliación del lanzamiento. Un aumento temporal de consultas puede reflejar confusión, un defecto o simplemente más equipos utilizando el flujo; la cifra aislada no identifica la causa.
Investigar un cambio antes de fijar el siguiente objetivo
Una caída de la retención agregada es un punto de partida. Compara cohortes con el mismo periodo de observación y examina el canal de adquisición, el plan, el tamaño del equipo u otras diferencias relevantes. Una campaña que atraiga a otro perfil de cliente puede modificar la tasa global aunque grupos comparables se comporten de forma parecida. Acompaña cada porcentaje del número de equipos que representa, especialmente en segmentos pequeños.
Revisa la instrumentación antes de interpretar una variación brusca. Un evento duplicado, un identificador ausente o un retraso del pipeline de datos pueden alterar el cálculo sin cambiar el comportamiento de los clientes. Contrasta una muestra de eventos con los registros operativos y documenta las carencias de cobertura conocidas. SQL permite examinar esos registros y reproducir cálculos por cohortes; la guía de SQL para analítica de producto desarrolla esa relación.
Con esas comprobaciones, la referencia histórica sirve para fijar un objetivo. La variación observada, la población afectada y el mecanismo por el que se espera que funcione el cambio deben orientar la ambición. Un objetivo elegido porque queda bien en una presentación aporta poca ayuda cuando hay que decidir qué problema del cliente atender.
Mantener el marco a medida que cambia el producto
Revisa los guardrails operativos con una frecuencia que permita responder a los fallos, y la retención cuando las cohortes correspondientes hayan completado su periodo. En cada revisión de producto registra qué ha cambiado, la explicación mejor respaldada, la incertidumbre y la siguiente acción. Si una métrica lleva varias revisiones sin informar ninguna decisión, reconsidera su lugar en esa reunión antes de añadir otro dashboard por costumbre.
Las definiciones también necesitan control de versiones. Si el trabajo compartido empieza a incluir un tipo de tarea nuevo, registra el cambio y comprueba si puede reproducirse el cálculo histórico. Evita presentar las definiciones antigua y nueva en una misma serie sin explicar la diferencia. La misma disciplina se aplica cuando cambian los criterios de elegibilidad, las zonas horarias o las fuentes de eventos.
Métricas de producto para Product Managers desarrolla definiciones, funnels, cohortes, North Star y guardrails mediante un SaaS ficticio. Para investigar si una variación refleja el comportamiento del producto o un fallo técnico, la guía de logs y observabilidad aporta el contexto operativo. Conserva juntos la definición, sus limitaciones actuales y la decisión que informa para que la siguiente persona pueda seguir el cálculo.
