Marketplace Compliance: Adding a Required Attribute to a Million Offers

Marketplace compliance migration is the work of bringing a catalog that is already selling up to a requirement that arrived after it was built, without switching the catalog off while you do it.

A new information requirement for products arrives with a deadline nobody negotiates with you. Your new offers meet it in a week.

A million old ones never meet it on their own. And they keep selling.

This article breaks down:

• Why does a gate on new offers fix nothing?
• Which 4 stages does a compliance migration run through?
• Who fills in the missing field?
• Who should own the migration, and with what authority?

Key insights

• A new rule arrives with a deadline. Your new offers meet it within a week. The million already on sale never will, and they keep selling.
• You control one thing: how many offers you switch off, and in which week. The deadline and the rules come from outside.
• Making the field required only stops the problem growing. Offers already published never pass that gate again.
• Blocking edits is the expensive step. It lands on the offers that sell, so a small number of offers costs a large share of sales.
• Sellers will not do this for you. Fill in whatever your own data already knows, then ask for the rest with a named list and a counter.

Why can't a marketplace stop selling while it adapts?

That is why the question "are we compliant" is useless here: it has two answers, and both are false. "Yes," because new offers pass validation, and "no," because the old ones do not.

The real answer is a number.

You have three levers, and only one is yours. The deadline comes from outside, and so does the scope of the requirement.

That leaves the third: how many offers and how much GMV you are willing to switch off to bring non-compliance to zero, and in which week. That is the only currency in this decision.

One calibration for the whole article: the catalog holds a million offers from 4,000 sellers, and the new requirement adds three mandatory fields in three categories, touching 180,000 offers from 900 sellers. Switched off on the day the requirement lands, they cost around 9% of monthly GMV.

Left alone, they are 180,000 live offers missing a field the law requires.

Weeks 0, 4, 10, and 14 below are a planning example and nothing more.

Why does a gate on new offers fix nothing?

The first reflex is always the same. Add the field and set it as required.

A good move, and a few days of work. It fixes the future only, because the gate stands at the moment of publication, and 180,000 offers are already published.

They never pass through it again.

This problem only looks like ordinary catalog debt. Misclassifying it that way is the most common error here.

Weak descriptions and empty optional attributes you can carry for years, and they have a chapter of their own. Here two things are different, and they change everything.

The clock belongs to somebody else. A conversation about catalog debt ends with the words "we will add it to the backlog." This one ends with a date you did not set.

The risk is yours, and the work is somebody else's. The seller has to fill the field in, and the offer sits on your storefront.

Practitioners at large platforms describe the same thing long after a requirement takes effect. You open a random offer, the EU responsible person field is empty, and it is selling.

Nothing blocked it, because nothing in the system had a reason to revisit an offer approved earlier.

Which 4 stages does a compliance migration run through?

A compliance migration always has the same four stages, and each needs a decision from a different person.

1. Week 0: the field becomes mandatory for new offers

The cost in GMV is zero, so it goes first. The decision taken here is not technical: does the field sit on the offer or on the product page?

On the product page, one seller fills it in once for everybody. Cheaper, and that seller is answerable for data they do not have.

On the offer, it is 180,000 entries instead of 40,000, and everybody answers for themselves.

2. Week 4: soft validation across the live catalog

The rule walks the existing offers and flags the non-compliant ones without taking them off the storefront. The seller gets a named list and a counter.

You get your first real number: until now, the 180,000 was an estimate from the database. The cost in GMV is zero.

The real cost is the attention of 900 sellers, and you cannot spend it twice in one quarter.

3. Week 10: hard validation on every change to an offer

This is where the switching off starts, and where the trap sits. Sellers change prices and stock levels every day, so if validation blocks the update, the pace of the switch-off is set by somebody else's price list and not by your schedule.

An offer nobody touches survives. A fast-moving offer, the one you earn on, disappears first.

4. Week 14: switch off whatever did not make it

Two decisions here, and both are easy to miss. Do you switch off the offer or the whole product page?

If it is the page, you pull a product off the storefront that five other sellers sell correctly. And does the seller restore the offer themselves once the field is filled in?

If not, at 15,000 offers, that is a full-time job.

The last two rows are not a mistake: stage 3 switches off three times fewer offers and four times more GMV, because it lands on the fast-moving ones. That is why the cap is counted in GMV, and why a stage without a number is not a stage.

It is an intention.

Who fills in the missing field?

The seller has no reason to move fast on this, and that is not a complaint. Their 300 offers on your platform are a fraction of their work, and three fields across 300 rows is a day nobody gives back.

A seller fills in the minimum required for publication. Since the old offer is already published, they met the minimum yesterday.

That leaves two routes.

1. Route one: you assist with data and a bulk tool

Start from what you already hold. If the same product carries five offers and one has the field filled in, you know it for the other four.

With a product identifier, you pull part of the data from outside sources. In our example, that is the difference between 180,000 and 70,000 offers left for manual work: two-thirds of the problem that sellers never even see.

For the rest, you need a per-seller list by name, a "fill this in for every offer of this brand" tool, and a coverage counter visible to the seller. Plus one uncomfortable thing.

The tool has to work in the channel where the seller works. In some markets, most offers arrive through third-party integrators.

If the field is filled in only by clicking around the panel, your campaign has missed most of the catalog.

2. Route two: you pay in GMV

You do not assist. You enforce, and you accept that more goes off.

That answer is lawful, and sometimes rational when the affected offers are a long tail with no sales. It does require somebody to approve the number in advance.

The third route, the one most companies take, is not a route. "We will send an announcement and follow up" is not a project.

It is the appearance of one: no data to help with and no consequence to force the issue. Name it the announcement-instead-of-a-tool trap and ask for the coverage counter.

No counter, no project.

One thing to settle with a lawyer before the campaign: changing what you require from sellers is a change to the terms of your relationship with them, and regulations on transparency in platform-to-seller relations set a notice period for it and a durable form of notification. There is an exception for changes that follow from a legal obligation.

Whether yours falls within it is settled by a lawyer. "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension" develops the procedure for changing terms.

Which one question checks a vendor in half a minute?

This is the most practical thing in the article, because it detects a difference that no feature list mentions.

Some platforms can validate an offer only at publication, never the catalog that is already standing. A rule switched on today touches nothing approved yesterday, and there is no toggle for it, because the mechanism does not exist.

Others can walk the live catalog and produce an explicit outcome: a warning, or removal from the storefront. That difference decides whether stages 2 to 4 are configuration or a migration project at your cost.

Ask it like this: "On the demo, switch on a new mandatory field in a category that already has published offers, and show me what happened to those offers. Not to the new ones."

Three follow-up questions: how many offers the rule touched and where that list is · whether the outcome is a warning or removal from the storefront, and whether I get to choose · whether it runs as a background batch or locks the panel.

Three answers that mean "we cannot do it." "The rule will fire when the seller updates the offer" is stage 3 dressed up as stage 2, so what goes off is GMV · "we will run an export, you fill it in a spreadsheet, we import it back" is a project whose price you will see later · "raise it as a ticket with our team" means the pace of your compliance is set by somebody else's backlog.

Who should own a compliance migration, and with what authority?

1. Not the technical team

The technical team delivers the field, the validation, and the report, but the decision "we switch off 4,000 offers this week" is commercial. A project parked in IT gets as far as stage 3 and stops there.

2. Not the category owner and not the lawyer

The category owner has neither the tool nor the power over the schedule, and when asked to switch off their own GMV, they answer "not now." From where they sit, they are right.

A lawyer answers what is required. A lawyer will never answer how much you are allowed to switch off.

3. The owner of the marketplace channel's result

The owner is the person accountable for the result of the whole marketplace channel, and they need exactly one authority, named explicitly in the decision: the right to switch off an offer without the category owner's consent and without the seller's consent, inside an approved GMV cap. That cap (say 2.5% of monthly GMV) gets approved once, on a single slide.

Without it, stage 4 turns into a separate negotiation with every category owner.

What does a compliance migration leave behind?

1. Build a capability that outlives this requirement

More product requirements are on the way: for products that connect to a network, and for information about repairability and the origin of materials. The capability is four reusable things: a field you can add without a system release · validation that runs on the catalog and not only at publication · a campaign with a named list, a bulk tool, and a counter · a coverage report as a standing metric.

At the first requirement, this looks like overpaying. By the third, it is obvious it was the cheapest part.

2. Field coverage joins your metrics permanently

Get the board used to the scale right away: 96% coverage sounds excellent until you work out that 4% of a million offers is 40,000 items.

3. The substance belongs to other chapters; this one is method

Product safety: "GPSR for Marketplaces: Product Safety, Traceability, and Recalls". Environmental fees and registration numbers: "Extended Producer Responsibility (EPR) for Marketplaces: Who Pays the Environmental Fee?".

Category permits and prohibitions: "Restricted and Prohibited Products on a Marketplace: The 3 Gates". Price history: "Omnibus Directive on a Marketplace: Price History and Honest Promotions".

That last one is the best proof that such a change can demand a capability nobody built before, and that a history you never recorded cannot be reconstructed at all.

4. The mechanics match the data that blocks a payout

"Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions": as long as the field is missing, something has to be held back. The only question is whether that happens by your decision or as a surprise.

How do you run a compliance migration, step by step?

The recipe is reusable. At the next requirement, you go back to step one.

1. Count the exposure before anybody talks about the deadline: how many offers, how many sellers, how much GMV, in how many categories. Without those four numbers, the conversation is about impressions.
2. Settle whether the field sits on the offer or on the product page. That decides who fills it in and how many times, which is the entire cost.
3. Close off new offers in the first week. The debt stops growing before you start paying it down.
4. Fill in automatically everything that follows from the data you already hold, then measure what is left. That number is what the decision is about.
5. Get the cap on switched-off GMV and the schedule approved once, by one person. One slide: four stages, four numbers, one date.
6. Run the campaign with a named list, a bulk tool, and a counter, in the channel where the seller works.
7. Switch off in stages, with a report after each and with self-service restoration of an offer, and leave the coverage report running.

Which mistakes do operators make in a compliance migration?

1. The announcement-instead-of-a-tool trap

Three emails and a reminder on a webinar, with no data and no consequence. Coverage climbs by a few percent, and you learn the real scale when there is no time left for stages.

2. Hard validation with no cap calculated

You switch it on Wednesday, and by Friday many times more GMV has gone off than assumed, because the block landed on the fast-moving offers. Rolling the rule back is the only option, and the quarter is gone.

3. A field added as optional "for now"

It produces a coverage report that grows by zero and the illusion of a project under way. The most expensive way to document doing nothing.

4. Switching off the product page instead of the single offer

One non-compliant offer pulls a product off the storefront that five other sellers sell correctly. The phone call comes the same day.

5. Ownership assigned to whoever holds the tool

IT holds the tool and has no mandate, so the project ends at stage 2. And it looks like a success the whole way there.

What do you still have to settle yourself before the schedule?

This guide is a migration method, and it deliberately carries no date, no threshold, and no article number. Confirm five things by name with a lawyer before you set the schedule.

1. Whether the requirement covers offers already published or only new ones, and whether there is a transition period for goods placed on the market earlier. That settles whether this article applies to you at all.
2. Who carries the duty: the seller, you, or both of you independently. That decides whether assisting with data is a courtesy or a necessity.
3. Whether an offer with an incomplete field may be sold up to the day it is switched off, and the risk in that period.
4. How and how far in advance you notify sellers about the requirement and about the sanction of switching an offer off.
5. What you do with orders already placed against an offer you are switching off.

Families of regulation for the agenda of that conversation, with no verdict on which touch your assortment: rules on consumer product safety (known in the trade as GPSR), on transparency in platform-to-seller relations (P2B), on ecodesign and the digital product passport (ESPR), on the cyber resilience of products with digital elements (CRA), on fairness in promotions (a directive known as Omnibus), on extended producer responsibility (EPR), and on energy labeling.

What nobody knows, we do not know either: how many such requirements are coming and in what order. That is why the answer lies in capability and not in one more project.

Summary: What do you control in a compliance migration?

One lever: how much GMV goes off, and in which week. Everything else is method — count the exposure before the deadline is discussed, close off new offers first, fill in automatically whatever your own data already implies, then get one person to approve the cap and the schedule on a single slide.

What you keep afterwards is the capability, because the next requirement is already being drafted.

Ask a vendor whether a rule switched on today can walk the catalog that is already published. Building a marketplace that has to survive the next required attribute? Talk to us about the build.

Frequently asked questions on a marketplace compliance migration

How do you add a required product attribute to a catalog that is already live?

In four stages, each with its own cost in GMV. Make the field mandatory for new offers, run soft validation across the live catalog to get a real number, switch to hard validation on every change, and finally switch off whatever did not make it.

Stage three is the expensive one, because it hits the offers that sell.

Why does making a field mandatory not fix the existing catalog?

Because the gate stands at publication, and those offers are already published. They never pass through it again unless somebody edits them.

That is why a platform that can only validate at publication cannot run this kind of migration at all.

Who should own a compliance migration on a marketplace?

Whoever is accountable for the result of the whole marketplace channel. Not the technical team, which has the tool and no mandate, and not the category owner, who is asked to switch off their own GMV.

The owner needs one authority stated explicitly: the right to switch an offer off without the category owner's consent and without the seller's.