THE SHORT ANSWER
A useful catalog readiness audit checks four things separately: stable product identity, accurate commercial facts, supported descriptive detail and a dependable update process. Start with a representative sample, record exceptions, then expand the review by category and risk.
Define what the audit is allowed to conclude
Write down the destination, market and source snapshot before opening a spreadsheet. A basic source audit can identify missing values or duplicate IDs, but it cannot establish every destination rule or prove that an integration account is approved. Put those boundaries in the report rather than leaving readers to infer them.
Separate observations from decisions. A row may have a missing material value, a price-format error and an untested image URL. These are different findings with different levels of certainty. A single pass/fail label often loses the information needed to route the fix.
Build a representative sample
Include more than best sellers. Cover simple products, variant groups, sales, unavailable items, long descriptions and products from different suppliers. If a category has unusual identifiers or fulfillment rules, include it deliberately. Record how the sample was chosen so the result is not mistaken for a random statistical estimate.
Use a small local check to discover the shape of the data. Then inspect the full catalog in a workflow that can handle its size. A clean hundred-row sample should not be described as proof that the remaining hundred thousand rows are also clean.
Assign a resolution to every finding
An issue list becomes useful when each finding has an owner, a proposed correction and a way to verify it. Group repeated mapping errors rather than creating hundreds of indistinguishable tasks. Keep genuinely product-specific gaps separate so a broad rule does not overwrite exceptions.
Use four resolution states: fix now, source evidence needed, destination clarification needed and accepted limitation. Save the reason for the last category. Without a reason, accepted limitation can become a hiding place for work that nobody owns.
Recheck the update process
Ask what happens when tomorrow’s source changes. Can the team reproduce the audit, preserve relevant approvals and identify the exact release that followed? Test one ordinary refresh and one intentional breaking change. Recovery behavior is part of readiness, not an optional exercise after launch.
Finish with a bounded next step. That might be a mapping repair, a supplier request or a controlled pilot. Avoid turning the report into a generic recommendation to automate everything. The value of the audit is that it makes the next decision specific.
A product feed audit template you can reuse
Create one finding record per distinct cause and affected scope. Include the snapshot date, source name, item IDs, observed value, expected value, owner and verification step. When the same mapping omission affects many rows, connect those rows to one root-cause task. When evidence differs by product, keep the decisions separate.
Choose severity by the harm an incorrect value can cause and whether it blocks the intended action. A stock mismatch on a purchasable variant may need immediate attention; an optional style term may be a lower-priority source request. The order depends on your destination and product category, so record the reason for the priority instead of applying an unexplained universal score.
| Audit area | What to inspect | A useful verification step |
|---|---|---|
| Product identity | Missing IDs, duplicates and lost leading zeros | Compare IDs across source, output and the next import |
| Variant selection | Family IDs, option combinations and selected URLs | Open two variants and compare their stock and images |
| Commercial facts | Price, currency, promotions and availability | Reconcile with the current offer and stock source |
| Descriptive evidence | Missing or conflicting category-specific attributes | Trace each proposed value to a supported fact |
| Update reliability | Refresh failures, count changes and stale releases | Run a normal refresh and an intentional failure case |
Measure improvement on the same cohort
A before/after comparison needs the same item cohort and the same checks. Suppose 20 of 200 inspected rows lack a source-supported size value. Size coverage is 90 percent for that inspected cohort. If a mapping repair resolves 15 rows, coverage becomes 97.5 percent. Record the remaining five as source gaps. Neither percentage measures platform acceptance or the accuracy of unrelated fields.
Keep a small release gate alongside the coverage report: unresolved identity conflicts, commercial mismatches, changes awaiting approval and operational failures. A release with better descriptive coverage can still be unsuitable if one of those gates fails. Give every unresolved exception an owner and a recheck date so the audit leads to specific work.
Coverage = (inspected rows - rows missing the verified attribute) / inspected rows
Before: (200 - 20) / 200 = 90%
After: (200 - 5) / 200 = 97.5%ILLUSTRATIVE WORKED EXAMPLE
Example: split a shared mapping failure from individual source gaps
Illustrative finding: 80 rows share a missing image mapping, while six individual products lack a verified brand. Create one mapping task for the 80 rows and six sourcing tasks. Recheck both groups against the same saved snapshot before closing the audit.
Your practical checklist
- State the destination and market.
- Cover normal and difficult product cases.
- Separate facts, formatting and access checks.
- Give each issue an owner and verification step.
- Test the next refresh and recovery path.
Common questions
What is a sensible first sample size?
Choose enough rows to cover the distinct product and source patterns. A fixed count is less important than clearly recording what the sample represents.
Can a free checker replace a full audit?
It can expose basic issues in a small sample. Full-catalog rules, approvals and recurring operations require a broader workflow.
What should a feed audit report contain?
Keep the inspected snapshot and scope, each finding’s cause and affected items, the proposed resolution, an owner and a repeatable verification step. Report sample findings separately from full-catalog results.
Sources & scope
Primary references below show their latest recorded check date. Examples are illustrative, not customer results. Use the current destination documentation for implementation decisions.