In this tutorial you build one complete data product and publish it, so that another team can find it in the Data Market and request access. Working through a single realistic example is the fastest way to see how domains, assets, ports, and contracts fit together — each of which has its own reference page, but which only make sense in combination.
By the end you will have a published product with one output port, a data contract carrying a service-level agreement (SLA), and a named owner.
The scenario
The Marketing team keeps rebuilding the same churn analysis from raw event tables, and each analyst gets slightly different numbers. Two curated BigQuery tables already exist — daily churn scores and customer segments — but nobody outside the team knows about them, and nobody has promised to keep them running.
You will package those two tables as a data product called Customer churn signals, so Marketing and Customer Success consume one agreed source.
Before you start
Three things must be in place. The wizard cannot create them for you:
- The Data Product Standard application is added to your Space.
- The domain the product belongs to exists — in this example, Marketing.
- The two BigQuery tables are already cataloged in Dawiso, by a scan or added manually.
If the domain does not exist yet, create it first: every data product belongs to exactly one domain, and the wizard asks for it in the first step.
Step 1 — Launch the wizard and set the identity
In the top navigation, click + Create, then select Create Data Product under Wizards.
On the Basics step, enter:
| Field | Value |
|---|---|
| Space | Analytics |
| Domain | Marketing |
| Name | Customer churn signals |
| ID | dp-marketing-churn-signals |
| Type | dataset |
| Visibility | organisation |
| Description | Daily churn scores and customer segments for the active subscriber base, refreshed every morning. |
| Value proposition | Gives Marketing and Customer Success one agreed churn number, so campaigns and retention outreach target the same customers. |
The value proposition is the field consumers read to decide whether your product is worth adopting, so state the benefit rather than the contents. “Daily churn scores” describes the data; “one agreed churn number” explains why anyone should care.
Set the ID deliberately — it should not change once other systems reference it. A convention such as dp-<domain>-<subject> keeps a growing portfolio readable.
Step 2 — Name who is accountable
On the Ownership step, the wizard has already set you as Owner. Keep it if you are genuinely the accountable person; reassign it if not.
Then add the roles that matter for this product:
- Steward — the Marketing analyst who owns what “churn score” means and approves the contract.
- Custodian — the data engineer who runs the pipeline that refreshes the tables.
Leave SME and Producer empty for now. Every role except Owner can be set later on the product’s Ownership panel, and naming nobody is better than naming the wrong person.
Step 3 — Select the data
On the Data assets step, filter the technology to BigQuery and search for the two tables. Select:
churn_scores_dailycustomer_segments
Check the CONTAINED IN column before moving on. If an asset is already published through another product’s output port, it is not available here — that data belongs to another team’s product, and you would consume it rather than republish it.
Step 4 — Expose the data through an output port
On the Ports step, the wizard has created one output port named Primary Output. Rename it to something a consumer would recognize:
| Field | Value |
|---|---|
| Port name | Churn signals — BigQuery |
| Description | Daily churn scores and segment assignments, one row per active customer. |
Attach both tables to this port. The port takes its technology from the first asset you attach, and every other asset must match — which is why both BigQuery tables can share one port.
One port is the right answer here because both tables serve the same audience through the same technology. If you later add a REST API for the application team, that becomes a second output port with its own contract, not another asset on this one.
Step 5 — Add a contract with service levels
On the Data contracts step, create a contract and attach it to the output port:
| Field | Value |
|---|---|
| Name | Churn signals — standard tier |
| Contract ID | dc-marketing-churn-signals |
| Version | 1.0.0 |
| Level | Product |
| Description | Covers the daily churn signals delivered through the BigQuery output port. |
Then add the service levels you are willing to stand behind:
- Freshness — refreshed daily by 06:00 UTC.
- Availability — 99.5%.
This step is optional in the wizard, and skipping it is reasonable for a product only your own team uses. This product crosses a team boundary, so the contract is what turns “the table is usually there by morning” into something Customer Success can plan around. Promise what the pipeline actually delivers today, not what you hope to deliver.
Step 6 — Review and publish
On the Review step, work through the Completeness panel. Each unresolved item has a Fix link back to the step that owns it.
Then choose how to finish:
- Save For Later parks the product in the announcement state — not yet visible to consumers, and it does not need an Owner.
- Publish Now moves it to production, where it becomes live and appears in the Data Market. This needs an Owner, which you set in Step 2.
Choose Publish Now. The product is live.
Verify what you built
Open the Data Market and find Customer churn signals. A consumer from another team now sees the description and value proposition, the output port and how the data is delivered, the contract and its terms, and a named owner to hold to them — enough to decide whether to request access without contacting you first.
You built:
- A data product in the Marketing domain, in production.
- One output port publishing two BigQuery tables.
- A data contract with freshness and availability commitments.
- An Owner, a Steward, and a Custodian.
Next steps
The product is publishable, not finished. Three things are worth doing next:
- Run through the Pre-publish checklist to see what a reviewer would still flag.
- Classify the underlying tables for PII Level and Confidentiality — churn data usually carries personal data, and classification rolls up from the columns.
- Read What makes a good data product and judge this product against the six characteristics.
When another team asks for a change to the port, handle it as a versioned change rather than an edit — see Versioning and breaking changes.