Data enrichment: adding attributes you can trace back to a source

Most business records start thin. A CRM row holds a company name and a website; a supplier list has names and tax numbers; a sign-up form captures an email address. Data enrichment is the work of filling in the rest from other sources, so the record becomes useful for routing, scoring, research or onboarding checks. Done well, it saves people hours of manual lookups. Done carelessly, it fills your systems with plausible values nobody can trace, and those values outlive everyone’s memory of where they came from.

What enrichment is, and what it is not

Enrichment takes a record you already have, works out which real-world entity it refers to, and appends attributes about that entity from another source. There are three steps, and each fails in its own way:

1. Identify. Choose the key: a domain, a registration number, an email address, a product code.
2. Match. Find the same entity in the source. This is where most errors are born.
3. Append. Write the new values, ideally with a note of where each one came from.

Several neighboring activities are easy to blur with it. Cleansing corrects or standardizes values you already hold, such as country codes or duplicates. Discovery, or lead generation, finds records you do not have yet, for example companies that match a profile. Extraction pulls values out of documents. Enrichment often uses extraction and feeds discovery, but its starting point is always an existing record.

Common types of enrichment

Pick the type by the decision it supports. If the enriched field will route an inbound lead, size and region may be enough. If it will feed a credit or onboarding check, you need the registry record, not a provider’s estimate.

Where the values come from

Sources differ less in format than in what you can say about a value afterwards.

• Your own material. Contracts, invoices, onboarding forms and correspondence often already hold the answer. They are the most defensible source, because you know exactly where the value came from.
• Official registries and filings. Authoritative for legal facts, though coverage, format and access rules vary by country.
• Pages the company publishes. Current and specific, but self-described and sometimes aspirational.
• Commercial data providers. Broad coverage through one interface. Check how each field is sourced, how often it is refreshed and what the licence lets you do with it; data enrichment APIs lists the selection questions.
• Agent-led web research. Flexible for fields nobody sells, slower per record, and only as good as the evidence it keeps. Web enrichment for sales data covers that workflow.

Enrichment about people carries extra obligations. Before adding personal attributes, check the legal basis for processing under the data-protection rules that apply to you, and whether the source’s terms permit the use you have in mind.

Matching decides quality

A wrong match does more damage than a missing value, because it looks like data. “Acme Ltd” in your CRM may be one of several companies with similar names, a subsidiary inside a group, or a business that has since renamed itself. Matching on name alone is the classic failure.

A defensible matching rule names the evidence it requires:

accept a match only if:
  - registration number matches, OR
  - website domain matches AND country matches
mark as "possible match, needs review" if:
  - name matches AND city matches, but there is no domain or number
never merge on:
  - name similarity alone
  - a domain shared by a hosting or parking service

Keep the match decision on the record. When someone later asks why a company shows 500 employees, “matched on the domain example.com” is an answer; “the provider said so” is not.

Provenance: every value needs a source

Provenance means storing, next to each enriched value, enough information to check it again. Field-level provenance looks heavier than a plain column, but it is what lets you trust, refresh and correct the data later.

{
  "field": "headquarters_city",
  "value": "Rotterdam",
  "source": "company registry extract",
  "source_ref": "registry record URL or document ID",
  "retrieved": "YYYY-MM-DD",
  "method": "extracted",          // extracted | provider | inferred | human-verified
  "supporting_text": "Registered office: ... Rotterdam",
  "status": "confirmed"           // confirmed | unknown | conflicting
}

Two fields in that example deserve emphasis. Method separates a value read from a document from one a model inferred, and the two should never carry equal weight. Status makes “unknown” a legitimate outcome. An enrichment process that cannot return unknown will fill gaps with guesses, and once guesses reach a spreadsheet they look identical to facts. Missing evidence is an open question argues the point at length, and citations that hold up covers what makes a source reference worth keeping.

Keeping enriched data correct

Enriched data starts to decay the day it is written. A few habits keep it honest:

• Refresh by field, not by table. Registration numbers rarely change; job titles change constantly. Give each field type its own refresh interval.
• Refresh on triggers as well. A detected merger, rebrand or change of address should reopen the related fields rather than wait for the schedule.
• Rank your sources. When two sources disagree, a written priority order (registry, then provider, then inference) settles it the same way every time. Record the conflict instead of hiding it.
• Protect human corrections. A value a person has verified should not be overwritten by the next automated pass. Keep versions instead of replacing values.
• Review before writing back. Pushing enriched values into a CRM or an outreach tool spreads them to everyone who uses it; check a sample before the bulk update.

How GoCux handles the evidence side

GoCux is built around keeping each value tied to what supports it. Extraction reads the material you provide and returns each value together with the passage behind it; when the material does not contain a value, it is left as unknown rather than filled in with a guess. FindAll builds a table from matching criteria and the columns you ask for, with evidence on every row, and it reports the limits of its coverage instead of rounding them away, since a count of results does not prove the list is complete. For values that change, Pulse asks a recurring question over sources you choose and puts each change in front of a reviewer; a detected change does not update anything on your behalf. Exporting data out of the workspace pauses for a person, with the files in scope listed. See Extraction, FindAll and Pulse for each of these.

An enrichment checklist

• Each enriched field exists because a named decision needs it.
• The matching rule is written down and never accepts name similarity alone.
• Every value stores its source, retrieval date, method and supporting text.
• “Unknown” and “conflicting” are allowed statuses, and they are reported.
• Each field type has a refresh interval and at least one trigger that reopens it.
• Values a person verified are protected from automated overwrites.
• Enrichment of personal data has a checked legal basis and source terms that permit it.
• A sample is reviewed before enriched values are written back to other systems.