Case #031 - 𧩠Two ASINs, thousands of reviews, one hidden Amazon rule
A seller tried to merge two old ASINs into their GS1 replacements while keeping their reviews safe from disappearing when merging, and Amazon still said no.
If youâre new here, welcome.
If youâve been reading for a while, thank you for being here.
Each week, we break down one real Amazon case from the field. Not to share tactics, but to decode how Amazonâs system actually behaves and what to do when it breaks.
All past cases live in a single searchable archive, built to help you identify recurring patterns across time.
OSS LAB is powered by Online Seller Solutions, the Amazon operations team behind the cases we publish, working directly inside Seller Central to resolve complex operational issues. Contact Online Seller Solutions to learn more about our Amazon services and how we can help resolve the issues affecting your account.
Context
Old barcodes, new ASINs, one goal
A seller had two product lines that had been listed for over a decade, each using UPCs bought secondhand rather than issued directly through GS1.
Over time, Amazon ran a barcode check on active listings, and some got flagged.
To fix it, the seller created brand new ASINs using proper GS1-issued UPCs, thinking they could merge the old with the new ones to replace them going forward.
At that point, nothing about the request looked unusual, since it was the same product, same packaging, same manufacturer, only the barcode had changed. So the seller came to us with what seemed like a simple ask:
Align the backend data between the old ASIN and the new one
Submit the merge
And let the new ASIN inherit the reviews the old one had built up.
But before we could even get to that step, we needed to check whether the two listings actually matched on the backend, since Amazon requires several fields to align before any kind of merge is possible.
So our first review focused on attributes that appeared mismatched, such as model number, product description, number of items, part number, and UPC, since inconsistent data is the most common visible reason a consolidation request stalls.
Correcting those seemed like the obvious next step.
There was also something further back worth noting. At some point earlier in the productâs life, the original ASIN had been sold by Amazon itself, as a first-party vendor, alongside the sellerâs own sales. That detail did not seem relevant at the time. It became the actual center of the case once we dug into the backend, which is where this story diverges from what everyone expected.
Note: When Retail holds contribution rights on an ASIN, that ASIN cannot be consolidated or deleted through any seller-facing process, regardless of how clean the attribute data becomes.
Diagnostic
Why the merge was never possible
Amazonâs self-service merge tool only works when both ASINs are true duplicates, meaning the UPC, brand, specifications, and every product attribute match exactly. Since the new ASINs existed specifically to carry a corrected, GS1-issued UPC, they could never match the old ASINs on that single point, and Amazonâs system does not make exceptions for âclose enough.â
They were like two really similar products in Amazonâs eyes.
Knowing that, we still aligned every other attribute Amazon checks during a merge evaluation: model number, product description, number of items, part number, so that if there was any flexibility on the identifier requirement, nothing else would stand in the way.
That work turned out to matter later, just not for the reason we expected.
That is where the detail from earlier mattered, because since Amazon had sold the original ASIN as a first-party vendor at some point, Amazonâs catalog kept a separate record marking that listing as one Amazon itself had contribution rights to.
And when that record exists, the ASINâs attributes cannot be consolidated or deleted through any seller-facing process, no matter how clean the attribute data becomes.
That meant that this case sat outside the standard merge checklist entirely, since it turns into an ownership issue instead of a merge one.
So, with both the identifier mismatch and the ownership record working against a true merge, we had to find whatever legitimate gap Amazonâs system allowed.
The good thing is that Amazon states that ASINs grouped into a variation family keep their reviews attached individually. In practice, the live product page shows one combined review count for the entire family, not separate counts per child ASIN. That gap, between what the policy says and what the page actually displays, is what lets us protect the sellerâs review history without âneeding a mergeâ at all.
If you are dealing with a merge request that keeps getting rejected without a clear reason, we can help. Book a diagnostic call with our Amazon Expert Team.
Though Process
Finding what Amazon actually allows
The seller wanted one thing above everything else, keep the reviews, keep selling under the new GS1 codes, stop selling under the old ones. The word âmergeâ was just the label the seller used to describe that outcome, it was not actually the only way to get there.
We had to rule things out one at a time before we could see the real answer.
First, could this qualify as a duplicate resolution, Amazonâs actual name for what most sellers call a merge.
No, because that only works when both ASINs share the exact same identifiers, and these did not, on purpose, since the whole reason the new ASINs existed was to fix a bad identifier.
Second, could Amazon just force a merge anyway?
No, because Amazon Retail had a claim on both original listings, and nothing a seller does can override that. So two paths closed, in that order.
Once both were closed, we asked a simpler question.
What does the seller actually need, not what did they originally ask for? They needed the reviews visible, they needed the new ASINs live, they needed the old ones gone from the customerâs view without deleting the review history attached to them.
A variation family gave us all three. It let the old ASINs stay in the system, marked out of stock, while the new ASINs became the ones customers actually see and buy.
The only thing standing in the way after that was a small rule: two ASINs in the same variation family cannot share the same color attribute. That was solvable in one conversation with the seller.
Once that was fixed, every requirement from the case, keep the reviews, retire the old SKUs, sell under the new ones, was met, not through a merge, but through the one tool Amazon actually makes available for this exact situation.
Want to see how the case was actually resolved?
Premium subscribers get access to the full breakdown, including:
The full breakdown of how we confirmed Retail contribution as the blocking factor
The exact color attribute conflict that had to be resolved before the variation could be approved
Why the variation family displayed combined review counts despite Amazonâs documentation stating reviews arenât merged
The âWhat This Teaches Youâ section, where we extract the larger Amazon pattern behind the case
The entire archive of every premium OSS Lab case study weâve published, instantly unlocked
Additional Amazon system behaviors, enforcement patterns, and operational intelligence we reserve exclusively for OSS Lab members
