# Encuentra la mayor caída del embudo

- **URL canónica:** https://playbook.affpartners.io/es/apps/practices/quality-funnel/
- **Versión Markdown:** https://playbook.affpartners.io/es/apps/practices/quality-funnel/index.md
- **Módulo:** Calidad del producto
- **Tiempo:** 60 minutos para la primera auditoría

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.

## Resultado

Una tabla de embudo de cinco pasos con un punto de caída, una causa probable y un responsable del siguiente cambio.

## Busca un punto débil de la ruta, no todos los problemas a la vez

Piensa en la ruta del usuario como cinco puertas. En cada paso algunas personas se van. Tu tarea es ver en qué puerta se pierden más usuarios, entender la causa probable y arreglar eso primero.

## Qué vas a necesitar

- **Accesos:** AppMetrica, Firebase, Amplitude o cualquier reporte donde se vean las acciones de los usuarios.
- **Un colega:** Un analista o un desarrollador durante 15 minutos si no conoces los nombres de los eventos.
- **Periodo:** Los últimos 14 a 30 días, sin incidentes importantes ni picos de tráfico por publicidad.

## Términos en lenguaje sencillo

- **Funnel — Una secuencia de pasos que lleva a un resultado:** Definición: Compara la cantidad de usuarios en cada paso y revela la mayor caída. Ejemplo: Instalación → primera apertura → registro → primera acción útil → visita de regreso.
- **Conversion — La proporción de personas que pasan al siguiente paso:** Definición: Muestra cuántas de las personas que empezaron un paso lo completaron o llegaron al siguiente. Ejemplo: 80 registros completados de 100 iniciados: 80 ÷ 100 × 100% = 80% de conversión.
- **Analytics event — El registro de una acción concreta del usuario:** Definición: La app envía un evento cuando un usuario abre una pantalla, toca un botón o completa una acción. Ejemplo: registration_started y registration_completed muestran cuántas personas abandonan el registro.
- **FTD — El primer depósito de un usuario:** Definición: La primera vez que un usuario registrado fondea su cuenta. Es el resultado de toda la ruta, no un botón suelto que haya que promocionar con más insistencia. Ejemplo: Si 100 personas completan el registro y 24 hacen un primer depósito, la conversión a FTD es del 24%.
- **D1 / D7 / D30 — Regreso a los 1, 7 o 30 días:** Definición: La D viene de day, día. La métrica muestra qué proporción de un grupo de usuarios nuevos volvió después del número de días elegido. Ejemplo: D7 = 18% significa que 18 de cada 100 usuarios nuevos volvieron a los siete días.
- **Crash-free rate — La proporción de usuarios sin cierres inesperados de la app:** Definición: Cuanto más cerca del 100%, menos usuarios sufrieron un cierre inesperado de la app durante el periodo elegido. Ejemplo: Un 99,5% de usuarios crash-free significa que el 0,5% sufrió al menos un cierre inesperado.
- **ANR — Un bloqueo de una app de Android:** Definición: Android registra un ANR cuando la interfaz deja de responder al usuario durante demasiado tiempo. Ejemplo: El usuario toca un botón, la pantalla se congela y Android ofrece cerrar la app.

## 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.

## 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**
  - **Fuente:** Abre el reporte «Embudo» y agrega: primer inicio → registro iniciado → registro completado → primera acción útil → visita de regreso.
  - **Si no hay acceso:** 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**
  - **Fuente:** Toma la cantidad de usuarios en cada paso para un mismo periodo. No mezcles iOS y Android en la primera revisión.
  - **Si no hay acceso:** Con cinco números alcanza. No esperes un dashboard perfecto para detectar una caída grande.
- **Si todavía no hay eventos**
  - **Fuente:** Recorre la ruta diez veces con una instalación limpia en iOS y en Android. Anota errores, demoras y pantallas confusas.
  - **Si no hay acceso:** Escribe una especificación técnica breve para los eventos: ese será el primer resultado de la auditoría.

## Haz tu primera auditoría en cinco pasos

1. **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.
   - **Ejemplo:** Instalación → primer inicio → registro iniciado → primera acción útil → visita de regreso.
2. **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.
   - **Ejemplo:** 1.000 abrieron la app, 820 iniciaron el registro, 460 lo completaron.
3. **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.
   - **Ejemplo:** 460 ÷ 820 × 100% = 56%. Es decir, el 44% de quienes iniciaron el registro no lo terminó.
4. **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.
   - **Ejemplo:** En Android 12 el código de confirmación llega tarde y no se explica cómo reenviarlo.
5. **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.
   - **Ejemplo:** Arreglar el reenvío del código; responsable: el equipo de Android; revisión: la tasa de registros completados a los 14 días.

## 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.

## Artefacto final: 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.

## Lista de verificación antes de decidir

Si falta algún punto, anótalo como una tarea aparte; no lo supongas.

- [ ] Los cinco pasos están nombrados como acciones del usuario, no como pantallas internas.
- [ ] Cada paso tiene un número del mismo periodo.
- [ ] iOS y Android se revisan por separado.
- [ ] Se revisaron los errores técnicos y las solicitudes de soporte antes de cambiar la interfaz.
- [ ] Hay un cambio elegido, con responsable y fecha de revisión.

## 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.

## Regla principal

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.

## Crece con GameChange Partners

[Explorar el programa de afiliados ↗](https://gamechange.partners/es?utm_source=academy&utm_medium=referral&utm_campaign=gcpacademy)

---

- [Versión HTML](https://playbook.affpartners.io/es/apps/practices/quality-funnel/)
- [Todas las prácticas](https://playbook.affpartners.io/es/apps/)