Cómo medir la adopción de features

La tasa de adopción de una feature es la proporción de usuarios elegibles que realmente la usan. La fórmula es simple — adoptantes dividido entre la población que podría adoptarla — pero el número no significa nada hasta que defines tres cosas: quién cuenta como elegible (amplitud), qué tan profundo la usan (profundidad) y en qué ventana de tiempo (tiempo). Si te equivocas en eso, lanzas un dashboard que dice 80% cuando el número honesto es 12%. Esto es un how-to: instrumenta la feature, calcula las tres métricas y actúa sobre ellas.

Prerrequisitos

• Una herramienta de analytics que capture eventos custom atados a un ID estable de usuario/cuenta — Amplitude, Mixpanel, Heap o Pendo. Heap auto-captura clicks (menos instrumentación inicial, taxonomía de eventos más desordenada); Amplitude y Mixpanel necesitan llamadas explícitas a track() (más trabajo, datos más limpios).
• Una “población elegible” definida. No todos los usuarios pueden usar cada feature — una feature detrás de un plan Enterprise tiene como denominador los seats Enterprise, no todos los seats. Escribe esta regla antes de calcular nada.
• Una definición de qué significa “usar la feature” como uno o más eventos concretos, no una vista de página. Abrir la página no es adopción; completar la acción central sí lo es.

Paso 1 — instrumenta la acción central, no la página

Dispara un único evento nombrado sobre la acción que entrega el valor de la feature. Para una feature de exportación masiva, el evento es bulk_export_completed, no export_page_viewed. En Amplitude o Mixpanel, agrega la llamada track('bulk_export_completed', { row_count, format, account_id }) en el callback de éxito de la exportación, después de generar el archivo — nunca al hacer click en el botón, porque los clicks incluyen fallos y rage-clicks. En Pendo o Heap puedes etiquetar el elemento del DOM en estado de éxito, pero un evento del lado del servidor es más confiable porque sobrevive a los ad-blockers y a los crashes del cliente.

Adjunta account_id y plan_tier como propiedades del evento para luego poder filtrar el denominador a las cuentas elegibles. Sin esto, puedes calcular la amplitud sobre todos los usuarios pero nunca sobre la población elegible — y el número de la población elegible es el que importa.

Paso 2 — calcula las tres fórmulas

Amplitud    = adoptantes / usuarios elegibles      (¿la tocaron siquiera?)
Profundidad = acciones centrales / adoptante       (¿qué tanto se apoyan en ella?)
Tiempo      = adoptantes dentro de N días de elegibilidad / usuarios elegibles en ese cohort

• Amplitud es la tasa de adopción titular. Un adoptante es cualquier usuario elegible que disparó el evento central al menos una vez en la ventana. La amplitud responde “¿esta feature aterrizó en absoluto?”
• Profundidad separa una feature que la gente prueba una vez de una feature de la que la gente depende. Calcúlala solo sobre los adoptantes (no toda la base), o una amplitud baja enmascarará una profundidad alta. Una feature con 15% de amplitud y 40 acciones por adoptante al mes es una feature de power-user, no un fracaso — trátala distinto de una con 15% de amplitud y 1.2 acciones.
• Tiempo de adopción es la amplitud medida contra un reloj de cohort. “¿Qué proporción de cuentas que se volvieron elegibles en marzo usaron la feature dentro de 30 días?” Esta es la métrica que te dice si tu onboarding hace visible la feature, y es la que la mayoría de los equipos se salta.

Ejemplo trabajado: una feature está gateada a 500 cuentas Enterprise. En una ventana de 30 días, 145 dispararon el evento central, generando 1,160 acciones centrales en total. Amplitud = 145 / 500 = 29%. Profundidad = 1,160 / 145 = 8 acciones por adoptante. Si solo 60 de las 145 adoptaron dentro de 30 días de volverse elegibles, tiempo de adopción(30d) = 60 / 500 = 12%.

Paso 3 — elige la ventana deliberadamente

La ventana no es cosmética. Una feature de uso diario (un dashboard) debe medirse sobre una ventana activa móvil de 7 o 28 días — alguien que la usó el trimestre pasado no es un adoptante hoy. Una feature de uso trimestral (una exportación de compliance) necesita una ventana de 90 días o reportarás churn que es solo estacionalidad. Empata la ventana con la cadencia natural de la feature, escríbela en la definición de la métrica y nunca compares dos features medidas en ventanas distintas.

Paso 4 — fija el piso del denominador

Para una feature con menos de un ciclo de release de antigüedad, la población elegible aún está creciendo, así que la amplitud queda artificialmente deprimida por cuentas que se volvieron elegibles ayer. Excluye cuentas elegibles por menos que la cadencia natural de la feature (p. ej. descarta cuentas elegibles por menos de 28 días para una feature de uso semanal). Reporta amplitud sobre la población madura y tiempo de adopción sobre el cohort completo — responden preguntas distintas.

Cómo se ve lo bueno

No hay un benchmark universal; la tasa de adopción es específica de cada feature. Una feature de workflow central en el rango de 40-60% de amplitud es sana; una feature de power-user o de admin viviendo en 5-15% de amplitud puede ser totalmente exitosa si la profundidad es alta entre los pocos que la adoptan. El número que debería alarmarte es una feature con amplitud baja y profundidad baja después de una ventana de cadencia completa — esa es una feature que nadie necesitaba, y la acción es retirarla o reconstruirla, no empujar más fuerte con el enablement.

Actuar sobre los datos

• Amplitud baja, profundidad alta — problema de descubrimiento. A quienes la encuentran les encanta. Hazla visible en el onboarding y en la app (guías de Pendo, prompts de empty-state), luego vuelve a medir el tiempo de adopción.
• Amplitud alta, profundidad baja — valor superficial o una feature de uso único. Si debería ser recurrente, el momento de activación no se está fijando; investiga la caída del segundo uso.
• Amplitud baja, profundidad baja, ventana completa transcurrida — candidata a eliminar. Confírmalo con un cross-tab de churn/expansión antes de retirarla, pero no sigas invirtiendo enablement en una feature que la población elegible votó en contra.

Errores comunes

• Vistas de página como adopción. Contar page_viewed infla la amplitud con todos los que entraron por accidente. Guarda: el evento central se dispara en el callback de éxito de la acción que entrega valor, nunca en la navegación o el click.
• Denominador = todos los usuarios. Dividir entre el total de cuentas cuando la feature está gateada por plan subestima la adopción entre quienes sí pueden usarla. Guarda: filtra el denominador por plan_tier/entitlement, definido en el Paso 1.
• Sin ventana, o ventanas desemparejadas. Un número acumulado de por vida de “alguna vez la usó” solo sube y no te dice nada de la salud actual. Guarda: define una ventana móvil emparejada con la cadencia de la feature (Paso 3) y nunca compares features medidas en ventanas distintas.
• Amplitud y profundidad promediadas juntas. Reportar “acciones promedio por usuario” sobre toda la base mezcla adoptantes y no-adoptantes en un medio sin sentido. Guarda: calcula la profundidad solo sobre los adoptantes.

Relacionados

• NRR vs GRR — la adopción es un indicador adelantado de la retención
• Pendo — guías in-app para impulsar la adopción de features de amplitud baja
• Amplitude — análisis de cohort y funnel para el tiempo de adopción