10 min read
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 to the Marketplace. We ended that blog with a warning: 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. 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 concepts. If you haven't read that one yet, it's a good starting point. 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 prominently displayed in the data product interface and immediately gives consumers a signal of how much 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 are always calculated; the remaining 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 mentioning up front. First: the colored 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 plans, and on 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 enable or disable the optional dimensions 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 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 per-dataset threshold configuration. For Timeliness, you set the maximum acceptable age of the data per dataset, so the weight stays global but the definition of 'fresh enough' can vary per dataset. For Diversity, you configure the minimum expected number of fields and rows per dataset. The dimension weight is still global; only the threshold value differs. Adjusting the dimension weights and the display format requires access to the data quality admin settings, which is typically reserved for tenant administrators.
The seven dimensions
Validity and Completeness: the mandatory pair
Every dataset in a Qlik data product is scored on Validity and Completeness, regardless of how you've 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 like 'N/A' or 'Unknown' all count as gaps. A dataset where 40% of the 'Customer phone number' field is empty scores poorly on completeness. That's exactly the kind of signal you want visible before consumers start building on top of it.
The optional dimensions
Besides the mandatory pair, you can enable up to five additional dimensions and decide how much weight each carries in the total score.
Accuracy is where your own business rules come into play. Instead of checking format or presence, accuracy evaluates whether values are actually correct according to logic you define. For example: 'revenue must be positive' or 'end date must be later than start date'. How you build these rules is discussed further on 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 hasn't been updated on schedule. For operational datasets where freshness is critical, this dimension is worth enabling and weighting more heavily.
Findability creates a useful feedback loop: it rewards datasets that are well documented and tagged correctly. A dataset with a clear description and relevant tags scores better than one without. This directly incentivizes the documentation work covered in part 2.
Usage tracks whether the dataset is actually used in Qlik apps and other downstream tools. A low usage score doesn't necessarily mean the data is bad, but it does raise a useful question: does this data product serve 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 like 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 really becomes powerful for your specific business context. Qlik supports two types of accuracy rules.
Global rules are defined at the tenant or space level and can be applied to multiple datasets. They're ideal for organization-wide standards: 'all date values must be in the past', 'revenue values must be positive', 'country codes must be 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 specific to your catalog.
Both types are built through a visual rule builder: you select the column or columns you want to validate, choose the type of check, and preview the results against a sample of your data before confirming the rule. This makes it practical for data stewards and analysts to create and maintain rules.
It's 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 where a critical rule fails on 40% of records. Thoughtfully setting severity levels is part of getting meaningful signals out of the Accuracy dimension.
AI-suggested rules
Sometimes it's hard to figure out which rules should apply to your dataset. Instead of having to come up with this 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, for example 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 react to instead of having to come up with something from nothing.
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).
Your tenant administrator needs to enable this in the admin settings if it isn't already.
Semantic types
Some columns in a dataset have special requirements. A column like Email has a technical database type such as varchar(50), but there are specific properties that make it an email address. For instance, every valid email address will contain an @ and end in an extension like .com or .nl. Email is what's called a semantic type, just like Phone Number or IBAN, for example. Qlik already has a library of built-in semantic types by default, but also lets you create your own types via dictionaries, regular expression patterns, or composite types. This way, you could, for example, create a semantic type that validates whether the correct department names for your company 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.
Once columns are assigned semantic types, users searching the Qlik Catalog can filter by 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 highest-return things you can do to improve both your Trust Score and the overall usability of your catalog.
Getting started yourself
In this blog, we've shown you how to get started with data quality in your own Qlik environment:
- Register your datasets and let Qlik calculate the baseline Validity and Completeness scores. Identify the obvious issues first.
- Assign semantic types to your key columns. Particularly identifiers, dates, and fields with specific format requirements. This directly improves your Validity score and your catalog's findability.
- Work with your tenant administrator to make sure the Trust Score dimensions and weights reflect your organization's priorities. Remember this is a global setting, so it's worth aligning with other teams before changing anything.
- Run the AI rule suggestions and evaluate them against your business context. Apply the meaningful ones; reject or adjust the rest. Make sure cross-region processing is enabled if you want to use this feature.
- 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.
- Configure per-dataset Timeliness thresholds for datasets where freshness is critical.
- Make sure your data product's documentation mentions known quality issues or limitations. Transparency is part of trustworthiness.
Next time: putting your data product to use
With a well-built data product and a credible Trust Score, you're ready for the final question: how can the data products in Qlik actually be used by end users? In part 4, we'll 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 documentation options, filtering options, and the limitations you should know about. See you then!
Contact
Curious how you can structurally improve data quality and increase trust in your data products? With the Qlik Trust Score, custom quality rules, and smart use of AI, you can take concrete steps toward reliable data.
At E-mergo, we help organizations set up data quality, build data products, and get the most out of the Qlik platform.
Want to brainstorm about this or see what it looks like in practice? 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