When Two Marketplace Sellers Disagree About Product Data

A product data dispute on a marketplace is what happens when two sellers of the same goods send different values for one field on a shared page, and somebody has to decide which one the buyer sees.

One shared product page, one "power" field, two different values, each from a seller of the same goods. Someone has to settle it, and if your system has nobody to do that and nothing to do it with, chance does. Chance also sends the bill.

This article breaks down:

• Which 3 kinds of product data disagreement do you get?
• Which 4 tiers of evidence settle a dispute?
• What does the buyer see while a dispute is open?
• Who has the mandate to close a dispute?

Key insights

• Two sellers arguing over one field are arguing about who pays. A page promising 2,000 W on a 1,400 W device turns 12 returns a quarter into 33, and the seller who shipped correct goods carries them.
• Three kinds of disagreement arrive in one queue. Facts close with evidence. Taste closes with a standard. An offer on the wrong page comes off the page first, then you talk.
• Rank the evidence: manufacturer documentation, then a photo of the rating plate, then an independent datasheet, then a seller's word. Whoever wants the field changed brings something from a higher tier.

What is a marketplace data dispute?

Two sellers who state a different wattage for the same device are not arguing about physics. They are arguing about who carries the cost when the page says one thing and the product says another.

One will pay in returns, the other in an offer that looked worse than it was. That is why neither backs down, though either could check who is right in a minute.

Run the numbers. The page promises 2,000 W, the device delivers 1,400 W, and it sells 300 units a quarter.

Returns go from 4% (12 units) to 11% (33 units). That is 21 more returns, each with a logistics cost, a support cost, and an entry in the metrics that get accounts suspended.

The seller who pays for shipped goods matching his own label and not matching a page he never wrote.

That tells you what will not settle a dispute like this. Not who is right, because both sides are.

Not a vote, because three resellers outvote one manufacturer. Not seniority.

That is the most common trap, because seniority tends to be a default policy nobody chose: in some systems, the value entered earlier wins a conflict. The content of the page is then decided by the order sellers registered in.

What is left is evidence. The rest of this article is about turning discussion into a procedure that requires nobody to be right.

I assume a write precedence policy already exists at your company; who may change which field is the subject of "Who Owns Product Data on a Marketplace?". This article is about the day it was not enough.

Which 3 kinds of product data disagreement do you get?

Putting them in one queue is the first operational mistake: two of the three do not close with evidence.

A technical fact is the value of a field with a unit: power, weight, dimension, composition, compatibility. Its definition lives outside your platform.

Public classification standards describe a product by a class and a set of properties, at a scale of tens of thousands of classes and thousands of properties. There is exactly one correct answer.

Commercial content is the photo, the title, the order of features, the length of the description. It has no objective answer, because it is an interest: the manufacturer wants consistency with the brand, the reseller wants the phrase people search for.

Do not arbitrate here. Set a catalog standard and enforce the standard ("Product Data Quality on a Marketplace: What You Can Enforce").

Whether the offer belongs on the page asks whether this offer is an offer of this product at all: a 128 GB variant attached to the page for the 256 GB version. The most dangerous of the three, because it decides what the buyer finds in the box.

Offer matching covers the mechanics. You handle this one in the opposite order from the other two: first you detach the offer, then you talk.

The table describes one example catalog with 25 reports a week, and it is not a market measurement.

Which 4 tiers of evidence settle a product data dispute?

Four tiers, strongest first:

1. Manufacturer documentation or a conformity document. The manufacturer issues a document taking responsibility for the product meeting its requirements, and keeps technical documentation with the description, the identification, the risk assessment, and the label wording. It holds that documentation for years after the product goes to market. This is the strongest evidence there is.
2. A photo of a real unit with the rating plate or label visible. Weaker, because it covers one unit, but verifiable in a few minutes.
3. Data from an independent source. A manufacturer datasheet, or an entry in a product data exchange network. Those networks work on one principle: the data comes from a designated source.
4. A seller statement. A report rather than evidence. Certainty in an email is not a tier.

The rule fits in one sentence: whoever wants to change a field brings evidence from a tier above the one the current value stands on. Without that, the change does not go through.

It is not that the seller is wrong. It is that he has no evidence.

That difference lets you refuse without judging the seller and without entering a technical argument nobody on your side is qualified to have.

There is a softer version of this idea: a trust score, where the seller with the higher rating wins the field. Some platforms have one, and by default it starts everybody equal.

Practitioners from large rollouts say that at several hundred sellers, nobody maintains it, because nobody can defend why one seller gets a three and another a four. Evidence works per field and needs no ranking of people.

The effect on those same 25 reports: of the 11 that concern a fact, 7 arrive with tier one or tier two evidence and close within fifteen minutes, while 4 consume the whole weekly discussion budget.

One exception. When the disputed field is one the regulations require (details of the responsible entity, a warning, a marking), the report stops being a commercial dispute.

Product safety and recalls and restricted and prohibited products cover it.

What does the buyer see while a product data dispute is open?

Almost nobody asks this, and it is the most expensive question: the site keeps running, so the page keeps claiming something for the whole dispute. Three policies. Choose in advance.

1. The last value accepted as good stays up

The cheapest option, but if that value is the disputed one, you keep selling against it and multiply the returns from the first section.

2. You fall back to the manufacturer's documentation

The strongest option on the merits, on one condition: that value is stored separately, marked as coming from that source, rather than overwritten by the first seller edit.

If the page holds only the current state, there is nothing to fall back to.

3. The field disappears from the page

Honest, and the buyer notices: nobody gets a promise you cannot back.

The cost is real too. A field that is gone cannot be filtered on, so the product drops out of the listings where it used to show.

Run the numbers on what you are really deciding. A dispute over a fact with no evidence runs 9 days at your company, and the page gets 400 views a day: 3,600 views carrying a value nobody stands behind.

That is not a database setting. It is a decision about 3,600 promises.

Why in advance: in some systems, an edit to a shared page goes live immediately, and a product once approved cannot be sent back for review. The field policy is then the only thing you control.

The approval queue has a chapter of its own.

How do sellers use edits to a shared page as a weapon?

The shared page model creates an abuse the per-seller listing model never sees: a seller edits the page his competitor stands on. The repertoire is predictable.

A photo swapped for a worse one, a misleading condition added ("power supply not included"), a unit changed from meters to centimeters, a description cut down to one sentence.

Data quality will not catch this, because every change on its own looks like a correction, and some of them are. You catch it with a pattern: who edits the pages he is losing on.

An example: a seller files 18 changes in a month, 16 of them on pages where his offer is not the default; the offer is added to the cart with one click.

A split of 16 out of 18 is not chance.

This requires a change log with the author, the value before and after, and the source. It has to be kept longer than a few months, because the pattern only shows across quarters.

Some systems have one, but keep it brief and without export.

There are three sanctions: a warning, withdrawal of edit rights where the seller is not the source of the data, and suspension. Each needs a reason, delivery, and a path of appeal.

What turns a product data report into an object with a clock?

At most operators today, it works like this: an email to the seller account manager, a row in a spreadsheet, a decision in a meeting, someone passing it to the catalog team. Three consequences: you cannot count how many there are, cannot measure how long they take, and cannot reconstruct what settled them.

Four fields at minimum, so that a report is an object rather than correspondence:

• what it concerns: the product and the specific field, so never "the description is bad";
• who is reporting: a seller, your team, a buyer;
• what evidence they attached, and which tier of the hierarchy it comes from;
• who settled it and when, and on what basis;
• what the buyer saw: a fifth field, if you want to measure the cost of delay.

Staffing, on a hypothetical catalog of 60,000 product pages and 25 reports a week: 15 simple ones at 20 minutes is 300 minutes, 10 hard ones at 90 minutes is 900 minutes. Together that is 20 hours a week, or half a full-time position.

It goes on work that implementation budgets almost never show. That is a number for the board.

The clock matters as much: a first response within 5 business days, a resolution within 10, and past the deadline, an escalation plus the automatic field policy. Without a deadline, the queue grows arithmetically.

25 come in, you close 18; that is 7 more a week, and after a year, 364 open cases.

Who settles a product data dispute on a marketplace?

Not the lawyer, because this is not a legal dispute. Not the seller with the longer history, because history is not evidence.

Not the seller account manager, whose goal is to bring in supply. Not the catalog team alone, whose goal is different again: complete pages.

You need one person holding two things at once: access to the documentation, and a mandate to close the case against one of the parties. Practitioners describe the argument over who fixes the page, the account manager or the catalog team, as one that never ends.

The result is a catalog where nobody owns the broken pages.

Name the person who can close a dispute over a field today and tell one of the sellers no. If you name three people, or none, you have your answer.

That is the first thing to fix, before the tool and before the vendor conversation.

What do product data disputes change about the rest of your catalog?

1. The policy for a disputed field is a product setting

Settle it before launch, because once a dispute is running, the system's default behavior chooses for you.

2. The field change log stops being an IT topic

It becomes evidence in a case, material for spotting a pattern of abuse, and the basis for justifying the sanctions in "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension".

3. Recruiting manufacturers depends on this path

A manufacturer arrives at a page somebody else wrote, often badly. Give him a route that runs on evidence, and he joins.

Make every change wait on manual work by your team, and he waits too. That is how it went in the rollouts we know, and this is the seller you wanted most.

4. Money enters once a data error ends in a refund

On a €1,000 cart at a 12% commission, the seller gets €880; the question is what happens to the remaining €120 when the fault lies with a page he did not write. Who pays for a refund, and the commission on a refunded order covers that.

5. Where the neighbouring topics live

Seven neighbouring decisions have chapters of their own: the shared page model, offer matching, ownership of fields, description quality, duplicates and merging, catalog rules, and the approval queue.

How do you check your last 10 product data reports?

Do not audit the procedure. Take the last ten data reports and walk through them with your team.

• How many can you find in a system, and how many in somebody else's inbox?
• For how many can you say what evidence settled them?
• How many days from the report to the change appearing on the storefront?
• What did the buyer see in the meantime, and did anybody choose that?
• Who signed off on the decision, and could that person say no to a bigger seller?

Four questions for the vendor, asking to see each one on screen:

1. A data error report as an object: who reported it, what evidence, who settled it, when, and on what grounds.
2. Where the policy for a disputed field is set, and what the buyer sees while the case is open.
3. The history of a single field: who entered the value, when, from what source, and how long that record survives.
4. A list of changes to shared pages broken down by seller, so the pattern is visible rather than a single edit.

Which mistakes do operators make about product data disputes?

1. A dispute with no object

Reports live in email; the decision happens in a meeting. You do not know the count, the duration, or the basis of the ruling.

When the same case returns, you start from zero.

2. One queue for three kinds of disagreement

Cases with no objective answer push back the ones where the evidence is within reach, and the outcome decides what goes in the box.

3. Seniority as the default policy

Nobody chose it, and it runs anyway: the value entered earlier wins. The effect is a lottery that looks like a rule.

4. No clock

Cases never close, and after a year you have several hundred pages carrying values nobody stands behind.

5. A reporter role with no decider role

Three people can raise the problem, and none can close it. Sellers learn that pressure works better than evidence, and the most credible ones stop reporting.

What do you still have to settle about a disputed field?

This is a method for running a dispute. It settles no question about which value is true.

It does not replace an architect or a catalog team. It shows what to ask them: where a report lives, what evidence closes it, what the buyer sees, and who holds the mandate to say no.

Three limits, stated plainly. When the disputed field is one the regulations require, this stops being a commercial dispute and calls for a conversation with a lawyer.

You need a pattern, and the judgment stays on your side. And the hierarchy of evidence does not work without access to documentation: in categories where none exists, some fields will end up flagged as unconfirmed.

Our own claim is narrower and independent of those limits: a data dispute always ends as somebody's cost, so the only question is whether that cost is decided by your rule or by your luck.

Summary: What closes a product data dispute?

Evidence, a clock, and one named person. Sort the report into one of three kinds so that arguments with no right answer stop blocking the ones that decide what goes in the box.

Rank the evidence so that a refusal is about the tier of proof rather than about the seller. Decide in advance what the page shows while the case runs, because it keeps selling either way.

Then give the queue a deadline, because twenty-five reports in and eighteen closed is seven a week, and seven a week is 364 open cases a year.

Take your last ten reports and count how many you can find in a system rather than in somebody's inbox. Building a marketplace where a data report is an object with evidence, an owner, and a deadline?

Talk to us about the build.

Frequently asked questions on marketplace product data disputes

How should a marketplace settle a product data dispute between sellers?

On evidence, ranked in tiers, and never on who is more senior or who sells more. Whoever wants a field changed supplies proof from a tier above the one the current value rests on. That lets you refuse without judging the seller and without entering a technical argument.

What should a product page show while a data dispute is open?

One of three things, chosen before the first dispute: the last value accepted as good, the value from the manufacturer's documentation, or nothing at all. Falling back to documentation only works if that value was stored separately instead of being overwritten by the first seller edit.