Who Owns Product Data on a Marketplace?

Product data ownership on a marketplace is the rule that decides whose value stands on the page when two sources send a different one for the same field.

In a workshop, ownership of data sounds like a question about the org chart. In the system, it comes down to one rule: what happens when two sources give a different value for the same field. If nobody ever set that rule, your catalog already has an owner.

This article breaks down:

• Which 4 sources know something about the same product page?
• Why does product data ownership have to be set per field?
• Why does the same catalog correction come back three times?
• What does data provenance record for every value?

Key insights

• The owner of a field is whoever wins the next import. If nobody set that rule, your catalog already has an owner, and it is the file that arrives at three in the morning.
• Four parties each know part of one product page: the manufacturer knows the thing, the seller knows this unit, your catalog team knows the other six thousand pages, and a generator knows nothing at all.
• Locking a field protects the correction and freezes everything else about it. A locked weight will not move when the packaging changes. Give every lock a review date.
• Record four things for every value: who wrote it, when, from which source, and how sure anyone is. A value from the manufacturer's feed and a value a generator guessed must not look the same.

Who owns a product field: the person who typed it, or the last import?

Take one field and one product page. The manufacturer says the color is "graphite." The seller's feed says "black," and that feed runs every night.

The question "who owns the product data" has exactly one answer here, and it is not a person's name: the owner is the value standing on the page after the last import. If the rule says the newer entry replaces the older one, the manufacturer loses 365 times a year, and nobody notices, because every single overwrite looks like an ordinary update.

So "data owner" and "field owner" are two different objects. The first is a sentence about accountability, and it lives in the slide deck from the workshop.

The second is a merge rule, and it lives in the configuration. The gap between them is the norm: the catalog team believes the page "belongs to us," while the system runs a policy nobody chose, because it was the default.

The test that settles this in two minutes. Do not ask who owns the product page. Ask instead: show me on screen what the system does when a seller file carries a different value from the one my person typed in. If the answer is "nobody has changed that since launch," you have found your owner. It is the import.

Which 4 sources know something about the same product page?

Take a product page with thirty fields. No single party knows all of them, and that is the whole difficulty.

The manufacturer knows whatever is a property of the thing itself: technical data, dimensions, materials, photos, the data you need to demonstrate conformity. Call it sixteen fields out of thirty.

Some sales channels write this into their data specifications outright: the brand field is filled in by whoever makes the goods.

The seller knows what the manufacturer cannot know: whether the item is available, what condition this particular unit is in, how long shipping takes from their warehouse, what price they are selling at. That is around eight fields.

On part of the assortment, the seller is also the only source of anything at all, because no manufacturer ever described a piece of handmade work, a spare part, or a second-hand item.

Your catalog team knows what nobody else knows: how this page looks against six thousand similar ones. Category, unit of measure, naming convention, consistency across variants.

A system that generates content automatically will fill a dozen or more descriptive fields in two seconds and knows not one fact about the product. It is an ally on form.

It is the worst possible owner of any field where being true is what matters.

Reality is skewed. In the rollouts we know, practically every product page is built from seller data, and a seller loading a few thousand items goes for the minimum: required fields, a short description, done.

Hence the sequence that practitioners describe in almost identical words. A reseller creates the page with weak data.

A year later, the manufacturer of that same product joins the platform and cannot fix the description of its own product.

Why does product data ownership have to be set per field?

One decision per field. "The page belongs to us" does not say who sets the shipping time.

"The page belongs to the seller" does not say who fixes the category. The only thing that works is a matrix where every field carries three rulings: who may write, what happens on a conflict, whether the field can be locked.

Thirty fields times three questions is ninety rulings. In practice, twelve fields generate most of the conflicts, so the real number is thirty-six decisions.

There are four conflict policies you meet on the market, and what separates them is the kind of mistake each one makes:

• last write wins: chosen most often, because it requires no decision;
• first write wins: the oldest correct value owns the field forever;
• source ranking: every source carries a weight, and the page is merged field by field from the best entry available;
• field lock: the value is taken out of the merge, and no import touches it.

Watch the scope as well as the rule. In some products, the merge is granular, so one field loses.

In others, a single source overwrites the whole record, which means a weaker feed does not spoil the color; it swaps out the entire page. Sometimes the overwrite policy is global as well.

You allow everyone, or you block everyone. Then you cannot set anything per field.

Ask the vendor about this before you sign the contract.

A field lock has a price. It does what it promises: it protects the correction.

It also does a second thing that nobody remembers six months later. It freezes data that ought to keep updating.

A locked weight will not change when the manufacturer changes the packaging, and a locked description will not accept a new safety warning. A locked field is taken out of circulation.

That is a state that needs a review date on it.

Two fields you should never lock: the identifier and the category. They are keys rather than descriptions.

The identifier is what you match offers to a product on, and the category is what routes validation and attributes. A locked key freezes mechanics rather than content, and some systems forbid it outright. That is a good instinct.

Why does the same catalog correction come back three times?

This is a pain every operator has, and almost nobody names it. The catalog team makes forty corrections a week.

After the nightly import, thirty of them revert, because the seller feed still carries the old value and the rule says the newer entry wins. The real productivity of that team is not forty corrections a week.

It is ten. After three weeks, your report shows one hundred and twenty changes made and thirty that lasted.

The worst part of this is not the arithmetic. The correction reverts without leaving a trace, so nobody knows it came back.

Nobody finds out until the same person sees the same error for the third time. At that point they stop reporting it, because they have learned that reporting changes nothing.

Meanwhile, a false diagnosis takes hold: "the sellers are uploading garbage again." The seller uploads what the seller has. Your merge rule picked the value standing on the page.

On top of that comes the empty-field trap. Some import tools have a mode in which the file is absolute truth: whatever is not in the file disappears.

A column the seller left blank then wipes your value. "Does empty mean 'not provided' or 'clear this'" is not a technical detail.

It is the same ownership decision, asked from the side of missing data.

The organizational effect is predictable. A permanent argument starts over who is supposed to fix the page: the seller onboarding team or the catalog team.

Both sides are right. There is no field owner, so there is no owner of the correction either, and the result is a backlog running into tens of thousands of pages.

Who is obliged to clean that up and who funds it is settled by catalog debt.

What does data provenance record for every product value?

Data provenance is not one vendor's jargon. The accepted definition describes a record of the people, organizations, objects, and activities that produced or changed a given piece of data.

That record is what settles whether the information can be trusted. It also hands you a structure you can copy: who is responsible for the change, through what activity (import, manual edit, generation), what the value was derived from, and which version it is.

A whole class of metadata management systems turns this into a product. It is a standard part of data governance.

Four columns per value: who, when, from which source, with what confidence. The last one gets skipped most often and is the most useful of the four: "value from the manufacturer feed" and "value guessed by a description generator" cannot look identical in the database, because one of them is not a claim about facts.

Two hundred thousand product pages times thirty fields is six million values, so provenance gets written as a change event rather than as columns sitting next to the page.

Without provenance, three conversations cannot be settled. You cannot tell a seller why their data disappeared.

That seller has a right to a statement of reasons and to an appeal (the rules on decisions about sellers). You cannot tell an inspector where the value in a field required by regulation came from, and how many such fields apply to you is covered by product safety and recalls and restricted and prohibited products.

And you cannot tell the board whether the catalog is improving, because you are measuring changes reported rather than changes that survived the night.

When a seller leaves, the product page stays. So, often enough, do their photos and descriptions.

That is a question about a content license, and the contract settles it (the documents you sign with a seller). You can only act on that decision if you know which fields came from the seller who is leaving.

Without provenance, you hold a right you do not know how to use.

Which of the 4 precedence policies should you run?

The recommendation: source ranking by default, the lock as an exception with a review date. Thirty decisions at the start are cheap.

Three years of data sliding backwards are not.

What does field ownership change about the rest of your build?

1. The merge rule is an architectural decision

It belongs in the same conversation where you fix the source of truth for price, stock, and orders. That conversation happens before the build.

Changing the policy on a live catalog is a migration, because it touches values that already stand on the page.

2. The seller contract has to name fields

If you state that you may correct their data, say which fields and with what effect on their feed.

Onboarding gains one question along the way: not only "which columns are we mapping," but "what does an empty column do?"

3. Where the neighbouring topics live

Six neighbouring decisions have chapters of their own: the choice between a shared page and a listing per seller, duplicates of the same thing, validation rules on a published catalog, approval of a change before publication, ownership of a translation, and a dispute between two parties who both have a claim.

How do you build a product field matrix in 90 minutes?

Public product classification standards describe tens of thousands of classes and thousands of properties. Your product page has a few dozen, so you do not need a project.

You need one ninety-minute meeting.

1. List ten to fifteen fields where the arguments happen: name, description, brand, identifier, category, technical attributes, dimensions and weight, photos, compliance fields, price, availability, shipping time.
2. For each one, settle three things: who may write, what a conflict does, whether the field can be locked. Seven minutes per field, twelve fields, thirty-six rulings.
3. Write it down as a table. It is the input for the configuration and for the contract at the same time.
4. Whatever you leave unsettled already has an owner. That owner is the last file. Put it in the table openly, so nobody mistakes the absence of a decision for a decision.

Four questions for the platform vendor, each with a request to show it on screen:

1. Show me a conflict on one field: my person types a value, the import carries a different one. What does the buyer see the next morning?
2. Is precedence set per field, or only globally per source? And can a field be taken out of the merge permanently?
3. Show me the history of one value: who, when, from where. How many months back does it reach?
4. Does an empty column in the file mean "not provided" or "clear this"?

Which mistakes do operators make about product data ownership?

1. Ownership settled at the level of the page

"The page is ours" sounds like a decision and does not settle a single real conflict. The conflicts are then settled by the default rule that nobody remembers.

2. The field lock as a cure for everything

After a year, you have thousands of fields out of circulation, including ones that ought to be updating. Frozen data looks exactly like current data in the admin panel.

3. An import that does not tell "empty" from "not provided"

A seller who left a column blank deletes your value. You see the effect only when a complaint comes in.

4. Corrections with no record of provenance

You do not know they reverted, so you measure the team's work by the number of changes reported rather than the number that lasted. The report grows, the catalog does not.

5. Precedence for whoever came first rather than for whoever knows

A manufacturer joining a year after the reseller cannot fix the description of its own goods, so it stops listing. You lose two hundred offers and the best data source in the category.

What do you still have to settle with an architect?

This is a map of decisions. The order in which your systems overwrite one another (catalog, PIM, ERP, external channels) needs a diagram drawn with an architect, because it depends on how many times the same value crosses a system boundary and where somebody normalizes it.

Our role ends when you walk into that meeting with a field matrix.

We deliberately leave four things unsettled, each with a chapter of its own: the dispute process between two parties who both have a claim, the obligation to clean up broken data and who funds it, the license to seller content after the seller leaves, because that is a matter for the contract and a lawyer, and the scope of fields required by regulation for your categories.

The history of price changes runs on separate rules and sits in price history and discount messages.

Summary: What settles product data ownership on a marketplace?

A table with one row per field and three rulings in each row: who may write, what a conflict does, and whether the field can be locked. Ten to fifteen fields produce nearly all the arguments, so this is ninety minutes of work rather than a project.

Source ranking is the sane default, and the lock is an exception with a date on it. Whatever you leave unsettled is settled anyway, by the newest file, and the only difference is that nobody chose it.

Ask to be shown one conflict on screen: your person types a value, the nightly file carries another, and the buyer sees something the next morning. Building a marketplace where every value can say who wrote it, when, and from where?

Talk to us about the build.

Frequently asked questions on product data ownership

Who owns product data on a marketplace?

Whichever source your merge rule lets win, field by field. Accountability named in a workshop changes nothing on the page.

The manufacturer knows the thing, the seller knows this unit and its availability, and your catalog team knows how the page sits among the others, so ownership splits by field instead of landing on one party.

What is per-field write precedence?

A rule set for each field separately: who may write it, what happens when two sources disagree, and whether it can be taken out of the merge. Four policies are in common use: last write wins, first write wins, source ranking, and a field lock.

Ask a vendor whether precedence can be set per field at all, or only globally per source.

Why do catalog corrections keep reverting?

Because the seller's feed still carries the old value and the merge rule prefers whatever arrived most recently. The correction goes back without a trace, so the team measures changes made instead of changes that survived.

Provenance on every value is what turns that into a number you can act on.