Como a análise de dados revelaram falhas no fluxo de links de pagamento

Estava começando a trabalhar com dados na lucree, passei a taguear com minha front as telas dos portais e percebi existir um volume muito alto de eventos sobre uma ferramenta que até então era, sim, utilizada, mas estava além do desproporcional para sua segunda função.

Contexto

Na Lucree, iniciei a implementação do uso de dados no time de produto. Para isso, comecei a taguear manualmente o portal (sem GTM no início) e configurei o acompanhamento via GA4. A partir disso, construí dashboards no Looker Studio para monitorar o comportamento dos usuários.

Problema identificado

Nos dados, percebi uma inconsistência:

Havia alto volume de links de pagamento gerados a partir do simulador de taxas, mas
Poucos acessos e links criados diretamente na tela de links de pagamento.

Ou seja, a funcionalidade secundária do simulador estava convertendo mais que a tela dedicada, o que indicava um problema de fluxo e usabilidade.

Descoberta

Para investigar, acessei o produto como cliente e mapiei os fluxos:

A tela de simulação oferecia informações mais completas para gerar o link.
A tela de links de pagamento era limitada, com dados faltantes e menos intuitiva.

Isso explicava por que os usuários preferiam criar links pela simulação, mesmo sendo um recurso secundário.

Proposta

Apresentei o diagnóstico aos stakeholders, que ficaram surpresos ao perceber o problema — antes estávamos “cegos” sem os dados.
Propus a revisão do fluxo de criação de links, unificando informações e tornando a tela dedicada mais robusta e eficiente.

Processo

Desenvolvimento de wireframes para explorar soluções.

Criação de protótipo de alta fidelidade no Figma.

Testes de usabilidade via Maze com colaboradores de diferentes níveis de conhecimento no sistema. Resultado: 89% de aproveitamento nos testes.

Entregas

Wireframes e protótipo de alta fidelidade.
Validação com usuários internos.
Criação de cards no Jira para priorização e acompanhamento com o time de desenvolvimento.

Pontos com Stakeholders

Melhor não colocar link FLEX, os clientes podem não entender, melhor colocar Flexível, fica mais fácil para lembrar o que é essa função.
Colocar uma função de Duplicar um link que já foi feito, pode ajudar a acelerar a criação de links no futuro.
Aprovado a ideia de criar o link na mesma tela com os links que já foram criados.
Status é ótimo para entender a situação e fazer devolutivas de cobranças.

Impacto

Detecção de um gargalo oculto no fluxo de produto.
Engajamento de stakeholders para apoiar mudanças.
Redução de riscos de inconsistência no uso da plataforma.
Base para evoluir a cultura de produto orientada a dados dentro da empresa.

Considerações finais

A visualização de dados no Looker/GA4 foi essencial para identificar inconsistências que, sem análise, passariam despercebidas.
O problema não estava na tecnologia, mas no fluxo e nas informações apresentadas ao usuário, mostrando a importância do design aliado à análise de dados.
O uso de testes de usabilidade (Maze) validou rapidamente a solução antes de consumir esforço de desenvolvimento, economizando tempo e recursos.
O case reforça como UX não é só interface, mas envolve diagnóstico, estratégia e alinhamento com o negócio.

Próximos passos

Monitorar o desempenho do novo fluxo após implementação, acompanhando métricas de conversão entre simulação e criação de links.
Expandir o uso de dados com Google Tag Manager para tornar a instrumentação mais escalável e flexível.
Aplicar testes com usuários externos/clientes reais, além dos internos, para validar em cenários mais diversos.
Documentar o aprendizado e compartilhar com o time de produto, criando uma cultura de decisão orientada a dados.
Explorar oportunidades adjacentes, como sugerir melhorias em outras jornadas do portal baseadas em dados.