A data quality assessment should end with a release decision for a defined use: approve, restrict or hold. Start with the business action, agree the evidence and error tolerances, test a representative dataset, and document which records may proceed. A high completeness score alone does not establish that enriched company and contact data are safe to use.
This guide gives enterprise data and RevOps teams a practical acceptance framework, a worked assessment ledger and four decision tools. The numerical examples are illustrative calculations, not measured provider performance.
What is a data quality assessment?
A data quality assessment evaluates whether a dataset meets the requirements of its intended use. Profiling describes the dataset: missing fields, formats, duplicate values and unusual distributions. Assessment interprets those observations against a business decision. Cleansing changes the data. Keeping those activities separate makes the result easier to challenge and reproduce.
Consider a company record with a valid domain, an employee count and a contact name. It may be useful for account research while remaining unsuitable for automated contact routing. The employment relationship may be old, the employee count may refer to the group, and the name may identify several people. The same record can therefore pass one assessment and fail another without either decision being inconsistent.
The output should be a short decision record supported by evidence. It should name the population tested, the intended action, policy version, measured outcomes, unresolved questions, approved scope and accountable owner. “The database scored 92%” is incomplete unless the reader knows what was measured, what was excluded and which failures the score could conceal.
Define the release decision before inspecting results
Write one sentence describing the action the data will enable. For example: “Approve proposed updates to company industry and headcount bands for existing enterprise accounts, while retaining current account identifiers and account ownership.” This is narrower and more testable than “improve our CRM”. It also makes a failed assessment actionable: a problem with headcount semantics need not block an unrelated contact-research workflow.
Agree tolerances before seeing supplier results. Otherwise the team may lower its standard to justify a favoured provider or raise it after seeing an inconvenient outcome. Record both the record-level acceptance rule and the batch-level release rule. Individual records can fail while an acceptable subset proceeds; a systemic mapping defect may require the entire batch to remain on hold.
| Decision | Evidence required | Permitted next step |
|---|---|---|
| Approve | Required field and identity checks pass; relevant segments meet agreed criteria | Release only the tested fields and workflow |
| Restrict | A clearly isolated subset passes; other segments remain uncertain | Release the passing subset with explicit exclusions |
| Hold | Critical defect, insufficient evidence or unreliable test design | Investigate and rerun the affected assessment |
A restriction must be enforceable. “Use with care” is not a control. “Do not update parent-company identifiers; release only the industry field for accounts with an exact accepted company match” can be implemented and audited. The approver should be able to explain why the allowed action is supported and why the excluded action is not.
Translate a data quality framework into testable rules
Use dimensions such as completeness, validity, accuracy, consistency, timeliness and uniqueness to organise the assessment. Then translate each dimension into an executable test or a documented review. A generic dimension is useful for classification; it is not yet an acceptance criterion.
For completeness, define which fields are required for which record types. A missing mobile number need not fail an account segmentation job. For validity, distinguish format from truth: a well-formed domain can identify the wrong company. For accuracy, define the reference evidence and its date. For consistency, specify whether two values genuinely contradict each other or describe different entities, periods or units.
For timeliness, use the age of the relevant observation when available, not merely the time the response arrived. For uniqueness, define the entity and grain: one person can legitimately have multiple employment records. A duplicate company name is not necessarily a duplicate legal entity. Our B2B data matching guide explains those identity decisions in more detail.
Every rule needs an identifier, owner, version, scope, test, denominator, severity and action. Add a reason code for outcomes that cannot be assessed. Unknown evidence should remain unknown. Converting an absent source date to today's date or an absent headcount to zero makes a dashboard look cleaner while weakening the decision it supports.
| Rule | Test | Failure treatment |
|---|---|---|
| ENTITY-01 | Returned company matches the intended account at the required entity level | Hold the proposed record update |
| SIZE-02 | Headcount value has an interpretable unit and company-versus-group scope | Exclude headcount; other fields may still qualify |
| DATE-03 | Observation date meets the agreed field policy | Review or exclude; do not invent a current date |
| WRITE-04 | Target record still matches the version evaluated | Reassess the changed record before writing |
| TRACE-05 | Decision can be reproduced from retained permitted evidence | Hold until traceability is adequate |
Build a sample that represents the decision
Freeze the eligible population before requesting enrichment. Remove duplicates according to the defined grain, document exclusions and retain stable input identifiers. If the evaluation uses only records with complete websites and familiar company names, its results will not describe the records that arrive with weak identifiers.
Separate a representative sample from an edge-case challenge set. Randomly sample within relevant segments such as geography, input quality and company structure. Use the challenge set to test common names, subsidiaries sharing a domain, recent job changes and conflicting evidence. Deliberately difficult cases are valuable, but their failure rate should not be presented as the production-wide failure rate.
If you oversample a small but important segment, report both its own result and a production-weighted result. Keep the weights tied to the target population rather than to whichever sample produces the most attractive headline. A sample with equal numbers from each country describes an equally weighted comparison, not necessarily the company's actual account portfolio.
Preserve a holdout sample when tuning matching or acceptance rules. Evaluate final performance on records that did not influence those settings. Otherwise an apparently improving score may simply show that the rule was adjusted to familiar cases. Keep the reference evidence separate from the supplier output being evaluated to reduce circular validation.
Illustrative accepted-record rates, zero baseline, 0–100% scale. Combined acceptance is 660 ÷ 1,000 = 66%. A release requiring at least 60% acceptance in every segment would fail for complex groups despite passing the headline test. Acceptance measures policy eligibility, not independently proven accuracy.
Keep missing, wrong and unassessed outcomes separate
A returned blank is not the same as a false value. A timeout is not evidence that the requested company or person does not exist. A conflicting result may be unassessed rather than incorrect. Your ledger should preserve these states so the team knows whether to improve input, retry a service, request evidence or correct a factual error.
For mutually exclusive reporting, assign each assessed record a primary disposition using a documented order. Keep secondary defect tags separately. Otherwise one record with three defects can inflate an apparent record failure rate. Conversely, selecting only one reason and discarding the others can hide root causes. Report record outcomes and defect occurrences as different measures.
The chart below illustrates a batch decision, not a supplier benchmark. The unresolved set remains outside the approved set even though some of those records may eventually prove correct. That distinction prevents a team from quietly converting uncertainty into success when it needs a better procurement score.
Illustrative mutually exclusive outcomes across 1,000 eligible records. Bars share a zero baseline and a 1,000-record maximum. Counts sum to 1,000. Secondary defects are recorded separately and are not added to this total.
Define the fields before testing the feed. Check the TargetWise API reference against your assessment ledger, including response states and available evidence. Evaluate the actual output rather than assuming every field is returned.
Use sampling uncertainty in the release decision
Finding no failures in a small audit does not establish that the population contains no failures. A sample can miss rare defects. That is particularly important when the error being tested is consequential, such as writing a value onto the wrong company record. Report the sample size and sampling method alongside any zero-failure claim.
The interactive chart calculates a one-sided 95% upper bound on an unknown failure probability after observing zero failures in independent, representative Bernoulli trials. The calculation is 100 × (1 − 0.05 raised to the power of 1/n), where n is the sample size. It is an illustrative sampling tool, not a universal sample-size recommendation or a guarantee about the next batch.
Independence and representativeness matter. Three hundred records copied from the same upstream source can share a systematic error. Testing only easy records does not justify inference about difficult ones. If records cluster by company, source or batch, use an appropriate sampling design and statistical method. More rows do not automatically provide more independent evidence.
At 100 independent representative trials and zero failures, the upper failure bound is 2.95%.
Illustrative binomial calculation. Bar scale: 0–10% failure probability, zero baseline. Formula: 100 × (1 − 0.05^(1/n)). The calculation does not apply to a convenience sample without the stated assumptions.
Decide whether the review queue is operationally viable
A policy that sends every ambiguous result to a person is incomplete unless someone can process that queue within its useful lifetime. Review capacity belongs in a data quality assessment because unresolved records affect both usable coverage and operating cost. A nominally cautious policy can produce a permanently growing backlog.
Estimate the incoming review cases, average handling time, available reviewer hours and rework rate. Begin with observed handling time when available; otherwise label the planning assumption and replace it after the pilot. Protect reviewer time for exceptional cases rather than spending it on formatting defects that a deterministic check can resolve.
The following model holds weekly volume at 1,000 records, handling time at four minutes per case and available review capacity at 12 hours. That allows 180 cases per week. At a 25% review rate, the team receives 250 cases and adds 70 cases to the queue before considering previous backlog or rework. The calculation is deliberately simple so a buyer can replace its assumptions.
250 cases require 16.7 hours; 70 cases exceed weekly capacity.
Illustrative assumptions: 1,000 weekly records, four minutes per case, 12 reviewer hours. All bars share a zero baseline and 500-case maximum. Backlog addition = max(0, incoming − 180); excludes existing queue and rework.
Write an assessment report procurement can challenge
Start with the decision and its limits. Then give the policy, sample, results and evidence. Keep observed measures separate from planning estimates. A supplier's claimed verification method is useful context, but it is not the same as independently checking your own returned records. Two suppliers agreeing is also not necessarily independent corroboration if their upstream sources overlap.
Include six items in the approval record: the precise permitted use; the population and exclusions; the versioned rules; the outcome counts and denominators; unresolved critical issues; and the owner, expiry or reassessment trigger. Attach a machine-readable ledger so engineering can reproduce the decision. Keep personal records in the authorised environment rather than copying them into a public report.
Use the same assessment policy when comparing providers. Hold input quality, population, deadline and adjudication method constant. Record errors, retries, incomplete responses and billing treatment. If one service returns results asynchronously and another does not, compare them at the business deadline, while separately explaining the available completion windows.
The commercial comparison should include supplier charges, implementation and review labour divided by accepted unique outputs. However, do not allow a low cost per accepted record to overrule a critical identity failure. Economics helps choose among acceptable workflows; it does not repair evidence that fails the release policy.
Move from a pilot to controlled production
Release a bounded batch first. Compare proposed changes with current values, preserve a recoverable history, and check the record version immediately before writing. Stop if a critical mapping defect appears. The first production batch tests a different risk from the offline sample: whether the integration applies the accepted result to the intended field and record.
Define reassessment triggers. These can include a new source, a schema change, a new geography, a revised matching model, unusual missingness, a sudden shift in acceptance or a reported wrong-company update. Routine schedules help, but a material change should not wait for the next quarterly review. The data freshness guide covers ongoing observation and refresh policies.
Maintain one history of policy changes and their effects. A rising acceptance rate is not necessarily an improvement if the policy was relaxed. Recalculate comparable metrics under the same rule version where possible, and make changes visible. This allows procurement and operations to distinguish a better dataset from a different definition of success.
Frequently asked questions
1. How is an assessment different from a data quality audit?
An assessment establishes fitness for a defined use. An audit often examines adherence to stated processes or controls. The activities can overlap, but the report should say whether it evaluated data outcomes, process compliance or both.
2. Can a complete record still fail?
Yes. Every field can be populated while the entity is wrong, the employment relationship is outdated or the value describes a parent group. Completeness should never substitute for identity and evidence checks.
3. How many records should be sampled?
Choose the sample from the acceptable uncertainty, expected failures, segment coverage and sampling design. There is no universally sufficient count. A small convenience sample can reveal defects but cannot justify a population-wide accuracy claim.
4. Should unknown outcomes count as failures?
Keep them separate in the evidence ledger. They may fail a release requirement because the evidence is insufficient, but that is different from proving the returned value false. Report both assessment status and release eligibility.
5. Can one overall data quality score be useful?
It can summarise trends under an unchanged policy. Retain component results and critical gates so a high average cannot conceal a harmful defect. Publish the formula and weights for anyone expected to act on the score.
6. Who should approve the assessment?
The business owner should approve the intended use and error tolerance, with data stewardship and engineering confirming evidence and implementation. Material contractual or privacy questions need the appropriate internal owner rather than an automated quality score.
7. How should disagreements between reviewers be handled?
Preserve both judgements, identify the disputed evidence and use a documented adjudication process. A high disagreement rate can reveal an ambiguous policy. Do not silently treat the first reviewer's opinion as reference truth.
8. Can AI perform data quality checks?
AI can assist classification and flag anomalies, but its output needs evaluation against the specific task. Require traceable evidence and deterministic checks where appropriate. An AI-generated explanation does not by itself verify a company fact.
9. What changes when enrichment moves to an API?
Assess operational states as well as returned data: authentication, timeouts, rate limits, partial responses, retries and completion deadlines. A successful HTTP response does not establish factual correctness or permission to update every returned field.
10. When should the result expire?
Set a reassessment date or event based on the workflow and evidence. A changed source, schema, geography or acceptance rule can invalidate earlier conclusions. Preserve the original assessment rather than rewriting its date to imply fresh testing.
Evaluate the data your workflow will actually use
Define the acceptance policy, select representative records and measure the resulting fields before expanding. Use the same decision rules to assess coverage, uncertainty and review cost.
Review TargetWise plans and field costs