HubSpot Data Enrichment: The Match Keys, the Credits and the Opt-Out Layer

HubSpot's own knowledge base contains a sentence that contradicts most of what is written about its enrichment feature: data enrichment does not consume HubSpot Credits. Smart properties do, and they are a separate feature on the same page, but the enrichment itself is not metered against the credit balance that governs so much else in the platform.

That single line changes how the feature should be evaluated. Most enrichment decisions are cost decisions, and this one is not. It is a data-governance decision, and the governance question turns out to be more interesting than the price.

Lead enrichment and data enrichment are the same job under two names here: HubSpot enriches the contact record from first name, last name and work email address, and the company record from company domain, whether you call the result an enriched lead or an enriched record. This page uses the vendor's own term throughout.

What HubSpot enriches, and from what

HubSpot's documentation is precise about the inputs, and the precision matters because it sets a ceiling on everything downstream.

For contact enrichment, HubSpot uses first name, last name and work email address. For company enrichment, it uses company domain. Those are the match keys, and they are the strongest available ones: a mailbox belongs to one identity and a domain belongs to one organisation. Company name is not among them, which is the right choice and worth noticing, because a provider that will match on a name will usually return something without telling you it guessed.

The sources are three. HubSpot names its own commercial dataset, third-party providers, and publicly available information from across the internet. When matching information is found across several of them, the corresponding properties in your CRM are updated.

The general shape of this job, and the write-back decisions that govern whether it helps or quietly corrupts a database, are covered vendor-neutrally in our CRM enrichment entry. What follows is what is specific to HubSpot.

Four ways a record gets enriched

The mechanics divide cleanly, and which one you use determines both the volume and the risk.

Automatic enrichment continuously enriches contact and company records according to settings you configure. HubSpot states that automatic enrichment settings are turned off by default for both contacts and companies and that a customer action is required to turn them on, and that the settings must be configured for contacts and for companies separately. That default is a good one and the separateness is the part teams miss: switching it on for contacts does nothing for companies.

Individual record enrichment runs on one record while you are looking at it, and lets you choose which properties to enrich.

Bulk enrichment runs from an object index page or an import, and here the behaviour changes: HubSpot states that when enriching in bulk, all eligible properties will be enriched for the selected records. You do not get the per-property choice you get on a single record.

The Intelligence tab enriches an individual record with property selection, and additionally surfaces website visitor activity and company qualification information.

The bulk case is the one to think about before running. A single-record enrichment is a considered act on chosen fields. A bulk run is every eligible property on every selected record, which is exactly the operation that overwrites something a rep learned on a call.

1. Step 1Write the segment query first

   List the fields your target segment actually filters on, before counting blank cells

2. Step 2Test record eligibility

   HubSpot recommends testing eligibility before enriching, so you learn what will not match before you commit

3. Step 3Enrich a readable slice

   Bulk enrichment writes every eligible property, so run a batch small enough for a person to read row by row

4. Step 4Read the changes, not the count

   Separate fields that were filled from fields that were rewritten; those two halves carry different risk

5. Step 5Then widen

   Only after the small batch has been read, and only across the fields the query needs

The permission and subscription boundaries

Two boundaries decide who can do any of this, and both are stated in HubSpot's documentation.

Super Admin permissions are required to configure enrichment settings and to manage user data enrichment access permissions. Data enrichment access or Super Admin permissions are required to enrich records at all. So enrichment is not a thing any user can quietly start doing, which is a sensible default given what a bulk run does.

On subscriptions, HubSpot lists the feature as available with Marketing Hub, Sales Hub, Service Hub, Data Hub and Content Hub at Starter, Professional and Enterprise, and with Smart CRM and Revenue Hub at Professional and Enterprise, except where noted. Smart properties, which do consume HubSpot Credits, are available on Starter, Professional and Enterprise subscriptions except Revenue Hub.

The practical read: enrichment reaches further down the ladder than most people assume, and the credit-consuming part of the page is the adjacent feature rather than enrichment itself.

The opt-out layer nobody plans for

This is the part of HubSpot's enrichment that has no equivalent in most vendors' documentation, and it is the reason to read the vendor's own pages rather than a comparison post.

Individuals can opt out of HubSpot's commercial dataset by contacting HubSpot directly and asking for their professional details not to be used for enrichment. HubSpot describes two routes: submitting its Privacy Preferences form with the delete-from-commercial-dataset option selected, and, for residents of some countries and regions such as the EU, following opt-out steps in an email HubSpot is required to send when a person becomes part of the dataset.

What happens next is the interesting part. HubSpot states that data protection laws require it to remove the individual's data and to notify customers who previously received it. So an opt-out is not a silent event on the vendor's side: Super Admins are notified, by an email whose subject line is "Action needed: Enriched data delete requests pending", and the contact gains a property labelled enrichment opt out.

Then the boundary. HubSpot is explicit that receiving an opt-out notice does not delete the contact or the data from your account. Data you received from enrichment remains unchanged, data you or your team added manually remains unchanged, and future enrichment updates stop for that contact. Its guidance is that if you collected data about the contact independently of enrichment, through a form submission or a direct interaction, you may be able to retain it, and that for data you received only through enrichment you should evaluate with your legal team whether you have a separate basis to continue using it.

That is an unusually candid piece of vendor documentation, and it hands you a real operational requirement: somebody has to own that inbox and that decision. An "action needed" email that lands in a Super Admin's inbox with no named owner is a compliance task with a default answer of nothing.

Enrichment governance

• ✓Yes: A named person owns the enriched data delete request notifications, not a role
• ✓Yes: You know which fields were populated only by enrichment and which came from your own interactions
• ✓Yes: Legal has been asked once, in advance, what your basis is for enrichment-only data after an opt-out
• ✓Yes: Automatic enrichment settings are configured deliberately for contacts and for companies, since they are separate
• ✓Yes: Bulk runs are limited to batches a person will actually read
• ✕No: Running bulk enrichment across the whole database to see what comes back
• ~Depends: Provider values and human-entered values kept in separate properties with a promotion rule

The second item on that list is the one that becomes urgent only once an opt-out arrives, and it is unanswerable in retrospect if nobody recorded provenance at the time. Recording which properties came from enrichment is cheap on day one and impossible on day four hundred.

Where enrichment stops being the answer

Enriching a record does not make it findable, because the field that was missing is rarely the field your segmentation actually filters on.

The pattern is consistent. A team looks at its CRM, sees thousands of half-empty rows, runs an enrichment project, and then finds the campaign still cannot be built. The reason is that the ideal customer profile was written in terms no provider sells: companies running a particular piece of software, companies that opened an office in a given region, companies whose service mix matches a specific offer. Enrichment fills the fields the provider happens to have.

So reverse the order. Write the segment query first, list the fields it needs, and only then count how many records are missing them. HubSpot's own recommendation to test record eligibility before enriching supports the same discipline from the other end. Doing it this way usually shrinks the job dramatically, because a real query needs four fields rather than forty.

The other limit is the one no fill rate can show you. A fuller record is not automatically a more correct one, and completeness is the easiest metric to improve. For outbound specifically, the truth surfaces downstream: a mailbox that belongs to somebody's previous employer passes every verification check and fails the only test that matters. Our own practice on that, and this is policy rather than a result we are claiming, is that every address entering a campaign is verified immediately before upload whatever source it came from and however recently that source verified it. The vendor landscape for that step is in email verification tools, and the deliverability reasoning is in the cold email deliverability guide.

How this sits against the alternatives

If you are choosing rather than configuring, the comparison shape is different.

HubSpot's own dataset is the default because it is already there and, on the evidence of its own documentation, does not draw down credits. What it will not do is run several sources in sequence and pay only for what the previous one missed, which is the discipline that makes multi-source enrichment affordable. That is set out in waterfall enrichment, and the credit-conscious build in a platform designed for it is covered in the Clay enrichment guide.

If your evaluation started from a Clearbit price you found somewhere, note that the question changed shape: Clearbit is now part of HubSpot, so any standalone figure predates the acquisition, and the alternatives roundup covers what to look at instead. For the platform-versus-orchestration fork that decides whether you run one source or several, ZoomInfo against Clay is the comparison to read.

Where we sit

RevenueFlow runs Email Bison and in-house tooling rather than HubSpot, so this is a documentation-grounded account of HubSpot's behaviour rather than a walkthrough of a system we operate for clients. We have no commercial relationship with the vendor.

The reason it is worth writing is that enrichment projects are usually started to fix a symptom of something else. If the campaign cannot be built, the constraint is normally the definition of the segment rather than the completeness of the records. If what you actually need is qualified conversations rather than fuller rows, we will build the first campaign on your own market and you can judge the output rather than the input.

HubSpot enrichment match keys, enrichment methods, permission and subscription requirements, credit behaviour and the opt-out notice process are per HubSpot's own knowledge base articles on data enrichment and on enrichment-dataset opt-out notices, both last updated 10 July 2026 and fetched 15 August 2026. Verify current behaviour with the vendor before relying on it.