Ask three suppliers for a product data enrichment cost and you will get three numbers that cannot be compared. One quotes per SKU. One quotes a day rate. One quotes a fixed price for a batch of ten thousand lines. None of them state what is inside the price, so the cheapest quote is usually the one with the smallest scope hidden in it. This article gives you the cost model instead of a headline rate, because the model is the thing you can budget against.
Why nobody publishes a product data enrichment cost
Two products in the same catalogue can differ by a factor of fifty on effort. A garden hose with six attributes, a clean manufacturer PDF and one language takes a few minutes. A three-phase motor with sixty attributes, a scanned 1998 catalogue as the only source and three markets to serve takes most of an afternoon.
A published product data enrichment cost has to assume one of those two. If it assumes the hose, the price changes after discovery. If it assumes the motor, nobody clicks. So the market publishes nothing, and buyers compare quotes that are not measuring the same work.
We do not publish a flat rate either, and it would be dishonest to pretend we could. What we can do is show you the variables we price against. Then you can read any quote properly and ask the questions that expose the gaps.
Cost per SKU is the wrong unit
The unit of work in enrichment is not the SKU. It is the attribute value decision. One person or one model decides what goes in one field for one product. Someone confirms that decision is right.
That gives you a simple model. Cost per SKU is the number of fields you need populated, multiplied by the effort each field takes. Multiply again by how much verification each field needs, then add a fixed cost for copy and media.
Everything that moves your product data enrichment cost moves one of those four terms. A supplier quoting per SKU without asking about your attribute schema is pricing a term they have not measured. That is fine for a rough order of magnitude. It is not fine for a budget you take to your finance director.
The seven variables that move the price
Each one changes a term in the model above.
1. Attribute count and depth
Thirty populated attributes cost roughly five times what six cost. Not exactly, because the marginal attribute is usually harder than the first. The easy fields are on the front page of the datasheet. The last five are buried in a footnote, a drawing, or a certification document.
Ask any supplier to price against your actual attribute schema, node by node. A category average tells you nothing. If you do not have a schema yet, that is your first piece of work and it is a different job. We set out the shape of it in our guide to product attributes.
2. Where the source data comes from
This is the biggest single swing factor and the one buyers underestimate most. Structured supplier feeds in BMEcat or a clean spreadsheet are cheap to work from. Native digital PDFs are moderate. Scanned PDFs, photographs of spec plates and printed catalogues are expensive, because someone has to read them.
The state of your existing records matters just as much. Enriching an empty field is quicker than correcting one that holds a plausible but wrong value. The wrong value has to be investigated before it can be replaced. If half your catalogue was populated by a temp in 2019, price for correction rather than completion.
Sometimes the source material has to be found before it can be used. That is product data sourcing, and it belongs on a separate line.
3. Images, documents and other assets
Asset work is priced separately from attribute work in every honest quote, because it behaves differently. Renaming and mapping existing images to SKUs is cheap. Retrieving assets from supplier portals is slower. Background removal, cropping to a channel specification and building a hero and gallery set is a production job with its own rate.
Documents are their own line again. A datasheet, a safety sheet and a declaration of performance each need finding and naming. Each then has to be linked to the right SKU and checked for the right revision. That is not enrichment of a text field and should not be priced as if it were.
4. Languages and markets
Translation is not a percentage uplift on the English price. It has three separate components: machine translation, human review, and market specific adaptation of units, compliance wording and terminology.
The third one is where the cost sits. Converting millimetres for a German site is trivial. Knowing that a UK trade term has no equivalent in French plumbing is not. Ask for translation to be quoted per language and per field type. Ask which fields get human review rather than machine output.
5. Category complexity and expertise
Some categories can be enriched by a careful generalist working to a good specification. Others cannot. Fasteners, bearings, electrical distribution equipment, automotive parts with fitment data and anything carrying a compliance obligation need someone who understands the product.
That expertise is a real cost and it is worth paying for. The alternative is a cheaper rate and a rework bill six weeks later. Your product managers reject the batch because thread pitch and drive type have been mixed up.
6. Volume and banding
Volume reduces unit cost, and it does so in steps rather than smoothly. The first thousand SKUs in a new category carry the setup. That means reading the schema, agreeing the rules, calibrating the sample and building the extraction prompts.
After that, the rate should fall. Ask for the band thresholds in writing. A supplier who quotes the same rate at 2,000 and at 200,000 SKUs is guessing. Either the small batch is overpriced or the large one is unprofitable.
7. One-off backlog or ongoing flow
Clearing a backlog and running a monthly flow are different commercial shapes. The backlog is a project with a defined end. It should be priced as a fixed scope with an agreed acceptance test.
Ongoing flow is a service. New lines arrive, supplier data changes, channel specifications shift, and someone keeps the schema and the rules current. Priced as a retainer it is usually cheaper per SKU than the backlog, because the setup is already paid for. Priced per SKU with no minimum it will be dearer, because nobody can plan capacity against it.
How enrichment gets priced
Five models cover almost everything you will be quoted.
| Model | Best for | Risk it carries |
|---|---|---|
| Per SKU | Bounded backlogs | Scope creep on attributes |
| Per attribute value | Deep technical data | Hard to forecast totals |
| Per output type | Copy and media work | Ignores source difficulty |
| Day rate | Undefined scope | No cap, no acceptance test |
| Monthly retainer | Ongoing flow | Idle capacity if volumes dip |
Most real engagements combine two. A fixed-price backlog with a per-language uplift, or a retainer with a day rate for schema changes. What matters is that the model matches the shape of the work. You should be able to tell from the quote which model you are buying.
A worked example, with indicative bands
Three catalogue profiles come up repeatedly. The bands below are indicative. We will not put a firm number against your catalogue before we have seen a sample of it.
Simple retail line. Eight to twelve attributes, a clean supplier feed, images already supplied, one language. Indicative cost per SKU: £0.30 to £1.50.
Mid-complexity distributor line. Twenty to thirty-five attributes, a mix of digital and scanned PDFs, some asset retrieval, one or two languages. Indicative cost per SKU: £1.50 to £4.00.
Technical industrial line. Forty to eighty attributes, legacy and scanned sources, documents as well as images, three or more languages. Indicative cost per SKU: £4.00 to £12.00.
Run your own catalogue through the same grid before you put a product data enrichment cost in a budget. Count the attributes in your schema for your three biggest categories. Sample twenty products and record where the source data actually came from. That exercise takes an afternoon and it will change the quotes you receive.
Ask for a paid pilot as well. A sample batch of 250 to 500 SKUs, charged at the standard per-SKU rate with no project minimum, tells you more than any proposal. You measure the output against your own acceptance criteria rather than against a slide.
Costs that sit outside the enrichment quote
Buyers get caught by these more often than by the enrichment rate itself.
- Schema and taxonomy design. If your categories and attributes are not defined, enrichment cannot start. That is taxonomy and attribution work and it is a separate engagement.
- Your own team’s time. Someone internal answers questions, arbitrates on edge cases and signs off batches. Budget one to two days a week of a product manager for the duration.
- Acceptance and quality control. Whoever checks the output needs a sampling plan and time to run it. Skipping this is how a 40,000 SKU batch gets accepted and then rejected by merchandising.
- Rework and change requests. The schema will change mid-project. Agree the rate for reprocessing before you need it, not after.
- Loading and configuration. Getting enriched data back into your PIM, mapped to the right fields and pushed to channels, is integration work.
- Maintenance drift. Enriched data decays. Suppliers change specifications and channels change requirements. A catalogue with no maintenance budget needs the same project again in three years.
Twelve questions to put in the request for quote
- What attribute schema is this priced against, and at which taxonomy nodes?
- What source types are assumed, and what happens when the source is a scan?
- Is asset work included, and which operations specifically?
- Which fields get human review and which are machine output only?
- What is the volume band table, and where are the thresholds?
- Is translation quoted per language, per field type, or as a blanket uplift?
- What is the acceptance test, and what accuracy threshold applies?
- Who pays for rework when output fails the acceptance test?
- What is the rate for a schema change mid-project?
- How is a SKU with no findable source data handled and charged?
- What is in the setup fee, and is it charged once or per category?
- What does the same work cost as an ongoing monthly service?
If a supplier cannot answer eight of those twelve in writing, the price they have given you is a guess. Our own product content enrichment proposals are built around those answers. They are the only way to make two quotes comparable.
How to phase the budget across a year
Do not buy the whole catalogue at once. It is the most expensive way to purchase enrichment and the slowest way to prove it worked.
Start with a paid pilot in one category and set the acceptance criteria yourself. Then rank your categories by revenue and by how badly the current content performs. Buy the top tranche. Measure conversion, returns and search performance on the treated lines against the untreated ones. That evidence funds the next tranche.
The mistake we see is buying enrichment by SKU count, because SKU count is easy to budget. Rank by revenue instead. In most distributor catalogues a small share of lines carries most of the money. Enriching those first changes the payback period completely.
Where AI changes the number, and where it does not
AI has cut the cost of the first draft substantially. Extraction from datasheets, attribute normalisation and description generation are all cheaper than three years ago. A supplier not using them is overcharging you.
What AI has not changed is the cost of being wrong. A generated thread pitch that nobody checked is worse than an empty field. An empty field does not get a customer to order the wrong part. The verification term in the cost model stays. We set out where the line sits in our piece on manual, AI or hybrid product descriptions.
Treat a quote that is dramatically cheaper than the others as a statement about verification, not about technology. Ask what percentage of the output a human actually reads.
Key takeaways
- There is no single product data enrichment cost, because two SKUs in one catalogue can differ fifty times on effort.
- Price is driven by attribute count, source quality, asset work, languages, category complexity, volume banding and backlog against flow.
- Cost per SKU only means something when it is quoted against your own attribute schema at node level.
- Budget separately for schema design, your team’s time, acceptance testing, rework and loading.
- Buy a paid pilot first, rank the rest by revenue, and let measured results fund each tranche.
- A quote much cheaper than the rest is usually cheaper on verification, not on technology.
Bring us a sample of your catalogue and your attribute schema. We will tell you which of the seven variables is driving your cost and what we would scope first. You can see how we approach the work on our product content enrichment page. Our overview of what enrichment involves in practice covers the delivery side. When you are ready, book a thirty minute discovery call.