How to build a data product in DataLens
A data product is the difference between "the customer data is in four systems" and "here is the customer dataset, and here is who owns it".
What you will do
You will identify candidate data products across your datasets, define the schema each should have, and see clearly which fields are mapped, which are derived and which are missing.
Data Products is a Pro capability.
When this is useful
- The same entity — customer, product, order — is assembled differently by every team that needs it.
- You are building a Customer 360 and want it defined once rather than rebuilt per report.
- Data is being consumed across teams and needs an owner and a contract.
- A domain-oriented data architecture is being introduced and needs somewhere concrete to start.
Before you start
- A Pro entitlement — Data Products is gated. Without it the section is not available.
- Several related datasets loaded — A data product is assembled from sources. One dataset does not need one.
- A view on ownership — A product without an owner is just a dataset with ambitions.
Steps
Open Deliver → Data ProductsPro
Select Deliver in the navigation, then Data Products. The screen works in three stages: Discover, Model and Transform.
The Discover stage, with Catalogue and Built tabs.
Discover candidates
Use Discover Data Products. DataLens examines the datasets you have and proposes products they could form.
These are proposals, not decisions. The screen says as much: confirm and customise before adding to the model.
A list of candidate data products with the datasets behind each.
Review and approve
Go through the candidates. Approve All accepts them wholesale and Clear All discards them, but the useful path is usually neither — review each one.
A proposal that assembles the wrong sources is worse than no proposal, and only you can tell.
Define the product
Set a Product Name and a Description. Name it for what a consumer would look for, not for how it was built.
The description is what someone reads when deciding whether this is the dataset they need. Write it for them.
Define the target schema
In the Model stage, define the schema the product should expose. Each field gets a status: Mapped where a source provides it, Derived where it is calculated, Gap where a source exists but does not cover it, and Missing where nothing supplies it.
The Gap and Missing fields are the honest output. They are what the product does not yet deliver, stated plainly rather than discovered by a consumer.
Each field marked Mapped, Derived, Gap or Missing.
Map and build
In the Transform stage, map the sources onto the target schema and apply it to produce the output.
The product created and listed under Built.
Publish it
A built product is available as a node in Model and can be published or exported like any dataset — with the difference that it is defined, described and owned.
What happens next
A data product can be a node in further modelling, published as an endpoint, or exported — the same surfaces as any dataset, from a defined starting point.
Quality rules and stewardship in Govern are what turn a defined product into a governed one.
Example
Customer data lives in the CRM, the billing database and the product database. Rather than every team assembling its own version, one Customer 360 product is defined with an agreed schema, an owner and two fields marked Missing because no system currently supplies them. Those two gaps become a backlog item instead of a silent inconsistency.
Tips
- Review discovered candidates rather than approving them all. The screen tells you to confirm and customise for a reason.
- Name the product for the consumer, not for the sources.
- Pay attention to Gap and Missing fields — that list is the roadmap for the product.
- Assign an owner. A product nobody owns decays back into a dataset.
Limitations
- Data Products is a Pro capability.
- Discovery proposes candidates from the datasets you have loaded. It cannot propose a product from a source you have not connected.
- Fields marked Missing stay missing until a source supplies them — the status is a statement of fact, not a step that can be skipped.
- A built product reflects the sources at build time; keeping it current depends on the pipeline or capture feeding it.
Related how-to guides
Join datasets and create views
Join datasets on the keys that relate them and save the result as a reusable view.
Connect a CRM
Bring Salesforce, HubSpot, Dynamics 365 or Zoho objects in as datasets you can join with everything else.
Set data quality rulesPro
Turn a one-off quality check into a standing rule, so the same problem is caught every time.
Publish and export data
Export as CSV, TSV, JSON, JSONL or Excel, publish an API endpoint, or generate a PDF or Word report.
Related questions
More of these on the DataLens FAQ page.
What is a data product in DataLens?
A defined, described and owned dataset assembled from your sources — a Customer 360 rather than four systems each holding part of the customer. DataLens can discover candidates across your loaded datasets, then help you define the target schema, showing which fields are mapped, derived, a gap, or missing entirely. It is a Pro capability.
Can DataLens help build a Customer 360 view?
Yes. Load the sources — CRM, billing, product — then use Data Products to define a customer product with an agreed schema, or join them into a view if you do not need the full product definition. The field-level Gap and Missing statuses tell you honestly what the view does not yet cover.
Try this in DataLens
DataLens is in private beta. Request access and work through this guide on your own data.
Request beta access