How to audit marketplace product data quality

A marketplace product data quality audit should tell you which records prevent buyers from finding or understanding items, what is wrong with those records, and which fixes are safe to automate. A catalog-wide completeness percentage cannot answer those questions by itself.

Start with one category and a sample you can inspect. The result should be a prioritized repair queue, not a score with no next action.

Define quality for a specific category

A chair needs dimensions and condition details. A phone needs a precise model, storage capacity, and network status. Requiring the same attributes for both makes a completeness score misleading.

Write a category contract with required fields, optional fields, allowed values, source requirements, and freshness expectations. Distinguish a valid blank from a missing value. A handmade object may genuinely have no manufacturer part number.

Give each rule an owner. An operations team can decide which details are needed to publish a chair, while engineering owns whether the stored value has the right type. Neither decision should be hidden in a prompt.

Sample by risk rather than convenience

Include new and established sellers, high-traffic and low-traffic listings, recent imports, and records changed by previous automation. Sample across categories and seller formats. A random sample alone can miss a small but important group with severe problems.

Keep the selection criteria and record IDs. Repeat the audit against a comparable sample after fixes, rather than choosing cleaner examples for the second report.

Check six dimensions

These are proposed audit dimensions, not an external certification. Set thresholds based on the consequences of errors in your marketplace.

Make each finding actionable

An illustrative finding might read: “34 of 100 sampled tables have a width in the description but no structured width. Twenty-six include explicit units. Eight do not.” The first group can enter an extraction workflow; the second needs clarification.

Keep the numerator and denominator visible. A 90% completeness claim is hard to interpret if it includes irrelevant fields or excludes blocked listings. Count affected listings and affected fields separately.

For product feed consumers, external requirements provide another check. Google's product data specification identifies missing variant attributes, low-quality images, and conflicts between submitted data and website content as potential problems. Your internal contract should also reflect how your own marketplace works.

Prioritize repairs by consequence

Fix wrong product identity before adding decorative descriptions. Fix a broken primary image before enriching a secondary specification. Use traffic, commercial importance, severity, and ease of verification to order the queue.

Avoid an arbitrary score that conceals the underlying issue. A listing with a false model number and excellent field coverage can be more harmful than a sparse but honest listing.

Use duplicate detection, category mapping, and image checks as separate repair workflows.

Turn the audit into a recurring process

Run checks when sellers submit or edit records, then periodically inspect older data for stale sources and changed rules. Track the age of unresolved findings and the recurrence rate after a repair.

Goodfolk is intended to identify these issues and prepare improvements. A useful pilot should produce a visible issue list with evidence and measurable review effort. Ask for the audit output first, then decide which classes of change may progress to approval or automatic publication.