Práctica 01.01 · Calidad del producto
Encuentra la mayor caída del embudo
No hace falta dominar de golpe todos los reportes de analítica. Traza cinco pasos claros, identifica la mayor caída y elige un cambio para el próximo release.
60 minutos para la primera auditoría
En lenguaje sencillo
Busca un punto débil de la ruta, no todos los problemas a la vez
Qué vas a necesitar
01
Cuándo aplicarla
Los registros o las primeras acciones útiles están bajando, los usuarios se quejan de la ruta y el equipo no sabe qué arreglar primero.
En lenguaje sencillo
De dónde sacar los datos
Elige la opción que el equipo ya tenga. Si la analítica no está configurada, empieza con una revisión manual: la práctica igual dará un resultado.
AppMetrica o Firebase
Abre el reporte «Embudo» y agrega: primer inicio → registro iniciado → registro completado → primera acción útil → visita de regreso.
Si no conoces los nombres de los eventos, pide a un desarrollador la lista de eventos del registro y de la primera acción útil.Una hoja de cálculo o un reporte de BI
Toma la cantidad de usuarios en cada paso para un mismo periodo. No mezcles iOS y Android en la primera revisión.
Con cinco números alcanza. No esperes un dashboard perfecto para detectar una caída grande.Si todavía no hay eventos
Recorre la ruta diez veces con una instalación limpia en iOS y en Android. Anota errores, demoras y pantallas confusas.
Escribe una especificación técnica breve para los eventos: ese será el primer resultado de la auditoría.02
Haz tu primera auditoría en cinco pasos
Dibuja la ruta
Anota cinco pasos como acciones simples del usuario, sin nombres internos de pantallas ni jerga del equipo.
- Dónde hacerlo
- Una hoja de papel, FigJam o la primera columna de la tabla final.
- Cómo se ve el resultado
- Instalación → primer inicio → registro iniciado → primera acción útil → visita de regreso.
Pon cinco números junto a los pasos
Anota cuántos usuarios únicos llegaron a cada paso durante el mismo periodo.
- Dónde hacerlo
- El reporte «Embudo» en AppMetrica o Firebase, o una exportación de un analista.
- Cómo se ve el resultado
- 1.000 abrieron la app, 820 iniciaron el registro, 460 lo completaron.
Calcula la conversión entre pasos
Divide el número del paso siguiente por el del anterior y multiplícalo por 100%. El porcentaje más bajo es el primer candidato a investigar.
- Dónde hacerlo
- En la tabla, junto a cada paso.
- Cómo se ve el resultado
- 460 ÷ 820 × 100% = 56%. Es decir, el 44% de quienes iniciaron el registro no lo terminó.
Verifica la causa
Revisa los errores y los tickets de soporte, y luego recorre el paso tú mismo. No cambies la interfaz hasta descartar un problema técnico.
- Dónde hacerlo
- Reportes de errores, tickets de soporte y una instalación limpia de la app.
- Cómo se ve el resultado
- En Android 12 el código de confirmación llega tarde y no se explica cómo reenviarlo.
Elige un cambio
Anota el cambio, su responsable y la métrica que compararás después del release. No metas varias pantallas en tu primer experimento.
- Dónde hacerlo
- Una tarea en el backlog o un plan corto para el próximo release.
- Cómo se ve el resultado
- Arreglar el reenvío del código; responsable: el equipo de Android; revisión: la tasa de registros completados a los 14 días.
03
Ejemplos prácticos
Carga lenta después del registro
El usuario creó una cuenta pero espera 40 segundos la primera pantalla y cierra la app. La prioridad es la velocidad y un estado de carga claro, no otro campo del formulario.
Rutas distintas según la plataforma
En Android el registro se completa notablemente menos que en iOS. Revisa primero los errores de esa versión concreta y después cambia la interfaz.
Una tabla para una decisión del equipo
No necesitas un reporte grande. Completa cinco filas y destaca la única caída que el equipo atenderá en el próximo release.
| Paso | Usuarios | Conversión | Qué vemos |
|---|---|---|---|
| Primer inicio | 1.000 | — | Punto de partida |
| Iniciaron el registro | 820 | 82% | Caída aceptable |
| Completaron el registro | 460 | 56% | Principal punto de caída |
| Completaron la primera acción útil | 350 | 76% | Revisar las indicaciones |
| Volvieron en D1 | 150 | 43% | Observar después del arreglo |
Conclusión: revisar primero el registro en Android — errores, campos obligatorios y tiempo de espera. Responsables: producto + desarrollador de Android.
04
Lista de verificación antes de decidir
Si falta algún punto, anótalo como una tarea aparte; no lo supongas.
05
Cómo saber si el cambio ayudó
Señal principal
La conversión en el paso problemático creció respecto al periodo anterior al release.
Métrica de control
Los errores, los cierres inesperados y las solicitudes de soporte en los pasos vecinos no aumentaron.
Resultado de negocio
Más usuarios llegaron a la primera acción útil y al FTD sin presión adicional.
El FTD es el primer depósito del usuario y el resultado de toda la ruta. Primero haz que la ruta sea clara y fiable; después revisa el resultado de negocio.