Which Product Facts Actually Change a Business Decision?
Every supplier sends a different format, half the attributes are missing, the feed throws errors and nobody has ever agreed what the categories mean. That's the ordinary condition of an apparel catalogue and it isn't a failure of discipline. Only two of your attributes pay off in more than one place, three of them will waste your time by looking as though they do, and one of them is permanent work that never finishes.
In 60 seconds
Sort your attributes by how many destinations one correct value serves. There are four groups and they behave completely differently.
- Only two attributes pay off everywhere: the product identifier and the party record about your company.
- Material, weight and brand are false friends. They exist in every system under the same name and mean different things.
- Recycled content, recyclability and care instructions have no standard home in any commerce or search feed specification checked.
- Product category spans five or more non-mappable hierarchies. A crosswalk per destination is permanent maintenance.
- No study measures duplicate attribute entry inside one company, so no cost figure appears on the page.
| Group | Attributes | Fix it once? |
|---|---|---|
| Universal | The product identifier, and the party record about your company | Yes. One correct value serves every destination there is. |
| False friends | Material, weight, brand | No. They exist in every system under the same name and mean different things. |
| Single destination | Colour, size, gender and age group on one side; recycled content, care instructions and producer registration on the other | No, and that is fine. Fix them where they are used. |
| Never | Product category | It has no crosswalk. Maintaining one is a standing job, not a project. |
Most catalogue clean-up effort goes into the last three groups, because that is where the errors are visible. The gain is in the first.
Jump around this page
The two that genuinely pay off once
The product identifier. It's the only universal join key in the whole chain. It's present in commerce feeds, marketplace listings, retailer onboarding and the open web vocabulary, and it's what a passport hangs off. It is also the field merchants most commonly cannot supply, and the one where an error becomes permanent, because a code goes onto goods and the goods go into somebody's wardrobe. What allocating one commits you to, how many a range needs and what it costs by country is a subject of its own.
The party record. Who made this, who imports it, who answers for it inside the Union and which producer schemes the company is registered with. It's small and stable, changes rarely and applies to a whole catalogue, not to a product. Every system that can stop you trading asks for it, and almost every system a merchant uses stores it in the wrong place, so it gets typed again every time. That's a separate subject, on the registrations that gate a listing.
Between them those two carry more reuse than every other attribute combined. They are also the two nobody enjoys working on, because neither of them makes a product page look better.
The three that waste your time by looking universal
These appear in commerce systems and in regulatory formats under the same name and describe different objects. They fail silently in both directions, which is what makes them expensive: a value good enough for a feed is not a compliance value, and a compliance value pushed back the other way arrives as a string the feed cannot use.
Material. A shopping feed wants a primary material as a short string, used to filter and display. Textile labelling wants a percentage per fibre, drawn from a closed statutory list, held per component so that a shell, a lining and a trim do not collapse into one word.
Weight. A commerce system means shipping weight, for rate calculation. Producer responsibility reporting means mass placed on the market, which is the basis of a fee.
Brand. A feed wants a marketing string. The regulatory side wants a legally accountable entity with an address.
The full account of why one word ends up meaning two things, and the three harder pairs sitting underneath these, is on where product data stops meaning the same thing. For planning, a clean-up project that maps by field name and calls that reuse will under-deliver on one side and over-claim on the other.
The ones that only ever serve one destination
A lot of effort goes into treating these as though they should reconcile.
Commerce only. Colour, size, gender and age group appear in no regulatory instrument. Colour normalisation against an enumerated marketplace list is a real and irritating problem with no compliance counterpart. Size on some marketplaces is a structured hierarchy of gender, age range, size system, size class and body type, and none of that reaches a passport.
Regulatory only. Recycled content, recyclability and care instructions have no standard home in any commerce or search feed specification we checked. That data has to be sourced, verified and maintained entirely outside the commerce stack, and there is no reuse argument in either direction. Producer registration numbers are the same shape and worse, because they are not a product attribute at all.
The consequence is a relief, not a problem. You don't have to reconcile these. You have to know which side of the line each one sits on and stop paying twice to make them agree.
The one that never finishes
Product category classification is the starkest non-overlap in the whole picture. A global classification standard, a shopping taxonomy, a marketplace browse tree, a passport's own scheme and a different national schedule for every producer responsibility scheme are five or more mutually non-mappable hierarchies for the same underlying concept.
There is no mapping. Anything claiming to structure once and publish everywhere has to maintain a crosswalk per destination, and that crosswalk is permanent maintenance rather than a one-off. Budget it as a standing cost or do not promise the outcome.
What nobody can tell you, including us
The claim underneath this whole subject is that the same attribute gets collected repeatedly inside one company for different purposes. It is almost certainly true and no study anywhere measures it.
The EU-funded project that studied passport costs for smaller businesses directly reported that providers themselves would not supply quantitative figures, for commercial reasons and in some cases because they did not know. The widely quoted claim that one in four product records is wrong has no primary document behind it; the nearest real source is a UK grocery data quality report from 2009, measuring a different construct in a different sector. Two vendor figures for returns caused by poor content differ from each other and neither publishes a sample size.
So there is no number for how much duplicate entry costs you, and anybody quoting one is quoting something else. What the return on this work is, and what it would take to establish it, is a page of its own.
What to do first
Fix identifiers before anything visible. They are the join key, the error is permanent once goods ship, and every other improvement is easier once products can be told apart reliably.
Pull the party record out of your product rows. One list, keyed on the legal entity and on country and scheme. It is an afternoon and it stops the re-typing permanently.
Stop trying to reconcile the single-destination attributes. Decide which side of the line each one lives on and leave it there.
Treat composition as the exception worth doing properly. It's the one attribute with a genuine commerce destination and a genuine compliance destination, and the only place the reuse argument is strong once the semantics are carried, not the string. What the field is allowed to say and the four rules that already bind it are set out on fibre composition.
Do not buy a crosswalk. Buy, or build, the discipline of recording where each value came from. The mapping to each destination changes; the provenance does not. Running that over your own catalogue in a day is set out on the product data you already have.
You can see how much of a record is already usable before deciding what is worth fixing. It runs on your own data, in your browser.
What this page is not
It is not an argument for a product information platform. That is a decade-old category with funded incumbents and it solves a broader problem than this one. This page asks the narrower question of which apparel product attributes repay being fixed once.
It is not a data governance framework. The audience for those is engineering and the answer would be the wrong one.
It is not a claim that regulatory work fixes your feed. Most of what breaks a feed is commerce-only data that no instrument has any interest in.
What would change this page
A commerce or feed specification adding a home for recycled content, care instructions or a textile certification. That would move an attribute from the regulatory-only group into the universal one and change the sequencing above.
Any published measurement of duplicate attribute entry inside a single company. It would be the first, and it would let this page carry a number instead of an argument.
Which Product Facts Actually Change a Business Decision?
Direct answer
Fix the product facts that change an important decision, output, eligibility rule or action before you spend heavily making every record look complete.
Ask more than “is this field missing?”
- What changes if this value is wrong or unknown?
- Who requires, uses, verifies or blocks an outcome because of it?
- How many outputs depend on it?
- Is it an upstream dependency for other facts?
- What evidence is needed to establish it correctly?
- Can fixing it once remove repeated work elsewhere?
A product fact is often high-value when changing the value changes something consequential: whether a product can be listed, which legal requirement applies, whether a claim can be published, whether a retailer accepts a feed, whether a procurement rule passes, whether a warning appears or whether another calculation can be trusted.
Fix facts that change decisions before facts that merely improve the appearance of completeness.
That is a prioritisation rule, not a claim that only immediately decision-changing data matters. Foundational identity, hierarchy and evidence controls can have high infrastructure value because many future decisions depend on them.
Evidence labels used on this page
| Label | Meaning |
|---|---|
| [REGULATION] | A legal requirement or legal example, limited to the cited scope |
| [STANDARD] | A formal standard or specification |
| [PRACTICE] | Evidence-backed information-governance practice |
| [RECOMMENDATION] | ActivateDigital governance recommendation |
| [SYNTHESIS] | An analytical model used to explain prioritisation |
Why all product data is not equally valuable
A catalogue can contain hundreds of attributes. They do not all carry the same operational weight.
One missing field may be cosmetic. Another may stop a product from being listed. A third may be the evidence dependency behind a sustainability claim. A fourth may be used by six systems and corrected manually in each one.
Treating those four gaps as equivalent creates expensive remediation programmes with weak priorities.
Completeness is useful, but incomplete as a decision metric
A completeness percentage can tell you how much of an expected schema has been populated. It cannot, by itself, tell you whether the record can perform its intended job.
Record A is 95% complete, but the missing or unreliable fields include:
Record B is 70% complete, but it contains every field needed for the immediate release decision, current retailer feed and required online information.
For that immediate job, Record B may be more operationally ready.
Completeness isn't meaningless. Read it against a purpose:
- complete for which decision?
- complete for which channel?
- complete for which regulation?
- complete for which claim?
- complete for which calculation?
What counts as a decision-changing product fact?
[SYNTHESIS] A decision-changing fact is a product assertion where a different value, status or confidence level can change a material outcome.
The outcome can be regulatory, commercial, operational or customer-facing.
Examples include:
- a manufacturer location that changes which responsible-person information is needed
- a product identifier that determines whether two feeds refer to the same SKU
- a composition value that changes a labelling or claim rule
- a certification status that controls tender eligibility
- an allergen result that changes a warning
- an evidence status that determines whether a claim can be substantiated
- product weight that changes a calculation or logistics rule
- repair information that materially changes consumer or service action.
If correcting an attribute does not change any current or foreseeable decision, output or dependency, it may reasonably sit behind a fact that does.
A practical taxonomy of decisions
This is a working taxonomy, not a universal industry standard.
| Decision type | Core question | Example fact |
|---|---|---|
| Regulatory | Can the product be placed or made available in this context? Which rule applies? | manufacturer location, classification, conformity state |
| Publication | Can this claim, warning or value be published? | substantiation status, allergen result, recycled-content evidence |
| Channel | Will a retailer, marketplace or distributor accept the record? | identifier, required attribute, image or package information |
| Product identity | Are these records the same model, variant, batch or SKU? | GTIN, model code, variant relationship |
| Evidence | Is the fact sufficiently substantiated for its intended use? | source, test result, certificate validity |
| Commercial | Can this product enter a tender, market, programme or customer requirement? | certification, origin, supplier/facility status |
| Operational | What workflow, supplier action or escalation should happen? | failed test, expiring evidence, missing critical input |
| Consumer decision support | Does the information change selection, use, maintenance, repair or disposal? | fit, ingredients, warning, care, repairability |
The same fact can sit in several categories. Manufacturer legal identity, for example, can affect a regulatory check, an online offer, a retailer feed and customer service.
That overlap is why some facts are worth fixing centrally.
Who cares enough to act, pay or block?
Who cares enough about this fact to act, pay, choose, enforce or block an outcome?
This adds an incentive test that simple data-quality scoring misses.
| Actor | What they may do with the fact | Why it creates value or risk |
|---|---|---|
| Regulator / market-surveillance authority | assess compliance or request evidence | can restrict, investigate or require corrective action |
| Retailer | accept or reject an item or feed | controls access to a sales channel |
| Marketplace | validate structured listing requirements | can block publication or reduce discoverability |
| Procurement team | qualify a supplier or product | controls tender or customer eligibility |
| Brand / manufacturer | publish a claim or release a product | bears legal and reputational risk |
| Consumer | compare, select, use or avoid a product | information can change purchase and safe use |
| Repairer / recycler | identify product, material or service route | information can change lifecycle action |
| Internal operations team | trigger review, supplier action or escalation | wrong data creates repeated manual work or risk |
“Who pays?” should not be reduced to immediate revenue. A regulator may create enforcement risk rather than purchase value. A consumer warning can matter because it protects safe use. An evidence field can matter because it prevents an unsupported claim.
The stronger question is who has a consequential dependency on the fact?
Product fact -> decision chain
[SYNTHESIS] Use this chain to expose why a field matters:
PRODUCT FACT -> RULE / QUESTION -> DECISION -> ACTION / OUTPUT -> ACTOR -> VALUE / RISK
Example 1: manufacturer establishment
[REGULATION] Assume a non-food consumer product is within the scope of the EU General Product Safety Regulation, is sold online in the EU and the manufacturer is not established in the Union. Article 19 requires the distance-sales offer to show the responsible person's name, postal address and electronic address.1
manufacturer established outside EU -> what responsible-person information must the online offer display? -> responsible-person details required for this offer -> publish the correct details -> merchant / regulator / consumer -> market-access and compliance risk
The manufacturer-location fact is valuable because it changes a required output.
Example 2: product identity
GTIN maps to two different variants -> are channel records referring to the same saleable item? -> NO / conflict -> stop feed propagation and resolve identity -> retailer / operations / consumer -> listing integrity and order accuracy
Example 3: recycled-content claim
recycled content = 40%, evidence status UNKNOWN -> is the public claim substantiated? -> not established -> withhold or qualify claim until evidence is resolved -> brand / consumer / regulator -> claims risk and trust
Example 4: certificate expiry
certificate expires in 30 days -> does customer qualification require a current certificate? -> renewal or replacement evidence needed -> open owner task before expiry -> procurement / account team -> revenue continuity and eligibility
Example 5: derived carbon figure
product weight evidence is disputed -> can the current carbon calculation be trusted? -> not yet -> fix the weight dependency before recalculation -> sustainability / customer / reporting team -> avoids false precision and rework
A prioritisation framework for deciding what to fix first
[RECOMMENDATION] Do not start with a fake universal score. Start with eight questions.
1. Decision impact
What changes if the fact is wrong, missing, expired or unknown?
High-impact facts can change market access, safety, claims, eligibility, release or a major commercial output.
2. Frequency of use
How many decisions, systems or outputs consume the same fact?
A fact used in six places has greater “fix once” value than one used in a single annual report.
3. Risk
What is the consequence of using the wrong value?
Consider legal, safety, customer, operational and reputational risk rather than revenue alone.
4. Actor demand
Who requires the fact and how strongly can they enforce that requirement?
A hard retailer gate is different from an optional merchandising preference.
5. Evidence cost
How difficult is it to establish the fact correctly?
High-value does not mean easy. The evidence cost helps sequence work and identify where a temporary UNKNOWN state may be rational.
6. Reuse value
Can one governed correction remove repeated manual work in several systems?
This is where central product truth earns disproportionate value.
7. Change rate
How often does the fact change and how quickly must downstream systems react?
A stable identifier and a frequently changing availability field need different controls.
8. Dependency
Do other facts, calculations or rules depend on it?
An upstream input can deserve priority even if users never see it directly.
Use judgement, not arithmetic theatre
A simple High / Medium / Low assessment across these dimensions is often enough to expose priority.
If a business later wants a numerical model, it should define weights around its own decisions and evidence costs. A universal “data value score” would create false precision.
High-value facts are contextual, not a universal top ten
The same field can have very different value by business context.
| Fact | When it can be high-value | When it may be lower priority |
|---|---|---|
| GTIN / product identity | joins listings, orders, evidence and variants | internal-only prototype with no channel use |
| Manufacturer legal identity | regulatory outputs, retailer feeds, labels, support | rarely lower where regulated product data is in scope |
| Responsible-person details | applicable EU online product offers and compliance | products / markets where the rule does not apply |
| Composition | labelling, claims, restrictions, consumer choice | products where no decision or output consumes it |
| Product weight | logistics, calculations, regulated fields | low if only an unused merchandising detail |
| Country of origin / manufacture | customs, procurement, claims, customer rules | low if the output does not require it and definition is unresolved |
| Allergen status | safety warning, labelling, consumer choice | irrelevant to products without that risk territory |
| Conformity state | product release and regulated market access | not a generic field outside relevant regimes |
| Carbon figure | customer requirement, adopted disclosure, validated claim | defer if no current use and underlying inputs are weak |
| Recycled content | claim, tender, regulated output | defer if not used and evidence is expensive or uncertain |
| Classification / code | determines regulation, duty, feed or eligibility | lower where no downstream rule consumes it |
| Supplier / facility | traceability, certification scope, procurement | lower if only a free-text duplicate of another governed entity |
| Certification | retailer, tender or scheme eligibility | lower if no actor requires that scheme |
The goal is not to rank these permanently. It is to reveal why the fact matters here.
Facts that are expensive to perfect but low-impact
Product-data programmes often become expensive because “complete everything” feels safer than making choices.
That can lead teams to:
- enrich long-tail descriptive fields before fixing identity
- calculate environmental figures before stabilising their inputs
- research optional attributes with no current consumer or channel use
- overwrite UNKNOWN with weak guesses to improve dashboards
- manually repair the same fact in several systems rather than fix the upstream owner.
[RECOMMENDATION] It can be rational to defer a field when:
- no material decision or output currently depends on it
- evidence acquisition is disproportionately expensive
- a stronger upstream dependency must be fixed first
- the value is genuinely unknown
- the business can safely represent the gap without inventing an answer.
Deferral should be visible, not forgotten. Record why it is deferred and what event would raise its priority.
Derived fields: fix dependencies before outputs
A derived value can look like one field while depending on several upstream facts.
A carbon footprint, for example, may depend on product weight, material composition, geography, process data and a chosen methodology.
If those inputs are weak, “fix carbon” can become the wrong remediation task.
A stronger sequence may be:
- establish product identity and scope
- verify weight and composition
- confirm the methodology and geography
- calculate the derived figure
- store the derivation and evidence links
- publish only when the intended claim or output is supportable.
This principle applies beyond environmental data. Risk classifications, eligibility states, warning logic and readiness statuses can all be derived from upstream facts.
So the dependency graph is part of priority.
Reuse and “fix once” value
Some attributes are worth fixing centrally because they recur.
Fix once where the same governed fact changes several decisions or outputs.
Take manufacturer legal identity. One corrected record may feed:
- regulated online product information
- retailer feeds
- product labels
- declarations
- a Digital Product Passport where applicable
- customs or compliance workflows
- customer service.
That is more than completeness. It is reuse value.
The same logic applies to product identity, controlled composition, classification and evidence references.
UNKNOWN and deferral are valid states
A missing value and an unknown value are not always the same thing.
- Missing can mean the field has not been populated.
- UNKNOWN can mean the organisation has looked and does not have sufficient evidence to assert a value.
- Conflicted can mean credible evidence supports incompatible values.
- Deferred can mean the field is intentionally not being enriched yet because a higher-priority dependency comes first.
These states prevent weak guesses from masquerading as product truth.
[RECOMMENDATION] Use UNKNOWN when the evidence does not support a defensible assertion and the downstream decision can tolerate that state. If a channel or legal rule cannot tolerate UNKNOWN, that fact moves up the priority queue because the missing evidence now blocks an outcome.
Worked example: 20 issues, which five should be fixed first?
Assume a non-food consumer product is sold online in the EU and through a major retailer. The manufacturer is outside the EU. The business finds 20 data issues in one record.
| # | Issue | Initial view |
|---|---|---|
| 1 | GTIN is linked to two variants | identity conflict |
| 2 | Manufacturer legal name differs across systems | inconsistent core fact |
| 3 | Responsible-person details are missing from the EU online record | regulatory output blocker in this scenario |
| 4 | Required warning text is missing for the target market | safety / publication blocker |
| 5 | Recycled-content claim says 40% but supporting evidence is not established | claim substantiation risk |
| 6 | Package depth is blank | retailer data gap |
| 7 | Marketing colour says “stone” in one feed and “oat” in another | merchandising inconsistency |
| 8 | Long description is six months old | content freshness |
| 9 | Product net weight differs by 30 g between two sources | evidence conflict |
| 10 | Country-of-manufacture evidence is incomplete | unresolved fact |
| 11 | HS classification has not been reviewed this year | review gap |
| 12 | One lifestyle image is missing | merchandising gap |
| 13 | Certification expires in 40 days | future eligibility risk |
| 14 | Supplier facility name is duplicated under two spellings | entity hygiene |
| 15 | Carbon footprint is blank | derived-field gap |
| 16 | Care wording could be clearer | content quality |
| 17 | Spare-part availability is UNKNOWN | lifecycle gap |
| 18 | Packaging material family is missing | enrichment gap |
| 19 | Search synonym is missing | discoverability gap |
| 20 | Internal product subtitle is inconsistent | internal presentation gap |
The first five
1. Fix the GTIN / variant conflict
Why first: identity is a dependency. Until the business knows which saleable item the record refers to, evidence and fixes can be attached to the wrong product.
Decision impact: channel, fulfilment and evidence integrity. Reuse: very high. Actor: retailer, operations, customer. Priority: FIRST.
2. Fix manufacturer legal identity
Why: it is a reused core fact and also determines the context for the responsible-person requirement in this scenario.
Decision impact: regulatory and publication. Reuse: high across several outputs. Actor: merchant, regulator, retailer. Priority: VERY HIGH.
3. Establish and publish the responsible-person details
Why: under the assumed GPSR scenario, the online offer requires this information when the manufacturer is not established in the Union.1
Decision impact: a required public output. Actor: regulator, merchant, consumer. Priority: VERY HIGH.
4. Resolve the required warning
Why: a missing required warning is a safety and publication problem, not a cosmetic completeness issue.
Decision impact: safe sale and publication. Actor: consumer, compliance team, retailer. Priority: VERY HIGH.
5. Stop or substantiate the recycled-content claim
Why: a public claim with unestablished evidence creates a decision now: prove it, qualify it or stop publishing it.
Decision impact: claim publication. Actor: brand, consumer, regulator. Priority: HIGH.
What happens to the other 15?
They do not disappear.
The certification expiry may become urgent because of a customer qualification rule. Package depth may become a hard retailer gate. Country of manufacture may become critical for a tender or customs process. The 30 g weight conflict should be resolved before a dependent calculation uses it.
But a blank carbon field should not automatically outrank an identity conflict or unsupported public claim. If no current output needs carbon and its inputs are weak, it is rational to defer calculation while fixing the upstream data.
The core rule: priority follows consequences and dependencies, not row count.
Common mistakes
Chasing 100% completeness without a decision map
A perfect percentage can still hide the five fields that block the business outcome.
Treating every field as the same risk
A colour-name inconsistency and a missing required warning are not equivalent defects.
Prioritising the visible output instead of the upstream dependency
Fixing a carbon number without fixing disputed weight or composition creates repeated rework.
Asking “who pays?” only in revenue terms
Regulators, consumers, repairers and internal operators can create important value or risk without being direct buyers of the data.
Filling UNKNOWN with a guess
A guessed value can convert a transparent evidence gap into false product truth.
Fixing the same value in each channel
If one fact is repeatedly corrected downstream, move upstream and govern it once.
Building a universal “top ten fields” list
Field value depends on product category, business model, channel, law, customer requirement and current objective.
Direct questions
Which product data should I fix first?
Start with facts that change a material decision or output, especially where they are reused widely, carry high risk or block other work.
What product data has the highest business value?
There is no universal field list. Value depends on what the fact changes, who depends on it, how often it is reused and what happens if it is wrong.
Should I aim for 100% product-data completeness?
Completeness is useful as a control metric, but it should not be the only priority metric. Define completeness against the decision, channel or output being supported.
How do I prioritise missing attributes?
Assess decision impact, frequency of use, risk, actor demand, evidence cost, reuse, change rate and dependency. Use a qualitative view before inventing a numerical score.
What makes a product attribute decision-critical?
A different value or evidence status changes a consequential decision, action or output.
Which product facts should be fixed centrally?
Prioritise facts that are reused across several systems or outputs and where one governed correction can prevent repeated downstream work.
Should I calculate carbon if the source data is incomplete?
Not automatically. If the calculation depends on weak weight, material, geography or methodology inputs, fix the dependencies first unless an immediate requirement justifies a controlled interim method.
When is UNKNOWN better than a guessed value?
When the evidence does not support a defensible assertion and the downstream process can represent uncertainty. If UNKNOWN blocks a mandatory outcome, acquiring the missing evidence becomes higher priority.
What would change this page?
Revisit priorities when the business objective, product category, applicable regulation, customer requirement, channel gate or evidence cost changes. The framework is an ActivateDigital prioritisation recommendation, not a universal product-data ranking.
Keep exploring
The question this one usually raises next.
Also worth reading
- CompareImplementationThe product data you already have, and which of it a passport can useWhere each value actually lives, and the four questions that decide whether one can be published.
- Another anglePassport informationIdentifiers, and what allocating one commits you toThe join key, what a catalogue actually needs and what it costs.
-
ActivateDigital current Knowledge estate and final DPP V1 estate, used for the existing “fix once”, evidence, UNKNOWN, scope and readiness doctrine. Existing public Knowledge is editorial/context material rather than independent regulatory authority.
Start with the data you already have.
No clean dataset required. ActivateDigital structures what you give it and shows what is still missing.
Sources
-
A cross-system attribute reuse analysis across seven product data systems, compiled 27 August 2026Field research
The load bearing source. Used for the four groups, for the two universal attributes, for the three false friends, for the commerce-only and regulatory-only sets, and for the finding that product category classification has no cross-system mapping.
-
A European Commission funded study on passport service provisionInstitutional research
Cited for one proposition: that potential providers were reluctant to supply quantitative figures for commercial reasons and in some cases did not have them.
-
A UK grocery product data quality report, October 2009Industry research
Cited only as the traceable origin of a widely restated figure, and for what it actually measured.
-
Search demand evidence on merchant product data language, compiled 27 August 2026Field research
Used for the merchant vocabulary in the opening and for the observation that this demand is served by feed tools, product information vendors and platform help centres rather than by anybody connecting it to product compliance. Demand in that research is qualitative throughout and no volume figure exists, so none appears here.
Sources as at 30 August 2026.