Data contracts entre marketing e engenharia: acordo que funciona
Marketing pede campo novo na sexta; engenharia deploya schema change no domingo; segunda-feira conversão zerou e ninguém sabe se foi tag, campanha ou bug de dados. Data contract — acordo formal de schema, SLA, ownership e breaking changes — é a ponte entre times que falam línguas diferentes. Não é burocracia: é o documento que impede tag quebrada silenciosa e reunião de crise evitável.
O que é data contract no contexto marketing + engenharia?
Data contract define expectativas mutuáveis sobre dados: quais eventos/campos existem, tipos, valores permitidos, frequência de entrega, owner de cada lado, processo de change request e o que acontece quando alguém quebra o acordo. É API documentation para dados internos.
No contexto marketing-engenharia: contrato cobre dataLayer events, GA4 parameters, CRM fields sync, UTM conventions, offline conversion payloads e schemas de warehouse tables consumidas por BI.
Por que marketing e engenharia precisam de contrato explícito?
Marketing opera em velocidade de campanha; engenharia opera em velocidade de sprint com review, teste e deploy. Sem contrato, marketing assume ‘só adiciona um campo’ e engenharia assume ‘não mexe em prod sem spec’. Resultado: campos inventados no GTM que app não envia, eventos renomeados que quebram dashboard, sync CRM atrasado que invalida atribuição.
Contrato alinha expectativas: marketing sabe lead time de 1 sprint para evento novo; engenharia sabe que rename de property é breaking change com 2 semanas de notice. Ambos sabem quem escalar quando dado não chega.
- Schema de eventos e campos documentado
- SLA de entrega (freshness, uptime)
- Owner producer e consumer por dataset
- Processo de change request com lead time
- Definição de breaking vs non-breaking change
O que incluir em um data contract prático?
Identificação: nome do dataset/evento, versão, owner producer (eng/product), owner consumer (marketing/analytics). Schema: campos, tipos, required/optional, enum values, exemplo JSON. SLA: freshness (T+1 8h), availability (99% monthly), latency máxima.
Change policy: non-breaking (add optional field) = notify; breaking (rename, remove, type change) = 2 sprint notice + dual period. Quality expectations: null rate max, volume min, reconciliation tolerance. Enforcement: testes automáticos que falham CI quando contrato violado.
| Seção | Conteúdo | Owner | Enforcement |
|---|---|---|---|
| Schema | Campos, tipos, enums | Producer + Analytics | dbt tests, JSON schema |
| SLA | Freshness, availability | Producer (Eng) | Freshness checks, alertas |
| Breaking changes | Rename, remove, type change | Ambos acordam | Version bump, dual-fire |
| Quality | Null rate, volume, reconciliação | Analytics | Pipeline tests |
| Escalation | Contatos, severity, MTTR | Ambos | Runbook, on-call |
Como implementar enforcement técnico?
dbt tests validam schema no warehouse: not_null, accepted_values, relationships. JSON Schema ou Avro no pipeline de ingestão rejeita payload inválido. CI/CD: PR que altera evento dispara teste contra contract. GTM: custom template valida dataLayer push antes de fire tag.
Enforcement sem burocracia: testes automáticos substituem email ‘por favor não quebre’. Falha no CI = deploy bloqueado até fix ou contract update aprovado.
Como gerenciar breaking changes sem paralisar marketing?
Classifique changes: additive (novo optional field) = deploy anytime com registro; modification (rename, type change) = RFC + dual period; removal = deprecation notice 4 semanas + dashboard migration. Marketing participa do RFC quando change afeta reporting.
Dual period: evento/property antigo e novo coexistem por 2 semanas; warehouse view unifica; dashboards migram para novo; antigo deprecated. Comunicação proativa — Slack #data-changes, não surprise na daily.
Qual processo de change request funciona?
Template leve: solicitante (marketing/analytics), evento/campo desejado, use case de negócio, urgency, consumer impact. Triage semanal: analytics + eng avaliam feasibility, effort, conflict com taxonomia. Aprovado → entra sprint → instrumentação → staging validation → prod → contract updated.
Fast track para non-breaking: analytics adiciona optional property via PR sem reunião. Breaking sempre passa por RFC. SLAs realistas: evento novo = 1-2 sprints; fix de bug = 24-48h.
- Template de request padronizado
- Triage semanal producer + consumer
- Fast track para non-breaking changes
- RFC obrigatório para breaking
- Contract versionado no git junto com código
Como medir se data contract está funcionando?
KPIs: incidentes de dado quebrado por quarter (meta: queda); MTTD de schema violation; % changes que passaram por processo vs ad hoc; satisfação de marketing com lead time. Qualitative: marketing consegue saber quando dado estará disponível sem perguntar no Slack?
Retrospectiva trimestral: contratos atualizados? Testes cobrindo schema? Breaking changes respeitaram dual period? Ajuste processo — contrato vivo, não PDF esquecido.
Checklist prático
- Data contracts documentados para eventos/datasets críticos
- Schema versionado no git com owners definidos
- SLA de freshness acordado e monitorado
- Classificação breaking vs non-breaking change
- Processo de change request com template
- Enforcement via dbt tests ou JSON schema
- Canal de comunicação de mudanças (#data-changes)
- Retrospectiva trimestral de contratos
Erros comuns
- Contract em PDF que ninguém lê ou atualiza
- Zero enforcement — contrato honor system
- Breaking change sem notice deployado direto
- Marketing bypassa processo via GTM workaround
- SLA irreal prometido e nunca cumprido
- Owner undefined — ninguém responsável quando quebra
Marketing e engenharia falando línguas diferentes?
A DataScroll facilita data contracts com schema, SLA e ownership claros — para dados fluírem sem surpresa.