How to Measure Data Quality for Trusted GTM Records

How to measure data quality starts with the decision a record must support. A CRM record is not simply good or bad. It is fit, incomplete, stale, or contradictory relative to a specific workflow such as routing, segmentation, personalization, or account research.

What it means to measure data quality in GTM systems

Data quality in a GTM system is the fitness of a record for a defined operational use.

A contact can be usable for one workflow and unfit for another. A record with a company domain and location may be enough for account assignment. The same record may not be ready for an outreach workflow if it lacks a work email address. A title may be useful as free text for account research but not sufficient for routing if your routing logic depends on normalized seniority and department values.

This is why CRM data quality should not collapse into a single label such as “complete” or “clean.” That label hides the condition that matters.

Separate the checks you make:

• Identity confidence: Do you know which person or company this record represents?
• Field completeness: Is the field present when a workflow needs it?
• Field validity: Does the value conform to the format or controlled vocabulary your system expects?
• Data consistency: Does the entity have compatible values across records and connected systems?
• Data freshness: Is the value still appropriate for a live person or company?
• Evidence-backed accuracy: What source and validation outcome support the value?

A populated field is not automatically accurate. VP Sales may be a valid title string. It may still describe a previous employer. California may be a valid location value. It may still be too broad for territory assignment. A company domain may look structurally correct but point to a parent company rather than the account your seller is working.

Your measurement framework should make those distinctions visible. It should show which field failed, why it failed, and which workflow is affected.

Start with the decisions your data must support

Start with business decisions, then work backward to the fields required to make them.

Teams often begin a data cleanup project by listing every field in the CRM. That produces a long backlog and weak priorities. Instead, map the decisions that drive routing, selling, reporting, and research. For each decision, define the minimum acceptable field state.

For example:

• Lead routing may require a usable company domain, location, seniority, and department.
• Account assignment may require company name, company domain, location, and relevant firmographic fields.
• Outreach preparation may require current title, employer, work email, and a deliverability status for the returned address.
• Segmentation may require normalized department, seniority, company domain, industry, and employee range.
• Pipeline reporting may require stable account identity and consistent company attributes across the CRM and reporting system.
• Account research may require a company description, industry, headcount, funding information, or monthly visits, depending on the research brief.

Write the requirements as operational rules. Avoid vague requirements such as “title should be good.” Use rules that a person or system can evaluate:

• A record routed by department must have a department value from the routing vocabulary.
• A record used for work-email outreach must have an email returned by the enrichment process and an associated email status.
• A company used in account assignment must have a resolvable company domain or another documented account-identity rule.
• A record included in an industry segment must have an industry value with known provenance.

Then assign a business owner to every critical field. The owner does not need to perform every correction. They decide what the field means, when it is required, and what happens when it is unresolved.

For example, sales operations may own routing rules for seniority and territory-related location. Marketing operations may own segmentation requirements. Revenue operations may own company identity and reporting definitions. The person responsible for a workflow should help define the data quality rule behind it.

Without that ownership, data teams end up enforcing rules that look tidy but do not match how the CRM is actually used.

Use five practical dimensions to assess each field

Use five practical data quality dimensions to assess each required field: completeness, validity, consistency, freshness, and evidence-backed accuracy.

Completeness

Data completeness asks whether a required value is present when a workflow needs it.

Completeness is conditional. A work email is not required for every contact record. It becomes required when the record enters an email-based outreach process. Department may not matter for a founder-led account review, but it can matter for a territory or persona-based routing rule.

Measure completeness against the relevant workflow, not against every possible field in your schema.

A blank company domain is a completeness issue if account matching depends on domain. It is not necessarily an issue for a manually researched prospect whose employer is still under review.

Validity

Data validity asks whether a value conforms to its expected format, type, or controlled vocabulary.

Validity checks should be mechanical where possible:

• A company domain should be a registrable domain rather than a full URL or a free-text company name.
• A LinkedIn URL should be stored as a URL, not copied into a notes field.
• A country should be derived or normalized consistently from a published location string.
• Seniority should use an approved value when downstream automation depends on it.
• Department should use an approved value when it drives ownership, segmentation, or reporting.

For normalized people fields, Enrichments uses these seniority values: founder, c_level, vp, director, manager, senior, and entry.

Its department values are: engineering, product, design, sales, marketing, finance, operations, people, legal, support, data, it, executive, and other.

A free-text title can remain useful alongside these values. Do not replace the title with a normalized label. Use the title as the source expression and seniority or department as a field designed for consistent downstream logic.

Consistency

Data consistency asks whether the same entity has compatible values across records and systems.

A person can appear in a CRM, product system, enrichment workflow, and warehouse. A company can appear under a legal name, a brand name, and a domain. Consistency checks identify conflicts that interfere with matching or automation.

Examples include:

• The same company domain attached to unrelated company names.
• A contact assigned to one employer while their current title and company profile indicate another.
• Different department values for records that share the same title normalization rule.
• A location stored as free text in one system and as a territory code in another, without a documented mapping.

Consistency does not mean every field must be identical everywhere. It means differences need an explanation. A source location may be published as free text, while your CRM stores a territory value derived from it. Both can be valid if the derivation is documented and reversible.

Freshness

Data freshness asks whether a value is still appropriate for a live contact or company.

Titles, employers, locations, company descriptions, funding details, and web traffic indicators can change. A field can be complete, valid, and internally consistent while still being stale.

Treat freshness as a property of the field, not only the record. A company domain may remain stable for a long time. A person’s title may require more frequent review. Your freshness policy should reflect the risk of making a wrong decision with an old value.

Record the time the value was observed or last validated. If you cannot establish that time, mark the freshness assessment as unknown rather than assuming the field is current.

Evidence-backed accuracy

Accuracy should be an evidence-backed assessment, not an assumption based on field population.

For each important value, capture what supports it:

• The originating source or system.
• The time observed.
• The validation outcome.
• Any transformation applied.
• The person or process that accepted an exception.

For work email, distinguish between the address itself and the status returned with the deliverability check. Available statuses are verified, probable, unverified, risky, undeliverable, and unknown.

That status gives your workflow more information than a non-empty email field. It does not make every outreach decision automatically safe or appropriate. Your own policies still determine how you use each status.

Build a field-level data quality scorecard

A data quality scorecard should evaluate fields independently, rather than assigning each record an opaque pass-or-fail label.

A single record label makes triage difficult. A contact may have a valid company domain, current title, and usable location, while lacking the email required for outreach. Calling that record “bad” does not tell an operator what to fix or whether the record can still support account research.

Use a scorecard that makes each assessment inspectable.

Field	Operational use	Checks	Evidence to record	Remediation owner
Work email	Outreach	Present when needed, deliverability status available, not known to be undeliverable	Source, observation time, email status	Marketing operations
Title	Persona and research	Present, readable as current work title, compatible with employer	Source, observation time, prior value if changed	Sales operations
Seniority	Routing and segmentation	Value uses the approved vocabulary	Source title, normalization rule	Revenue operations
Department	Routing and segmentation	Value uses the approved vocabulary	Source title, normalization rule	Revenue operations
Company domain	Account matching	Registrable domain, compatible with company identity	Source, observation time, matching decision	Data operations
Location	Territory and regional reporting	Published location retained, derived country documented if used	Source location, transformation	Sales operations
Firmographic field	Account prioritization	Present when required, source and observation time known	Source, observation time, field-specific review rule	Account operations

Keep the scoring rules simple. A reviewer should be able to understand why a field passed, failed, or remains unresolved without reconstructing a hidden model.

You can use labels such as:

• Ready: Meets the rule for its defined workflow.
• Needs review: Has conflicting evidence, missing provenance, or an exception that requires a person.
• Not ready: Missing, invalid, stale, or inconsistent for the workflow.
• Not required: Not needed for the current operational use.

These are workflow states, not permanent judgments about a contact or company.

Document the source, observation time, validation outcome, and remediation owner for every important assessment. This turns the scorecard into an operating artifact rather than a dashboard that merely reports a problem.

Revise the rules when downstream requirements change. If a new routing policy starts using department, department validity becomes more important. If a team stops using a firmographic field in any decision, remove the rule instead of maintaining cleanup work with no operational purpose.

Measure quality at the point where records enter and change

Measure data quality at intake and change points, before poor values spread into workflows.

The main entry points are usually imports, form submissions, integrations, enrichment runs, and manual edits. Each needs its own field-level data validation rules because each introduces different failure modes.

For imports, check column mappings and reject values that land in the wrong field. A company name should not become a company domain. A LinkedIn URL should not become a free-text note. Preserve the import source so you can trace corrections later.

For form submissions, distinguish what a person supplied from what your system derived. Do not overwrite a submitted company name with an inferred company identity without a review rule. Both values may be operationally important.

For integrations, define which system is authoritative for each field. If the CRM owns account assignment and an enrichment workflow supplies new company details, the enrichment should not silently replace assignment fields. It should provide new evidence for the field owner to evaluate.

Live enrichment needs the same discipline. Enrichment is live rather than a licensed static database, so the same request can legitimately return different data at a later time. Treat a new result as new evidence, not as an automatic replacement for every stored value.

For example, a newly returned title can indicate a job change. It can also conflict with a recent value from a trusted internal process. Compare provenance and observation time before writing it back. Preserve prior source values where they support an existing workflow, audit trail, or dispute-resolution process.

When you use Enrichments for people records, you can request specific fields such as title, seniority, department, location, company_domain, or email. Ask for the fields that serve a defined repair task. Work email is requested by name and is charged only when an address is returned; its deliverability check is included with the returned address.

Turn findings into a repair queue

A repair queue should prioritize fields that block a defined workflow before cosmetic cleanup.

Start with failed rules that prevent a record from being routed, matched, segmented, or safely included in an automated action. A missing title may matter less than an invalid company domain when the domain is the key used to assign an account. A formatting inconsistency may be low priority if it does not affect matching, reporting, or automation.

Choose the remediation path based on the failure:

• Normalization: Convert valid but inconsistent input into an approved representation.
• Enrichment: Request missing data for an identifiable person or company.
• Verification: Evaluate the evidence or validation result attached to an existing value.
• Merge review: Resolve duplicate records or conflicting entity identities.
• Source-data request: Ask for better input when the record cannot be responsibly resolved.
• Workflow holdout: Exclude unresolved records from an automated action until they meet the minimum field state.

Use closed vocabularies when routing or segmentation depends on the value. Seniority and department are common examples. Free-text values create ambiguity in workflow rules. A routing system should not need to decide whether VP Engineering, Vice President of Engineering, and Engineering Leader mean the same thing every time a record arrives.

Keep a separate path for identity conflicts. Do not use enrichment to force a match where the identifier evidence is weak. A wrong merge can contaminate more records than an unresolved record held for review.

For work-email workflows, define your treatment of each email status before activation. Records with undeliverable or unknown statuses may need to stay out of certain automated actions. The rule should reflect the workflow and your own outreach obligations, not merely the presence of an email string.

Make data quality measurement an operating habit

Data quality measurement works when it becomes part of CRM operations, not a one-time cleanup project.

Review the scorecard on a regular cadence and after major process, integration, or schema changes. A new lead form can introduce a new source of inconsistent values. A revised territory model can change what counts as a valid location. A new account-scoring process can make a previously optional firmographic field operationally important.

Track remediation decisions in an auditable log. For each material change, retain:

• The field changed.
• The prior value and new value where appropriate.
• The source of the new evidence.
• The time observed.
• The rule that prompted the change.
• The owner or process that approved it.
• Any unresolved conflict or exception.

This log helps teams explain why a field changed and identify recurring intake problems. If many records fail the same department rule, the solution may be a better integration mapping or form design, not repeated manual normalization.

Retire rules that do not affect an operational decision. A scorecard should become more useful over time, not accumulate checks because they once seemed sensible. Add rules when new workflows introduce real dependencies.

Use the findings to improve the systems that create the data: intake forms, integration mappings, enrichment requests, CRM field definitions, and governance rules. That is the practical outcome of measuring data quality. You create a repeatable way to decide which records are ready, which need repair, and which should stay out of automated GTM workflows until the evidence is strong enough.