O último post de produto que publiquei aqui foi em outubro de 2025. De lá para cá, mudou muita coisa. Não no sentido de “lançamos features novas”, isso também aconteceu, mas no sentido de que a arquitetura inteira da plataforma mudou. E quando a arquitetura muda, o que você consegue fazer com o produto muda junto.
Este post é mais longo e mais técnico que o habitual. Nos próximos dias vou publicar posts mais curtos explorando cada tema individualmente. Mas achei importante registrar a visão geral primeiro.
O problema com “plataforma de pagamentos”
Quando comecei a Glass Data, o modelo de dados era centrado em pagamentos. Fazia sentido: o caso de uso principal era antifraude transacional. Cada evento era uma transação, cada métrica era calculada sobre transações, cada regra avaliava campos de uma transação.
O problema é que a realidade dos clientes não cabe nesse modelo. Tem cliente que precisa monitorar chargebacks como eventos separados. Tem cliente que quer cruzar dados de login com dados de pagamento. Tem cliente que precisa acompanhar cadastros, alterações de conta, tentativas de saque. Tudo isso era possível antes, mas sempre com adaptações, encaixando dados em campos que não foram feitos para aquilo.
A pergunta que ficava era: e se o modelo não assumisse que tudo é um pagamento?
Eventos sob medida: a mudança de fundação
A maior mudança desses seis meses foi a introdução de tipos de evento configuráveis, com campos (dimensões) definidos pelo cliente. Em vez de uma tabela de pagamentos com campos fixos, agora cada tipo de evento tem seus próprios campos, suas próprias métricas e seus próprios monitoramentos.
Na prática, isso significa que um cliente pode ter um tipo de evento pagamento com campos como valor, bin_do_cartao, emissor, e ao mesmo tempo um tipo de evento alteracao_de_conta com campos como tipo_de_alteracao, valor_anterior, endereco_ip. Cada um com suas regras, seus dashboards e suas métricas.
Métricas flexíveis
Com eventos configuráveis, o sistema de métricas precisava mudar também. Antes, as métricas eram fixas: taxa de aprovação, taxa de fraude, ticket médio, todas pré-definidas sobre pagamentos.
Agora as métricas são construídas sobre qualquer tipo de evento. Você define a agregação (contagem, soma, média, percentual), os filtros e o agrupamento. Quer uma métrica que calcule a taxa de rejeição por emissor em pagamentos acima de R$ 500? Define uma vez e ela fica disponível nos dashboards e nos monitores.
Além disso, métricas agora podem depender de outras métricas. Uma taxa de conversão pode ser definida como a razão entre duas contagens, sem precisar de lógica customizada.
Monitores e alertas
O terceiro pilar foi o sistema de monitoramento. Antes existiam monitores básicos, mas estavam acoplados ao modelo de pagamentos. Agora os monitoramentos são entidades independentes, vinculadas a tipos de evento e métricas.
Um monitor avalia uma condição sobre uma métrica, por exemplo, “se a taxa de chargeback do tipo de evento pagamento, filtrado por merchant_id, ultrapassar 1.5% nas últimas 24 horas”. Quando a condição é atendida, um alerta é disparado.
O sistema de alertas foi construído com dispatch configurável. Hoje os alertas saem por email, mas a arquitetura já suporta outros canais.
Filtros de exclusão também foram adicionados: você pode monitorar tudo exceto um subconjunto específico de dados. Isso é útil para evitar falsos positivos em segmentos que têm comportamento naturalmente diferente.
Filtros: o trabalho invisível
Uma parte grande do esforço foi refatorar o sistema de filtros. Parece pouco glamoroso, mas filtros são a base de quase tudo na plataforma, dashboards, métricas, monitores, regras, relatórios.
A refatoração principal foi separar dimensões de filtros: dimensões são os campos do evento, filtros são as condições aplicadas sobre eles. Antes, essas duas coisas estavam misturadas no código e na interface. Agora a distinção é clara, o que permitiu adicionar suporte a exclusão (não só inclusão), listas multi-valor e autocompletar de campos.
O resultado é que montar uma consulta complexa ficou mais rápido e menos propenso a erro.
O que une tudo isso
Se eu tivesse que resumir esses seis meses em uma frase: a Glass Data deixou de ser uma ferramenta de antifraude em pagamentos e virou uma plataforma de monitoramento de eventos.
Isso não significa que deixamos de atender antifraude, pelo contrário, o caso de uso de antifraude ficou mais poderoso. Mas agora o mesmo motor serve para compliance, monitoramento operacional, análise de risco em cadastros, detecção de abuso em programas de fidelidade, e qualquer outro cenário onde você precisa avaliar eventos em tempo real contra regras e métricas.
A flexibilidade tem um custo: a curva de configuração inicial é maior. Mas a aposta é que clientes que precisam de controle granular preferem investir tempo na configuração do que ficar limitados por um modelo fixo. E para quem quer começar rápido, os templates de tipos de evento resolvem.
O que vem a seguir
Nos próximos posts vou explorar cada um desses temas com mais profundidade, especialmente a parte de métricas e monitores, que é onde a flexibilidade mais aparece no dia a dia. Também quero falar sobre as decisões de produto por trás dessas mudanças: por que generalizar agora, o que isso significa para o roadmap, e como isso muda a conversa com clientes.
Se você quer entender melhor como isso funciona na prática, esse é um bom momento para conhecer a Glass Data.
