Metrics - spectrum_platform - spectrum_quality_1 - 23.1

Spectrum Data Quality Guide

Product type
Software
Portfolio
Verify
Product family
Spectrum
Product
Spectrum > Quality > Spectrum Quality
Version
23.1
Language
English
Product name
Spectrum Data Quality
Title
Spectrum Data Quality Guide
Topic type
Overview
Reference
Tips
How Do I
First publish date
2007
ft:lastEdition
2024-03-04
ft:lastPublication
2024-03-04T22:52:13.486265

Metrics specify the way in which data is measured. This is used for reporting purposes to show which types of exceptions occur in your data. For example, if the condition is designed to evaluate the record's completeness (meaning, for example, that all addresses contain postal codes) then you could specify "Completeness" as the data quality metric.

Note: The metrics you establish here will serve as default options both for Data Stewardship Settings and the Exception Monitor stage.

You can select one of the predefined metrics or you can define your own metric.

  • To define your own metric, click the Add item button Image of Add item buttonand configure options as necessary.
  • To edit an existing metric, select it, click the Edit item button Image of Edit item button, and make desired changes.
  • To delete a metric, select it and click the Delete item button Image of Delete item button.
  • To filter the list of metrics, enter search data in the Filter field. The table updates dynamically.

The following predefined metrics are initially available. These can be edited as required.

  • Accuracy—The condition measures whether the data could be verified against a trusted source. For example, if an address could not be verified using data from the postal authority, it could be considered to be an exception because it is not accurate.
  • Completeness—The condition measures whether data is missing essential attributes. For example, an address that is missing the postal code, or an account that is missing a contact name.
  • Consistency—The condition measures whether the data is consistent between multiple systems. For example if your customer data system uses gender codes of M and F, but the data you are processing has gender codes of 0 and 1, the data could be considered to have consistency problems.
  • Interpretability—The condition measures whether data is correctly parsed into a data structure that can be interpreted by another system. For example, social security numbers should contain only numeric data. If the data contains letters, such as xxx-xx-xxxx, the data could be considered to have interpretability problems.
  • Recency—The condition measures whether the data is up to date. For example, if an individual moves but the address you have in your system contains the person's old address, the data could be considered to have a recency problem.
  • Uncategorized—Choose this option if you do not want to categorize this condition.
  • Uniqueness—The condition measures whether there is duplicate data. If the dataflow could not consolidate duplicate data, the records could be considered to be an exception.