How do you score product data completeness?

Why a percentage beats a pass/fail flag

A boolean tells you a product is not ready. It does not tell you whether that product is one image away or thirty attributes away, and so it cannot help you decide what to work on this morning.

That single limitation is what keeps enrichment programs unfocused. With a binary flag, ten thousand incomplete products are an undifferentiated pile. With a score, they sort. The top of that sorted list is almost always a group of high-traffic products sitting at 80%, each needing one or two fields, where a day of work moves more revenue than a month spent on the products at 20%.

A score also gives you a trend. “Median site-readiness in Flooring rose from 61% to 84% over the quarter” is a sentence a merchandising director can act on. “4,000 products failed validation” is a sentence that produces a meeting.

Define the bars before you compute anything

Completeness is meaningless until you have said complete for what. Most catalogs need three definitions, and conflating them is the usual reason a scoring program produces numbers nobody trusts:

1. Valid. The record can exist and be identified. These are the SKU creation requirements, and they should score near 100% for everything, because anything below it should never have been created.
2. Merchandisable. The record can be presented to a customer without embarrassment: imagery, description, the category’s required attributes, the values its filters depend on.
3. Channel-ready. The record satisfies one specific destination, which frequently wants things nobody else does: a marketplace category ID, a compliance document, a fifth image, a shortened title.

Score against all three. A product at 100% valid, 90% merchandisable and 40% marketplace-ready is telling you something precise, and a single blended average would hide all of it.

Weighting

Not every attribute deserves the same influence. A missing hero image and a missing secondary material do not cost the same thing, and an unweighted score treats them identically.

Three tiers are enough to start:

• Required. Absence blocks publication to this destination. Weight 3.
• Important. Absence degrades the experience: filters miss the product, search relevance drops, the spec table looks thin. Weight 2.
• Nice to have. Improves the listing without being load-bearing. Weight 1.

The score for a product against a destination is then the sum of the weights of populated attributes divided by the sum of the weights of applicable attributes, expressed as a percentage.

Two refinements:

Applicability, not universality. The denominator should include only the attributes that apply to this product’s category. Penalizing a paint SKU for an empty thread-pitch field makes the whole score untrustworthy, and once merchants distrust the number they stop using it.

Populated is not the same as populated well. An empty string, a whitespace character, TBD, N/A, Unknown, and a description of nine words should not count as populated. Define a minimum bar per attribute type: a value from the controlled list, a number in a plausible range, text above a length floor. Without one the score will drift upward while the catalog stays where it was.

Rule of thumb. If completeness rises while your defect counts stay flat, the score is measuring effort rather than quality. Tighten what counts as populated.

Slice it where the work happens

The aggregate number is for the executive summary. The operating value is in the slices:

• By category. Finds structural gaps, usually attribute sets that were defined and never backfilled.
• By brand or supplier. Finds partners who send poor content, which is a commercial conversation you can win.
• By destination. Finds the channel you are under-serving.
• By onboarding date or batch. Finds the migration or bulk load where things went wrong.
• Weighted by traffic or revenue. Finds what to fix first. Most programs skip this slice, and it is the one that justifies the rest.

Thresholds as publishing gates

Once the score is trusted, it becomes a control rather than a report: a product must clear a minimum for a destination before it can publish there. Sixty percent might be enough for an internal catalog; a marketplace listing might demand ninety-five.

This makes the trade explicit and moves the argument to the right place. Instead of merchants asking for a validation rule to be waived for a specific product, the conversation becomes what the threshold should be for that channel. A policy decision, made once, visible to everyone. It integrates directly with per-destination gatekeepers, where the score is one condition among several.

Two cautions. Do not set thresholds so high that nothing publishes, which converts the score from a tool into an obstacle and guarantees someone builds a bypass. And keep at least one blocking condition outside the score, because a weighted percentage can be cleared while a mandatory field is empty. Required means required. Use the score for everything above that line.

Routing low scores to enrichment

Low-scoring products are a queue, and the queue can be worked several ways: assigned to the merchandising team, sent back to the supplier with the specific gaps named, or routed to automated enrichment: attribute extraction from images and documents, description generation from structured attributes, classification suggestions from supplier text.

Whichever path a product takes, one rule keeps the score honest: re-score after human approval, not after generation. If generated values increment the score at the moment they are written, the number stops measuring trustworthy data and starts measuring throughput of a machine. Hold generated values in a proposed state, score them at zero until approved, and let the score rise when a person has accepted them.

That discipline also gives you a useful secondary metric, approval rate by attribute and by category, which tells you where automated enrichment is trustworthy enough to loosen review and where it is not.

What the score cannot tell you

Completeness measures presence. It says nothing about accuracy, and a catalog can be 100% complete and substantially wrong.

That gap is covered by different instruments: defect reporting for conditions that should never be true, periodic sampling against the supplier source for values that are plausible but incorrect, and data regression testing for whether the data still produces the right outcomes on the site. Run completeness alongside those, not instead of them.