La fuga de onboarding de $1.3M: Cómo un botón flotante mató el crecimiento de una app fintech

"Lo intentamos todo"

La empresa es una app de fintech de mediano tamaño que ofrece cuentas digitales, transferencias P2P y crédito en cuotas. Alrededor de 1,7 millones de usuarios activos mensuales, principalmente en América Latina. Crecimiento saludable. Product-market fit real.

Pero su onboarding estaba sangrando. Solo el 23% de los usuarios que iniciaban el proceso de registro lograban completarlo.

El onboarding de fintech es difícil. Requisitos de KYC, carga de documentos, verificación de identidad. Nadie espera una tasa de finalización del 90%. Pero los benchmarks del sector para apps con flujos de verificación similares rondan el 35-45%. Este equipo estaba 12 puntos por debajo del piso.

Habían pasado cuatro meses atacando el problema. Redujeron el flujo de siete pasos a cuatro. Contrataron un UX writer para reescribir todos los textos y mensajes de error. Agregaron barras de progreso, guardado automático y captura biométrica de documentos. Corrieron pruebas A/B en botones hasta que el equipo de diseño les rogó que pararan.

Parte de eso ayudó marginalmente. Nada resolvió el problema central.

Su analítica señalaba el abandono en el Paso 2: una pantalla llamada "Datos Personales", donde los usuarios ingresaban su nombre completo, fecha de nacimiento, número de documento y nacionalidad. Más de 30.000 usuarios llegaban a esa pantalla cada mes y desaparecían sin completarla.

Lo más desesperante era esto: cuando cualquier miembro del equipo abría la app y pasaba por esa pantalla, todo se veía bien. Layout limpio. Los campos funcionaban. El teclado aparecía. Sin problemas.

Cuando los números tienen sentido, pero la historia no

Este era el snapshot mensual que el equipo de análisis miraba todos los lunes:

Iniciaron el onboarding: 84.319Llegaron a Datos Personales: 71.847Completaron Datos Personales: 41.073Completaron el onboarding completo: 19.393

El abismo entre 71.847 y 41.073 era el agujero negro. Usuarios que ya habían verificado su correo, aceptado los términos de servicio y estaban listos para entregar sus datos de identidad simplemente se detenían.

El equipo tenía hipótesis. Quizás el campo de número de documento era confuso. Quizás los usuarios todavía no confiaban en la app con su número de identificación. Quizás el formulario necesitaba validación inline. Cada hipótesis se convertía en un experimento. Cada experimento consumía 2-3 semanas y movía el número una fracción de punto porcentual.

Nadie pensó en cuestionar si la pantalla en sí estaba fundamentalmente rota para una parte de sus usuarios. Porque en sus celulares, no lo estaba.

La primera tarde con grabación de sesión

El cambio ocurrió cuando el Head de Producto decidió dejar de adivinar y empezar a observar. Configuraron la grabación de sesión de UXCam en el flujo de onboarding, lo que les llevó menos de 20 minutos.

El gerente de producto revisó el primer lote de grabaciones tres días después.

Eligieron una sesión al azar. Un usuario con un Samsung Galaxy A13 (uno de los celulares más comunes en su mercado) había llegado a través de una campaña paga en Instagram. Verificó el correo. Llegó a Datos Personales.

Cuatro campos en la pantalla: nombre completo, fecha de nacimiento, número de documento y nacionalidad.

El usuario escribió su nombre. Todo bien. Seleccionó su fecha de nacimiento en el selector de fecha. Todo bien. Luego fue a tocar el campo de número de documento.

Y apareció un modal de ayuda.

El gerente de producto se inclinó hacia adelante. El usuario cerró el modal, volvió a tocar. El modal apareció de nuevo. El usuario desplazó hacia abajo, desplazó hacia arriba, intentó tocar levemente hacia la izquierda. Esta vez se abrió el dropdown de nacionalidad. Apareció un teclado alfabético, el teclado equivocado para un campo numérico.

El usuario borró todo, intentó cambiar de campo, ingresó tres dígitos en algún lugar, se dio cuenta de que estaba escribiendo en el campo equivocado. Después de 38 segundos peleando con el formulario, tocó el botón de retroceso y se fue.

El gerente de producto vio 20 sesiones más esa tarde. Nueve de ellas mostraban exactamente la misma dificultad.

La anatomía de un bug invisible

Esto es lo que estaba pasando.

Seis meses antes, el equipo de plataforma había agregado un botón flotante de ayuda, un pequeño círculo con el ícono "?", en varias pantallas de la app. Vivía en la esquina inferior derecha, a 16dp del borde de la pantalla. En las pantallas de dashboard y de transacciones, donde fue diseñado originalmente, quedaba cómodamente por debajo de todos los elementos interactivos.

Luego el equipo de onboarding rediseñó la pantalla de Datos Personales. Nuevo layout de campos, nuevo espaciado, nueva librería de componentes. Nadie verificó si la posición fija del botón de ayuda global entraría en conflicto con el nuevo formulario.

En celulares con pantallas altas (Pixel 7, iPhone 14, Galaxy S23), había suficiente espacio vertical para que el botón flotara por debajo del último campo del formulario. Sin superposición. Sin problema. Estos eran los celulares que el equipo usaba para QA.

En celulares con viewports más cortos (Galaxy A13, Xiaomi Redmi 10, Moto G32, básicamente los dispositivos que representaban aproximadamente el 37% de su base real de usuarios), el botón se posicionaba justo encima del campo de número de documento.

Pero la superposición de posicionamiento era solo el comienzo. Tres problemas distintos se apilaban uno sobre otro:

La superposición en sí. El botón de ayuda interceptaba los toques destinados al campo de número de documento. Los usuarios recibían un modal de ayuda que no pidieron y no entendían por qué.

Activación accidental de campo. Cuando los usuarios intentaban tocar alrededor del botón de ayuda, frecuentemente golpeaban el dropdown de nacionalidad. Los objetivos de toque eran pequeños en pantallas más chicas. Esto activaba el dropdown y cambiaba el teclado al modo alfabético.

El tipo de teclado no se recuperaba. En varias versiones de Android (MIUI, One UI 3.x), una vez que el teclado alfabético aparecía por la activación del dropdown, no volvía al numérico cuando el usuario finalmente lograba enfocar el campo de número de documento. El hint de tipo de entrada no se volvía a leer después de un cambio de foco. Los usuarios veían un teclado QWERTY para un campo que esperaba números.

Cualquiera de estos problemas por separado habría sido una molestia. Juntos, convirtieron un formulario simple en una tarea imposible para más de un tercio de la base de usuarios.

El log de eventos que parecía completamente normal

Esto es lo que debería asustarte: el sistema de analítica capturaba todos los eventos en esa pantalla. Y ninguno de ellos parecía anormal.

user_reached_personal_details user_tapped_help_button user_dismissed_help_modal user_tapped_help_button user_dismissed_help_modal user_left_onboarding

Cada evento disparó correctamente. La métrica de

estaba elevada en esa pantalla, pero el equipo lo interpretó como "los usuarios necesitan más ayuda en este paso". Estaban a dos semanas de planificar un tutorial de tooltip más detallado para el formulario cuando el gerente de producto empezó a ver las grabaciones.

Estaban a punto de construir una experiencia de ayuda más elaborada para un botón que causaba el problema.

Sin crash reports. Sin logs de errores. Sin excepciones. La app hacía exactamente lo que el código le indicaba. El botón de ayuda se abría cuando se tocaba. El teclado aparecía cuando un campo recibía foco. Cada componente individual funcionaba según lo especificado.

El problema era físico. Un conflicto espacial entre elementos de UI que solo se materializaba en un rango específico de tamaños de pantalla. Las analíticas basadas en eventos son estructuralmente ciegas ante esto. Rastrean qué pasó (el usuario se fue), no por qué (porque un botón estaba cubriendo físicamente el campo que necesitaba).

Del Patrón Vago al Diagnóstico Preciso

El gerente de producto había encontrado el problema en 20 grabaciones. Pero necesitaba más que una corazonada. Necesitaba cuantificarlo, entender la distribución de dispositivos y confirmar que no había otros problemas ocultos en el flujo.

Ver mil sesiones de forma manual llevaría semanas. Así que abrieron Tara AI.

Tara es la analista de producto con IA de UXCam. No analiza tablas de eventos ni metadatos. Mira las grabaciones de sesión de la misma manera que lo haría un analista humano, cuadro a cuadro. Ve lo que los usuarios intentan hacer, dónde dudan, qué los confunde y dónde las cosas fallan silenciosamente. Detecta problemas que nunca fueron instrumentados porque nunca fueron anticipados.

El gerente de producto preguntó: "¿Por qué los usuarios están abandonando la pantalla de Datos Personales durante el onboarding?"

Tara revisó las sesiones de onboarding abandonadas, las observó e identificó el patrón central:

Análisis de Tara:

En 74 sesiones abandonadas en Datos Personales, 31 mostraron el mismo patrón de comportamiento: los usuarios intentaron repetidamente interactuar con el campo de número de documento, pero un elemento flotante de UI interceptaba sus toques.

El patrón que observo: el usuario toca el área del campo de número de documento, aparece un modal de ayuda, el usuario lo cierra, lo intenta de nuevo, el modal reaparece o se activa el dropdown de nacionalidad, el teclado muestra un layout alfabético para un campo numérico, el usuario intenta corregir y abandona después de 30-45 segundos.

Esto parece depender del dispositivo. Las sesiones en dispositivos con pantallas más grandes no muestran el problema de superposición.

Sesiones que vale la pena revisar:

• Sesión #4418: Seis intentos de toque, tres activaciones accidentales del modal de ayuda, abandona a los 41 segundos

• Sesión #4455: El usuario ingresa texto en el campo de nacionalidad por accidente, no puede recuperarse, se va

• Sesión #4502: El usuario logra pasar el campo en el segundo intento, pero abandona la siguiente pantalla (posible carryover de frustración)

Todo lo demás en el flujo funciona sin problemas. Los usuarios completan la verificación de correo sin fricción, y quienes logran pasar el campo de número de documento terminan los pasos restantes rápidamente.

Ese último insight reformuló el problema por completo. El flujo de onboarding no estaba ampliamente roto. Había un único punto de estrangulamiento, y era este campo, en esta pantalla, en un conjunto específico de dispositivos.

El gerente de producto profundizó: "Compara cómo los usuarios interactúan con el formulario de Datos Personales en sesiones exitosas versus sesiones abandonadas."

Comparación de Tara:

En las sesiones exitosas, los usuarios recorren los campos en orden (nombre, fecha de nacimiento, número de documento, nacionalidad), tocando cada campo una vez. Tiempo total en la pantalla: 20-35 segundos. Sin interacciones con el modal de ayuda. Los teclados cambian correctamente entre texto y numérico.

En las sesiones abandonadas, los usuarios llegan al campo de número de documento y se quedan atascados. Tocan 3-6 veces en la misma área. El modal de ayuda aparece 1-4 veces por sesión. Los usuarios saltan entre campos de forma errática. El tiempo en la pantalla se extiende a 35-65 segundos antes de rendirse.

El factor determinante: en las sesiones exitosas, el botón flotante no superpone el campo de número de documento. Estos parecen ser dispositivos con pantallas más grandes. En las sesiones abandonadas, el botón está posicionado directamente sobre el área de entrada del campo.

Diez minutos con Tara le dieron al gerente de producto lo que semanas de análisis manual habrían dado: la causa raíz, el patrón de dispositivos, la firma de comportamiento y sesiones específicas como evidencia para reproducir en una reunión.

La corrección en nueve días

Identificar el problema y corregirlo son cosas distintas. El botón flotante de ayuda era un componente global propiedad del equipo de plataforma. Aparecía en 14 pantallas. Moverlo para una pantalla específica implicaba crear lógica de posicionamiento especial, lo que el equipo de plataforma resistió inicialmente.

También había un stakeholder que originalmente había defendido la ubicación del botón de ayuda. "Nuestras tasas de engagement con la ayuda en esa pantalla son muy buenas", señaló en la revisión, sin darse cuenta de que esos "engagements" eran usuarios tocando accidentalmente un botón que bloqueaba lo que realmente querían.

El gerente de producto reprodujo tres grabaciones de sesión en la reunión. Un usuario intentando seis veces ingresar su número de documento. Otro llenando accidentalmente el campo equivocado y perdiéndose. Un tercero que quedó inmóvil durante 22 segundos después de su cuarto intento fallido, sin tocar nada, sin desplazarse, solo mirando una pantalla que se negaba a cooperar, antes de cerrar la app.

Esa pausa de 22 segundos cambió el rumbo de la reunión.

Nueve días después, la corrección estaba en vivo:

Posicionamiento dinámico. El botón de ayuda ahora detecta la altura del viewport y se reposiciona en la esquina superior derecha cuando superpondría elementos del formulario.

Aislamiento del área de toque. Una zona de exclusión de 12dp alrededor de los campos del formulario evita que el botón se renderice en áreas conflictivas.

Aplicación forzada del tipo de teclado. Declaraciones explícitas de tipo de entrada que se reeditan al enfocar, corrigiendo el comportamiento de teclado bloqueado en las versiones de Android afectadas.

Indicador visual de foco. Un borde de color y una animación sutil de pulso en el campo activo, para que los usuarios siempre sepan dónde está su cursor.

Primero lo lanzaron al 15% del tráfico. Las grabaciones de ese cohorte contaron toda la historia: los usuarios tocaban el campo de número de documento una vez, el teclado numérico aparecía, escribían su número y seguían adelante. El despliegue completo ocurrió 72 horas después.

El Impacto de la Corrección del Formulario

Antes:

• Finalización del onboarding: 23%

• Finalización de la pantalla de Datos Personales: 57% de quienes llegaron a ella

• Tiempo promedio en Datos Personales: 47 segundos

• Toques en el botón de ayuda por día en esa pantalla: 4.218 (en su mayoría accidentales)

• Intentos promedio de toque en el campo de número de documento antes del éxito o abandono: 3,4

Después:

• Finalización del onboarding: 41%

• Finalización de la pantalla de Datos Personales: 89%

• Tiempo promedio en Datos Personales: 22 segundos

• Toques en el botón de ayuda por día: 311 (intencionales)

• Intentos promedio de toque en el campo de número de documento: 1,1

Un aumento del 78% en la finalización del onboarding.

Usuarios activados adicionales por mes: 15.178 Ingresos promedio por usuario activado en el primer año: $87 Valor mensual recuperado: $1.320.486

A lo largo de los 11 meses que el bug existió: aproximadamente $14,5 millones en valor de cliente en el primer año, perdidos. No por una caída del servidor, una falla en el pago o una mala campaña de marketing. Porque un botón de ayuda estaba en el lugar equivocado en los celulares que sus usuarios realmente tenían.

El usuario que giró el celular

Aquí está el detalle de esta historia que no puedo dejar de pensar.

Cuando el equipo analizó los datos después de la corrección, encontró algo inesperado. Más de 200 usuarios habían completado el onboarding girando su celular al modo landscape específicamente en la pantalla de Datos Personales, y luego volviéndolo al modo portrait para el resto del flujo.

Doscientas personas descubrieron de forma independiente que el modo landscape desplazaba el layout lo suficiente como para mover el botón de ayuda lejos del campo de número de documento. Habían encontrado un workaround para un bug que el equipo de producto ni siquiera sabía que existía.

Ninguna de ellas abrió un ticket de soporte. Ninguna dejó comentarios en la tienda de apps. Simplemente lo resolvieron solas y siguieron adelante.

Por cada usuario lo suficientemente ingenioso como para descubrir eso, probablemente había mil que asumieron que la app estaba rota y se fueron. Esos usuarios querían registrarse con suficientes ganas como para experimentar girando el celular. Imagina cuántas personas tuvieron menos paciencia.

Eso es lo que caracteriza a las fallas silenciosas de UI en fintech. Los usuarios no están navegando casualmente. Ya tomaron la decisión de confiarles su identidad, sus documentos, su dinero. Cuando el formulario no coopera, no piensan "ah, debe ser un bug de UI". Piensan "algo está mal con esta app" y se registran en la competencia.

Por Qué el Onboarding Fintech Es Vulnerable

El checkout de e-commerce tiene su versión de este problema también (la historia del campo de formulario de $2M es prueba de ello). Pero el onboarding de fintech enfrenta presiones que hacen que los bugs silenciosos de UI sean aún más dañinos.

No puedes simplificar más allá del piso regulatorio. Los requisitos de KYC significan que no puedes saltarte el campo de número de documento ni posponerlo. Cada campo del formulario existe porque una regulación lo exige. Si cualquiera de ellos está roto, todo el flujo está bloqueado. No hay opción de "continuar como invitado".

La confianza se rompe en una sola dirección. Un usuario que está entregando su número de documento está haciendo un acto de fe. Cualquier fricción en ese momento no se lee como "bug menor". Se lee como "esta app no puede ser confiada con mis datos". Una vez que se forma esa impresión, es muy difícil revertirla.

El onboarding suele ser un momento único. A diferencia de un flujo de checkout donde los usuarios pueden volver la semana siguiente, el onboarding de fintech es un compromiso. Si la experiencia falla, el usuario descarga a la competencia y se registra ahí. El costo de cambio es casi nulo.

La diversidad de dispositivos no es una matriz de pruebas, es toda tu base de usuarios. Si estás sirviendo a LATAM, MENA o SEA, tus usuarios están en cientos de modelos Android diferentes con tamaños de pantalla, versiones de SO y comportamientos de teclado completamente distintos. El dispositivo que tu equipo usa para QA representa quizás el 5% de tu tráfico real.

Encuentra tu versión de este bug

Tu problema puede no ser un botón flotante. Quizás un encabezado fijo cubre la parte superior de un formulario cuando se abre el teclado. Quizás un checkbox de confirmación es inaccesible en pantallas más pequeñas. Quizás un botón de carga de documentos cae debajo del fold. Quizás el campo de OTP pierde el foco en ciertas versiones de Android.

La categoría es la misma: algo que funciona perfectamente en los dispositivos de QA pero falla en los celulares que tus usuarios reales tienen.

Configura la grabación de sesión en tus pantallas críticas de onboarding

Instala el SDK de UXCam y configúralo para capturar los pasos clave de tu onboarding: creación de cuenta, verificación de identidad, carga de documentos, primera transacción. Para apps de fintech, UXCam enmascara automáticamente el contenido de los campos sensibles, así que ves la interacción (toques, dudas, cambios de teclado) sin ver los datos reales que ingresan los usuarios. La configuración lleva menos de 20 minutos.

Guía de configuración: Centro de desarrolladores de UXCam.

Espera unos días para recolectar sesiones de tu mix real de dispositivos

Necesitas sesiones de los celulares que tus usuarios realmente tienen, no solo los de tu laboratorio de pruebas. Tres a cinco días generalmente son suficientes para ver patrones reales, especialmente en los dispositivos Android de gama media donde los problemas específicos de dispositivo tienden a concentrarse.

Apunta a Tara AI hacia tu mayor punto de abandono

En lugar de revisar manualmente cientos de sesiones, pídele a Tara que haga el análisis. Mira las grabaciones cuadro a cuadro, de la misma forma que lo haría un analista humano, pero en decenas de sesiones en minutos, no en semanas.

Comienza con: "¿Por qué los usuarios están abandonando durante [tu paso de onboarding]?"

Luego profundiza: "¿Qué patrones ves en cómo los usuarios interactúan con el formulario en [nombre de pantalla]?" o "¿Qué diferencia a los usuarios que completan la verificación de identidad de los que abandonan?"

Tara te dirá qué elementos están causando fricción, cómo se ve el patrón de comportamiento y te señalará sesiones específicas como evidencia. Detecta problemas espaciales, de teclado y fallas de interacción que nunca generan logs de errores. Exactamente el tipo de bugs que viven sin ser detectados durante meses.

Corrígelo, publícalo y convierte el monitoreo en un hábito

El gerente de producto de este equipo ahora consulta a Tara todos los lunes. Cinco minutos. "¿Hay algo nuevo en el flujo de onboarding?" Desde la corrección del botón flotante, han detectado dos problemas más, ambos menores, ambos resueltos dentro de un sprint, ambos antes de aparecer en cualquier métrica de conversión.

El $1,3 millón por mes que están recuperando no vino de una gran reformulación del producto. Vino de corregir un único botón flotante que nadie podía ver en su propio celular. La parte cara no fue la corrección. Fueron los 11 meses en que nadie sabía que estaba roto.

Session Recording como Infraestructura Fintech

Los dashboards te dicen dónde los usuarios abandonan. El análisis de falhas te dice cuándo la app se rompe. Ninguno de los dos te dice que un botón está cubriendo un campo del formulario en el 37% de los dispositivos.

Ese intervalo entre "qué pasó" y "por qué pasó" es donde viven los bugs más caros. Y en fintech, donde cada falla de onboarding es un cliente perdido a manos de la competencia, ese intervalo cuesta dinero real cada día que permanece abierto.

La grabación de sesión de UXCam te muestra lo que los usuarios realmente experimentan en sus dispositivos. Tara AI mira esas sesiones por ti, identificando fricciones, detectando patrones específicos de dispositivo y sacando a la superficie los problemas que ningún rastreamiento de eventos jamás capturará.

Comienza tu prueba gratuita hoy o solicita una demo.

Apunta a Tara hacia tu flujo de onboarding y pregunta: "¿Cuáles son las mayores fricciones que los usuarios están experimentando durante el registro?"

Puede que descubras que tu app funciona perfectamente. O puede que descubras que hay un botón flotante, o algo parecido, que te ha estado costando siete cifras en silencio.

¿Cuánto tiempo lleva el tuyo ahí?

---

El nombre de la empresa y los detalles identificatorios han sido modificados. Los bugs, los patrones de comportamiento, la naturaleza específica de dispositivo del problema y el impacto financiero son todos reales.