Data Quality in Qlik Data Products - Part 3

In part 2 of this series, we looked at building a data product in Qlik: registering datasets, structuring the product, assigning ownership and publishing it on the Marketplace. We closed that blog with a warning: a well-structured product filled with inaccurate or outdated data is demonstrably worse than no product at all, because it creates a false sense of confidence. But how do you know whether your data product is of good quality?

I previously wrote a blog about data quality as a concept, in which we laid the theoretical foundation for the underlying ideas. If you haven't read it yet, it's a good place to start. In this blog, we explain how Qlik’s data product functionality brings data quality to life within the platform.

The Qlik Trust Score

Qlik’s answer to the challenge of measuring data quality is the Trust Score: a composite, configurable score that gives every dataset a quality rating based on multiple dimensions. The score is displayed prominently in the data product interface and gives consumers an immediate signal of how far they can trust the data before they start working with it.

The Trust Score has evolved from the original Talend Trust Score, which covered five dimensions, into a framework with seven dimensions. Two dimensions are mandatory and always calculated; the other five are optional. The score can be displayed as a rating out of 5 or as a percentage, depending on what your organization finds most intuitive.

Before we discuss the individual dimensions, two things are worth pointing out up front. First, the coloured quality bar you see in the dataset overview is not the same as the full Trust Score. That bar only represents the two mandatory dimensions (Validity and Completeness) and is a quick visual summary. To see the complete picture, you need to open a dataset directly. Second, the Trust Score is available on Qlik Talend Cloud Enterprise and Premium subscriptions, and on the Qlik Cloud Analytics Premium and Enterprise tiers.

Configuring the Trust Score

The Trust Score configuration is managed centrally via Data Integration > Data quality > Qlik Trust Score in the platform. Here you can switch the optional dimensions on or off and set the weight of each active dimension, with all weights adding up to 100%. The configuration applies to all datasets across your entire tenant, not to individual data products. If you decide that Timeliness gets 30% of the weight, that applies to every dataset in your environment.

Timeliness and Diversity are an exception to this global rule in one specific respect: both offer a per-dataset threshold configuration. For Timeliness, you set the maximum acceptable age of the data per dataset, so the weight is the same globally but the definition of ‘fresh enough’ can vary by dataset. For Diversity, you configure the minimum expected number of fields and rows per dataset. The dimension weight is still global; only the threshold differs. Adjusting the dimension weights and the display format requires access to the data quality administration settings, which is usually reserved for tenant administrators.

The seven dimensions

Validity and Completeness: the mandatory pair

Every dataset in a Qlik data product is assessed on Validity and Completeness, regardless of how you have configured the rest of the score. Validity checks whether values have the correct format and type. This is where Qlik’s semantic types feature does a lot of the work. If your ‘Email address’ column contains values that don't look like email addresses, validity drops. Completeness measures how much data is missing: null values, empty fields and inconsistent placeholders such as ‘N/A’ or ‘Unknown’ all count as gaps. A dataset in which 40% of the ‘Customer phone number’ field is empty scores poorly on completeness. That is exactly the kind of signal you want to be visible before consumers start building on top of it.

The optional dimensions

In addition to the mandatory pair, you can enable up to five additional dimensions and decide how much weight each one carries in the overall score.

Accuracy is where custom business rules come into play. Instead of checking format or presence, accuracy evaluates whether values are actually correct according to the logic you define. For example: ‘revenue must be positive’ or ‘end date must be later than start date’. We discuss how to build these rules later in this blog.

Timeliness measures whether the dataset is refreshed often enough to remain useful. You set the expected refresh frequency per dataset, and Qlik flags when the data has not been updated on schedule. For operational datasets where freshness is crucial, this dimension is worth enabling and giving more weight.

Discoverability creates a useful feedback loop: it rewards datasets that are well documented and properly tagged. A dataset with a clear description and relevant tags scores better than one without. This directly encourages the documentation work covered in part 2.

Usage tracks whether the dataset is actually being used in Qlik apps and other downstream tools. A low usage score does not necessarily mean the data is bad, but it does raise a useful question: does this data product meet a real need?

Finally, Diversity is primarily aimed at AI use cases. It evaluates the variety, volume and distribution of values in a dataset to assess how suitable it is as training or retrieval data for AI applications. If your data products feed machine learning models or RAG-based tools such as Qlik Answers, this dimension is worth considering.

Custom data quality rules

Validity and Completeness give you a solid foundation, but the Accuracy dimension is where the Trust Score becomes truly powerful for your specific business context. Qlik supports two types of accuracy rules.

Global rules are defined at tenant or space level and can be applied to multiple datasets. They are ideal for organization-wide standards: ‘all date values must be in the past’, ‘revenue values must be positive’, ‘country codes must contain two characters’. You define them in one place and reuse them wherever they apply. Dataset-specific rules, as the name suggests, apply to a single dataset and capture logic that only makes sense in that context, for example checking whether a product code follows a pattern that is specific to your catalogue.

Both types are built with a visual rule builder: you select the column or columns you want to validate, choose the type of check and preview the results on a sample of your data before confirming the rule. This makes it practical for data stewards and analysts to create and maintain rules.

It is also useful to know that every rule has a severity level: Critical, Major, Standard or Minor. This level determines how much a failing rule affects the overall score. A dataset with a few minor violations scores very differently from one in which a critical rule fails for 40% of the records. Setting severity levels thoughtfully is part of getting meaningful signals from the Accuracy dimension.

AI suggestions for rules

Sometimes it is hard to think of which rules should apply to your dataset. Rather than having to come up with them yourself from scratch, Qlik can analyze your dataset and proactively suggest quality rules based on patterns it detects in the data. If a column consistently follows a certain format, such as a specific date pattern, a country code structure or a numeric range, Qlik will suggest a rule to formalize and enforce that pattern.

This is useful in two ways. First, it surfaces quality issues you didn't know existed: columns you assumed were clean, but where exceptions have quietly crept in. Second, it significantly lowers the barrier to getting started with custom rules. You have something to respond to instead of having to invent something from nothing.

Please note: AI-assisted rule generation requires “cross-region inference” to be enabled in your tenant, because Qlik’s GenAI capabilities process data outside your tenant region (see also https://help.qlik.com/en-US/cloud-services/Subsystems/Hub/Content/Sense_Hub/Admin/cross-region-data-processing.htm).

The tenant administrator needs to enable this in the administration settings if that has not already been done.

Semantic types

Some columns in a dataset have special requirements. A column such as Email has a technical data type from the database, for example varchar(50), but there are specific characteristics that make it an email address. Every valid email address contains an @ and ends with an extension such as .nl or .com. Email is a so-called semantic type, just like a Phone number or an IBAN. Qlik comes with a library of built-in semantic types as standard, but also lets you create your own types using dictionaries, regular expression patterns or composite types. For example, you can create a semantic type that validates whether your company's correct department names have been used.

When a semantic type is assigned to a column, Qlik uses it for validity: does this value look like an email address? Does this phone number follow the correct format for the Netherlands? This makes validity far more meaningful than simply checking whether a column contains a non-empty string.

When columns are tagged with semantic types, users searching the Qlik Catalog can filter on the kind of data a dataset contains. For example: finding all datasets that contain an IBAN column, without needing to know how each developer named that column. Investing time in assigning semantic types to the key columns in your data products is one of the most rewarding things you can do to improve both your Trust Score and the overall usability of your catalogue.

Getting started yourself

In this blog, we have shown how to get started with data quality in your own Qlik environment:

1. Register your datasets and let Qlik calculate the baseline scores for Validity and Completeness. Identify the obvious issues first.
2. Assign semantic types to your key columns, in particular identifiers, dates and fields with specific format requirements. This immediately improves your Validity score and the discoverability of your catalogue.
3. Work with your tenant administrator to make sure the Trust Score dimensions and weights reflect your organization's priorities. Remember that this is a global setting, so it is worth aligning with other teams before changing anything.
4. Run the AI rule suggestions and evaluate them against your business context. Apply the ones that make sense; reject or adjust the rest. Make sure cross-region processing is enabled if you want to use this feature.
5. Define any additional Accuracy rules for business logic the AI won't know about. Set severity levels thoughtfully so the score reflects the real impact of each violation.
6. Configure per-dataset Timeliness thresholds for datasets where freshness is crucial.
7. Make sure your data product's documentation mentions known quality issues or limitations. Transparency is part of trustworthiness.

Next time: your data product in use

With a well-built data product and a credible Trust Score, you're ready for the final question: how can end users actually use the data products in Qlik? In part 4, we look at the Data Marketplace from the consumer's perspective and show how analysts can go from discovering a data product to a working Qlik Sense app in just a few clicks, and how API endpoints work, including the documentation options, filter options and the limitations you need to be aware of. Until then!