Quality Score Best Practices¶

DO Calculating quality scores

Guidelines for keeping quality scores meaningful: a score should rise and fall with the data your team depends on, not with tables nobody watches.

Profile and scan only the tables you intend to monitor¶

Every container that has been profiled and scanned gets a score and joins the datastore average. A table with no checks scores very low, so running operations on the whole datastore during setup can flood the average with tables nobody meant to monitor. Select the tables you care about when you run Profile and Scan. See the low datastore score example for how this plays out.

Give every monitored field at least one check¶

Coverage is one of the most influential dimensions, and it rewards the first checks most: one check takes a field from 0 to about 60, and three checks reach about 94. A field with no checks drags its container down even when its data is correct. Start with one check per important field, then add more where the data is critical. See Coverage Dimension.

Scan all active checks on a regular schedule¶

Coverage also rewards checks that are asserted often and recently. A scan that asserts only selected checks counts only toward those checks, and checks left out of every scan lower Coverage over time. Pair targeted scans with a regular scan of all checks. Daily or more frequent assertion of every check gives the highest coverage.

Profile at least once a week¶

Consistency depends on profiling history: without it, the score cannot confirm that your data is stable. Regular profiling keeps statistics current, and weekly or more frequent profiling gives the maximum boost to Consistency.

Keep the default weights and decay period unless you have a clear reason¶

The defaults reflect scoring practices refined across many organizations. Changing weights alters how anomalies affect the score and can send misleading signals. When governance priorities do justify a change, document the rationale so others can read the score correctly. See Dimension Weights.

Configure the datastore once and override only the exceptions¶

Containers without their own settings inherit the datastore's decay period and weights. Set the common policy on the datastore, then add container overrides only where the data needs something different, such as Timeliness on a static reference table. See Settings Inheritance and Overrides.

Use tag weights to make critical tables count¶

By default every scored container counts equally in the datastore score. Give the tables your business depends on a tag with a positive weight modifier so a problem there moves the datastore score. Container weights are recalculated when the datastore's tags change, or when you use Move to, Merge, or Remove on a tag's page, so a tag assigned directly to a container counts only after one of those. See Tag Weight Modifiers.

Compare scores only across comparable settings¶

Two datastores with different decay periods or dimension weights produce scores on different terms. Before comparing totals, check that their settings match, and look at the dimension breakdown alongside each score.

Track the trend, not just the number¶

Different kinds of data have different inherent quality: a free-form text field will rarely match a constrained one. Focus on how a score changes over time and whether it meets the needs of the data's use case. See Interpreting Scores.

Re-scan after fixing the data¶

Qualytics does not know a fix landed until a scan confirms it. After correcting the source data, run a Scan so the anomalies are re-evaluated and the score reflects the fix.