Product core

The product core covers the data product itself and its business context. The app_overview object type is the application landing page and holds only a Description; domain groups related data products and carries a Description plus ownership. See What are data products for the concepts. This group has five object types: Domain, Data product, Use case, Product strategy, and KPI.

Domain

A domain is a business area — such as Sales, Marketing, or Finance — that groups related data products under one accountable team. Each data product belongs to exactly one domain, and domains can nest into sub-domains that mirror your organization. In the Data Product Standard application, domains come from the Open Data Product Specification (ODPS) and apply the Data Mesh principle of domain ownership.

Create a domain when a team needs a home for the products it owns, then assign each product and a steward to it. For example, a Sales domain groups the “Customer 360” and “Sales — daily overview” data products under the sales analytics team. For the full concept and how ownership works, see What are data products.

Domain attributes

A domain has one attribute:

Attribute	Description
Description	Rich-text summary of the domain.

A domain also carries an owner and a steward, which are relations rather than attributes.

Domain field reference

The application shows this help text when you create or edit a domain. It is reproduced here for reference.

Description

The description of this business domain. Explain what the domain covers, which part of the organisation owns it, and what kinds of data products belong to it. Write for a consumer browsing the catalog who needs to quickly decide whether their question fits this domain.

Good descriptions answer

What business area does this domain represent (e.g. Sales, Finance, Customer)?
Who owns it — which team / department is accountable?
What sub-areas or sub-domains does it contain?
Which source systems + upstream flows feed it?

Best practice

Keep it crisp — 1–2 paragraphs. Detail belongs on the individual data products.
Align the name and description with the business vocabulary, not engineering terminology.
If the domain has stewards or data product owners, name them here (or link to the owning team record).

Data product

A data product is a governed, consumable package of data built to be discovered and reused across teams. It has a clear purpose and a named owner. Consumers access it through one or more ports, and it can carry a data contract. As the central object of the Data Product Standard application, the data product comes from the Open Data Product Specification (ODPS). Every other object type describes or supports it.

Create a data product when a dataset, report, or API is ready to serve known consumers with a clear owner and purpose. For example, the “Customer 360” product in the Sales domain joins CRM and order data into one governed view for account teams. For what separates a data product from a raw data asset, see What are data products.

Data product attributes

A data product has these attributes:

Attribute	Description
Description	Rich-text summary of the product.
ID	Unique product identifier.
Type	Product classification, such as `raw_data`, `derived_data`, `dataset`, `reports`, or `algorithm` (see the field reference below for the full list of types).
Visibility	Access scope: `private`, `invitation`, `organisation`, `dataspace`, or `public`.
Governance Profile	Governance maturity: `structured`, `enforced`, `automated`, or `audit_ready`.
Portfolio Priority	Business priority: `critical`, `high`, `medium`, or `low`.
Value Proposition	Rich-text statement of the product’s value.
Product Version	Current version of the product.
Version Notes	A changelog-style note describing what changed in the current version.
Known Issues	Current data problems, limitations, or planned fixes disclosed to consumers.
Categories	A business-oriented classification of the data product — for example Finance, Customer, Marketing, Supply Chain.
Standards	Formal data or quality standards this product complies with.
Tags	Free-text tags for search and grouping.
Output File Formats	File formats the product is delivered in.
Content Sample URL	Link to a sample of the product’s output that consumers can preview before requesting access.
Logo URL	Image that represents the product in catalog and marketplace listings.
Brand Slogan	A short marketing tagline for the data product.
Product Series	Product family this product belongs to.

Data product field reference

The application shows this help text when you create or edit a data product. It is reproduced here for reference.

Description

The main description of the data product. Tell consumers what this product contains, what business questions it answers, and who should use it. Write for a colleague who has never seen this product — cover the data scope, its source, and the key business context.

Good descriptions answer

What data is in this product?
Where does it come from?
What is it designed to support?
What are the known limits of scope (geography, time window, granularity)?

Best practice

Set this as early as possible, even in draft form.
Prefer plain language over internal acronyms.
If the product is technical, add a short “for engineers” paragraph at the end.

Required by the ODPS standard. Without a description, consumers have no way to evaluate whether this product fits their needs.

ID

A unique, stable identifier for this data product. The Product ID is how other systems, APIs, contracts, and downstream consumers reference this product — think of it as its serial number.

What to enter

A short, machine-readable string (max 256 characters)
Use a meaningful convention that fits your organisation, for example dp-sales-daily-001, customer-360-v1, or a UUID
Make it URL-safe (lowercase letters, digits, dashes, underscores)

When to set it

At creation time, and never change it afterwards — external systems, data contracts, and lineage tooling may already depend on it
Every data product MUST have one; this field is required by the ODPS standard

Best practice

Pick a naming scheme and stick to it across your whole product portfolio — consistency makes cross-product discovery and governance far easier.

Type

Classifies the primary consumption pattern of this data product. Consumers use this value to quickly filter a catalogue and understand how they’ll interact with the product — passive data for analysis versus an active service, raw data versus a derived model, etc.

Choose the type that best describes the primary delivery model

Raw Data / Derived Data / Dataset — bulk data for downstream use
Reports / Analytic View / 3D Visualisation — pre-built analysis outputs
Algorithm / Decision Support / Automated Decision-Making — computational services
Data-Enhanced Product / Data-Driven Service / Data-Enabled Performance — data packaged into customer-facing or operational products
Bi-Directional — read/write integration

When to change it

Set this at creation. Only update it if the product changes its delivery model (e.g. a dataset becomes an API).

Visibility

Controls who can discover and see this data product in the catalogue. Getting this wrong can either expose sensitive data or hide valuable products from the people who need them — so choose deliberately.

Values

private — only your team sees it. Use during early development.
invitation — restricted to explicitly invited users or teams.
organisation — visible across your entire company.
dataspace — extended to trusted external partners in a shared data ecosystem.
public — openly discoverable to anyone.

How it evolves

Typical flow: start private or organisation during build, widen as the product matures, governance approvals complete, and documentation is ready for broader audiences.

Required by the ODPS standard.

Governance Profile

Signals how much operational rigour and control surround this data product. Helps consumers judge how trustworthy and well-managed the data is, and helps governance teams prioritise investment where it matters.

Values, from least to most strict

structured — basic policies in place (naming conventions, ownership, change control).
enforced — active policy checks and approval workflows.
automated — governance rules enforced by code: schema validation, automated quality checks, access controls.
audit_ready — full traceability, lineage, and compliance evidence suitable for regulators.

Set this when your organisation differentiates governance tiers — it makes cost/benefit decisions explicit. A critical product serving regulatory reports usually warrants audit_ready; an experimental dataset is fine at structured.

Portfolio Priority

Tells leadership, product managers, and on-call teams how important this data product is relative to others in your portfolio. Drives funding, staffing, incident-response order, and SLA ambition.

Values

critical — a failure has immediate, significant business impact. 24/7 support, tight SLAs.
high — strategic value; incidents get priority but not top-tier escalation.
medium — useful but not business-stopping.
low — convenience or experimental products.

When to fill it in

Any time you manage more than a handful of products. Without explicit priorities, everything looks equally important and resource allocation becomes guesswork.

Value Proposition

A concise statement (max 512 characters) of why this data product exists and the business benefit it delivers. Think of it as the elevator pitch — not “what’s in the box” but “why should I care?”.

Good value propositions

“Enables marketing to reduce churn by 15% through real-time customer behaviour signals.”
“Single source of truth for daily active users across all product lines — powers the weekly leadership review.”
“Compliance-certified view of all KYC events for anti-money-laundering reporting.”

Write it for a stakeholder who has never seen the product. It should answer:

What problem does this solve?
Who benefits?
What’s the measurable outcome?

Required by the ODPS standard. Often the difference between a widely-adopted product and one that quietly dies.

Product Version

Tracks the current release of the data product using semantic versioning (MAJOR.MINOR.PATCH, e.g. 2.4.1).

Semantics

Major (v1 → v2) — breaking changes: schema changes, removed fields, new access patterns. Consumers must migrate.
Minor — additive, non-breaking changes. Existing consumers keep working.
Patch — bug fixes only. No behavioural change.

When to set it

Set once the product reaches testing or production status, and bump on every release. Consumers and data contracts reference specific versions, so skipping versions or moving backwards breaks downstream dependencies.

Required by the ODPS standard.

Version Notes

A changelog-style note describing what changed in the current version. Helps consumers decide whether to upgrade and how to adapt their integrations.

Good notes are specific

Added customer_segment field. Removed deprecated zip_code_v1 column. Backfilled historical data to 2024-01-01. Breaking change: revenue now returns cents, not dollars.

Bad notes are vague

Various improvements and bug fixes.

When to fill it

Every time you bump the version. Keep each note self-contained — consumers often read only the diff between their current version and the latest.

Known Issues

Transparently disclose current data problems, limitations, or planned fixes. Builds trust with consumers by showing you are aware of problems and managing them, rather than letting them be discovered in production.

What to include

Data quality issues with scope and impact (“Q3 2024 revenue figures are understated by ~2% due to a missed source system”)
Temporary limitations (“Latency spikes during nightly ETL window, 02:00-04:00 UTC”)
Planned corrections with ETA (“Fix expected by 2024-11-01 in v2.3.0”)

Clear this when the issue is resolved and document the fix in Version Notes. Leaving this empty when problems exist erodes consumer confidence the moment someone discovers an issue on their own.

Standards

Formal data or quality standards this product complies with. Critical for regulated industries where consumers must verify that data meets compliance requirements before using it.

Common examples

ISO 8000 — data quality
ISO 19131 — geographic information
GDPR, CCPA, HIPAA — privacy regulations
FINRA, MiFID II, SOX — financial industry
Internal organisation standards (e.g. ACME Data Quality v3)

Set this only when you’ve genuinely been validated against the standard — don’t claim compliance you haven’t earned. When compliance is a key selling point, this field is often the first thing a consumer reads.

Output File Formats

Formats the data product is available in for download or integration. Essential for technical consumers to know whether the output is compatible with their tools before committing to use the product.

Common values

JSON, CSV, TSV
Parquet, Avro, ORC — columnar formats for analytics
XML, XLSX
SQL — direct database access

When to fill it

Only if the product delivers data as files or exports. If the product is purely an API or a dashboard, leave this empty — the Product Type field already communicates that.

Content Sample URL

A URL pointing to a representative example of the product’s output — a sample JSON response, a CSV snippet, a preview screenshot, or a hosted demo.

Why it matters

Lets consumers evaluate the data structure, field names, and value formats before requesting access. Dramatically reduces the evaluation cycle — minutes instead of days.

Best practice

Use a synthetic or anonymised sample if the real product contains sensitive data
Keep the sample small (< 1 MB) and hosted on a stable URL
Update the sample when the product’s schema changes materially

Logo URL

URL of an image that represents this data product visually in catalogues, dashboards, and marketplace listings. Can be a team logo, a domain icon, or a custom product brand image.

When to fill it

Set this when your organisation values visual branding in its data marketplace, or when you have many products and visual differentiation helps users navigate quickly. Purely cosmetic — no functional impact.

Specs

Prefer SVG for crispness; PNG (min 256×256) is the common fallback
Hosted on a stable, cacheable URL
Square aspect ratio renders best in tile/card views

Brand Slogan

A short marketing tagline for the data product. Appears in catalogue listings alongside the logo and name to quickly convey the product’s essence.

Examples

“The single source of truth for customer identity”
“Real-time fraud signals you can trust”
“Every click. Every customer. Every channel.”

When to fill it

Useful when products are offered in an internal or external marketplace and you want them to stand out. Especially valuable when many similar products compete for attention. Skip for purely technical or internal-use products.

Product Series

Groups related data products that share a common theme, data domain, or customer segment. Helps consumers discover the full set of products that go together.

Examples

“Customer Analytics Series” — customer profiles, transactions, segmentation, churn
“ESG Reporting Suite” — emissions, diversity, governance metrics
“Risk Platform v2” — credit, market, and operational risk data products

When to use

You offer several related products and want to cross-promote them
You want leadership to see how many products serve each strategic area

Skip this for standalone products that don’t belong to a broader family.

Use case

A use case is a concrete business scenario that a data product supports. It records how a real team puts the product to work and what outcome they get from it.

Use cases come from the Open Data Product Specification (ODPS) and form part of a product’s business context in the Data Product Standard application. They let prospective consumers see how others already gain value, which builds trust before anyone adopts the product. For how use cases, strategy, and KPIs tie a product to business value, see Pricing, licensing, and data holders.

Add a use case when you can point to a specific, proven way the product is used, rather than a hypothetical one. Give it a clear title, describe the scenario, and link to supporting material such as a dashboard or report.

For example, the “Customer 360” product might carry a use case for weekly churn prediction. It describes how the retention team scores at-risk accounts before each sales review.

Use case attributes

A use case has these attributes:

Attribute	Description
Use Case Title	Short name of the use case.
Use Case Description	Rich-text description of the use case.
Use Case URL	Link to supporting material.

Product strategy

A product strategy connects a data product to the goals it is meant to advance. It states what the product should achieve over a set period and how that ties back to wider business objectives.

Product strategy comes from the Open Data Product Specification (ODPS) and gives a product direction beyond its technical delivery. In the Data Product Standard application, one strategy is the parent of one or more KPIs, so each goal has measurable indicators behind it. For how strategy and KPIs align a product with business value, see Pricing, licensing, and data holders.

Create a product strategy when a product needs clear objectives, a timeframe, and a way to track progress. Set a status such as planned or active, record the start and end dates, and note how the strategy aligns with business goals.

For example, the “Sales — daily overview” product might run an active strategy to raise self-service reporting adoption across regional sales teams within a year.

Product strategy attributes

A product strategy has these attributes:

Attribute	Description
Strategy Status	Progress state: `planned`, `active`, `at_risk`, `achieved`, `partially_achieved`, `cancelled`, or `expired`.
Start Date	When the strategy period begins.
End Date	When the strategy period ends.
Objectives	Rich-text list of objectives.
Strategic Alignment	Rich-text note on alignment with business goals.

KPI

A KPI, or key performance indicator, is a measurable value that shows whether a product strategy is on track. It pairs a target with a direction, so progress toward the goal stays unambiguous.

KPIs come from the Open Data Product Specification (ODPS) and turn a strategy’s objectives into numbers you can monitor. In the Data Product Standard application, each KPI belongs to a product strategy and makes its goals accountable. For how KPIs and strategy tie a product to business value, see Pricing, licensing, and data holders.

Add a KPI when a strategy objective can be measured and tracked over time. Give it a name and unit, then set the target and a direction such as increase or at_least. Also record who owns it and how it is calculated.

For example, a strategy for the “Customer 360” product might track monthly active consumers. The target is 50, the direction is increase, and the product lead reviews it each month.

KPI attributes

A KPI has these attributes:

Attribute	Description
KPI ID	Unique identifier of the KPI.
KPI Name	Name of the indicator.
Unit	Unit the KPI is measured in.
Target	Target value to reach.
Direction	Desired movement: `increase`, `decrease`, `at_least`, `at_most`, or `equals`.
Timeframe	Period the target applies to.
Frequency	How often the KPI is measured.
Owner	Person accountable for the KPI.
Calculation	Rich-text description of how the KPI is calculated.

For how these object types connect to each other, see Data product object types and attributes.

Domain

Domain attributes

Domain field reference

Description

Data product

Data product attributes

Data product field reference

Description

ID

Type

Visibility

Governance Profile

Portfolio Priority

Value Proposition

Product Version

Version Notes

Known Issues

Categories

Standards

Tags

Output File Formats

Content Sample URL

Logo URL

Brand Slogan

Product Series

Use case

Use case attributes

Product strategy

Product strategy attributes

KPI

KPI attributes

Related articles

We use cookies