Skip to content

How Datastore Quality Scores Work

This page describes the mechanics behind the Data Quality Score: how the score composes across levels, the 8 dimensions that feed the container score, how settings inheritance and overrides work, and what triggers a recalculation.

Score Hierarchy

Quality scores are calculated at three levels, each building on the one below:

graph TD
    A["<b>Datastore Score</b><br/>Weighted avg of containers"] --> B["<b>Container Score</b><br/>8-dimension model"]
    B --> C["<b>Field Score</b><br/>Per-field checks & profiles"]
Level How It's Calculated
Field Each field receives a score based on its accuracy, consistency, conformity, precision, coverage, and completeness, using Profile metadata and Scan anomalies.
Container Each container (table/file) aggregates its field scores using a multiplicative baseline model across 8 quality dimensions.
Datastore The datastore score is the weighted average of all container scores. Container weights can be influenced by tag weight modifiers.

Only Scanned Containers Count

The datastore score only includes containers that have been scanned at least once. Containers that have been synced and profiled but never scanned are excluded from the datastore-level score. This means a newly synced datastore will not have a quality score until you run your first Scan operation.

Settings Inheritance and Overrides

Datastore quality score settings define the decay period and dimension weights for the datastore score. They also act as the default for containers that do not have their own quality score settings. A container (table, file, computed table, computed file, or computed join) can override that inherited configuration with its own settings.

This means:

  • Unconfigured containers inherit datastore settings: Changing the datastore decay period or dimension weights affects containers that do not have an override.
  • Container overrides are local: Changing a container's settings affects that container, but it does not change the datastore settings or other containers.
  • System defaults apply first: Until the datastore is configured, its score and containers without overrides use the system defaults (180-day decay, all dimensions at weight 1.0).
  • Use overrides for exceptions: Configure the datastore once for the common policy, then add container settings only where the data needs a different decay period or dimension weighting.
graph TD
    DS["<b>Datastore Settings</b><br/>Decay: 90 days, Accuracy: 1.5"] --> DS_SCORE["Datastore Score<br/>(weighted avg of container scores)"]
    DS --> C1_SCORE["Container A Score<br/>(inherits datastore settings)"]
    C2["<b>Container B Override</b><br/>Decay: 30 days, Timeliness: 0"] --> C2_SCORE["Container B Score"]
    C1_SCORE --> DS_SCORE
    C2_SCORE --> DS_SCORE

In this example, the datastore uses a 90-day decay with a higher Accuracy weight. Container A inherits that configuration because it has no override. Container B uses its own 30-day decay with Timeliness disabled. Both container scores still contribute to the datastore's weighted average.

The 8 Quality Dimensions

Every container score is composed of 8 dimensions, each measuring a different aspect of data quality:

Icon Dimension Description Example
Completeness Percentage of fields with non-null values across all profiles. A field with 5% null values has lower completeness than a field with 0%.
Coverage Count and frequency of quality checks asserted for each field. More checks = higher coverage. A field with 10 active checks has higher coverage than a field with 2.
Conformity Adherence to specified formats and business rules defined by quality checks. An email field where 3% of values fail a pattern check has reduced conformity.
Consistency Uniformity of data types and representation over time, including changes in field distributions. A field that changes from 95% integers to 80% integers between scans shows consistency drift.
Precision Resolution and granularity of field values against expected patterns. A timestamp field truncated to day-level when hour-level is expected has lower precision.
Timeliness Data availability according to expected schedules and freshness. A table expected to update daily but last updated 3 days ago has reduced timeliness.
Volumetrics Consistency in data volume and shape over time. A table that normally has 1M rows but suddenly has 100K indicates a volumetric anomaly.
Accuracy How well field values match their real-world counterparts based on check assertions. A price field where 2% of values fail a "greater than zero" check has reduced accuracy.

Each dimension produces a score from 0-100. These are combined using a multiplicative baseline model (starting from a baseline of 70) where each dimension's impact is proportional to its configured weight. When only one dimension has a weight above 0, the container score simply mirrors that dimension's score instead of using the model.

How Dimensions Combine into a Container Score

Suppose a container has the following dimension scores (all weights at default 1.0):

Dimension Score
Completeness 98
Coverage 85
Conformity 92
Consistency 95
Precision 100
Timeliness 100
Volumetrics 100
Accuracy 88

The multiplicative model starts from a baseline of 70 and adjusts up or down based on each dimension. Dimensions scoring 100 have no negative impact; dimensions below 100 pull the score down proportionally to their weight. In this case, Coverage (85) and Accuracy (88) are the main detractors, producing a container score around 82.

At the datastore level, if this container has a weight of 3 and another container has a weight of 1 with a score of 95, the datastore score would be: (82 × 3 + 95 × 1) / (3 + 1) = 85.25.

Decay Period

The decay period controls how far back in time Qualytics looks when calculating scores. By default, only anomalies, profiles, and scans from the last 180 days are included.

The decay period can be set from 7 to 180 days, with a default of 180 days.

This means:

  • Old issues naturally age out: If an anomaly was detected 6 months ago and has not recurred, it no longer impacts the score.
  • Recent issues weigh fully: Any anomaly within the decay window is fully counted.
  • Shorter window (for example, 7 days): Focuses the score on recent quality activity. Use it when recent changes matter most.
  • Longer window (for example, 180 days): Provides a broader historical perspective for trend analysis.

Info

To configure the decay period for your datastore, see the Quality Score Settings page.

Dimension Weights

Each of the 8 dimensions has a configurable weight that controls its impact on the total container score:

  • A weight of 1.0 (default) gives the dimension its full impact.
  • A weight of 0 excludes the dimension from scoring: it is treated as fully healthy and cannot pull the score down.
  • Weights between 0 and 1 proportionally reduce the dimension's influence.

Weights can be set from 0 to 2.0 (in 0.1 increments), with a default of 1.0.

This allows you to align the scoring system with your organization's data governance priorities. For example, if timeliness is critical for your use case, increase its weight; if volumetrics is less relevant, reduce it.

Disabling a Dimension

Setting a dimension weight to 0 excludes it from scoring. The dimension turns grey in the settings UI and is treated as fully healthy, so it cannot pull the container or datastore score down. This is useful when a dimension is not relevant to your data (for example, Timeliness for a static reference table).

Info

To configure dimension weights for your datastore, see the Quality Score Settings page.

Tag Weight Modifiers

Tags assigned to datastores can include a weight modifier (-10 to 10) that influences how individual containers contribute to the overall datastore score. Containers with higher tag weights have more impact on the datastore-level quality score.

Tags and Weighting

For more on how tags influence quality scores, see the Tags Introduction page. For details on the weight calculation formula, see the Weighting documentation.

What Triggers a Recalculation?

Qualytics recalculates a quality score when an event changes the measurements or quality signals used by that score. These events include:

  • A Scan operation completes (anomalies detected or clean scan).
  • A partition-level scan finds new anomalies.
  • A scan is deleted.
  • A Profile operation completes (new field statistics available).
  • An anomaly status changes (acknowledged, resolved, etc.).
  • An anomaly is deleted.