Data Product Metrics and KPIs for Adoption and Value

Data product metrics are the measures that show whether a data product is used, trusted, and worth what it costs to run. They turn "we published a data product" into a question that can be answered: is anyone better off because it exists?

Most teams measure only what is easy to count, such as the number of products published or queries run. Those numbers rise even when nobody makes a better decision. A useful set of data product KPIs covers four things at once: whether people adopt the product, whether its data is good, whether it is delivered as promised, and whether it creates business value.

What Are Data Product Metrics?

Data product metrics are key performance indicators that a data product owner uses to judge whether the product is doing its job, and to decide what to improve, invest in, or retire. The idea comes straight from product management, adapted to data: a product is successful when its consumers succeed, not when it ships.

Zhamak Dehghani, who defined data products in the context of data mesh, made this explicit. Data product owners should define success criteria and business-aligned KPIs, such as the lead time for a consumer to discover and use the product. Her later writing adds data quality, decreased lead time, and data user satisfaction measured with a net promoter score as the objective measures that show data is delivered as a product.

Data product metrics differ from data quality metrics and data observability signals. Those describe the health of the data. Data product metrics include them, but also ask whether the right people use the product and whether it changes anything for the business.

The Four Categories of Data Product Metrics

A balanced scorecard looks at the product from four angles. Each one catches failures the others miss.

• Adoption: do the intended consumers find and use the product, and do they keep using it?
• Quality: is the data accurate, complete, valid, and consistent enough for the uses it was built for?
• Reliability: is the product delivered on time and available, as stated in its data SLA?
• Business value: does using the product lead to faster, cheaper, or better outcomes than the alternative?

The categories depend on each other. Low quality or poor reliability will eventually show up as falling adoption, and adoption without value means the product is busy rather than useful.

Adoption Metrics

Adoption metrics answer whether the product reaches the consumers it was built for. Count consumers, not queries: one scheduled pipeline can run thousands of queries a day for a single use case.

• Active consumers. The number of distinct people, applications, and AI agents that used the product in a period, usually a month. Track the intended consumers separately from incidental ones.
• Reuse across teams. The number of teams or use cases that depend on the product. Reuse is the main economic argument for data products, so a product used by one team only deserves a second look.
• Retention. The share of consumers active last quarter who are still active this quarter. Falling retention is often the first sign of a quality or relevance problem.
• Time to first use. How long a new consumer needs from discovering the product to using it successfully, the lead time Dehghani names as a KPI. Good documentation, a clear data contract, and a smooth access process shorten it.
• Time to access. The time from an access request to access granted. Long waits push consumers back to copies and workarounds.
• Consumer satisfaction. A short survey or net promoter score from the people who use the product, asked a few times a year.

Quality and Reliability Metrics

Quality and reliability metrics show whether the product keeps its promises. They are best tied directly to the targets in the product's contract and SLA, so the metric and the commitment cannot drift apart.

Quality

• Check pass rate by dimension. The share of quality checks that pass for each dimension consumers care about, such as completeness, validity, uniqueness, and timeliness. Report by dimension, not as one blended score, so the cause is visible.
• Open data issues. Issues reported by consumers or monitoring that are still unresolved, and how long they have been open.
• Contract breaches. The number of times the product violated its data contract, including unannounced schema changes.

Reliability

• SLA attainment. The percentage of delivery windows in which the product met its SLA, such as "ready by 6 a.m. on business days."
• Freshness and latency. The age of the newest data when consumers read it, compared with the target.
• Availability. The share of time the product's interfaces are reachable.
• Time to detect and time to repair. How quickly the team notices a problem, and how quickly it is fixed. Consumers often care more about these than about the number of incidents.

Business Value Metrics

Value is the hardest category to measure and the one most often skipped. Data products create value indirectly, through decisions and processes that use them, so value metrics usually combine a count with an estimate.

• Use cases enabled. The number of business use cases, reports, models, or applications that run on the product. Ask each owning team what the use case is worth to them.
• Rework avoided. The engineering time saved because teams reuse the product instead of building their own version. McKinsey reports that managing data like a product can deliver new use cases up to 90 percent faster and reduce total cost of ownership by 30 percent, mostly from this effect.
• Cost per consumer. The full running cost of the product, including compute, storage, and people, divided by active consumers. A falling cost per consumer is a sign of healthy reuse.
• Outcome impact. A measurable change in a business metric attributed to the product, such as lower churn after retention campaigns started using a churn score. Agree on the attribution method with the business owner up front.
• Decisions supported. For products that feed management or regulatory reporting, the reports and decisions that depend on them, and the cost of getting them wrong.

Vanity Metrics to Avoid

Some numbers look like progress but say little about whether data products work. They are fine as context, but they should not be targets.

• Number of data products published. Easy to inflate by wrapping existing tables in product metadata. A few products with many consumers beat many products with none.
• Raw query counts. One automated job can dominate them. Count consumers and use cases instead.
• Rows or terabytes served. Volume measures cost, not value.
• Catalog page views. Interest is not use. A product can be viewed often and then rejected because it does not fit.

How to Set Targets for a Data Product

Metrics only help when they come with targets, owners, and a moment when someone looks at them.

1. Start from the consumers. Ask the intended consumers what they need: how fresh, how complete, how quickly they need access. Those answers become the quality and SLA targets.
2. Pick one or two metrics per category. Eight well-understood KPIs are enough for most products. More than that and nobody reads them.
3. Measure a baseline first. Run the metrics for a month or two before committing to targets, so the targets reflect reality.
4. Assign each metric to a role. The data product owner owns adoption and value, the data steward owns quality, and the producing team owns reliability.
5. Review on a fixed cadence. A quarterly review is common. Use it to decide what to improve, and whether a product with no consumers should move toward retirement in its lifecycle.
6. Publish the numbers. Showing quality and SLA attainment next to the product, where consumers find it, builds more trust than any description.

How Dawiso Supports It

Dawiso is where the targets, definitions, and accountability behind data product metrics live, next to the products they describe. Usage and runtime figures themselves come from the platforms where the data is served.

• Quality targets and checks. In the data products platform, each product records quality dimensions with target objectives, and data contracts carry the executable checks, including the engine that runs them, such as Soda, Great Expectations, Monte Carlo, or dbt.
• SLA commitments. Products and contracts carry SLA properties across dimensions such as latency, uptime, update frequency, time to detect, and time to repair, plus support contacts.
• KPI definitions. The KPIs application documents each KPI with a definition and an optional calculation formula, and links it to business glossary terms and to the reports and data assets where it is used.
• Accountability. Every product has a named Owner and supporting roles such as Steward and Custodian, so each metric has someone who answers for it.
• Discoverability. Production products are listed in the Data Market with their value proposition, owner, contract, and terms, which shortens time to first use for new consumers.

Conclusion

Data product metrics exist to answer one question: is this product worth running? Answer it with a small, balanced set: adoption to show that the right consumers use it, quality and reliability to show that it keeps its promises, and business value to show that using it changes something. Avoid counting products, queries, or terabytes as success. Set targets with consumers, give each metric an owner, review it on a cadence, and let products that nobody needs move to retirement.

Sources

• Zhamak Dehghani, martinfowler.com - How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019; success criteria and KPIs such as lead time to discover and use)
• Zhamak Dehghani, martinfowler.com - Data Mesh Principles and Logical Architecture (2020; data quality, lead time, and net promoter score)
• McKinsey - How to Unlock the Full Value of Data? Manage It Like a Product (June 2022)
• Dawiso Help - Data Product Quality and SLAs
• Dawiso Help - Key Performance Indicators (KPIs)