The catalog under the hood: why your edit keeps reverting
- You understand why a listing is not a document but a catalog record with several contributors.
- You know product types and attribute schemas as what the catalog actually stores — flat files and the web form are only views onto them.
- You can tell the four common causes of reverting edits apart and treat each one specifically.
- You have a documented change process instead of a series of attempts.
The sentence that separates beginners from professionals: “I changed the title, and three days later the old one was back.” To the beginner that is a bug. To the professional it is entirely correct system behaviour — and they know which of four possible causes is behind it before opening a single case. This lesson explains the machine below the surface. It assumes the Listing track and repeats nothing from it.
As in the whole Listing track, every claim carries an evidence level: Amazon (own documentation), law, practice (broad consensus, no single public source) and disputed (sources contradict each other). Catalog mechanics in particular are mostly practice — Amazon deliberately does not document the internals. Anyone selling you certainties here does not have them.
1An ASIN is a record, not a document
The mental model behind almost every catalog problem: “My detail page belongs to me the way my website belongs to me.” Wrong. What Amazon stores is a product record under an ASIN. The detail page customers see is rendered from that record, with an offer block beside it listing every seller of that ASIN.
Three consequences follow, and all three are uncomfortable:
- Several parties feed the same ASIN. Every seller can contribute attributes; brand contributions, vendor data, GS1 sources and Amazon's own automatic enrichment come on top.
- Not every contribution wins. Amazon decides per attribute which contribution is displayed. The rule behind that is not publicly documented — only the outcome is observable.
- Your field content is a proposal, not a command. Even an accepted feed only means “contribution received”. Whether it appears on the detail page is a second decision.
Picture the catalog as a Wikipedia article, not as your Word document. You may write, others may write too, and an editorial process decides what ends up in the visible version. If your paragraph disappears, that was not a saving error — someone else edited, or the editors decided. And as on Wikipedia, the winner in the long run is not whoever saves loudest, but whoever brings the better source.
2Product types and attribute schemas: what the catalog really stores
The catalog knows no “bullet points” and no “description” as free text fields. It knows product types (for example KITCHEN or SHOES) and, per product type, an attribute schema: a machine-readable list of every allowed field with data type, value range, required flag and permitted enumeration values.
These schemas are publicly described: Amazon's Product Type Definitions provide a JSON schema of applicable attributes and constraints per product type and per store (evidence level: Amazon, Selling Partner API developer documentation). That is the catalog's actual language. Everything else you use is a translation of it:
| What you use | What it really is | What it can and cannot do |
|---|---|---|
| The web form in Seller Central | A form view onto part of the schema | Convenient, but it does not show every attribute of the product type. What the form does not offer, you cannot set there. |
| Flat file / template | A spreadsheet view onto the same schema | Shows considerably more attributes, including rarely used ones. ALWAYS pull the template fresh from your own account — it is account- and category-specific and goes stale. |
| API integration (Listings Items) | Direct access to the schema | Complete and logged; data quality depends on your own system. |
The practical conclusion almost nobody draws: if a field is missing from your form, it is not “unavailable” — it is only absent from that view. Before you conclude that your product type cannot do something, check the current template. Very often the attribute is right there under a technical name nobody would guess. And just as often the product type is simply wrong — then the attributes really are missing, but the fix is to correct the product type, not to hunt for the field. Which attributes actually have an effect in your category is covered in Listing lesson 13.
The AURELO spice grinder set is missing the “grinding mechanism” entry in the filter rail. The form offers no matching field — so, goes the obvious assumption, Amazon does not know the attribute. It is in the category's current template all along, under a technical name with a fixed value list. What goes in is the exact list value, not your own wording: free text there is silently ignored, the offer stays out of the filter, and the hunt starts in the wrong place. Two minutes of reading the template replace two weeks of guessing.
3Why edits revert: the four causes
“My change is gone” is an observation, not a diagnosis. There are four causes, and they need four different treatments. Fail to separate them and you open cases nobody can solve.
| Cause | How to spot it | Treatment |
|---|---|---|
| 1. Another contribution wins (another seller, vendor, brand contribution) | The displayed value is plausible but not yours. Often affects single attributes, not the whole listing. | Anchor brand rights in your account (Brand Registry, Growth L6), resend the contribution with complete attributes, add evidence (a photo of the packaging). |
| 2. Automatic enrichment or correction | The value is normalised, truncated or reformatted — not a competitor's wording. | Supply a clean, policy-compliant value; for titles follow your category's formatting rules, otherwise normalisation kicks in again. |
| 3. Feed only apparently accepted | The processing report shows warnings or “processed, not applied”. The page never changes. | Read the processing report line by line, not just the status. Note the error code, supply missing required attributes. |
| 4. Right field, wrong channel | Changed in the web form, then a feed or integration wrote the old state back. | Define ONE leading channel. Two systems maintaining the same ASIN overwrite each other in turns — forever. |
Cause 4 is the most common and the most embarrassing: not a competitor, not Amazon automation, but your own ERP dutifully writing back the day-before-yesterday state overnight. Always check that first, before you open a case anywhere.
Sending the same change several times in a row because “maybe it slipped through”. That blinds you: afterwards you no longer know which attempt worked, and with cause 4 you only speed up the ping-pong. One change, one channel, then wait — longer than feels right.
4The change process that produces evidence
Professionals do not change things differently, they document differently. The difference only shows in a dispute — but then completely:
- Capture the before state. The full detail page (a screenshot is enough) with date and time.
- One change per cycle. Change title, images and attributes at once and you can never attribute an effect to a cause — neither a success nor a rejection.
- Send through the leading channel, with a report. Save the report, do not just look at it.
- Wait. Amazon does not state publicly how long; circulating deadlines are not reliable (see Listing L16, “numbers without a source”). Practical rule: judge no earlier than the next day, later for images.
- Capture the after state and compare it with the before state — attribute by attribute, not by feel.
- Keep a register. Date, attribute, old value, new value, channel, outcome. This is the table that solves a support case in minutes instead of weeks.
On the AURELO set the fill quantity has been reverting to a wrong value for weeks. The register shows: changed three times in the web form, back the next morning every time — and every time during the same night. That practically proves cause 4 without a single support contact: a nightly sync writes back the old stock record. The case is not solved at Amazon but in your own system. Without a register there would have been a support case here that finds nothing on Amazon's side — because there is nothing there to find.
5When an ASIN is broken: creation, duplicate, merge
Four situations every professional hits once, and their sober assessment:
- Duplicate you created yourself (the same product twice because an attribute was missing the first time): close the weaker ASIN, do not advertise both. Sales and reviews do not move across automatically.
- Wrong product type chosen: attributes and filter membership hang off it (Listing L13). Correcting it is possible but can blank attributes — export first.
- Someone else's ASIN with wrong data that you sell on: you can contribute corrections, but you do not automatically win. Without brand rights your position is weak.
- Merged or split ASINs: such interventions affect reviews and sales history. They are a catalog correction, not a reach tool — abuse counts as catalog manipulation, and the variation rules (lesson 4) apply by analogy.
- Leading channel defined per ASIN and written down (web form OR feed OR API).
- Current category template pulled from your own account, not from a blog post.
- Product type verified: does it fit, or does it explain the missing attributes?
- Change register created: date, attribute, old, new, channel, outcome.
- Processing reports saved, not just read.
- For reverting values, your own system checked first, Amazon second.
- Brand rights anchored in the account before a dispute arises.
6Expert insight: the channel conflict and the single-source rule
The most expensive catalog mistake in larger accounts has a name: two sources of truth. As soon as two systems may maintain the same ASIN — the web form and an ERP, or two agencies each with their own feed — you get a loop that looks like Amazon arbitrariness from the outside and is in fact a data-model problem.
The loop has a signature you can recognise without knowing anything else:
- Regularity: the revert always happens at the same time of day — scheduled jobs run on a timetable, Amazon decisions do not.
- Selectivity: exactly the attributes the other system knows revert. Fields it does not carry stay put. That is the clearest fingerprint.
- Exactness: the identical old value comes back, not a normalised one. Amazon automation normalises; a feed copies.
The countermeasure is organisational, not technical: exactly one writing source per attribute group. Price and stock from the ERP, content (title, bullets, images, A+) from a single content channel. In practice that means genuinely switching the content fields off in the other system — empty fields in a feed are NOT a safe substitute: depending on configuration, “empty” is a value and deletes. If you cannot switch them off, do not send content fields at all rather than sending them blank.
| Attribute group | Recommended leading source | Why |
|---|---|---|
| Price, stock, handling time | ERP / repricer | Changes hourly, has to run automatically. |
| Title, bullets, description, search terms | One content channel (form OR feed) | Changes rarely; every change is a decision with a reason. |
| Images, A+ content | Content channel, logged separately | Review processes run differently and slower than for text. |
| Compliance attributes (GPSR, safety) | One accountable person, documented | Legally relevant — provability matters more than convenience here (Listing L15). |
Two additions separate “tidy” from “robust”. First: the catalog does not forget what you never wrote. An attribute you filled once and never sent again often stays put — even when it is long wrong. So every catalog clean-up starts with an export of ALL attributes, not just the maintained ones. Second: processing reports are evidence with an expiry date. They are not available forever. Whoever goes looking once the dispute is under way often no longer has them — they belong in your own folder on the day of the change, not in the intention to fetch them later.
“The agency handles the listings” is not a division of labour, it is a second writer without a register. If you outsource maintenance, the contract needs three sentences: who writes which attribute group, where the change register lives, and who receives the processing reports. Without them you later pay for reconstructing a state nobody remembers.
The pro track assumes the other three and repeats nothing from them. It opens once you have completed all three in full — every lesson quiz at 80 % or better, and every final quiz passed.
Not logged in? Your progress only counts with a free account.
Check yourself
6 quick questions — one at a time, instant feedback. With a free account your progress is saved.
Frequently asked
Is there a public rule for which contribution to an attribute wins?
No. Amazon does not document the prioritisation publicly. What is verifiable is only that several parties can contribute and that anchoring your brand in your own account noticeably improves your position. Everything beyond that is observation — and anyone quoting you a fixed ranking cannot back it up.
How do I notice that a feed was accepted but not applied?
Only from the processing report. The overall status is worthless for this: a feed can be fully processed and still have no effect on individual rows. So read the report line by line, treat warnings like errors and note the error code — it is the only entry point into a targeted search.
Is a custom API integration worth it with only a few products?
Rarely. The API's benefit is not speed but traceability and completeness — and you only need both once many ASINs or several editors are involved. Below roughly twenty ASINs, a clean template and a disciplined change register deliver the same value at a fraction of the effort.
The free Listing Check scores any ASIN from 0 to 100 in a minute — the fastest way to see whether the mechanics from this lesson actually hold on your own listing.
Go deeper: the complete guide to optimizing Amazon listings →
Everything in this academy comes from day-to-day selling practice — the same playbook behind Listimo, the tool that turns product photos into complete Amazon listings.