Defina o escopo (comece pequeno e crítico)
Escolha 1 a 3 indicadores ou processos que mais doem: conversão do funil, SLA de atendimento, receita por canal, churn. Data lineage funciona melhor quando nasce de uma pergunta concreta (“por que o relatório X mudou?”) e não de um projeto genérico de documentação.
Liste os “pontos de entrada” de dados
Mapeie todas as fontes que criam/alteram registros no CRM: formulários do site, importações de planilhas, WhatsApp/telefone, ferramentas de marketing, ERP/financeiro, e integrações via iPaaS/automação. Inclua quem faz o quê (time, sistema, fornecedor).
Cataloge os campos e suas regras (dicionário mínimo viável)
Para cada objeto (Contato/Empresa/Negócio/Ticket), selecione os campos críticos e descreva: definição, formato, valores permitidos, se é obrigatório, e exemplos. Aqui já aparecem as pegadinhas clássicas: campo duplicado com nomes diferentes, valores livres, e datas em formatos variados.
Mapeie as transformações: onde o dado “muda de roupa”
Descreva, com clareza, cada transformação: normalização (ex.: telefone), regras de roteamento, deduplicação, enriquecimento, cálculos, e mudanças de etapa no pipeline. Se você não consegue explicar uma regra em uma frase, ela provavelmente está complexa demais — e difícil de auditar.
Conecte o consumo: automações, relatórios e downstream
Aponte onde o dado é usado: dashboards, segmentações, cadências, SLAs, alertas, comissões, integrações de saída (reverse ETL, BI, data warehouse). O objetivo é responder rapidamente: “se eu mexer neste campo, o que quebra?”
Registre ownership e cadência de revisão (governança leve)
Defina um dono por domínio (ex.: Marketing é dono de ‘lead source’; Vendas de ‘etapa do pipeline’; CS de ‘health score’). Estabeleça uma rotina simples de revisão (mensal ou por release) e um processo de mudança: proposta → impacto → teste → publicação.
O que é data lineage no CRM (na prática, sem teoria demais)
No CRM, data lineage é o “raio-x” do dado: ele mostra como um campo chega até ali, quem altera, por qual integração passou e em quais relatórios/automação ele vira decisão. É diferente de só ter integração funcionando: lineage explica o comportamento do dado ao longo do tempo.
Em operações reais, o lineage costuma virar prioridade quando aparecem sintomas: queda súbita de conversão, duplicidade de contatos, origem de lead “misteriosamente” mudando, ou dashboards com números incompatíveis entre CRM e BI.
Checklist do lineage que resolve briga de números
Um lineage útil não precisa começar perfeito. Ele precisa responder perguntas de auditoria e impacto. Use este checklist para validar se você saiu do “achismo”:
- Consigo apontar a fonte de verdade de cada campo crítico (system of record).
- Se um valor está errado, sei em qual etapa do fluxo investigar primeiro (origem → transformação → consumo).
- Tenho uma explicação documentada para campos calculados e regras de automação (mesmo que simples).
- Se eu renomear/remover um campo, sei quais relatórios, segmentações e integrações param.
- Existe um responsável humano por aprovar mudanças no dado (ownership).
Modelo de mapeamento (tabela) para você copiar
A tabela abaixo é um “MVP” de data lineage. Ela é simples de manter e, ainda assim, cobre a maior parte dos incidentes de dados em CRM.
| Campo no CRM | Origem (fonte) | Transformações | Destino (consumo) | Risco comum | Dono |
|---|---|---|---|---|---|
| lead_source (origem do lead) | Formulário / Integração marketing | Normalização de valores; regra para “última origem” vs “primeira origem” | Dashboard de canais; roteamento SDR | Sobrescrita por importação ou integração | Marketing Ops |
| telefone (E.164) | WhatsApp / Formulário / Importação | Padronização DDI/DDD; remoção de caracteres; dedupe por telefone | Discador; WhatsApp; identificação de duplicados | Vários formatos impedem match e geram duplicidade | RevOps |
| etapa_do_pipeline | Vendedor / Automação | Mudança automática por atividade; regras de avanço/retrocesso | Forecast; métricas de conversão | Automação “pula” etapa e distorce o funil | Liderança de Vendas |
| status_de_cliente (ativo/inativo) | ERP/Financeiro | Regras por pagamento/renovação; janela de atualização (batch/tempo real) | CS; campanhas de reativação | Atraso de sincronização gera abordagem fora de contexto | Ops Financeiro + CS Ops |
Erros que sabotam o lineage (e parecem detalhe)
Três padrões aparecem com frequência quando o time tenta mapear lineage e desiste:
1) Misturar “fonte do dado” com “onde eu vejo o dado”. O dashboard não é fonte, é consumo.
2) Tratar campo como se fosse conceito único. Às vezes existem dois campos que significam ‘a mesma coisa’ (ex.: ‘origem’, ‘canal’, ‘utm_source’) e ninguém decide qual manda.
3) Ignorar transformações invisíveis: deduplicação automática, regras em iPaaS, fórmulas de BI, e automações que reescrevem valores (principalmente em origem, etapa e owner).
Perguntas frequentes
Data lineage é a mesma coisa que dicionário de dados no CRM?
Preciso de ferramenta específica para fazer data lineage no CRM?
Quais campos do CRM valem mapear primeiro no lineage?
Como o data lineage ajuda a reduzir duplicidade e “números que não batem”?
Leia também
Como criar um dicionário de dados no CRM (sem travar o time e sem virar burocracia)
Guia prático para criar um dicionário de dados no CRM: padrão de campos, definições, valores permitidos, dono do dado e regras de qualidade. Evite base suja, relatórios inconsistentes e automações quebradas.
Ler →
Governança de dados no CRM: como definir regras sem travar o time
Guia editorial para montar governança de dados no CRM: padrões de cadastro, dono do dado, permissões, qualidade e auditoria. Com passos e FAQ para não virar burocracia.
Ler →
Rotina de qualidade de dados no CRM: como implantar sem parar as vendas
Guia prático para criar uma rotina de qualidade de dados no CRM (padronização, duplicidade, obrigatórios, auditoria e governança) sem interromper vendas e atendimento.
Ler →
Governança de integrações no CRM: como evitar dados duplicados e automações conflitantes
Guia prático para organizar integrações do CRM (WhatsApp, e-mail, ERP, formulários e automação), definir dono, versionar mudanças e impedir contatos duplicados e fluxos que brigam entre si.
Ler →