Métricas de adopción de funciones: qué medir y cómo

Feature adoption metrics title card illustration

Las métricas de adopción de funciones te indican si las personas que podrían utilizar una función realmente lo hacen, con qué rapidez llegan a utilizarla y si siguen volviendo a ella. El conjunto básico está formado por la tasa de adopción, la amplitud, la profundidad, el tiempo de adopción y el uso repetido. Analízalas en conjunto, ya que cualquiera de ellas por sí sola puede llevarte a conclusiones erróneas.

Esta guía explica qué significa cada métrica, cómo calcular la tasa de adopción sin engañarte a ti mismo, cómo configurar los eventos que la sustentan y cómo presentar las cifras de forma que tu equipo pueda verlas. Nos dedicamos a crear paneles de control, así que te mostraremos dónde encaja un panel de control y dónde no.

dashrendrapp.dashrendr.comPon a la vista las métricas de adopción de funcionesCrea paneles personalizados para realizar un seguimiento interno de la adopción de funciones, incrústalos en tu producto o programa informes de métricas por correo electrónico.Prueba el entorno de pruebas

En resumen

La tasa de adopción de una función se calcula dividiendo el número de usuarios que la han adoptado entre el número de usuarios elegibles, no entre el total de usuarios. Define los criterios de elegibilidad y el evento de adopción antes de medir nada.
Utiliza un pequeño conjunto de métricas: tasa de adopción, amplitud, profundidad, tiempo de adopción y uso repetido. Cada una de ellas señala un tipo diferente de fallo.
Realiza un seguimiento de una función como si fuera un embudo: expuesta, activada, utilizada, utilizada de nuevo. El paso con mayor caída te indica qué debes corregir.
Compara cohortes que hayan tenido el mismo tiempo para convertirse; de lo contrario, los pasos posteriores del embudo parecerán peores de lo que son.
dashrendr es una plataforma de análisis para equipos de SaaS. Los paneles de control pueden integrarse en tu producto, aparecer en pantallas internas o enviarse en un correo electrónico programado, con una prueba gratuita de 14 días y sin necesidad de tarjeta de crédito.

Índice

Qué mide realmente una métrica de adopción de una función
Las métricas fundamentales de adopción de funciones
Define primero los usuarios elegibles y el evento de adopción
Crea el embudo: exposición, activación, uso y uso repetido
Instrumenta los eventos correctamente
Interpreta las cifras sin engañarte a ti mismo
Convierte los datos en acciones
Perspectiva: dónde deben situarse las cifras
Incluye las métricas de adopción en un panel de control
Una configuración sencilla con la que puedes empezar esta misma semana
Preguntas frecuentes
Fuentes

Qué mide realmente una métrica de adopción de una función

Una métrica de adopción de una función realiza un seguimiento del uso de una funcionalidad específica. La adopción del producto analiza el producto en su conjunto. Product Led Alliance lo plantea como una diferencia entre lo micro y lo macro: la adopción de una función es el análisis de componentes individuales, mientras que la adopción del producto es la visión holística de si el producto aporta valor.

Esta distinción es importante en la práctica. Un cliente puede tener una cuenta activa y en buen estado y, aun así, no llegar a utilizar nunca tu nueva función de informes. Las cifras a nivel de producto (inicios de sesión, cuentas activas semanales) parecerán correctas, mientras que la función que has tardado un trimestre en desarrollar permanece inactiva. Las métricas a nivel de función son las que te permiten detectar eso.

También ayuda separar la activación. La activación es el primer momento en el que un nuevo usuario obtiene valor del producto en su conjunto. La adopción de funciones es lo que ocurre después, función por función. Si quieres conocer la versión a nivel de producto, lo tratamos en nuestra guía sobre la tasa de activación.

What a feature adoption metric actually measures — overview diagram

Las métricas clave de adopción de funciones

Los proveedores las definen de forma ligeramente diferente, así que establece tu propia definición y cíñete a ella. Estas son las que merece la pena seguir.

Métrica	A qué responde	Fórmula o definición típica
Tasa de adopción	¿Qué porcentaje de usuarios elegibles utiliza la función?	Usuarios que la utilizan / usuarios elegibles × 100
Alcance	¿Qué grado de difusión tiene entre la base de usuarios?	Cuentas o usuarios con al menos un uso / base elegible
Profundidad	¿Con qué intensidad y regularidad se utiliza?	Usos por usuario a la semana, o acciones distintas dentro de la función
Tiempo de adopción	¿Cuánto tiempo transcurre desde el primer acceso hasta el primer uso real?	Mediana de días u horas desde que se cumple el requisito hasta el momento de la adopción
Uso repetido	¿Vuelven los usuarios?	Porcentaje de usuarios que vuelven a utilizarlo dentro de un plazo determinado
Tasa de abandono	¿En qué punto del proceso abandonan los usuarios?	Usuarios perdidos entre dos pasos del embudo

Tasa de adopción: tu punto de referencia

La guía de Plane describe el cálculo como el número de usuarios que han adoptado la función dividido por el número total de usuarios elegibles. Dos palabras de esa frase son clave: «adoptado» y «elegible». Volveremos sobre ambas más adelante.

Amplitud y profundidad: un dúo diagnóstico

La amplitud mide hasta qué punto se utiliza una función entre tu base de usuarios. La profundidad mide la intensidad y la constancia de ese uso, según la misma guía de Plane.

Una amplitud baja y una profundidad alta suelen indicar un problema de descubrimiento. A quienes descubren la función les encanta, pero la mayoría de la gente nunca la ve. Una amplitud alta y una profundidad baja suelen indicar curiosidad sin valor: todo el mundo hizo clic una vez, pero nadie se quedó. La documentación sobre el ciclo de vida de las funciones de GraphJSON señala lo mismo, advirtiendo de que una prueba amplia sin uso repetido es una situación diferente a la de un valor profundo en un público más reducido.

Tiempo de adopción

El tiempo de adopción es el lapso que transcurre entre el momento en que un usuario es capaz de utilizar la función y el momento en que realmente la utiliza para algo concreto. Un lapso prolongado apunta a fricciones en el recorrido: navegación oculta, un primer paso confuso, un requisito previo que falta. También es la métrica que relaciona más claramente el desarrollo de la función con la incorporación, ya que un recorrido lento hacia tus funciones clave es un recorrido lento hacia el valor.

Uso repetido y frecuencia

Un uso demuestra curiosidad. Un segundo y un tercero demuestran que se ha convertido en un hábito. La documentación de Amplitude sobre la adopción de funciones enumera ejemplos de medidas de adopción que incluyen el porcentaje de primer uso, el promedio de usos por usuario al día, los usos en 30 días por usuario y los usuarios que vuelven tras el primer uso. Elige el periodo que mejor se adapte a la frecuencia con la que debería utilizarse la función. Una función de exportación de facturación mensual y otra de bandeja de entrada diaria requieren definiciones diferentes de «repetición».

Otras métricas que encontrarás

La documentación de Heap define varias más: frecuencia de uso (interacciones por usuario), conversión del flujo de trabajo (el porcentaje de usuarios que completan el flujo de la función) y adopción por sesión (el porcentaje de sesiones que incluyen la función). Son útiles, pero añádelas solo cuando una métrica principal plantee una pregunta que ellas puedan responder. Diez métricas por función es una costumbre a la hora de elaborar informes, no una información relevante.

Define primero los usuarios elegibles y el evento de adopción

La mayoría de las cifras de adopción erróneas se deben a dos definiciones imprecisas.

Usuarios elegibles. Un usuario elegible es aquel para quien la función es relevante, por ejemplo, por rol, plan o tipo de cuenta. Si tu función de aprobaciones solo existe en el nivel Premium, contar a todos los usuarios del nivel gratuito en el denominador hace que la tasa parezca pésima y no te dice nada. La misma lógica se aplica a los administradores frente a los lectores, o a las cuentas que no han conectado los datos que necesita la función.

El evento de adopción. Las directrices de Plane indican que el evento debe ser una acción significativa que indique que el usuario ha obtenido valor. Abrir la página de configuración no es adopción. Guardar un informe configurado sí lo es. Exportar un archivo, también. Enviar la primera invitación, igualmente.

Una prueba rápida: si le mostraras el evento a un cliente, ¿estaría de acuerdo en que ha utilizado la función? Si no es así, elige un evento posterior.

Anota ambas definiciones en una frase cada una. Por ejemplo: «Elegible»: propietario o administrador de cualquier cuenta de pago creada hace más de 7 días. «Adoptado»: ha programado al menos un informe. Esa frase debe aparecer en el panel de control junto a la cifra.

Un ejemplo práctico

Supongamos que 400 cuentas cumplen los requisitos para la función de informes programados. En los últimos 30 días, 88 de ellas han programado al menos un informe. La tasa de adopción es de 88 / 400 = 22 %. De esas 88, 61 enviaron un informe en al menos dos momentos distintos, por lo que el uso repetido es de 61 / 88, aproximadamente el 69 %. La cifra de exposición podría indicar que solo 150 de las 400 cuentas elegibles abrieron alguna vez la página de informes.

Proportional stages from eligible accounts to repeat users

Ahora el panorama está más claro. De quienes vieron la función, 88 de 150 (aproximadamente el 59 %) la adoptaron, y la mayoría de ellos se mantuvieron fieles a ella. El eslabón débil es el descubrimiento, no el valor. Dedicarías tu próximo sprint a la ubicación y a las indicaciones de incorporación, no a rediseñar la función. Ese es el tipo de decisión que estas métricas están llamadas a respaldar.

Crea el embudo: exposición, activación, uso y uso repetido

Userpilot describe un embudo de adopción de funciones de cuatro etapas: exposición, activación, uso y uso repetido. Es un marco útil porque cada punto de abandono sugiere una solución diferente.

De «expuesta» a «activada». Los usuarios la vieron, pero no la pusieron en marcha. Solución: facilidad de descubrimiento, denominación, indicaciones dentro del producto.
De «activada» a «utilizada». Empezaron, pero no completaron la acción principal. Solución: fricción, pasos de configuración, falta de valores predeterminados.
De «utilizada» a «utilizada de nuevo». La completaron una vez y la abandonaron. Solución: el valor era escaso, falta el desencadenante del hábito o la función es, por naturaleza, una tarea puntual.

Para las funciones de tipo flujo de trabajo, Heap sugiere definir eventos de «Inicio de la función» y «Fin de la función», crear un embudo para ver cuántos usuarios completan el flujo, añadir pasos para identificar los mayores puntos de abandono y agrupar por segmentos para comparar el rendimiento. Los segmentos que vale la pena probar primero son: plan, rol, tamaño de la empresa y cohorte de registro.

Configura correctamente el embudo

La fiabilidad de un embudo depende de su configuración. El curso de análisis de productos de Kolom las enumera: la unidad de recuento (usuarios, cuentas, tiendas), las definiciones exactas de los eventos, si se requiere un orden concreto, la ventana de conversión (por ejemplo, 7 días) y la definición de la cohorte. Si modificas cualquiera de estos parámetros, las cifras cambiarán, así que anótalos junto al gráfico.

Implementa los eventos correctamente

No se puede medir la adopción si no se ha registrado. La documentación de planificación de eventos de Amplitude explica que los eventos registran las acciones de los usuarios y que las propiedades añaden contexto, como el nivel del plan o el rol, y que esos eventos alimentan la segmentación, los embudos y las cohortes. Para el SaaS, señalan métricas como la frecuencia de eventos clave, el tiempo hasta el evento clave y el análisis por rol o estado de pago.

Una lista de comprobación práctica para empezar con cada función que te interese:

Un evento por exposición (la función estaba visible o se abrió la página).
Un evento para la primera acción significativa (tu evento de adopción).
Un evento por finalización, si la función es un flujo de trabajo.
Propiedades de cada evento: ID de usuario, ID de cuenta, plan, rol y marca de tiempo.
Una convención de nomenclatura estable, por escrito, para que «report_scheduled» nunca se convierta en «ScheduleReport» seis meses después.

Si no dispones de una herramienta de seguimiento, puede que no la necesites para empezar. Si tu producto registra su propia actividad en una base de datos, es posible que la respuesta ya se encuentre en una tabla. Mostramos una versión de ello en nuestra guía sobre el panel de métricas SaaS de PostgreSQL. Si tus eventos se encuentran en Google Analytics, la guía de adopción de funciones de GA4 recomienda separar la exposición, el primer uso y el uso repetido, y señala que un embudo cerrado puede medir esa progresión junto con el tiempo transcurrido entre los pasos.

Interpreta las cifras sin engañarte a ti mismo

Compara lo comparable

Según Kolom, el error más común en los embudos es mezclar cohortes en diferentes etapas. Si la mitad de tus usuarios se registraron ayer y tu ventana de conversión es de 7 días, aún no pueden haber completado los pasos posteriores, por lo que el embudo parece peor de lo que es en realidad. Incluye únicamente las cohortes que hayan completado el periodo completo. Las vistas de cohortes también dejan claro si una función mejora para los nuevos usuarios registrados. Lo explicamos en nuestra guía de análisis de cohortes.

Analiza una caída antes de entrar en pánico

Cuando caen los eventos de una función, el abandono es solo una de las explicaciones. GraphJSON recomienda desglosar el cambio en: elegibilidad, número de usuarios que la adoptan, frecuencia de uso, estacionalidad, fallos de seguimiento o entrega, migración a una función sustitutiva y abandono real. Según nuestra experiencia al analizar los paneles de control de productos, el fallo de seguimiento es lo último que la gente comprueba y lo primero que debería comprobar. Una implementación que haya cambiado el nombre de un evento parece exactamente como si los usuarios hubieran perdido interés.

Ten cuidado con los valores de referencia

Encontrarás cifras publicadas sobre la «adopción media de funciones». Tómalas, como mucho, como una referencia aproximada. Las definiciones de usuarios elegibles, eventos de adopción y ventanas temporales varían enormemente, y una tasa del 20 % en una herramienta de administración especializada puede ser más positiva que un 60 % en un botón de la navegación principal. Tu mejor punto de referencia es tu propio historial, por cohorte, con una definición fija.

Utiliza un sistema, no una sola cifra

Los equipos que se basan en una única métrica tienden a optimizarla hasta dejarla sin sentido. Profesionales del producto como Aakash Gupta y Ramli John abogan por una métrica «estrella polar» con métricas secundarias de control. Para una función, esa podría ser la tasa de adopción como indicador principal, con el uso repetido y el tiempo de adopción como métricas de control.

Convierte los datos en acción

La medición importa cuando cambia lo que haces a continuación. Hay tres estrategias que funcionan bien.

Crea un segmento de usuarios inactivos por cada función. Heap recomienda crear un segmento de usuarios que no hayan realizado el evento de uso en los últimos 30 días para cada función infrautilizada, de modo que puedas estudiar y dirigirte a ese grupo. Los usuarios que cumplan los requisitos y nunca la hayan probado son tu mejor público para un correo electrónico o un recordatorio dentro de la aplicación.

Activa intervenciones basadas en cohortes. Amplitude documenta la sincronización de cohortes con herramientas integradas en la aplicación, por ejemplo, con CommandBar, de modo que los usuarios que no hayan adoptado funciones clave reciban una guía paso a paso.

Comparte la métrica entre equipos. Gupta y John también insisten en que los equipos de producto, marketing y éxito del cliente deben alinearse en torno a métricas de activación compartidas. Si el equipo de éxito del cliente persigue cifras diferentes a las del equipo de producto, los cambios en la incorporación se estancan. Un panel de control compartido es una forma económica de solucionar eso.

Perspectiva: dónde deben residir las cifras

Creemos que el mayor problema de adopción no es la fórmula. Es que las cifras se encuentran en una herramienta a la que solo una persona tiene acceso, por lo que nadie actúa en función de ellas.

Por eso hemos creado dashrendr como capa intermedia. Las bibliotecas de gráficos te obligan a crear tú mismo los diseños, la multitenencia y las exportaciones. Las herramientas de BI para empresas pueden superar los 1.000 dólares al mes y su configuración requiere un esfuerzo considerable. Una vista de adopción de funcionalidades es algo sencillo: unas cuantas fichas, un embudo, una tabla de cohortes. No debería ser necesario un proyecto.

Nuestra opinión es que cada cifra debe mostrarse a las personas que pueden cambiarla. La tasa de adopción y el embudo deben aparecer en una pantalla que el equipo de producto consulte semanalmente. Los lunes se envía un breve resumen al equipo de éxito del cliente por correo electrónico. Si la función es importante para los clientes, muéstrales su propio uso dentro de tu producto, tal y como describimos en nuestra página de casos de uso de análisis de producto. Los clientes que pueden ver lo que utilizan y lo que aún no han probado suelen plantear mejores preguntas a tu equipo.

Y mantén las definiciones en el panel de control. Una cifra sin su regla de elegibilidad y su evento de adopción es una cifra sobre la que alguien acabará discutiendo.

— Paloma

Incluye métricas de adopción en un panel de control

dashrendr es una plataforma de análisis para equipos de SaaS. Puedes conectar tus fuentes de datos o enviar tus propios datos a través de la API REST y, a continuación, crear paneles de control en un editor de arrastrar y soltar. Entre las fuentes compatibles se incluyen PostgreSQL, MySQL, MongoDB, BigQuery, Google Analytics y Google Sheets.

En cuanto a la adopción de funciones, esto significa que puedes:

Representar gráficamente la tasa de adopción, el alcance y el uso repetido a partir de tu propia tabla de eventos, con segmentos por plan o rol.
Utilizar paneles de control internamente para realizar un seguimiento de los KPI de tu producto en una pantalla de equipo. Consulta los paneles de control internos para ver cómo funciona.
Incrustar un panel de control en tu producto para que los clientes vean su propio uso.
Enviar por correo electrónico un panel de control de forma programada, diaria, semanal o mensual, a través de informes automatizados.

Los planes empiezan en 6 $ al mes (Hobby), con el plan Starter a 15 $ al mes, el Grow a 39 $ al mes y el Premium a 99 $ al mes. Cada miembro adicional del equipo cuesta 3 $ al mes. Todos los planes incluyen una prueba gratuita de 14 días y no es necesario facilitar ningún dato de tarjeta de crédito. Consulta la página de precios para ver qué incluye cada plan.

Una configuración sencilla con la que puedes empezar esta misma semana

Elige una función que hayas lanzado en el último trimestre y que sea importante para la retención o los ingresos.
Redacta la regla de elegibilidad y el evento de adopción en una sola frase cada uno.
Confirma que los eventos existen y que incluyen el ID de la cuenta, el plan y el rol. Soluciona las lagunas antes de crear ningún gráfico.
Crea el embudo de cuatro etapas con una ventana de conversión fija.
Añade tres mosaicos: tasa de adopción, uso repetido y tiempo medio de adopción, cada uno desglosado por plan.
Revisa únicamente las cohortes que hayan completado la ventana.
Programa un correo electrónico semanal para los equipos de producto y de éxito. Cambia una cosa y observa qué cambia.

Si quieres reflexionar sobre quién ve qué una vez que los clientes están involucrados, nuestro artículo sobre métricas para mostrar a los clientes es una buena lectura siguiente. Y si necesitas justificar el trabajo, nuestra guía sobre el ROI de la analítica te ofrece una forma de calcularlo.

Preguntas frecuentes

¿Cuál es una buena tasa de adopción de una función?

No existe una cifra universal válida para todos los casos. Depende de cómo definas a los usuarios elegibles, qué se considere adopción y cuánto tiempo esperes. Compara tus propias cohortes entre sí según una definición fija y establece objetivos por función en función de la frecuencia con la que debería utilizarse de forma natural.

¿Cómo se mide la adopción de una función?

Divide el número de usuarios que han realizado una acción significativa con la función entre el número de usuarios para los que la función es relevante. A continuación, ten en cuenta el uso repetido y el tiempo de adopción para poder distinguir entre curiosidad y hábito. Un embudo que abarque desde la exposición hasta el uso repetido muestra en qué punto se pierden los usuarios.

¿Cuál es la diferencia entre la adopción de una función y la adopción del producto?

La adopción de una función se centra en una sola característica, como por ejemplo si los usuarios utilizan los informes programados. La adopción del producto se centra en la aceptación y el uso generales de todo el producto. Puede darse una fuerte adopción del producto y una débil adopción de una función específica, por lo que es necesario tener en cuenta ambas perspectivas.

¿Qué métricas ayudan a mejorar la incorporación?

El tiempo de adopción y el abandono entre los pasos del embudo son las métricas más directas. Muestran cuánto tardan los nuevos usuarios en llegar a una función clave y en qué punto se estancan. Combínalas con vistas de cohortes para poder comprobar si los cambios recientes en la incorporación han sido realmente útiles.

Progreso

Métricas de adopción de funciones: qué hay que monitorizar y cómo hacerlo