Muito dado, pouca leitura
O problema central não era ausência de informação. Era a incapacidade de convertê-la em decisão.
A operação já dispunha de logs sobre aplicativos instalados nos celulares dos clientes, um ativo com potencial relevante para identificar presença de concorrentes, fintechs de nicho, apps de apostas e outros contextos de uso capazes de influenciar comportamento financeiro e relacionamento com o app do banco. O obstáculo estava no formato. Os dados chegavam em estruturas JSON aninhadas, sujas e pouco amigáveis para leitura estratégica.
Isso gerava um primeiro tipo de cegueira: a competitiva. Sem classificação adequada, o banco não conseguia enxergar com clareza quais ecossistemas digitais estavam mais presentes na base, quais categorias ganhavam força e como essa informação poderia orientar ações comerciais ou análises de mercado.
Havia também uma segunda cegueira, mais operacional. Sem saber quais outros aplicativos conviviam com o app bancário no ambiente do cliente, a engenharia perdia contexto para investigar falhas silenciosas e possíveis interferências sobre estabilidade. Em um cenário em que a meta de crash free users precisava ficar acima de 98%, essa ausência de leitura limitava a capacidade de antecipar ou explicar incidentes.
As alternativas existentes tampouco resolviam o problema. APIs de lojas de aplicativos entregavam classificações genéricas demais, enquanto a classificação manual de 300 mil apps únicos seria lenta e financeiramente inviável. O desafio, portanto, não era apenas organizar dados. Era construir uma forma eficiente de transformar massa não estruturada em inteligência utilizável.
Uma camada de inteligência sobre a stack que já existia
A resposta foi usar melhor o que a operação já tinha, em vez de ampliar a arquitetura com novas dependências.
A MATH estruturou a solução sobre Microsoft Copilot, ferramenta já homologada no ambiente do cliente, adicionando uma camada de engenharia de prompts desenhada para limpar, interpretar e classificar dados não estruturados em escala. Em vez de tratar IA como caixa preta, o projeto trabalhou a orquestração da inferência com regras replicáveis e ajustáveis.
A primeira frente foi a limpeza e organização dos logs. O sistema passou a interpretar os registros brutos dos aplicativos e convertê-los em categorias mais úteis à leitura do negócio, distinguindo concorrentes, plataformas de investimento, apps de apostas e outras tipologias relevantes para a operação.
A segunda frente foi a governança. A classificação foi desenhada com privacy by design, permitindo gerar leitura sobre perfis e contextos de uso sem expor identificação pessoal do cliente. Isso preservou conformidade com LGPD ao mesmo tempo em que manteve a utilidade analítica da informação.
A terceira frente foi o modelo híbrido de evolução. Em vez de fixar uma taxonomia rígida e estática, a solução foi pensada para incorporar revisão humana e ajuste fino quando novas categorias ganhassem relevância no mercado. Isso permitiu que a inteligência acompanhasse movimentos recentes, como o crescimento de apps de bets, sem depender de reconstrução completa do fluxo.
A quarta frente foi a transformação da classificação em ação. Os dados passaram a alimentar dashboards no Power BI, possibilitando segmentações mais precisas e cruzamentos com critérios de negócio, como atividade recente, perfil comportamental e presença de determinados aplicativos. O ativo técnico deixou de ser apenas uma base tratada e passou a funcionar como camada de apoio à decisão comercial e à estabilidade digital.
O ganho da solução não veio de adicionar ferramenta nova. Veio de aplicar inteligência sobre um recurso já disponível e transformá-lo em capacidade analítica real.
O que passou a ser possível enxergar
O primeiro resultado foi velocidade. A classificação dos dados passou a acontecer em ritmo 20 vezes superior ao dos métodos anteriores, tornando viável tratar uma base que, até então, era grande demais para revisão manual e confusa demais para leitura direta.
O segundo resultado foi time-to-value. Em vez de meses dedicados à criação de uma nova plataforma, o MVP ficou pronto em uma semana. Isso permitiu validar rapidamente o potencial do ativo e colocar a inteligência em circulação com agilidade incomum para um contexto de alta complexidade.
O terceiro resultado foi expansão de uso. O projeto começou atendendo um grupo menor de usuários estratégicos e se espalhou organicamente para outras áreas, incluindo frentes ligadas a canais, crédito e investimentos. Esse movimento mostra que a solução não respondeu a uma dor isolada. Ela criou um ativo com utilidade transversal.
O quarto resultado foi técnico e operacional. A identificação mais precisa de aplicativos ofensores deu mais contexto para a engenharia proteger a estabilidade do app e sustentar a meta de mais de 98% de usuários crash free. Isso significa que a classificação não serviu apenas à leitura competitiva. Ela também fortaleceu a capacidade de resposta sobre experiência digital.
Ao final, a operação deixou de conviver com um pântano de dados pouco utilizáveis e passou a operar com uma camada de leitura estratégica construída sobre recursos que já estavam à disposição.
