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 you get started. In this blog, we dive into the Qlik environment itself. I'll walk you through how a Qlik Data Product is structured and show you step by step how to create one and which decisions you can make along the way.

Whether you are a Qlik developer who has been building QVD layers for years or have only been working with the platform for a short while: by the end of this blog, you will 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 its Talend Cloud Data Integration (QDI) offering. The big news is that Data Products are now also available for Qlik Cloud Analytics. This means you can bundle your QVDs and other data assets into a fully fledged data product directly in the Analytics environment you already work in, without a QDI licence.

Previously, applying data product principles to your QVD layer meant switching to another 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 are already well on your way. The data product functionality gives you the structure to formalise what you are 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. At the core of a data product are datasets: your QVDs, or more broadly any 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 on which you describe the purpose, the contents and the context that consumers need. Qlik offers a GenAI-assisted documentation feature that can draft a first version based on your dataset names and metadata. It is a good starting point, although you will always want to review and personalise it. Alongside the documentation, ownership information is key: who owns the product and who should you contact if something is wrong? This is not decorative metadata: it is a crucial governance component that is often underestimated.

Qlik also automatically tracks lineage for the datasets in your product: where the data comes from, which transformations it has gone through and which apps or other downstream assets depend on it. This lineage is visualised 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 discuss 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 about that in part 4.

Creating a data product, step by step

Now it gets practical. This is how you 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 are 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

From the Qlik Cloud home menu, open Data Products. This is your home base for creating and managing data products. You will 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 will 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 help consumers determine whether this product is what they are looking for. The space you choose determines access: who can see and use the product is governed 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 will look at it more closely 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 organisation is not a product, it is a data dump.

Step 5: Set up ownership and documentation

Assign an owner and add relevant contact information. Qlik lets you add free-text role titles next to the name of the person concerned, giving you the flexibility to reflect your organisation's actual governance structure. Some roles worth considering:

• Data Product Owner: responsible for the business value and lifecycle of the product. This is the person who decides what goes into the product and keeps it relevant. In Qlik terms, this person will usually also have the Data Product Manager platform role.
• Data Owner: the senior business stakeholder with ultimate accountability for the domain this product represents. Often a head of department 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 is not right.
• 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 in all four roles for every data product, certainly 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 greatly 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 is worth investigating the cause before exposing the product to consumers. Part 3 of this series covers this in detail.

Step 7: Activate and publish

When you are satisfied, activate the product and publish it to the Data Marketplace. During activation, you choose the managed space in which the published copy appears. 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 some tips and considerations for more effective data products.

What scope makes sense?

The best data products are focused on a business domain, not on 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 are 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 may 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: deciding what goes in, maintaining the documentation and being 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: browsing the marketplace, viewing quality metrics and creating analytics apps directly from the product. Assigning these roles thoughtfully 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 does not bypass Qlik's access controls. Access to the underlying data is still governed 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 does not change what they are 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 reliable? 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 confidence.

In part 3 of this series, we take a deep dive into data quality: how the Qlik Trust Score works, how to configure 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. Until then!