Build a Useful Lead-List Error Taxonomy
Define error types, consequences, and counting units before auditing a lead list, with a worked example that avoids double-counting affected records.
10/24/20263 min read


A report saying a lead list has seventeen errors is incomplete. Seventeen wrong entity matches require a different response from seventeen capitalization inconsistencies. The count also means little until you know whether one record with three problems contributes one error or three.
Build a small error taxonomy before the audit. Its purpose is to route repair and control use, not to produce an impressive quality percentage. The categories should describe observable defects against an agreed research requirement.
Start with intended use and a counting unit
A company list used for an internal regional estimate may not require named contacts. A record prepared for an approved account-owner handoff may require current responsibility evidence. Missing a contact is not automatically an error in both contexts.
The W3C: Data Quality Vocabulary discusses data quality in relation to use and includes ways to describe quality measurements and annotations. The taxonomy below is an editorial method, not a W3C certification scheme.
For this method, count an affected record once in the overall record total. Count each distinct defect separately in the defect log. Keep both numbers, and label them plainly. A single unsupported company match may create several downstream wrong fields; group those consequences under the original identity defect rather than pretending each copied field is an independent discovery.
Use categories that lead to different repairs
Begin with five types. Identity means the record refers to the wrong or unresolved entity. Evidence means a material claim lacks adequate support or exceeds its source. Currency means the evidence no longer supports the time-sensitive claim being made. Handling means an applicable restriction or ownership instruction is missing or incorrectly applied. Structure means the value cannot be interpreted or used as required.
Severity is a separate field. A structure error can be critical if it attaches a restriction to the wrong person. A missing optional label can be minor. Define severity by the consequence for the intended use, not by the category name or how easy the repair looks.
Use three action levels: block the affected use, return for correction before acceptance, or correct without blocking the current purpose. Keep an unresolved status for questions that cannot yet be classified. Do not force a reviewer to guess severity just to complete the audit.
A filled fictional defect log
An invented internal handoff list contains ten records. Reviewers find the following:
R02: company identifier belongs to a similarly named business. Type identity; block handoff; owner data steward; verify the entity before any dependent fields are reused.
R04: operations responsibility inferred from a broad job title. Type evidence; return for correction; owner researcher; narrow the claim or obtain suitable evidence.
R04: optional location label has inconsistent capitalization. Type structure; nonblocking for this handoff; correct during routine cleanup.
R07: a dated stop instruction was omitted from the handoff. Type handling; block relevant contact action; owner account lead; restore the restriction and review pending tasks.
R09: a role is described as current using an old source contradicted by a later departure announcement. Type currency; return for correction; owner researcher.
The report therefore contains five distinct defects across four affected records out of ten inspected. It does not say fifty percent of records are defective. It also does not call the remaining six universally verified: they passed the specified checks for this use and this version.
Resolve boundaries before scaling the audit
Review R09 carefully. If the later announcement names a different person, the issue might instead be identity. Record the reason for classification and retain the evidence reference. Classification helps action; it should not obscure uncertainty.
When two reviewers disagree, keep their original labels until the discrepancy is discussed. Update the taxonomy with a short boundary example rather than silently rewriting the historical result. If definitions change materially, label the report version so comparisons do not mix different rules.
Publish a repair summary, not a single grade
The fictional release note says: ten records inspected; four affected; five defects; R02 and R07 held from the relevant use; R04 and R09 returned; optional formatting repair queued. It names the owners and the conditions for release.
That summary supports immediate decisions. A single ninety-percent quality score would conceal both the counting problem and the blocked actions. Start with a taxonomy small enough that reviewers can apply it consistently, then add categories only when they change who acts or what must happen next.
Continue with Measure Sales Navigator Prospecting with a Small, Honest Funnel or Compare Two Target Segments with a Fair Sales Experiment.
