Case: Infraestrutura de dados
CASE STUDY · DATA STRATEGY · PRODUCT STRATEGY · SERVICE DESIGN
Como criamos uma
infraestrutura de dados
para atribuir receita e
orientar decisões de
investimento
A empresa coletava dados em diferentes sistemas, mas não conseguia
acompanhar a jornada completa do usuário entre aquisição,
relacionamento e conversão. Sem essa rastreabilidade, era impossível
atribuir receita às operações corretas ou orientar decisões de
investimento.
Liderei a definição de uma estratégia de dados que conectou toda a
jornada em uma única arquitetura de rastreabilidade, transformando dados
fragmentados em uma base confiável para decisões de negócio.
IMPACTO
99+
planilhas
utilizadas para consolidar dados da operação
1
visão consolidada
Uma única lógica de rastreabilidade aplicada em todo o fluxo
VISÃO GERAL
DESAFIO
A empresa operava com dados
fragmentados entre aquisição,
relacionamento, conversão e analytics.
Cada equipe criava seus próprios
identificadores, planilhas e regras de
análise, impedindo acompanhar a
jornada completa do usuário e atribuir
receita às operações corretas.
SOLUÇÃO
Estruturei uma arquitetura de
rastreabilidade baseada em um
identificador compartilhado,
padronizando a comunicação entre os
sistemas e criando uma base única
para relacionar investimento,
comportamento do usuário e receita.
ESCALA
A estratégia foi aplicada em todo o fluxo
operacional, conectando aquisição,
relacionamento, conversão e analytics
sob uma mesma lógica de
rastreabilidade.
MINHA ATUAÇÃO
Product Strategy • Product Design • Service Design • Data
Strategy • Discovery • Facilitação • Alinhamento entre Squads
ARTEFATOS ESTRATÉGICOS
Decisões principais
Service Blueprint, Decision Matrix, Data Flow — As-Is → To-Be, Arquitetura
de Identificadores
Governança e implementação
Tracking Plan, Event Taxonomy, Data Dictionary, Dashboard Operacional,
RFC
O DESAFIO
A empresa conhecia sua
receita. Mas não sabia de
onde ela vinha.
Os sistemas responsáveis por aquisição, relacionamento, conversão e analytics funcionavam de
forma independente. Cada equipe analisava apenas sua parte da jornada, utilizando parâmetros
próprios que não compartilhavam uma linguagem comum.
Sempre que uma nova operação era criada, seus identificadores precisavam ser configurados
manualmente em diferentes etapas do fluxo. As convenções utilizadas eram conhecidas apenas
pelas pessoas que as haviam criado, e qualquer alteração exigia atualizações em planilhas,
scripts e alinhamentos entre equipes. Cada nova operação aumentava a quantidade de
parâmetros, planilhas e scripts necessários para manter a rastreabilidade funcionando.
Na prática, mais de 99 planilhas eram utilizadas para consolidar e cruzar informações da
operação. Mesmo com esse volume de dados, a empresa continuava respondendo apenas
perguntas agregadas.
Era possível saber quanto havia sido investido e quanto havia sido faturado, mas não identificar
quais operações geravam retorno, quais consumiam investimento sem resultado e onde
concentrar novos esforços.
"O problema não era falta de dados. Era
uma operação incapaz de conectá-los."
DISCOVERY
Descobrindo onde a
rastreabilidade era perdida
Antes de propor qualquer solução, conduzi um processo de investigação para entender como cada equipe produzia, consumia e interpretava os dados da sua etapa da jornada.
Mapeamos:
quais informações cada área produzia;
quais informações recebia das etapas anteriores;
como identificava campanhas e operações;
quais planilhas e sistemas utilizava;
onde existiam dependências manuais;
onde o contexto era perdido entre uma etapa e outra.
O Service Blueprint revelou que o problema não estava em uma ferramenta específica.
Cada equipe havia criado sua própria forma de representar campanhas, operações e eventos. O modelo de rastreabilidade funcionavam apenas localmente e deixavam de fazer sentido quando os dados precisavam travessar diferentes sistemas.
O INSIGHT
“O problema não era a ausência de integração. Era a ausência de uma identidade comum entre os dados.”
Cada equipe conseguia explicar sua própria etapa.
Nenhuma conseguia explicar a jornada completa.
A DECISÃO QUE DEFINIU A ESTRATÉGIA
Criando uma linguagem
comum entre todos os
sistemas
O diagnóstico mostrou que adicionar novas integrações resolveria apenas problemas locais.
A verdadeira oportunidade era criar uma identidade compartilhada capaz de acompanhar a
mesma operação desde sua origem até a geração de receita.
O desafio deixou de ser apenas de integração e passou a ser de arquitetura: encontrar uma
estrutura de identificação capaz de funcionar entre diferentes plataformas, respeitar suas
restrições técnicas e ainda preservar o contexto completo da operação ao longo da jornada.
Diversas alternativas foram avaliadas considerando: escalabilidade, compatibilidade entre plataformas, governança, rastreabilidade, esforço de implementação.
A decisão foi estruturar uma arquitetura baseada em um identificador compartilhado entre todos
os sistemas.
Esse identificador preservava o contexto da operação ao longo da jornada, reunindo informações
como origem, campanha, etapa da jornada, modelo de aquisição, plataforma de relacionamento e
demais atributos necessários para reconstruir a trajetória completa dos dados.
PROBLEMA
Cada sistema utilizava uma forma diferente de identifying operações,
usuários e eventos.
ALTERNATIVAS AVALIADAS
Manter identificadores independentes por sistema.
Criar integrações ponto a ponto.
Adotar um identificador compartilhado.
DECISÃO
Criar um identificador compartilhado como base da nova
infraestrutura de rastreabilidade.
TRADE-OFF
A alternativa escolhida exigia maior esforço inicial de arquitetura, governança e alinhamento entre equipes.
Comparação das alternativas consideradas e dos principais trade-offs que orientaram a decisão pelo identificador compartilhado. As informações deste artefato foram abstraídas para preservar dados proprietários e confidenciais.
A NOVA ARQUITETURA
Padronizando a
comunicação entre sistemas
independentes
Com a estratégia definida, estruturei uma infraestrutura para centralizar a criação de novas
operações.
Em vez de cada equipe criar seus próprios parâmetros e manter convenções diferentes, a criação
de uma nova operação passou a seguir uma única estrutura de identificação.
A interface gerava automaticamente um identificador padronizado, utilizado pelos diferentes
sistemas para preservar o contexto da jornada ao longo de todo o fluxo.
A configuração manual foi reduzida às etapas estritamente necessárias na plataforma de origem,
enquanto o restante da operação passou a compartilhar o mesmo padrão.
Além da arquitetura de identificadores, também foram definidos padrões para eventos, atributos e
documentação técnica, criando uma linguagem comum entre Produto, Engenharia, Dados e
Operações.
INTERFACE DO PRODUTO
Centralizando a criação de novas operações
A interface permitia cadastrar os dados da operação e gerar o identificador padronizado utilizado como origem da rastreabilidade.
System Map — Arquitetura de Rastreabilidade
Visão conceitual de como uma identidade compartilhada conecta diferentes etapas da jornada e preserva o contexto necessário para atribuição de receita. Sistemas, fluxos e mecanismos foram abstraídos e modificados para preservar informações proprietárias e confidenciais.
System Map — Arquitetura de Rastreabilidade
TRANSFORMAÇÃO
Da fragmentação à
inteligência operacional
Com a nova arquitetura implementada, dados antes isolados passaram a ser relacionados dentro
de uma única estrutura.
Investimento, comportamento do usuário e receita deixaram de ser analisados separadamente e
passaram a compor uma mesma visão operacional.
Essa padronização permitiu consolidar indicadores financeiros confiáveis e criou uma base
consistente para a evolução da estratégia de dados.
Data Flow — As-Is → To-Be
ANTES
99+ planilhas
parâmetros criados separadamente;
convenções compreendidas apenas por quem as definia;
planilhas independentes;
scripts atualizados manualmente;
dados fragmentados por equipe;
receita analisada de forma agregada;
dependência de conhecimento individual.
DEPOIS
Visão operacional consolidada
cadastro centralizado;
identificador compartilhado;
padrão comum entre sistemas;
contexto preservado ao longo da jornada;
custos, comportamento e receita relacionados;
indicadores financeiros consolidados;
base preparada para automação.
IMPACTO
O que passou a ser possível
A nova infraestrutura habilitou capacidades que antes não existiam.
Mais de 99 planilhas deram lugar a uma visão operacional consolidada — mas
o ganho mais importante foi tornar receita, LTV e rentabilidade rastreáveis.
Cards de impacto
Receita atribuída
Relacionar resultados financeiros às operações
e campanhas que os originaram.
LTV consistente
Calcular o valor gerado ao longo da jornada
utilizando dados conectados.
Rentabilidade comparável
Entender quais operações geravam retorno e
quais consumiam investimento sem resultado
proporcional.
Projeções mais confiáveis
Usar dados históricos conectados para apoiar
previsões de receita e resultados.
Jornada rastreável
Acompanhar o contexto da operação entre
aquisição, relacionamento, conversão e
analytics.
Decisões orientadas por evidências
Substituir uma visão agregada por análises no
nível de cada operação.
Uso operacional
Com o fim das mais de 99 planilhas, os dados consolidados passaram a alimentar um dashboard
operacional utilizado por coordenadores e diretoria para acompanhar indicadores financeiros e
apoiar decisões sobre continuidade, otimização e expansão das operações.
CAMADA DE DECISÃO
Uma única visão operacional para acompanhar resultado
O dashboard consolidava os indicadores utilizados por coordenadores e diretoria para
acompanhar receita, LTV e rentabilidade das operações.
Escala
A estratégia foi aplicada em todo o fluxo operacional, conectando aquisição, relacionamento,
conversão e analytics sob uma mesma lógica de rastreabilidade.
Evolução futura
A arquitetura também foi concebida para servir como base para futuras automações e modelos
de inteligência artificial voltados à identificação de operações com oportunidades de escala e
interrupção de esforços não rentáveis.
APRENDIZADOS
Dados confiáveis começam
por uma linguagem
compartilhada
Problemas de dados raramente surgem pela ausência de informação.
Na maioria das vezes, eles aparecem quando diferentes sistemas e equipes utilizam linguagens
diferentes para representar a mesma jornada.
Escalar uma operação de dados não é sobre conectar o maior número possível de ferramentas. É
sobre garantir que, independentemente de por onde a informação passe, o contexto da operação
original nunca se perca.
"Quando todos os sistemas passaram a
reconhecer a mesma operação, os dados
deixaram de explicar apenas o passado e
passaram a orientar as próximas decisões."