Existem duas formas de guardar a informação de que um lead virou cliente. A primeira é atualizar um campo: “status = cliente”. A segunda é guardar cada evento que levou até ali — visitou a página de preços, baixou o material, recebeu uma ligação, assinou o contrato — numa sequência ordenada e imutável. A primeira é como apagar o quadro e escrever só a resposta final. A segunda é guardar cada rascunho, cada rabisco, cada correção, na ordem em que aconteceram.
Esse segundo modelo tem nome: Event Sourcing. O padrão foi nomeado e formalizado por Martin Fowler em dezembro de 2005, como parte do seu catálogo de padrões de arquitetura corporativa, e desde então se tornou a base conceitual por trás de praticamente toda Customer Data Platform (CDP) moderna.
A mudança de paradigma: de estado para evento
A forma tradicional de guardar dado — e a que a maioria dos sistemas usa por padrão — é persistir estado: uma tabela de clientes com uma linha por pessoa, e cada campo dessa linha reflete o valor atual. Quando algo muda, o valor antigo é sobrescrito pelo novo. Isso é simples e suficiente para a maioria das aplicações — mas tem uma consequência irreversível: o histórico de como se chegou ali desaparece.
Event Sourcing inverte essa lógica. Em vez de guardar o estado atual, o sistema guarda a sequência completa de eventos que aconteceram — e o estado atual deixa de ser algo armazenado diretamente, passando a ser calculado ao somar (ou “reproduzir”) todos os eventos até aquele ponto. O log de eventos se torna a única fonte da verdade; tudo o mais é derivado dele.
O exemplo mais direto: o carrinho de compras
O exemplo mais citado, e o mais próximo de marketing, é o carrinho de compras de e-commerce. Em vez de o carrinho ser uma tabela que diz “contém: 2 produtos, valor R$ 150”, o sistema registra cada evento individualmente: “item A adicionado”, “item B adicionado”, “item A removido”, “quantidade de B alterada para 2”. O estado atual do carrinho é a soma de todos esses eventos, calculada no momento em que alguém precisa saber “o que tem no carrinho agora”.
O Kafka — a plataforma de mensageria mais usada para esse tipo de arquitetura — atua como o “event store”: o registro permanente e ordenado de tudo o que aconteceu. A partir desse fluxo de eventos, diferentes serviços consomem a mesma informação para propósitos completamente diferentes: um serviço de detecção de fraude analisa padrões de adição e remoção suspeitos; um serviço de cobrança calcula o valor final; um serviço de e-mail dispara um lembrete se o carrinho ficar parado por tempo demais.
A consequência mais importante: ninguém precisa concordar sobre o schema final
Esse é o ponto conceitual mais valioso do padrão, e o menos intuitivo à primeira vista: como os eventos brutos são a fonte da verdade, cada serviço consumidor pode interpretar esses eventos à sua própria maneira, construindo seu próprio modelo de dado otimizado para seu próprio propósito.
O time de e-mail pode interpretar “item adicionado ao carrinho” como um gatilho de campanha de carrinho abandonado. O time de BI pode agregar o mesmo evento numa métrica de intenção de compra por categoria de produto. O time de detecção de fraude pode olhar para a velocidade entre eventos como sinal de comportamento automatizado suspeito. Nenhum desses times precisa negociar um schema comum antecipadamente — cada um extrai do mesmo log bruto o que é relevante para si.
Tradução direta para CRM e CDP
A diferença entre modelo de estado e modelo de evento é exatamente a diferença entre um CRM tradicional e uma CDP construída sobre event sourcing:
| Modelo de estado (CRM tradicional) | Modelo de evento (CDP moderna) | |
|---|---|---|
| O que é guardado | “Status do lead = qualificado” | Toda a sequência: visitou site → baixou material → abriu e-mail → recebeu ligação → foi qualificado |
| Reconstruir o passado | Impossível — o valor antigo já foi sobrescrito | Trivial — basta reproduzir os eventos até o ponto desejado |
| Nova regra de segmentação | Só se aplica a partir de agora, com dado futuro | Pode ser recalculada sobre todo o histórico já registrado |
| Auditoria | Exige log separado, muitas vezes incompleto | Nativa — o histórico completo é a estrutura de dado em si |
O modelo de evento permite reconstruir “como estava a nossa base em março?” com precisão, porque nada foi sobrescrito — só permite calcular novos estados a partir da mesma sequência bruta. Também permite recalcular segmentações inteiras com uma regra nova, aplicada retroativamente sobre todo o histórico, algo praticamente impossível quando só o estado final foi preservado.
A trilha de auditoria como efeito colateral, não como projeto à parte
Um benefício frequentemente subestimado: em arquiteturas de estado, “trilha de auditoria” costuma ser um recurso adicional, construído separadamente e sujeito a lacunas — alguém esquece de logar uma mudança, ou o log de auditoria não cobre todos os pontos de entrada do sistema. Em event sourcing, a auditoria é a estrutura de dado — não existe uma “mudança que não foi registrada”, porque toda mudança só existe na forma de um evento gravado.
Isso conecta diretamente com exigências regulatórias como LGPD, que frequentemente pedem rastreabilidade de quando e como um dado pessoal foi coletado, alterado ou usado — uma pergunta que o modelo de evento responde por design, e que o modelo de estado precisa reconstruir com esforço extra.
O exemplo mais eloquente: o New York Times desde 1851
O caso mais citado de event sourcing em escala é o do New York Times, que armazena cada artigo, imagem e registro de assinatura desde 1851 como um event store — o log bruto e imutável de tudo o que já aconteceu na publicação. A partir desse log central, o jornal desnormaliza o dado em múltiplas “views” especializadas, alimentando diferentes índices de Elasticsearch otimizados para diferentes tipos de busca e análise.
O paralelo com martech é direto: o log de eventos bruto (cada interação do cliente, desde sempre) é a fonte da verdade; os “views” especializados (segmentação para campanha, pontuação de lead, relatório de atribuição) são derivados dele, cada um otimizado para seu próprio uso, sem competir pela mesma estrutura de dado.
O custo: “qual é o estado atual” deixa de ser trivial
Nenhum modelo de arquitetura vem sem custo, e este é o trade-off central do event sourcing: responder “qual é o estado atual deste cliente agora?” deixa de ser uma leitura direta de um campo e passa a exigir projeção — percorrer (ou consultar um resumo pré-calculado de) todos os eventos relevantes até chegar ao estado presente.
Na prática, sistemas de event sourcing maduros resolvem isso com snapshots periódicos — um resumo do estado calculado até certo ponto, para não precisar reprocessar tudo desde o primeiro evento a cada consulta — e com padrões complementares como CQRS, que separa explicitamente o modelo otimizado para escrita (gravar eventos) do modelo otimizado para leitura (consultar o estado atual).
É por isso que CDPs baseadas em evento são simultaneamente mais poderosas e mais complexas de operar que um CRM tradicional: o ganho de flexibilidade e histórico vem acompanhado de uma camada de engenharia adicional que precisa ser bem projetada para não sacrificar velocidade de consulta.
Quando vale a complexidade
Event sourcing não é a escolha certa para toda operação. Ele se paga quando pelo menos uma destas condições é verdadeira:
- A operação precisa reconstruir estados passados com frequência — auditoria, compliance, ou análise histórica de jornada.
- Diferentes times consomem o mesmo dado bruto de formas genuinamente diferentes, e forçar um schema único geraria atrito constante entre eles.
- Regras de segmentação e pontuação mudam com frequência, e recalcular retroativamente sobre o histórico completo é um requisito real, não hipotético.
Para uma operação pequena, com um único sistema de verdade e baixa necessidade de reconstrução histórica, um CRM tradicional baseado em estado continua sendo a escolha mais simples e barata — trazer a complexidade de event sourcing sem o problema correspondente é custo sem benefício.
Um teste simples para reconhecer o modelo por trás de uma ferramenta
Nem sempre o fornecedor usa o termo “event sourcing” explicitamente na documentação ou na conversa comercial, mesmo quando a arquitetura por trás é exatamente essa. Um teste prático e rápido para descobrir o modelo real: peça para visualizar o histórico completo de interações de um único contato específico, ordenado cronologicamente, desde o primeiro registro até hoje.
Se a ferramenta apresenta uma linha do tempo detalhada — cada visita, cada abertura de e-mail, cada mudança de status, na ordem exata em que aconteceram — é sinal de que o dado subjacente é guardado como eventos. Se a ferramenta só consegue mostrar “o estado atual” e talvez um resumo agregado (“5 visitas ao site, 3 e-mails abertos”), sem a sequência detalhada e cronológica de cada interação individual, é sinal de que o modelo por trás é de estado, não de evento — mesmo que o material de venda use a palavra “jornada do cliente” livremente.
Próximos passos para avaliar sua CDP ou CRM
A ação concreta: pergunte ao fornecedor da sua CDP ou plataforma de dados de cliente se ela armazena eventos brutos e imutáveis, ou apenas o estado atual de cada contato. A resposta determina diretamente se você consegue, daqui a um ano, recalcular uma segmentação nova sobre o histórico completo — ou se só vai conseguir aplicá-la a partir de agora, com o passado perdido.
Se a resposta for “só guardamos o estado atual”, isso não invalida a ferramenta para o uso presente, mas é uma limitação real a considerar antes de depender dela para qualquer análise que dependa de reconstruir “como era antes”.
