Data consumer

What is a data consumer?

A data consumer is any person, team, report, dashboard, model, API, or downstream process that reads a data product. An analyst pulling last month's figures is a consumer. So is a Power BI dashboard, a churn model, a billing API, or a nightly sync into another system.

Most consumers are not people. On a modern data platform the majority are systems: semantic models, AI agents, automated workflows, and integrations that read one dataset and build the next on top of it.

The label exists to flip the point of view. Data has value only when something reads it to analyse, decide, or act, and that reader is the consumer you build for.

What a producer owes a consumer

Naming a consumer creates an obligation. Once a data product has real consumers, the producer owes them three things.

A contract
A data contract writes down the shape a consumer can rely on: the fields, their types, the meaning of each value, the data quality to expect, and the terms of use. For data that leaves the company, a data sharing agreement covers the same ground in legal terms.

A service level
A consumer needs to know how fresh the data is and how often it lands. A service level objective sets that: availability, latency, freshness, and update frequency.

A deprecation notice
When a field is renamed, dropped, or changes meaning, affected consumers need warning first. Data contracts formalise this as a notice period agreed before the old version is retired. Without a list of consumers, you have no one to warn.

When a breaking change hits a consumer

Suppose a customer data product has a column status with the text values active and churned. A producer tidies it up and switches to numeric codes, 1 and 2, without telling anyone.

A human consumer notices: the churn report shows numbers where it used to show words, and an analyst asks what changed. An automated consumer does not. A churn model that filtered on the text churned now matches nothing and reports zero customers at risk. A billing API that branched on active treats every account as inactive. Same change, no error raised, wrong results for days.

This is why consumers get named and ranked by how critical they are. A producer who knew that model and that API read the column would have shipped the change as a new version, warned the owners, and kept the old values until they migrated.

Consumer, producer, and owner

These three roles blur easily, but point in different directions.

Data producer
The team that builds and runs the data product. The obligation runs one way: the producer promises the contract and the service level, the consumer relies on them. In a data mesh this is the whole idea, where consumers are treated as customers.

Data owner
The role accountable for a dataset, deciding who may access it and which policies apply. A consumer uses the data; the owner sets the rules around it. Sometimes the owning team consumes its own data, but often the consumer sits elsewhere.

Data governance connects the three, and data lineage makes the consumer list usable: trace a column downstream and you see which reports, models, and APIs a change will hit.