O problema era falta de uma leitura que fizesse sentido para o comportamento real
A operação já acumulava uma quantidade alta de eventos, métricas e visões analíticas. Ainda assim, as decisões seguiam limitadas porque a maior parte dessa leitura estava organizada em torno de produto, funcionalidade ou etapa técnica, e não da intenção concreta do usuário.
Esse modelo escondia gargalos importantes. Em jornadas como parcelamento de fatura, o cliente levava tempo demais, clicava demais e retornava demais até concluir uma ação que deveria ser simples. O efeito disso não aparecia como falha de infraestrutura. Aparecia como abandono silencioso em um produto altamente rentável.
A consequência era dupla. De um lado, receita deixava de ser capturada. De outro, a organização seguia discutindo experiência com base em sinais fragmentados, sem uma linguagem comum entre UX, negócio, dados e finanças. O problema não era coletar mais informação. Era reorganizar o que já existia em torno do motivo real da navegação.
Uma nova forma de medir a jornada, mais próxima da intenção e mais útil para o negócio
A resposta foi transformar Jobs To Be Done em sistema analítico operacional.
A MATH estruturou um modelo em BigQuery para reconstruir jornadas a partir da intenção declarada ou inferida do usuário. Em vez de contar todas as telas igualmente, a análise passou a considerar apenas o que era necessário para concluir a tarefa, destacando loops, retornos, desvios e fricções com muito mais precisão.
Cada jornada foi modelada como um funil realista. Isso significa que o percurso não era mais tratado como uma abstração idealizada da navegação, mas como o caminho efetivamente percorrido pelo cliente até converter, desistir ou se perder.
A arquitetura foi desenhada para escalar. Tabelas particionadas e clusterizadas, atualizações automáticas e scripts modulares permitiram replicar a lógica para outras jornadas sem reconstrução completa da base. Isso fez do projeto algo maior do que uma análise pontual. Criou uma camada durável de leitura da experiência.
A partir daí, a operação passou a gerar produtos analíticos derivados com valor direto para o negócio: valoração de espaços do app, identificação de abandono, monitoramento de fricção e painéis acionáveis para diferentes áreas. Em uma frente de investimentos, por exemplo, o cruzamento entre navegação e transação passou a mostrar captação por clique, por visualização e por campanha, deslocando a área de dados de suporte para motor de receita.
O ganho do projeto veio quando a jornada deixou de ser observada como rastro técnico e passou a ser tratada como tentativa de resolver uma necessidade concreta.
Menos atrito, mais contratos, um novo papel para analytics
O primeiro resultado apareceu na jornada de parcelamento de fatura. O tempo médio de conclusão caiu de 1 minuto e 46 segundos para 44 segundos. O número de cliques necessários caiu de 13 para 5. Essas duas reduções mostram que a melhora não foi cosmética. A experiência ficou objetivamente mais curta e mais eficiente.
O segundo resultado veio na conversão. A taxa saltou de 8% para 19%, com variação de 13,6% e mais de 2.100 contratos adicionais por mês. Isso representa um deslocamento importante na capacidade do app de converter intenção em resultado.
O terceiro resultado foi financeiro. O ganho incremental estimado pelo próprio time de finanças chegou a R$ 16,4 milhões por ano apenas nessa frente analisada. E esse valor foi gerado sem aumento proporcional de custo operacional, porque a arquitetura construída permitiu reuso, modularidade e continuidade de análise.
O quarto resultado foi de maturidade analítica. Mais de 40 jornadas foram mapeadas depois dos primeiros ganhos, muitas delas por demanda direta da própria operação. Isso mostra que o projeto deixou de ser uma frente de diagnóstico e passou a funcionar como infraestrutura de decisão para o ecossistema digital.
