9 min read
Building Your First Data Product in Qlik - Part 2
In part 1 of this series, we discussed the concept of data products, the Data Mesh philosophy, and what to consider before getting started. In this blog, we dive into the Qlik environment itself. I'll walk you through the structure of a Qlik Data Product and show you step by step how to create one and which decisions you can make along the way.
Whether you're a Qlik developer who's been building QVD layers for years or someone who's only recently started working with the platform: by the end of this blog, you'll have a concrete idea of what working with Data Products in Qlik looks like in practice.
A feature for every Qlik Cloud user, with a few extras for Talend QDI
As mentioned in the first blog, Qlik launched data product functionality some time ago as part of the Talend Cloud Data Integration (QDI) offering. The big news is that Data Products are now also available for Qlik Cloud Analytics. That means you can bundle your QVDs and other data assets directly in the Analytics environment you already work in into a full-fledged data product, without a QDI license.
Previously, applying data product principles to your QVD layer meant switching to a different part of the platform. Now, Qlik Analytics users have access to the same governance capabilities: structured ownership, discoverability, lineage, and quality monitoring. In short: if you have a Qlik Analytics environment and a reasonably well-structured QVD layer, you're already well on your way. The data product functionality gives you the structure to formalize what you're already doing.
What a Qlik Data Product consists of
Before you create anything, it helps to understand what a Qlik Data Product actually consists of. The core of a data product is formed by datasets: your QVDs, or more broadly, all registered data assets in the Qlik Catalog, grouped into a coherent, domain-specific collection. But around those datasets sit several layers of functionality that turn a simple grouping of files into something genuinely useful.
Each data product has its own documentation page where you describe the purpose, content, and context consumers need. Qlik offers a GenAI-assisted documentation feature that can draft a first version based on your dataset names and metadata. A good starting point, though you'll always want to review and personalize it. Alongside the documentation, ownership information is central: who owns the product, and who should you reach out to if something's wrong? This isn't decorative metadata: it's a crucial governance component that's often underestimated.
Qlik also automatically tracks lineage for the datasets in your product: where the data comes from, what transformations it has gone through, and which apps or other downstream assets depend on it. That lineage is visualized and directly available to consumers from the data product interface. Finally, each dataset carries a Trust Score: Qlik's data quality framework that gives consumers an impression of the overall quality of the data. We'll cover exactly how that works in detail in part 3 of this blog series. Once everything is in order, the product can be published to the Data Marketplace: the self-service discovery layer where business users can browse and use data products. More on that in part 4.
Creating a data product, step by step
Now it gets practical. Here's how to create a data product in Qlik Cloud Analytics.
Step 1: Make sure your datasets are registered
Before you can create a data product, your QVDs or other data assets need to be registered in the Qlik Catalog. In Qlik Cloud, you can register them directly from the catalog interface by pointing Qlik to the relevant space and connection. Once registered, they become available for profiling, quality monitoring, and inclusion in data products. If you use Qlik Talend Data Integration to land and transform data, your datasets are already in the catalog as part of that pipeline.
Step 2: Navigate to Data Products
Open Data Products from the Qlik Cloud start menu. This is your home base for creating and managing data products. You'll see an overview of existing products and an option to create a new one.
Step 3: Create the data product
Click to create a new data product. You'll be asked for a name, a description, and a space. For the name, choose something descriptive and domain-specific. 'Finance' is too broad; 'Financial Results & Actuals' is better. Don't skip the description. Even two sentences already help consumers determine whether this product is what they're looking for. The space you choose determines access: who can see and use the product is determined by the permissions on that space.
Step 4: Add datasets
Now you add the datasets that belong to this product. This is where the most important design decision is made, and we'll pay more attention to that in the next section. The short version: include datasets that logically belong to the same business domain and that a consumer typically needs together. A data product that contains every dataset in your organization isn't a product, it's a data dump.
Step 5: Set up ownership and documentation
Assign an owner and add relevant contact information. Qlik lets you add freely definable role titles alongside the name of the person in question, giving you the flexibility to reflect your organization's actual governance structure. A few roles worth considering:
- Data Product Owner: responsible for the business value and lifecycle of the product. This is the person who decides what's in the product and keeps it relevant. In Qlik terms, this person will typically also hold the Data Product Manager platform role.
- Data Owner: the senior business stakeholder with ultimate responsibility for the domain this product represents. Often a department head or similar. Not necessarily a day-to-day operational role, but the right escalation point for access and policy decisions.
- Data Steward: the operational guardian of the data. Monitors quality, maintains definitions and documentation, and investigates anomalies. This is the person consumers should call when something's wrong.
- Technical contact: the data engineer or developer who built and maintains the underlying pipelines and QVDs. Keep this separate from the business roles above; consumers deserve to know who fixes things when something breaks.
You don't need to fill all four roles for every data product, especially not at the start. But having at least a Data Product Owner and a Technical contact gives consumers two clear points of contact and contributes strongly to trust in the product.
Step 6: Check the Trust Score
Before publishing, look at the quality metrics of your datasets. If one or more scores are low, it's worth investigating the cause before exposing the product to consumers. Part 3 of this series covers this in detail.
Step 7: Activate and publish
Once you're satisfied, activate the product and publish it to the Data Marketplace. During activation, you choose which managed space the published copy will appear in. All users with the right access to that space can then discover and use the data product.
The decisions that matter most
Creating a data product is the easy part. Structuring it well takes more thought. Here are a few tips and considerations for more effective data products.
What scope makes sense?
The best data products are focused on a business domain, not a technical system. 'Sales data from CRM' is a technical description; 'Customer & Opportunity Intelligence' is a domain-focused one. Domain-focused products are more likely to be reused across multiple use cases, because they're defined around a business concept rather than a data source. A useful question to ask: do consumers of this product typically need all the datasets together, or are some datasets unlikely to be used alongside each other? If the latter is the case, those datasets might belong in a separate product.
On the other hand, don't split too aggressively either. If consumers consistently have to combine datasets from two supposedly separate products to answer a single question, those datasets probably belong together.
Which roles do you assign?
Qlik Data Products work within Qlik's existing role-based access model. The two key roles are the Data Product Manager and the Can Consume role. The Data Product Manager can create and manage data products. This is the person responsible for the product's lifecycle: decides what goes into it, maintains the documentation, and is accountable for quality. Think of it as a product owner role in the software development sense. The Can Consume role gives users the ability to discover and use the data product: by browsing the marketplace, viewing quality metrics, and creating analytics apps directly from the product. Thoughtfully assigning these roles is what makes the difference between a data product that gets used and one that gathers digital dust.
What about security?
Publishing a data product doesn't bypass Qlik's access controls. Access to the underlying data is still determined by the permissions on the datasets and spaces. The data product is a discovery and governance layer. It helps users find and understand the data, but it doesn't change what they're allowed to see. This is an important point to communicate clearly to security-conscious stakeholders: a data product is not a back door.
Next time: making your data trustworthy
Now that you know how to build a data product in Qlik, the logical next question is: how do you make sure the data in it is actually trustworthy? A well-structured product filled with inaccurate or outdated data is arguably worse than no product at all, because it creates a false sense of trust.
In part 3 of this series, we'll dive deep into data quality: how the Qlik Trust Score works, how to tune and refresh it, how to define your own quality rules, and how Qlik's AI can help you uncover quality issues you didn't even know you had. See you then!
Contact
Curious how data products in Qlik can help your organization get more value out of data? At E-mergo, we help organizations set up data products, strengthen data governance, and make the most of the Qlik platform.
Want to brainstorm about your situation or take a practical look at what's possible? Feel free to get in touch with us. We're happy to think along with you.
Written by Lennaert van den Brink
Cluster Manager/Senior BI Consultant