A/B Test — Activación de Experiencia de Registro
A/B test para determinar el flujo de activación más efectivo: formulario manual vs. escaneo automático de INE como primer paso del registro.
- Empresa
- Aviva Crédito
- Mi rol
- Product Designer
- Periodo
- ene 2025 – abr 2025
Resultados
Ganó el Flujo B. El escaneo automático de INE redujo la fricción, disminuyó los errores en el ingreso del CURP y aumentó la tasa de finalización de la activación. Este resultado determinó el diseño definitivo del flujo de registro. El ingreso manual sigue disponible como opción pero representa un porcentaje mínimo del total de accesos.
Problema
Los datos de registro mostraban altas tasas de abandono y error en el flujo de activación, sin evidencia de cuál enfoque sería más efectivo para los nuevos usuarios.
Research
Muestra mínima de 1,000 usuarios únicos por variante para significancia estadística. Métricas clave: tasa de finalización del registro, tiempo promedio de completado, tasa de error en datos ingresados, y adopción del escaneo de INE en Flujo B. Duración: 4-8 semanas. Para instrumentar el test fue necesario crear nuevos eventos de analytics en el contexto de la migración de Google Analytics 3 a GA4, internalizando el proceso de creación de eventos. Participé en la construcción del dashboard de seguimiento en Looker a través de BigQuery; posteriormente el equipo de Data migró la infraestructura a DBT.
Solución
A/B test entre Flujo A (formulario manual: celular + CURP con escaneo de INE opcional) y Flujo B (escaneo de INE como primer paso para autocompletar el CURP). La distribución al 50% se gestionó con Firebase Remote Config, limitado a primeras descargas durante el periodo del test.
Aprendizajes
1. La fricción justificada reduce errores: el escaneo de INE como primer paso (Flujo B) parecía más complejo, pero eliminó los errores de tipeo en CURP y aumentó la tasa de finalización. La complejidad percibida no equivale a fricción real.
2. Firebase Remote Config como herramienta de diseño: distribuir el A/B al 50% desde una configuración remota (sin cambios de código por variante) fue la decisión que hizo el experimento viable. Sin este patrón, el test hubiera requerido dos sprints de desarrollo.
3. Crear los eventos de analytics es parte del sprint de diseño: la instrumentación de GA4 fue clave para medir la tasa de error por tipo de campo. Sin ese dato, hubiera sido imposible confirmar cuál variante ganó y por qué.
Próximos pasos
1. Propagar el patrón de escaneo de INE a otros flujos de captura documental — comprobante de domicilio y CLABE son los candidatos inmediatos donde el autocompletado podría reducir errores.
2. Medir el impacto de la migración de GA3 a GA4 en la consistencia de los eventos: el dashboard fue construido en Looker sobre BigQuery y posteriormente migrado a DBT; validar que los eventos del flujo de registro siguen siendo consistentes post-migración.