Diferenciación de usuarios en la app Aviva

La calificación de la app subió de 3.3 a entre 3.7 y 3.9 estrellas en Play Store. El rediseño del onboarding redujo la confusión en el acceso y habilitó dos nuevos canales de captación de prospectos: lista de espera y agendado de citas en kiosco.

La app Aviva tenía una calificación de 3.3 estrellas en Play Store, impulsada principalmente por reseñas de usuarios que no eran clientes y no podían ingresar. Dos problemas raíz: no existía un camino claro para usuarios sin cuenta Aviva, y la app no comunicaba que para iniciar sesión era necesario tener una solicitud previa en kiosco.

El punto de partida fue el análisis de reseñas negativas en Play Store para identificar patrones de fricción. El hallazgo principal: la mayoría de las quejas provenían de usuarios sin cuenta activa que no entendían el modelo de negocio. La validación incluyó un A/B test de 4-8 semanas distribuido con Firebase Remote Config, con una muestra mínima de 1,000 usuarios únicos por variante.

Diseñé una nueva experiencia de onboarding que diferencia entre tres tipos de usuario: cliente activo (préstamo vigente), usuario con solicitud previa en kiosco, y nuevo usuario sin antecedentes. Para los nuevos usuarios diseñé flujos de lista de espera y agendado de cita en el kiosco más cercano. La solución fue validada mediante un A/B test que comparó formulario manual contra escaneo automático de INE.

70.36% de tasa de conversión (activación completa de cuenta) en los primeros 90 días post-lanzamiento. Tiempo promedio de activación: 1.5 minutos desde descarga hasta cuenta activa. Los errores más frecuentes del funnel se concentraron en OTP (código no recibido) y escaneo de INE (fallos de captura), cuantificados en GA4 con eventos de diseño instrumentados por el equipo.

1. El grupo más grande de no-conversiones no tiene solución de diseño: los usuarios que descargan la app sin pasar por un kiosco Aviva no pueden avanzar en el flujo. El problema es de canal y expectativa, no de UX. Eso requiere una estrategia de comunicación pre-descarga.

2. La creación de eventos de analytics fue un bloqueador invisible: sin los eventos correctos en GA4, hubiera sido imposible medir el éxito del rediseño. Internalizar este proceso fue una decisión crítica que aceleró la capacidad del equipo de iterar con datos.

3. El OTP y el escaneo de INE son los puntos de fricción más medibles: los errores derivados de estas dos acciones son cuantificables y priorizables. Representan oportunidades de mejora con impacto directo en la tasa de conversión del 29.64% restante.

1. Reducir errores en escaneo de INE — investigar patrones de fallo (iluminación, dispositivo, orientación) y mejorar el feedback en tiempo real durante el escaneo.

2. Comunicación pre-descarga para usuarios sin kiosco — diseñar una pantalla de «no disponible aún» con CTA hacia el canal de kiosco o lista de espera.

3. Migrar infraestructura de analytics a DBT — el equipo de Data ya inició la migración de BigQuery/Looker a DBT; mantener alineación entre eventos de diseño y el nuevo modelo de datos.