Every customer database has gaps. The signup came from a form that did not ask for a phone number, the company moved, the email belongs to a domain that no longer exists. Enriching is filling those gaps by querying a data provider. The technical part is usually the simplest. The hard part is deciding who to enrich, keeping the result in the right place and knowing how much it cost.
What it means to enrich a database
You have an identifier, such as a CPF, a CNPJ or an email, and you ask a provider for the data that is missing. The provider returns new or updated fields: company name, segment, address, phone, registration status. Which fields depends on the provider and the contract.
Enrichment is useful when a missing piece of data changes a decision. A phone number lets you reach out by SMS. A company’s segment lets you split the campaign. The registration status keeps you from billing someone whose business has closed.
Before enriching, filter
The costliest mistake is sending the whole dataset to the provider. Some of the records will not be used, some already have the data and some were invalid from the start.
Start with the cut. Which records go into the next campaign or the next analysis? Which are missing the field you need? Which have a valid identifier? In DeepMiner, that cut is the filter of a flow strategy, with the expected record count before you save. You see the volume before you spend.
It is also worth looking at purpose. Under Brazil’s LGPD, processing personal data requires a defined purpose and must be limited to what is necessary for it. Enriching only the records that will be used helps meet that principle.
The result has to return to the record
Enrichment that ends in a separate spreadsheet becomes one more dataset to cross-reference. The new data needs to return to the source record, showing which provider supplied it and when.
In DeepMiner, the enrichment provider is linked to the index with a field mapping: which field in your data goes into the request. The returned data arrives through the return webhook and goes into the record itself, with the status reported by the provider.
With the data on the record, it shows up in each record’s detail, next to your data fields.
Cost visible per run
Every record sent to the provider has a cost. When enrichment runs by script or manual upload, the cost only appears on the invoice at the end of the month.
In DeepMiner, each run shows the total records, the processed ones, the failures and the amount debited from the prepaid balance. The statement keeps each debit. A strategy with a per-run limit controls the volume of each round, and the Insufficient balance status keeps a run from starting without balance.
Enriching on a recurring basis
Data ages. A dataset enriched a year ago already has changed phone numbers and closed companies. Instead of a one-off project, enrichment can be a routine: a strategy that runs every week on the records imported in the last few days.
Date filters help here: the last 7, 30 or 90 days on the import date, for example. Recurrence can be daily, every N hours, on weekdays or by cron.
A roadmap to get started
- Import the data and mark a key field, so reimports update instead of duplicating.
- Configure the enrichment provider and link it to the index, completing the mapping.
- Create a strategy with the cut that really needs the new data and check the expected records.
- Run it once manually, check the returned fields on a few records and only then schedule it.
- Follow runs and statement, and adjust the filter if the volume strays from what you expected.
Want to see enrichment running on a dataset like yours? Book a demo.
Frequently asked questions
What is data enrichment?
It is completing or updating fields in a dataset, such as address, phone or company data, by querying an external provider from an identifier you already have.
Should I enrich the whole dataset?
Rarely. Enriching only the records that will be used in a campaign or an analysis reduces cost and data exposure.
Where does the data the provider returns go?
Onto the record itself, in provider fields separate from your data fields. That way you can tell where each value came from.