Amazon product information management: the OneSila fix

Amazon product information management is the work of getting your product data complete, structured and mapped to what Amazon asks for, before it reaches Amazon. The error arrives from Amazon because Amazon is the thing doing the checking. That does not mean the problem lives there. Most of what looks like a marketplace-specific error turns out to be a product data problem that simply surfaced at the marketplace, and the two are worth telling apart, because they get fixed in different places.

The cost is not the typing. It is the round trip. You see the error in one system, the value belongs in another, and confirming the fix worked means waiting for a sync you did not trigger. At fifty products that is an annoyance. At four hundred it is most of a week.

OneSila removes the round trip by putting the error next to the data. Amazon's validation messages and listing rejections are pulled back and shown against the product record itself, so the person who can fix the value is looking at the error and the value on the same screen. The correction is made once, in the product, and synchronises out to the live listing. Nobody opens Seller Central to clear it.

Amazon raises two different things, and they tend to get filed as one pile called "listing errors". Validation errors fire when you create or update a product: something is missing, or a value is not one Amazon accepts for that category. Your two missing fields are this kind. Listing rejections come later, after validation has already passed. These are Amazon objecting to what the listing says rather than to whether a field is filled: false medical or safety claims, prohibited words like "guaranteed" or "cure".

The first is a data problem. The second is a content problem wearing the same uniform, and it can come from three places: the product's default content, the Amazon-specific content, or the skill that generated the copy. The rejection text will not tell you which. Fixing the listing solves the case in front of you. Fixing the skill is the only one of the three that stops the phrase appearing on everything it writes next.

Both classes land in OneSila the same way, against the product. One queue, one place to work, rather than a data problem in your catalogue and a content problem in Seller Central.

Take Item Height Unit. There are usually three answers to where it should have come from. Sometimes it is already in your source data and was never mapped across. Sometimes it can be inferred from what you already know about the product, by a person or by a language model working from your product data. And sometimes nobody holds it at all, which means a supplier email or a tape measure. That third case is worth naming plainly: a share of this starts before you touch it, with a supplier who sent a price and a product name and nothing else.

Those three look identical in the interface. An empty field is an empty field. But an empty field somebody could fill from context and an empty field blocked on information nobody has yet are different jobs, and running them as one queue is what makes attribute work feel endless. One is a correction. The other is a research request that needs a name attached to it.

Whoever or whatever produces the value, it reaches Amazon under your account, and you are answerable for it. What OneSila lets you set is the route rather than the responsibility. Some classes of change publish straight through. Others wait for a reviewer. That is a decision you make once, per class of change, instead of product by product on a Friday afternoon. Where a language model fills the gap, the useful design is a certainty rule: it commits a value when the evidence your rules accept is actually there, and leaves an honest gap when it is not.

That gate misses in both directions and the two failures look identical in the output. Too strict and it leaves obvious fields blank. Too loose and it commits a confident guess that becomes a correction later. Worth knowing that the misses are not random: they cluster where classification is genuinely ambiguous, or where the data was never there to infer from. That is what makes review a targeted job rather than a re-check of everything.

When Amazon asks for an attribute you do not currently serve, the requirement resolves one of three ways in OneSila, and naming which one you are in is the actual decision.

1. Map it. Your existing field means the same thing and holds clean values. Point it at Amazon's field and move on.
2. Model it. Your field does not mean the same thing, so you add an Amazon-specific field to hold Amazon's value.
3. Derive it. The value can be worked out from other fields, so you set a rule that populates it when the condition is met.

Case two catches people out, because equivalence can run in one direction only. Say your catalogue tags a product Easter, and Amazon's category wants a value from its own list, which offers Holiday. Easter belongs inside Holiday, so that direction is safe. Coming back the other way is not: a Holiday product is not necessarily an Easter one. Point both at one shared field and you will quietly produce wrong values on one side. Two fields with a rule running in the safe direction gets you the reuse without the error. That example is illustrative rather than lifted from Amazon's documentation, but the shape of the problem is exactly this.

There is a test for whether you chose the wrong shape, and it is worth applying before you push a few hundred products rather than after. Check whether every value you hold has exactly one correct Amazon value, and then check the reverse. If the first fails, you need to model an Amazon-specific field. If only the reverse fails, you can derive. And if you find yourself adjusting mappings repeatedly just to get products to publish, that field wanted modelling all along.

Two things make this bigger than it first looks. Pulling your existing Amazon catalogue into OneSila brings Amazon's naming and its accumulated value vocabulary along with the products, which is where large piles of unmapped values come from. And years of free-text entry leave values nothing will match automatically: a colour field holding "main colour, pink children's skirt" is not going to resolve to Pink on its own. This work is real and it is paid once. We wrote about what that mapping work actually involves if you are sizing it up.

Once mapped, product rules in OneSila define what complete means for each product type, so the products missing an Amazon requirement show up as work before Amazon tells you about them rather than after.

Because rejections in OneSila are filterable, a fault with one shared cause stops being a drip of individual failures and becomes a set you can see. The content case makes it obvious: a prohibited word baked into a generation skill is not one rejection, it is every listing that skill has written. Without a filter you meet the same error two hundred times and treat it as two hundred problems.

Once you can see the set, there are three ways to clear it, and the useful difference is what each one leaves behind.

At a few hundred products, the first row is the difference between a day and a fortnight. At a few thousand, the second row is what stops you doing this again next quarter.

One honest caveat, because bulk tooling is not the whole answer. Teams do not run bulk operations they do not trust, and they are right not to. If the data underneath is inconsistent enough that nobody is sure what a filter will actually catch, people fall back to checking products one at a time even at sizes where that cannot work. Data quality gates the whole move. And clearing each rejection on its own while leaving its cause in place is how catalogue debt builds up in the first place.

For product data, the answer is very little. The product flow runs in OneSila, both classes of Amazon error surface there, and corrections sync back out. What stays in Seller Central is everything that was never product data: Amazon-specific reporting, order-related work, account settings, advertising, brand registry and policy appeals. That split is the right one rather than a gap. OneSila masters product information, while orders and stock belong in systems built to update continuously.

None of which means the connection never breaks. Syncs fail, and Amazon changes what a category requires without asking you first, which turns a product that published cleanly last quarter into one that does not. The useful difference is not that this stops happening. It is that it arrives as an error against the product, in the same queue as everything else, instead of as a listing you notice is missing three weeks later.

The other adjustment is habit rather than configuration. The instinct to open Seller Central and edit there takes a while to unlearn, and it is worth knowing that changes made downstream do not travel back up. OneSila is the write master. Our Amazon integration covers what connects and how.

If you want to test any of this before changing anything, filter your current rejection queue by error type and count the distinct causes. Most people find far fewer than they expected. Your first rejection tells you a field is empty. The second of the same kind tells you which decision you skipped.