The feed goes out on Monday. On Thursday a report says four hundred listings were rejected. The reasons are terse, the affected SKUs are listed by the marketplace’s own identifier rather than yours, and nobody can tell whether it is the same four hundred as last week.
That loop is the entire problem, and it is a loop you can close.
Short answer: treat every channel’s requirements as a declared rule set, hold the union of all of them in one record, and validate against each rule set before publishing rather than after. Rejection then happens in your system, attributable to a field and a person, instead of arriving three days later in someone else’s format.
What a channel actually demands
Pull apart any marketplace specification and it contains four kinds of requirement, which is useful because each needs a different mechanism.
Required fields. Present and non-empty. Easy to check, and the most common cause of rejection.
Format constraints. Title under a length, description without HTML, price with two decimals, image at a minimum resolution and aspect ratio. Also easy to check, and routinely missed because the constraint is buried in a PDF.
Vocabulary mapping. The channel’s category tree, its colour list, its size conventions. Your Navy has to become their Blue, and there is no way to derive that. It has to be maintained as a mapping.
Identity. A valid GTIN with a computing check digit, or an approved exemption. This is increasingly non-negotiable and it is the failure that takes longest to fix, because obtaining identifiers is an external process.
Google’s product data specification is the best public example to read if you want to see all four in one document, and its shape is broadly representative of what the larger marketplaces want.
Hold the union, generate the shapes
The instinct is to build a record per channel. It works for two channels and collapses at four.
The alternative is one record holding the union of every field any channel needs, plus a mapping layer per channel that selects, renames, converts and constrains. The record does not know about channels. The mapping does not hold data. Adding a fifth channel is then a new mapping and possibly a few new fields, rather than a fifth copy of everything.
Two properties make this work in practice:
Mappings are declarative. A mapping should be a document that says which source field becomes which target field, with which transformation. When mappings are code, only the person who wrote them can answer a question about them, and channel specifications change often enough that this matters.
Generation is idempotent. Running the same export twice produces the same output, and publishing it twice produces the same state at the channel. Without that property you cannot safely retry, and you will need to retry.
Validate before you publish
This is the change that removes most of the pain, and it is the reason the completeness model in what a PIM actually does exists.
Score every product against every rule set it is meant to satisfy, continuously. Show the result as a per-channel completeness figure with the missing fields named. Block publication for a product that does not pass. The queue of work then lives in your system, sorted by channel and field, and it can be assigned.
Compare that with the alternative, which is that the channel validates for you, in its own time, and reports in its own vocabulary. The information is the same. The latency and the attribution are not, and those are what determine whether anything gets fixed.
One caution worth stating: a completeness score is only as honest as the rule set behind it. Rule sets drift when a channel updates its specification quietly, which they do. Put a date on each rule set and review it, or your green dashboard will eventually be measuring last year’s requirements.
Images are part of the feed and they fail differently
Channels have image requirements: minimum dimensions, aspect ratio, background colour, no text overlay, a maximum file size, sometimes a specific format. These are the requirements most likely to be met by generating rather than by finding.
If your renditions are derived from a master by parameter, meeting a new channel’s image spec is a mapping entry rather than a production task. A square crop on white at 2000 pixels for one marketplace and a 4:5 crop for another are two parameter strings against the same master, not two files someone makes and stores. The rendition model is what makes that possible, and it is the difference between adding a channel in an afternoon and adding one in a sprint.
The image identity question is separate and worth being careful about. Some channels key on image URL and will re-fetch when it changes; others cache the first version they saw. Use stable URLs for the same content, change the URL when the content genuinely changes, and never reuse a URL for a different image.
Rejection handling as a first-class flow
You will still get rejections, because channels enforce things they did not document. Treat that as a routine flow rather than an incident.
- Map their identifier back to yours on ingest, so a rejection report arrives as your SKUs. This single step saves more time than any other.
- Classify by cause, not by product. Four hundred rejections are usually six causes. Fix the cause and the four hundred resolve together.
- Feed the cause back into the rule set. Every undocumented rule you discover becomes a check you run before publishing, permanently. This is how the rule sets become more accurate than the specifications.
- Keep the history. The same product failing repeatedly for different reasons means the record is thin, not that the channel is difficult.
How often should a feed run?
Less often than you think for the full catalogue, and much more often than you think for changes.
A full regeneration is a reconciliation, not an update. Run it on a schedule that suits the channel’s tolerance, typically daily or weekly, and treat divergence found by it as a bug in the change path rather than as normal operation.
Changes should propagate on change. Price and stock in particular have a short useful life, and a channel showing yesterday’s stock costs you more than the engineering to push it. Where a channel only accepts scheduled files, generate the file from live data at generation time rather than from a staged copy you maintain, which is the same argument made about internal integrations in wiring a DAM to a PIM.
The structural prerequisite for all of this is a model that can express what the channels ask for. If yours cannot represent a variant grid or a localised attribute, the mapping layer will end up carrying data, which is where syndication projects go to die. Attributes, variants and the SKU problem and the product data model that survives growth cover that groundwork, and the human side of keeping the queue moving is in running product content as an operation.
