A dashboard that was working fine yesterday is broken today. Nobody on marketing touched anything. The cause, nine times out of ten: a data engineer renamed a column, changed a data type, or altered what a null value means in an upstream table that a marketing dashboard or reverse ETL sync depended on — with no warning, because nothing formally obligated them to warn anyone. A data contract is a versioned, explicit agreement about the shape of a dataset (its schema, types, semantics, and update frequency) between the team that produces it and the teams that consume it, enforced so that a breaking change can't ship silently.

What a data contract actually specifies

A data contract isn't just a schema definition — a schema says what a table looks like today, but a contract says what guarantees the consumer can rely on going forward. It typically specifies: the exact column names and types, which columns are guaranteed non-null, the semantic meaning of ambiguous fields (does status = 'active' mean active-this-month or active-ever?), the update/refresh cadence (hourly? daily?), and — critically — the deprecation process: how much notice a consumer gets before a breaking change ships, and what the migration path looks like.

Schema definition vs. data contract

Aspect	Plain schema definition	Data contract
Describes structure	Yes	Yes
Describes semantic meaning of fields	Rarely	Yes, explicitly
Enforced before deploy	No — descriptive only	Yes — CI check blocks breaking changes
Includes deprecation/notice process	No	Yes
Ownership assigned	Often unclear	Explicit producer + consumer sign-off
Versioned	Rarely	Yes, with changelog

Why marketing teams specifically need this

Marketing is a uniquely heavy consumer of warehouse data it doesn't own: lead-scoring tables built by data engineering, product-usage events instrumented by the product team, revenue data owned by finance. Marketing dashboards, reverse ETL syncs, and lifecycle-automation triggers all read from tables marketing has zero control over. When data engineering treats a schema change as a purely internal refactor (which, from their side, it often looks like), they have no visibility into the fact that a Hightouch sync and three Looker dashboards downstream depend on that exact column name. A data contract forces that dependency to be visible and formally acknowledged before the change ships.

data_contract.yaml

text

# data contract: customer_ltv_model
version: 2.1.0
producer: data-engineering-team
consumers:
  - marketing-automation (Hightouch sync -> Braze)
  - revops-dashboards (Looker)

schema:
  customer_id:
    type: string
    nullable: false
  ltv_tier:
    type: enum[low, medium, high, vip]
    nullable: false
    semantics: "Recomputed daily at 2am UTC; reflects trailing 12mo spend"
  last_purchase_at:
    type: timestamp
    nullable: true
    semantics: "Null means no purchase on record, NOT unknown"

update_frequency: daily, 2am UTC
breaking_change_notice_period: 14 days
deprecation_process: "Old field kept alongside new field for notice period,
                       announced in #data-contracts Slack channel"

A contract nobody enforces is just documentation

Writing a data contract document and hoping people read it before changing a table provides almost no protection — the whole point is automated enforcement. The practical version of this is a CI check on the data pipeline (often via a dbt contract test or schema-diff check) that fails the build if a column a documented consumer depends on is renamed, dropped, or retyped without a version bump and notice period. Without that automated gate, a data contract is just a wiki page nobody checks before shipping.

Start with your highest-blast-radius tables, not all of them

Formalizing a data contract for every table marketing touches is unrealistic and will stall on bureaucracy. Start with the two or three tables that feed the most downstream dependents — usually the lead-scoring model, the core customer/account dimension table, and whatever feeds the lifecycle-stage field — and expand the practice only once it's proven low-friction on those.

Rollout priority for data contracts

Table/dataset	Downstream dependents	Priority
Lead scoring model	CRM routing, lifecycle emails, sales dashboards	High — contract first
Customer/account dimension table	Nearly every marketing and RevOps dashboard	High — contract first
Campaign-level UTM attribution table	Paid media reporting, finance ROI reports	Medium
One-off experimental analytics table	Single analyst's exploratory query	Low — skip formal contract

What's next

Data contracts protect the pipelines feeding your stack, but the stack itself still needs a coherent architecture to connect those pipelines to activation tools in the first place.

Next: Reverse ETL Deep Dive →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →