O vazamento de onboarding de US$ 1,3 milhão: Como um botão flutuante matou o crescimento de um app de fintech

"Tentamos de tudo"

A empresa é um app de fintech de médio porte que oferece contas digitais, transferências P2P e crédito parcelado. Cerca de 1,7 milhão de usuários ativos mensais, principalmente na América Latina. Crescimento saudável. Product-market fit real.

Mas o onboarding estava sangrando. Apenas 23% dos usuários que iniciavam o cadastro conseguiam concluí-lo.

Onboarding de fintech é difícil. Requisitos de KYC, upload de documentos, verificação de identidade. Ninguém espera 90% de conclusão. Mas os benchmarks do setor para apps com fluxos de verificação similares ficam em torno de 35–45%. Essa equipe estava 12 pontos abaixo do piso.

Eles passaram quatro meses atacando o problema. Reduziram o fluxo de sete etapas para quatro. Contrataram um UX writer para reescrever todos os rótulos e mensagens de erro. Adicionaram barras de progresso, salvamento automático e captura biométrica de documentos. Rodaram testes A/B em botões até o time de design implorar para parar.

Parte disso ajudou marginalmente. Nada resolveu o problema central.

A análise deles apontava o abandono para a Etapa 2: uma tela chamada "Dados Pessoais", onde os usuários inseriam nome completo, data de nascimento, número do documento e nacionalidade. Mais de 30.000 usuários chegavam a essa tela todo mês e desapareciam sem concluí-la.

A parte mais frustrante? Quando qualquer membro da equipe abria o app e passava por aquela tela, tudo parecia normal. Layout limpo. Campos funcionando. Teclado aparecia. Sem problemas.

Quando os números fazem sentido, mas a história não

Este era o snapshot mensal que o time de análise encarava toda segunda-feira:

Iniciaram o onboarding: 84.319

Chegaram a Dados Pessoais: 71.847

Concluíram Dados Pessoais: 41.073

Concluíram o onboarding completo: 19.393

O abismo entre 71.847 e 41.073 era o buraco negro. Usuários que já haviam verificado o e-mail, concordado com os termos de serviço e estavam prontos para fornecer seus dados de identidade simplesmente paravam.

A equipe tinha hipóteses. Talvez o campo de número de documento fosse confuso. Talvez os usuários ainda não confiassem no app com seu número de identificação. Talvez o formulário precisasse de validação inline. Cada hipótese virava um experimento. Cada experimento consumia 2–3 semanas e movia o número por uma fração de porcento.

Ninguém pensou em questionar se a tela em si estava fundamentalmente quebrada para parte dos usuários. Porque nos celulares deles, não estava.

A primeira tarde com gravação de sessão

A virada aconteceu quando o Head de Produto decidiu parar de adivinhar e começar a observar. Eles configuraram a gravação de sessão do UXCam no fluxo de onboarding, o que levou menos de 20 minutos.

O gerente de produto puxou o primeiro lote de gravações três dias depois.

Escolheram uma sessão aleatória. Um usuário com um Samsung Galaxy A13 (um dos celulares mais comuns no mercado deles) havia chegado por uma campanha paga no Instagram. Verificou o e-mail. Chegou em Dados Pessoais.

Quatro campos na tela: nome completo, data de nascimento, número do documento e nacionalidade.

O usuário digitou o nome. Tudo certo. Selecionou a data de nascimento no seletor de data. Tudo certo. Então foi tocar no campo de número do documento.

E um modal de ajuda apareceu.

O gerente de produto se inclinou para frente. O usuário fechou o modal, tocou de novo. O modal abriu de novo. O usuário rolou para baixo, rolou para cima, tentou tocar levemente à esquerda. Desta vez, o dropdown de nacionalidade abriu. Um teclado alfabético apareceu, o teclado errado para um campo numérico.

O usuário apagou tudo, tentou trocar de campo, digitou três dígitos em algum lugar, percebeu que estava digitando no campo errado. Depois de 38 segundos brigando com o formulário, tocou no botão voltar e foi embora.

O gerente de produto assistiu a mais 20 sessões naquela tarde. Nove delas mostravam exatamente a mesma dificuldade.

A anatomia de um bug invisível

Veja o que estava acontecendo.

Seis meses antes, o time de plataforma havia adicionado um botão flutuante de ajuda, um pequeno círculo com o ícone "?", em várias telas do app. Ele ficava no canto inferior direito, a 16dp da borda da tela. Nas telas de dashboard e de transações, onde foi originalmente projetado, ele ficava confortavelmente abaixo de todos os elementos interativos.

Então o time de onboarding redesenhou a tela de Dados Pessoais. Novo layout de campos, novo espaçamento, nova biblioteca de componentes. Ninguém verificou se a posição fixa do botão de ajuda global conflitaria com o novo formulário.

Em celulares com telas altas (Pixel 7, iPhone 14, Galaxy S23), havia espaço vertical suficiente para o botão flutuar abaixo do último campo do formulário. Sem sobreposição. Sem problema. Esses eram os celulares usados para QA pela equipe.

Em celulares com viewports menores (Galaxy A13, Xiaomi Redmi 10, Moto G32, basicamente os dispositivos que representavam cerca de 37% da base real de usuários), o botão se posicionava exatamente sobre o campo de número do documento.

Mas a sobreposição de posicionamento era apenas o começo. Três problemas distintos se acumulavam um sobre o outro:

A sobreposição em si. O botão de ajuda interceptava os toques destinados ao campo de número do documento. Os usuários recebiam um modal de ajuda que não pediram e não faziam ideia do porquê.

Ativação acidental de campo. Quando os usuários tentavam tocar ao redor do botão de ajuda, frequentemente acertavam o dropdown de nacionalidade. Os alvos de toque eram pequenos em telas menores. Isso ativava o dropdown e trocava o teclado para o modo alfabético.

O tipo de teclado não voltava ao normal. Em várias versões do Android (MIUI, One UI 3.x), uma vez que o teclado alfabético aparecia pela ativação do dropdown, ele não voltava para o numérico quando o usuário finalmente conseguia focar o campo de número do documento. O hint de tipo de entrada não era relido após uma mudança de foco. Os usuários viam um teclado QWERTY em um campo que esperava números.

Qualquer um desses problemas isolado seria uma inconveniência. Juntos, transformaram um formulário simples em uma tarefa impossível para mais de um terço da base de usuários.

O log de eventos que parecia completamente normal

Aqui está o que deveria te assustar: o sistema de análise capturava todos os eventos nessa tela. E nenhum deles parecia 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 disparou corretamente. A métrica de

estava até elevada nessa tela, mas a equipe interpretou isso como "os usuários precisam de mais ajuda nessa etapa". Eles estavam há duas semanas planejando um tutorial de tooltip mais detalhado para o formulário quando o gerente de produto começou a assistir às gravações.

Estavam prestes a construir uma experiência de ajuda mais elaborada para um botão que causava o problema.

Sem crash reports. Sem logs de erro. Sem exceções. O app estava fazendo exatamente o que o código mandava. O botão de ajuda abria quando tocado. O teclado aparecia quando um campo recebia foco. Cada componente individual funcionava conforme especificado.

O problema era físico. Um conflito espacial entre elementos de UI que só se materializava em uma faixa específica de tamanhos de tela. Análises baseadas em eventos são estruturalmente cegas para isso. Elas rastreiam o que aconteceu (o usuário saiu), não por quê (porque um botão estava fisicamente cobrindo o campo que ele precisava).

De "acho que vejo um padrão" a "sei exatamente o que está errado"

O gerente de produto encontrou o problema em 20 gravações. Mas precisava de mais do que um palpite. Precisava quantificar, entender a distribuição de dispositivos e confirmar que não havia outros problemas escondidos no fluxo.

Assistir a mil sessões manualmente levaria semanas. Então eles abriram a Tara AI.

A Tara é a analista de produto com IA do UXCam. Ela não analisa tabelas de eventos nem metadados. Ela assiste às gravações de sessão da forma que um analista humano faria, quadro a quadro. Ela vê o que os usuários tentam fazer, onde hesitam, o que os confunde e onde as coisas falham silenciosamente. Ela detecta problemas que nunca foram instrumentados porque nunca foram antecipados.

O gerente de produto perguntou: "Por que os usuários estão abandonando a tela de Dados Pessoais durante o onboarding?"

A Tara analisou as sessões de onboarding abandonadas, assistiu a elas e identificou o padrão central:

Análise da Tara:

Em 74 sessões abandonadas em Dados Pessoais, 31 apresentaram o mesmo padrão comportamental: os usuários tentaram repetidamente interagir com o campo de número do documento, mas um elemento flutuante de UI interceptava os toques.O padrão que observo: o usuário toca na área do campo de número do documento, um modal de ajuda aparece, o usuário o fecha, tenta de novo, o modal reaparece ou o dropdown de nacionalidade é ativado, o teclado exibe layout alfabético para um campo numérico, o usuário tenta corrigir e abandona após 30–45 segundos.Isso parece ser dependente de dispositivo. Sessões em dispositivos com telas maiores não mostram o problema de sobreposição.Sessões que merecem revisão:

• Sessão #4418: Seis tentativas de toque, três ativações acidentais do modal de ajuda, abandona aos 41 segundos

• Sessão #4455: Usuário digita texto no campo de nacionalidade por acidente, não consegue recuperar, sai

• Sessão #4502: Usuário consegue passar pelo campo na segunda tentativa, mas abandona a tela seguinte (possível carryover de frustração)

Todo o resto do fluxo funciona bem. Os usuários concluem a verificação de e-mail sem atrito, e aqueles que passam pelo campo de número do documento terminam as etapas restantes rapidamente.

Esse último insight reformulou o problema inteiro. O fluxo de onboarding não estava amplamente quebrado. Havia um único ponto de estrangulamento, e era esse campo, nessa tela, em um conjunto específico de dispositivos.

O gerente de produto foi mais fundo: "Compare como os usuários interagem com o formulário de Dados Pessoais em sessões bem-sucedidas versus sessões abandonadas."

Comparação da Tara:

Nas sessões bem-sucedidas, os usuários percorrem os campos em ordem (nome, data de nascimento, número do documento, nacionalidade), tocando em cada campo uma vez. Tempo total na tela: 20–35 segundos. Sem interações com o modal de ajuda. Os teclados alternam corretamente entre texto e numérico.

Nas sessões abandonadas, os usuários chegam ao campo de número do documento e travam. Tocam 3–6 vezes na mesma área. O modal de ajuda aparece 1–4 vezes por sessão. Os usuários pulam entre campos de forma errática. O tempo na tela se estende para 35–65 segundos antes de desistirem.

O fator determinante: nas sessões bem-sucedidas, o botão flutuante não sobrepõe o campo de número do documento. Esses parecem ser dispositivos com telas maiores. Nas sessões abandonadas, o botão está posicionado diretamente sobre a área de entrada do campo.

A correção em nove dias

Identificar o problema e corrigi-lo são coisas diferentes. O botão flutuante de ajuda era um componente global de propriedade do time de plataforma. Aparecia em 14 telas. Mover o botão para uma tela específica significava criar lógica de posicionamento especial, o que o time de plataforma resistiu inicialmente.

Havia também um stakeholder que havia originalmente defendido o posicionamento do botão de ajuda. "As nossas taxas de engajamento com a ajuda nessa tela são ótimas", ele apontou na revisão, sem perceber que esses "engajamentos" eram usuários tocando acidentalmente em um botão que bloqueava o que eles realmente queriam.

O gerente de produto reproduziu três gravações de sessão na reunião. Um usuário tentando seis vezes digitar o número do documento. Outro preenchendo acidentalmente o campo errado e se perdendo. Um terceiro que ficou imóvel por 22 segundos após a quarta tentativa frustrada, sem tocar em nada, sem rolar, apenas olhando para uma tela que se recusava a cooperar, antes de fechar o app.

Essa pausa de 22 segundos mudou o rumo da reunião.

Nove dias depois, a correção estava no ar:

Posicionamento dinâmico. O botão de ajuda agora detecta a altura da viewport e se reposiciona para o canto superior direito quando sobreporia elementos do formulário.

Isolamento de área de toque. Uma zona de exclusão de 12dp ao redor dos campos do formulário impede o botão de renderizar em áreas conflitantes.

Aplicação forçada do tipo de teclado. Declarações explícitas de tipo de entrada que são reativadas no foco, corrigindo o comportamento de teclado travado nas versões de Android afetadas.

Indicador visual de foco. Uma borda colorida e uma animação sutil de pulso no campo ativo, para que os usuários sempre saibam onde está o cursor.

Eles fizeram o rollout para 15% do tráfego primeiro. As gravações desse coorte contaram a história completa: os usuários tocavam no campo de número do documento uma vez, o teclado numérico aparecia, eles digitavam o número e seguiam em frente. O deploy completo aconteceu 72 horas depois.

O que mudou quando o formulário parou de travar os usuários

Antes:

• Conclusão do onboarding: 23%

• Conclusão da tela de Dados Pessoais: 57% dos que chegaram a ela

• Tempo médio em Dados Pessoais: 47 segundos

• Toques no botão de ajuda por dia nessa tela: 4.218 (maioria acidental)

• Tentativas médias de toque no campo de número do documento antes de sucesso ou abandono: 3,4

Depois:

• Conclusão do onboarding: 41%

• Conclusão da tela de Dados Pessoais: 89%

• Tempo médio em Dados Pessoais: 22 segundos

• Toques no botão de ajuda por dia: 311 (intencionais)

• Tentativas médias de toque no campo de número do documento: 1,1

Um aumento de 78% na conclusão do onboarding.

Usuários ativados adicionais por mês: 15.178 Receita média por usuário ativado no primeiro ano: $87 Valor mensal recuperado: $1.320.486

Ao longo dos 11 meses em que o bug existiu: cerca de $14,5 milhões em valor de cliente no primeiro ano, perdidos. Não por causa de uma queda de servidor, uma falha de pagamento ou uma campanha ruim. Porque um botão de ajuda estava no lugar errado nos celulares que os usuários realmente possuíam.

O usuário que girou o celular

Aqui está o detalhe desta história que ficou comigo.

Quando o time mergulhou nos dados após a correção, encontrou algo inesperado. Mais de 200 usuários haviam concluído o onboarding girando o celular para o modo paisagem especificamente na tela de Dados Pessoais, e girando de volta para o retrato no resto do fluxo.

Duzentas pessoas descobriram de forma independente que o modo paisagem deslocava o layout o suficiente para mover o botão de ajuda para longe do campo de número do documento. Elas haviam descoberto um workaround para um bug que o time de produto nem sabia que existia.

Nenhuma delas abriu um ticket de suporte. Nenhuma deixou feedback na loja de apps. Elas simplesmente resolveram por conta própria e seguiram em frente.

Para cada usuário engenhoso o suficiente para descobrir isso, provavelmente havia mil que simplesmente acharam que o app estava quebrado e foram embora. Esses usuários queriam se cadastrar com força suficiente para experimentar girar o celular. Imagine quantas pessoas tiveram menos paciência.

É isso que caracteriza as falhas silenciosas de UI em fintech. Os usuários não estão navegando casualmente. Eles já tomaram a decisão de confiar a você a identidade, os documentos e o dinheiro deles. Quando o formulário não coopera, eles não pensam "ah, deve ser um bug de UI". Eles pensam "tem algo errado com esse app" e vão se cadastrar em um concorrente.

Por que o onboarding de fintech é especialmente vulnerável

O e-commerce de checkout tem uma versão desse problema também (a história do campo de formulário de $2M é prova disso). Mas o onboarding de fintech enfrenta pressões que tornam os bugs silenciosos de UI ainda mais danosos.

Você não pode simplificar além do piso regulatório. Os requisitos de KYC significam que você não pode pular o campo de número do documento ou adiar para depois. Cada campo do formulário existe porque uma regulamentação exige. Se qualquer um deles estiver quebrado, o fluxo inteiro está bloqueado. Não existe saída do tipo "continuar sem cadastro".

A confiança se quebra em uma direção só. Um usuário que está fornecendo seu número de documento está dando um salto de fé. Qualquer atrito nesse momento não é lido como "bug menor". É lido como "esse app não pode ser confiado com meus dados". Uma vez que essa impressão se forma, é muito difícil revertê-la.

O onboarding geralmente é uma oportunidade única. Ao contrário de um fluxo de checkout onde os usuários podem voltar na semana que vem, o onboarding de fintech é um compromisso. Se a experiência falha, o usuário baixa um concorrente e se cadastra lá. O custo de troca é quase zero.

A diversidade de dispositivos não é uma matriz de testes, é toda a sua base de usuários. Se você atende LATAM, MENA ou SEA, seus usuários estão em centenas de modelos Android diferentes com tamanhos de tela, versões de SO e comportamentos de teclado completamente distintos. O dispositivo que sua equipe usa para QA representa talvez 5% do seu tráfego real.

Encontre a sua versão desse bug

Seu problema pode não ser um botão flutuante. Talvez um cabeçalho fixo cubra o topo de um formulário quando o teclado abre. Talvez um checkbox de confirmação seja inacessível em telas menores. Talvez um botão de upload de documento caia abaixo da dobra. Talvez o campo de OTP perca o foco em certas versões do Android.

A categoria é a mesma: algo que funciona perfeitamente nos dispositivos de QA, mas falha nos celulares que seus usuários reais carregam.

Configure a gravação de sessão nas suas telas críticas de onboarding

Instale o SDK do UXCam e configure-o para capturar as etapas principais do seu onboarding: criação de conta, verificação de identidade, upload de documentos, primeira transação. Para apps de fintech, o UXCam mascara automaticamente o conteúdo de campos sensíveis, então você vê a interação (toques, hesitações, mudanças de teclado) sem ver os dados reais que os usuários inserem. A configuração leva menos de 20 minutos.

Guia de configuração: Central de desenvolvedores do UXCam.

Aguarde alguns dias para coletar sessões do seu mix real de dispositivos

Você precisa de sessões dos celulares que seus usuários realmente carregam, não apenas dos que estão no seu laboratório de testes. Três a cinco dias geralmente são suficientes para ver padrões reais, especialmente nos dispositivos Android intermediários onde os problemas específicos de dispositivo tendem a se concentrar.

Direcione a Tara AI para o seu maior ponto de abandono

Em vez de rolar manualmente centenas de sessões, peça à Tara para fazer a análise. Ela assiste às gravações quadro a quadro, da mesma forma que um analista humano faria, mas em dezenas de sessões em minutos, não semanas.

Comece com: "Por que os usuários estão abandonando durante [sua etapa de onboarding]?"

Depois aprofunde: "Quais padrões você vê na forma como os usuários interagem com o formulário em [nome da tela]?" ou "O que é diferente entre os usuários que concluem a verificação de identidade e os que abandonam?"

A Tara vai te dizer quais elementos estão causando atrito, como é o padrão comportamental e apontar sessões específicas como evidência. Ela detecta problemas espaciais, de teclado e falhas de interação que nunca geram logs de erro. Exatamente o tipo de bug que vive sem ser detectado por meses.

Corrija, publique e torne o monitoramento um hábito

O gerente de produto desse time agora checa com a Tara toda segunda-feira. Cinco minutos. "Alguma novidade no fluxo de onboarding?" Desde a correção do botão flutuante, eles identificaram mais dois problemas, ambos menores, ambos resolvidos dentro de uma sprint, ambos antes de aparecerem em qualquer métrica de conversão.

Os $1,3 milhão por mês que estão recuperando não vieram de uma grande reformulação do produto. Vieram da correção de um único botão flutuante que ninguém conseguia ver no próprio celular. A parte cara não foi a correção. Foram os 11 meses em que ninguém sabia que estava quebrado. Gravação de sessão não é luxo para fintech. É infraestrutura.

Dashboards te dizem onde os usuários abandonam. Análise de falhas te diz quando o app quebra. Nenhuma das duas te diz que um botão está cobrindo um campo do formulário em 37% dos dispositivos.

Esse intervalo entre "o que aconteceu" e "por que aconteceu" é onde vivem os bugs mais caros. E em fintech, onde cada falha de onboarding é um cliente perdido para um concorrente, esse intervalo custa dinheiro real todos os dias que permanece aberto.

A gravação de sessão do UXCam mostra o que os usuários realmente vivenciam nos dispositivos deles. A Tara AI assiste a essas sessões por você, identificando atritos, detectando padrões específicos de dispositivo e trazendo à tona os problemas que nenhuma quantidade de rastreamento de eventos jamais capturará. Comece seu teste gratuito hoje ou solicite uma demo.

Direcione a Tara para o seu fluxo de onboarding e pergunte: "Quais são os maiores atritos que os usuários estão enfrentando durante o cadastro?"

Você pode descobrir que seu app funciona perfeitamente. Ou pode descobrir que há um botão flutuante, ou algo parecido, que está silenciosamente te custando sete dígitos.

Há quanto tempo o seu está por aí?

---

Nome da empresa e detalhes identificadores foram alterados. Os bugs, os padrões comportamentais, a natureza específica de dispositivo do problema e o impacto financeiro são todos reais.