Cómo convertir los datos de uso del producto en un informe de adopción de funcionalidades (2026)

Una exportación de uso es una larga lista de eventos: ID de usuario, nombre del evento, marca de tiempo y tal vez una o dos propiedades. Un informe de adopción de funciones es un solo porcentaje. La distancia entre ambos es de tres decisiones, no una fórmula.

Qué usuarios pertenecen al denominador. Qué se considera haber usado la función. Y en qué ventana de tiempo se está midiendo.

Si cambia cualquiera de estos factores, el número varía en decenas de puntos porcentuales. El informe sigue pareciendo correcto, y ese es precisamente el problema.

Esta guía explica qué se debe definir primero, las tres rutas manuales y dónde falla cada una de ellas.

Qué necesita antes de empezar

Necesita filas a nivel de evento, no un resumen preagregado. Una fila por evento, con un identificador de usuario y una marca de tiempo.

Necesita el nombre del evento que realmente representa a la función. Esto rara vez es tan sencillo como parece, ya que la mayoría de las funciones activan varios eventos. Un dato de adopción de funciones solo es tan bueno como ese mapeo.

También necesita saber quién podría haberla utilizado. Si la función se lanzó bajo un flag para un subconjunto de cuentas, el resto de los usuarios no pertenecen al denominador.

Un control rápido de coherencia le ahorrará una hora más tarde. Cuente los usuarios únicos en la exportación y compárelo con su recuento conocido de usuarios activos. Si difieren mucho, la exportación está filtrada de una forma que no ha notado.

Las tres decisiones que cambian el número

El denominador. Todos los usuarios registrados, los usuarios activos mensuales o solo los usuarios aptos para la función. Estos producen tres porcentajes diferentes a partir de los mismos eventos. Cada cifra de adopción de funciones es una fracción, así que defina ambas mitades antes de calcular nada.

Elegir a los usuarios aptos suele ser la opción más honesta para una función recién lanzada. Todos los usuarios registrados es el número que peor se ve y el más fácil de defender como conservador.

Qué significa "usado". Activar el evento una vez, activarlo dos veces o activarlo en dos sesiones distintas. Un solo clic durante un recorrido de bienvenida no es adopción, y la mayoría de los equipos lo aprenden por las malas.

Elija un umbral y escríbalo en el informe. Dos usos en dos días distintos es una regla común y defendible.

La ventana de tiempo. La adopción no es un momento puntual. Es la proporción de usuarios aptos que realizaron la acción dentro de un período, por lo que el período forma parte de la definición.

He aquí una sutileza documentada que vale la pena conocer antes de copiar la metodología de una herramienta. La documentación de retención de Amplitude explica cómo funciona su cálculo. "Calcula los datos de retención comparando la fecha de ese evento inicial con la fecha del evento de retorno que especificó".

El rango de fechas se aplica únicamente al primer evento. Amplitude afirma claramente que "los usuarios no tienen que activar el evento de retorno durante ese período para aparecer en el análisis".

Este es un comportamiento lógico y suele sorprender a la gente. Una hoja de cálculo que filtre ambos eventos en la misma ventana de tiempo no coincidirá con la herramienta, y ninguna de las dos está equivocada.

Cómo hacerlo manualmente

Option 1: Contar usuarios únicos y luego dividir

Comience con la deduplicación, ya que los recuentos de eventos brutos no representan a los usuarios que han adoptado la función. Obtenga la lista de usuarios únicos con UNIQUE.

Luego, cuente cuántos de esos usuarios activaron el evento de la función, utilizando COUNTIFS con el nombre del evento y los límites de fecha. Divida por su recuento de usuarios aptos.

Mantenga los dos recuentos en celdas visibles en lugar de anidarlos en una sola fórmula. Alguien preguntará cuál era el denominador, y usted querrá poder señalarlo directamente.

El límite de esto es que le da un solo número sin contexto. Sabe que el 18% la adoptó, pero no sabe nada sobre quiénes son.

Option 2: Crear una tabla de flags a nivel de usuario

Una fila por usuario apto, una columna por pregunta. ¿Activaron el evento?, ¿cuántas veces? y ¿en cuántos días distintos?

Ahora puede segmentar. Adopción por plan, por cohorte de registro, por tamaño de cuenta, o por si completaron el proceso de incorporación.

Aquí es donde la adopción de funciones se vuelve accionable en lugar de simplemente reportable. Un 18% combinado oculta que los nuevos usuarios están en un 40% y los usuarios del año pasado en un 4%.

Esa brecha es el hallazgo clave. Nuestra guía sobre análisis de cohortes explica por qué la cifra combinada varía cada vez que cambia el volumen de registros, incluso si el comportamiento no cambia.

El límite es el volumen y las uniones. Una exportación de un millón de filas más una tabla de cuentas supera el punto en el que las fórmulas siguen siendo cómodas de usar.

Option 3: Mantener una pestaña de definiciones junto a los números

Anote el nombre del evento, el umbral, la ventana de tiempo, el denominador y quiénes eran aptos.

Esto es lo que hace que el informe sea comparable el próximo mes. También es la pestaña que se pasa por alto cuando alguien necesita el número en diez minutos.

La limitación es que documentar una definición no significa aplicarla. Alguien seguirá recreando los mismos cinco filtros en cada ciclo.

El límite común. Las tres opciones asumen que los nombres de los eventos están limpios. Cuando la misma acción se activa bajo tres nombres diferentes después de una refactorización de código, el verdadero trabajo consiste en conciliar esos nombres antes de empezar a contar.

Dónde se ralentiza la ruta manual

El primer informe toma una mañana. El cuarto toma más tiempo, porque para entonces la definición se ha ido desviando silenciosamente.

Los nombres de los eventos cambian cuando cambia el producto. Un cambio de nombre en la base de código se convierte en una caída abrupta en su gráfico, y se ve exactamente como si los usuarios estuvieran abandonando la función. Así es como un gráfico de adopción de funciones termina reportando un cambio de código en lugar de una decisión del cliente.

Los cambios en el despliegue rompen el denominador. La función llega al 100% de las cuentas y la adopción parece disminuir, porque la población apta se triplicó.

Luego está el error de recuento que más tiempo sobrevive. Sumar los recuentos de eventos en lugar de los usuarios únicos infla la adopción cada vez que un puñado de usuarios avanzados utiliza intensamente la función.

Hay un costo más que solo aparece cuando se acerca la fecha límite. Cuando alguien pregunta "¿eso es bueno?", un solo porcentaje no puede responder, y construir la comparación se convierte en un segundo proyecto.

Cómo crear el informe con Powerdrill Bloom

Step 1: Subir su exportación de uso

Suba la exportación de eventos, o los archivos de eventos y cuentas juntos. Powerdrill Bloom analiza el perfil de las columnas al recibirlas, por lo que los nombres de eventos inconsistentes y los ID de usuario faltantes salen a la luz antes de calcular cualquier porcentaje.

Step 2: Describir la definición en lenguaje natural

Defina las reglas en lugar de construirlas. Indique el evento, el umbral, la ventana de tiempo y qué usuarios son aptos.

Luego haga las preguntas que detectan las trampas. Pregunte si algún nombre de evento parece casi un duplicado. Pregunte cuántos usuarios únicos activaron el evento en comparación con cuántos eventos se activaron, y cómo varía la tasa de adopción de la función según el mes de registro.

Step 3: Exportar el gráfico, informe o presentación

Extraiga la tendencia de adopción, una tabla por segmento o una diapositiva que contenga el número y la definición juntos.

Por qué esto es mejor que reconstruirlo en cada ciclo

	Ruta manual	Powerdrill Bloom
Deduplicar usuarios a partir de eventos	Columnas auxiliares por archivo	Solicitar usuarios únicos
Dividir por cohorte o plan	Unir y reconstruir la tabla	Solicitar el desglose
Eventos renombrados después de un lanzamiento	Detectarlo en el gráfico más tarde	Se detecta al subir el archivo
Cambiar la población apta	Rehacer el denominador	Indicar la nueva regla

En la tercera fila es donde se gana o se pierde la precisión. Un evento renombrado y una caída real se ven idénticos en un gráfico de líneas, y solo uno de ellos requiere una respuesta por parte del equipo de producto.

Errors comunes

Contar eventos en lugar de usuarios. Diez mil eventos de doscientas personas no es adopción. Deduplique primero, siempre.

Usar todos los usuarios registrados como denominador en una función bajo un flag. Si solo un tercio de las cuentas pueden verla, los otros dos tercios no son "usuarios que no la adoptaron". Simplemente no son aptos.

Tratar un solo clic como adopción. Un único evento durante la incorporación es solo exposición. Exija un uso repetido en días distintos si quiere que el número signifique algo.

Comparar una tasa combinada a lo largo de los meses. Los usuarios nuevos y los existentes adoptan las funciones a ritmos diferentes, por lo que la mezcla de usuarios altera el número por sí sola. Divida por cohorte antes de sacar conclusiones.

Ignorar un cambio de nombre de evento. Una refactorización produce una caída abrupta que parece abandono. Revise el diccionario de eventos antes de investigar el comportamiento de los usuarios.

Copiar la ventana de tiempo de una herramienta sin leer cómo funciona. Las ventanas de retención documentadas a menudo filtran únicamente el primer evento, por lo que una hoja de cálculo que filtre ambos no coincidirá.

Reportar el porcentaje sin adjuntar una definición. El número no tiene sentido sin el denominador y el umbral. Coloque ambos en el gráfico, de la misma manera que un buen tablero de KPI etiqueta sus métricas.

Conclusión

Decida la población apta, establezca un umbral de uso, fije la ventana de tiempo y deduplique los usuarios antes de dividir. Esos cuatro pasos convierten un porcentaje de adopción de funciones en algo sobre lo que un equipo de producto puede actuar.

Lo que lo hace costoso es que la definición tiene que sobrevivir a los cambios del producto. Tanto los eventos renombrados como la ampliación de los despliegues alteran el número sin que nadie toque el informe.

Si ahí es donde se va su ciclo de informes, pruebe Powerdrill Bloom en su exportación de uso. Consulte también nuestra guía para crear un gráfico de retención de cohortes, la recopilación de herramientas de IA para analítica de producto y la página del asistente de IA para CSV.

Preguntas frecuentes

¿Qué es la adopción de funciones?

Es la proporción de usuarios aptos que utilizaron una función dentro de una ventana de tiempo definida, medida en usuarios únicos en lugar de eventos. La definición solo es válida si se especifican el denominador y el umbral de uso.

¿Cómo la calculo a partir de una exportación de eventos?

Cuente los usuarios únicos que activaron el evento de la función dentro de su ventana de tiempo y luego divida por el recuento de usuarios aptos. Deduplique primero, ya que un solo usuario puede generar cientos de eventos.

¿El denominador debería ser todos los usuarios o los usuarios activos?

Utilice la población apta, es decir, los usuarios que realmente podrían acceder a la función. Usar todos los usuarios registrados produce una cifra conservadora y subestima la adopción si la función está detrás de un flag de despliegue.

¿Qué tan larga debería ser la ventana de medición?

Lo suficientemente larga para un ciclo de uso normal; por ejemplo, semanal para productos de uso diario y mensual para productos periódicos. Manténgala fija en todos los informes, ya que cambiarla altera el número.

¿Por qué mi número difiere del de la herramienta de analítica?

Por lo general, se debe a la ventana de tiempo o a la regla de deduplicación. Los cálculos de retención documentados a menudo aplican el filtro de fecha únicamente al primer evento, algo que una hoja de cálculo construida sobre ambos eventos no reproducirá.