SLA de qualidade de dados para marketing: o básico que falta
SLA de qualidade de dados de marketing transforma “o dashboard está estranho” em critérios objetivos: frescor, completude, validade e reconciliação. Sem SLA, ops vive no heroísmo e a liderança decide com números sem carimbo de validade. Qualidade não é projeto de limpeza pontual — é serviço contínuo com donos, alertas e severidade.
Por que marketing precisa de SLA de dados?
Mídia e growth operam em ciclo curto. Dado atrasado, duplicado ou com UTM quebrada gera otimização errada e disputa entre times. SLA deixa explícito o que é aceitável: por exemplo, gasto de ads disponível até 8h com tolerância de 2%, e leads do CRM até 9h com chave de origem preenchida em 98% dos casos.
Isso também protege o time de dados: sem acordo, qualquer pedido ad hoc vira prioridade máxima. Com acordo, há severidade P1/P2 e fila clara.
Quais dimensões de qualidade importam?
Frescor (quando atualizou), completude (nulos e buracos), validade (valores possíveis, tipos), unicidade (duplicatas de lead/evento), consistência (mesmo KPI entre fontes) e reconciliabilidade (bate com UI/fatura dentro da tolerância). Para marketing, acrescente integridade de taxonomia: campanhas fora do padrão de nomenclatura são defeito, não “detalhe”.
Nem toda dimensão precisa do mesmo rigor em toda tabela. Gasto diário por conta exige reconciliação forte; um ranking exploratório de termos de busca admite mais folga.
| Dimensão | Exemplo de regra | Severidade típica | Ação se falhar |
|---|---|---|---|
| Frescor | Fato ads D-1 até 08:00 | P1 se >2h atraso | Alerta + status no BI |
| Completude | utm_source nulo < 2% leads | P2 | Quarentena / correção GTM |
| Reconciliação | |gasto BI − UI| ≤ 3% | P1 se >5% | Bloquear decisão de verba |
| Unicidade | 0 duplicata de lead_id/dia | P1 | Parar sync até correção |
| Taxonomia | ≥95% campanhas no padrão | P2 | Backlog de rename + gate |
Como escrever um SLA que o time cumpre?
SLA bom é específico, mensurável, com horário e fuso, dono, canal de alerta e exceções (manutenção de API, outage de plataforma). Evite “dados confiáveis em tempo real” — isso não é contrato. Prefira: “pipeline Google Ads conclui até 07:30 BRT em 95% dos dias úteis”.
Inclua o que acontece na falha: banner no dashboard, mensagem no Slack, não envio de PDF executivo, ou freeze de otimização automatizada. Sem consequência operacional, SLA vira PDF esquecido.
Quem é dono de cada pedaço?
Fonte (Ads/CRM): contrato de acesso e mudanças de schema. Engenharia/dados: pipelines e testes. Marketing ops: taxonomia e dicionário de UTM. Analistas: uso correto das tabelas certificadas. Negócio: priorização do que é P1. RACI simples evita o clássico “achei que era vocês”.
Tabelas certificadas (gold) merecem selo e documentação; sandboxes não entram no SLA executivo.
- RACI por pipeline crítico
- Catálogo das tabelas gold vs sandbox
- Canal único de incidente de dados
- Janela de manutenção comunicada
- Revisão trimestral de tolerâncias
Como testar qualidade no pipeline?
Testes automatizados no ELT: volume inesperado (zero rows, spike), ranges (CTR > 100% impossível), referências (campaign_id órfão), reconciliação agregada diária vs API/UI, e schema tests (coluna sumiu). Ferramentas como dbt tests, Great Expectations ou checks SQL simples funcionam — o importante é rodar em CI/agendamento e alertar.
Para tagueamento, complemente com QA de site (debugView, crawlers de dataLayer) e amostragem pós-release. Dado de marketing quebra na coleta com frequência igual ou maior que na transformação.
Tolerâncias realistas
APIs de ads e atribuição tardia fazem o “gasto de ontem” mudar. SLA deve permitir reprocessamento dos últimos N dias e tolerância de reconciliação — senão você terá incidente eterno por comportamento normal da plataforma.
Como comunicar qualidade para quem não é de dados?
Traduza para decisão: “números de ontem confiáveis para otimizar budget” vs “estimativa com atraso”. Use status semáforo no BI, notas de metodologia e changelog quando a definição de conversão muda. Treine o time a olhar freshness antes de discutir performance.
Incidentes merecem post-mortem curto: impacto, causa, prevenção. Cultura de qualidade nasce de aprendizado, não de caça às bruxas.
Por onde começar o programa de qualidade?
Escolha 3–5 pipelines que sustentam decisão de dinheiro (gasto, leads, receita, conversões chave). Defina métricas de qualidade, alertas e um dashboard de saúde. Só depois expanda. Qualidade universal no dia um é miragem; qualidade onde dói é estratégia.
Checklist prático
- Lista dos pipelines P1 ligados a decisão de verba/receita
- Dimensões e limiares numéricos por pipeline
- RACI e canal de incidente
- Testes automatizados de volume/schema/reconciliação
- Semáforo de freshness no dashboard executivo
- Política de reprocessamento (últimos N dias)
- Runbook de falhas frequentes (OAuth, quota, schema)
- Revisão trimestral do SLA com marketing e dados
Erros comuns
- SLA vagamente qualitativo (“dado confiável”)
- Alertar tudo como P1 até ninguém olhar mais
- Ignorar atribuição tardia e abrir incidente por variação normal
- Não expor freshness no BI (usuário assume que está ok)
- Qualidade só no warehouse enquanto GTM quebra na origem
- Ausência de dono de taxonomia de campanhas/UTM
- Mudar definição de KPI sem changelog
Time discute número todo meeting?
A DataScroll institui SLA, monitores e ritual de qualidade para o debate voltar a ser de negócio — não de tag quebrada.