Catalog Rules on a Marketplace: Validation Before and After Publication

A catalog rule on a marketplace is a condition on a field that decides whether an offer may be published, and the only question that matters about it is whether it can also reach the offers already live.

A catalog rule is the only tool for steering the quality of someone else's data across hundreds of thousands of offers. If it works only on the way in, your catalog splits into two eras.

The older one never ends.

This article breaks down:

• At which 3 moments can a catalog rule fire?
• Which 3 outcomes can a catalog rule have?
• Why simulate a rule before switching it on?
• What does an unenforced rule teach sellers?

Key insights

• Ask a vendor one thing: can this rule run against what is already live on the front? Some platforms simply cannot, and say so in their documentation.
• A rule can warn, take the offer down, or just count. Start with counting. It changes nothing for anybody and gives you the number you need before deciding.
• Forty warnings nobody acts on teach sellers to skip your messages. Five rules that bite are worth more, and you only get one credible first attempt.

What separates a catalog rule from a gate?

A gate polices what comes in. A rule polices what is there.

The difference is invisible on deployment day, because from then on everything that comes in meets the requirement. It turns decisive the day you change your mind.

You add a field, or raise the bar.

Run the numbers on your own catalog. Assume 400,000 active offers and 5,000 new ones a month.

You switch on a requirement for one field. A year later, the catalog holds 460,000 offers, and 60,000 of them came through the gate.

The sentence "every new offer has this field" is true, and it covers 13% of the catalog. The other 87% keep selling and never meet that gate, because it stands on a road those offers already drove down.

The market splits into two classes here and does not say so out loud. In some products, the rule physically cannot reach a published catalog.

The vendor writes in the documentation that a new rule cannot be applied to existing products. In others, it reaches, with an effect you choose deliberately.

That is the line between a configuration change and a migration project, and one question separates them: can the rule run against what is already live on the front.

At which 3 moments can a catalog rule fire?

Instead of asking "do you have validation", ask about three moments. Each repairs a different part of the catalog, and none substitutes for the others.

1. At publication

The seller adds an offer, the form or the import refuses it, and they get an error message.

The cheapest layer, and the best covered on the market. It repairs the future and nothing else.

2. On every change to an offer

It works retroactively, but the pace is set by someone else's price list: an offer comes back for validation only when the seller touches it.

Say your sellers modified 120,000 offers out of 400,000 over a year. That does not mean you covered 30% of the catalog.

It means 280,000 offers never got a single edit, and the whole tail sits in there.

3. In bulk, against the live catalog

The only way to reach what is already standing.

Usually an asynchronous operation: the recalculation runs in the background, and for a while the filters still show the state from before. Worth knowing, because the first reflex after switching on a rule that "did nothing" is to switch it off.

4. The change to the configuration itself

Flipping an attribute from optional to required is sometimes an event with no consequences until somebody manually starts the recalculation.

Until then, two truths about the same field hold in your catalog.

Which 3 outcomes can a catalog rule have?

What a rule does on firing is a business decision. A rule that pulls offers off the front looks like an outage in the next day's sales report, so switching it on unprepared ends with the rule being withdrawn.

And nobody will let you switch it on a second time.

The third outcome gets lost in these conversations, and it matters most at the start: flag and count, and change nothing. Measurement mode changes nothing for the buyer or the seller, and it hands you the one number you need before you decide.

The pattern is proven outside marketplaces. In large sales channels, the severity level is an explicit property of the rule: one class stops the product from being shown, a second leaves it visible but lowers its results and announces a block to come, a third is only a suggestion.

Registries of data exchange standards add a ramp on top: a rule arrives as a warning and becomes blocking in the next release.

There is a fourth outcome you do not want at all. At least one product in this class has a pricing rule that does not deactivate offers below a threshold.

It deletes them. You cannot undo a deletion with a toggle.

Why simulate a catalog rule before switching it on?

No rule goes live without an answer to one question: how many offers will it cover, and whose offers are they? The answer has to be a number from before you switch it on.

An example worth reproducing on your own data. The rule requires one field in two categories.

Its scope holds 90,000 offers, and 26,000 offers from 310 sellers break it: 29% of the scope. Among them, the ones that rotate (sold at least once in the last 90 days) number 4,000, or 15%.

The interesting part sits elsewhere: 12 sellers account for 18,000 of those offers, the remaining 298 for 8,000. Twelve conversations close two-thirds of the problem, so 26,000 offers are not a migration.

They are twelve phone calls and one email campaign. You cannot guess that conclusion.

It falls out of the distribution.

The same number tells you what haste costs. Go straight to "take down," and 26,000 offers vanish from the front: 22,000 are debt nobody was buying, 4,000 are assortment that earns money today.

With a €1,000 cart and a 12% commission, every order you no longer fulfill is €120 of commission. That is the number that reaches the board.

Call this what your IT team calls it: a dry run. The request goes through full validation, returns a result, and persists nothing.

In infrastructure systems, this is a standard API feature. If the vendor lacks it, the second-best answer comes from software rollout practice: a partial, time-boxed launch plus an assessment of the result.

One category: a measurement, then a wider scope.

Ask for a simulation of a catalog rule specifically. In the products we know, a preview of the effects lives more often in the seller quality layer (which sellers the new thresholds will suspend) than in the catalog, and that is exactly what the demo will show you.

Why does an offer pass in March and fail in May?

A rule always has a scope, even when you never set one. In that case, the scope is everything.

Requirements are local by nature: a field that makes sense in food makes no sense in car parts, and some requirements differ between countries within one category. Scope has four axes: category (usually with inheritance downward, so a product in a subcategory has to satisfy the parent rule and the child rule), brand, seller, country.

A rule also has a dated version. Without one you cannot answer the seller's most common question.

"Why did this offer pass in March, and an identical one fails in May" is a question about the history of the rule. Registries of data exchange standards have done this for years: dated releases, an effective date, and an explicit record that the rule arrived as a warning and was tightened in the next release.

You need the same at a smaller scale: who, when, and what the previous value was.

A trap from real rollouts. In some products a rule narrowed to a category cannot be edited.

You have to delete it and create a new one. You lose the history, and the creation date of the new rule lies about when the requirement started to apply.

When a seller appeals, you stand with no evidence, and the right to a statement of reasons is covered by "P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension".

Who gets to write rules. Not IT, because this is not a technical change.

It is a change to the commercial terms for every seller at once. And not a single category manager, because a rule is a commitment of the whole platform.

A practical arrangement puts the owner at the level of the commission grid and requires two approvals before launch. One comes from category, the other from seller operations.

And the thing that surprises people in year two. In the rollouts we know, rules live in two engines: some in the platform, some in the product data system.

The seller then gets two rejections, at two moments, in two languages.

What does an unenforced catalog rule teach sellers?

Five rules that bite beat forty warnings that touch nobody. A warning without consequences is a lesson: the messages from this platform can be skipped.

When the rule that has to work arrives, you will pay a quarter of explaining for credibility already spent on warnings.

Hang this on a single metric: the share of offers that break the rule, as a percentage of the offers in its scope. Not "the share of new offers that comply".

That measures a gate and will always come out at 100%. You start at 29%.

If a quarter later, in warning mode, you are at 27%, the pace is 2 percentage points per quarter, and getting to 5% takes twelve quarters, which is three years. A metric that does not fall is information about you.

It tells you about the strength of the outcome, the clarity of the message, or a requirement nobody can meet.

Practitioners keep repeating one thing: you get exactly what you require. A rule that says "description longer than 300 characters" produces descriptions 301 characters long.

It polices form, and it will never replace a decision about what the content should say. That decision is "Product Data Quality on a Marketplace: What You Can Enforce".

What do catalog rules change about the rest of your catalog?

1. A rule is an instrument of catalog policy

It has an owner, a version, a scope, a message to the seller, and a metric. Without any one of those five, you have a validator.

2. A rule is deterministic; approval is discretionary

Everything expressible as a condition on a field should disappear from the human queue. That is the only way to stop the queue from the approval queue from becoming the speed limit of the entire marketplace.

3. A rule stands on structure and will not repair it

Categories and attributes are the category tree.

And a requirement for an identifier produces duplicates without matching from offer matching and the merging from duplicates and merging.

4. Where a permission or a clean-up programme belongs

Regulated categories are gated by a seller permission, which is restricted and prohibited products. Cleaning up what is already broken has its own owner and budget, and that is catalog debt. And if the rule is forced on you by a change in the law, it is a project with a deadline, a ceiling on the turnover you switch off, and phases.

How do you run one catalog rule through a full cycle?

Do not audit a feature list. Run one rule through a full cycle on your own catalog.

1. Pick one field and two categories. Narrow scope, clear requirement.
2. Demand the numbers before you switch anything on: how many offers are in scope, how many break the rule, how many sellers, how many of those offers rotate, and how they spread across sellers. If nobody can count that, you have no simulation. That finding matters more than the rule itself.
3. Switch it on in measurement or warning mode, for one category, for 30 days. The message to sellers goes out the same day, with the date the rule will be tightened.
4. Measure the drop. If there is none, either the message did not land, or the requirement cannot be met. Find out which before you tighten anything.
5. Only then take offers down, with the rule version recorded and the list of affected offers frozen as a snapshot.

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

1. Run a rule against a published catalog, and show whether it flags offers or takes them down. Show me whether the outcome is mine to choose.
2. Show the number of affected offers and sellers before the rule is saved, in the catalog itself.
3. Flip an attribute from optional to required and show what happened to the existing offers, and who starts the recalculation.
4. Show the history of a rule and tell me whether it can be edited without being deleted, and whether any rule erases data instead of changing a status.

Which mistakes do operators make about catalog rules?

1. A gate called a rule

You report compliance on the way in, and two years later most of your catalog has never passed through any requirement. You will hear about it from outside: from a regulator, a large brand, or an integrator.

2. Switching on "take down" mode without a simulation

The next morning, the sales report shows a drop, and the rule goes back on the "worth thinking about" list for a year. The cost is the lost turnover, and on top of it the right to a second attempt.

3. Forty warnings, zero consequences

Sellers learn that the platform's messages are decoration. The rule that has to work arrives in an environment with a practiced reflex of ignoring them.

4. A rule with no scope and no version

A requirement from food lands on car parts, and when a seller appeals, you cannot prove when it started to apply. In that conversation, a decision with no trace never happened.

5. A rule written by one person

The requirement shows up in the system, but not in the seller documents you sign with a seller and not in any message. The effect: hundreds of support tickets, and sellers who learn about the change from an error screen.

What do you still have to settle about your own rules?

This describes what a rules engine can do and how to switch it on safely. Four things stay outside that boundary.

How many rules are the right number, and how high to set the bar. It depends on the category, and on whether you compete on breadth of assortment or quality of the product page.

What exactly to require from descriptions, images, and attributes. A rule is a tool for carrying out the requirement.

Where the validation should sit: in the platform, in the product data system, or in both. That is an architectural question.

Our only claim is that the seller has to receive one coherent message.

Whether a non-compliant offer may stay online in warning mode when the missing field comes from a regulation and not from your own quality policy. That is a question for a lawyer, and the only place where measurement mode may not be available.

Summary: What makes a catalog rule work?

Reach, a chosen outcome, and a number you had before you switched it on. Reach decides whether the rule is a rule at all, because one that fires only at publication leaves your catalog split into two eras, and the older one never ends.

The outcome decides what the next morning's sales report looks like, which is why counting comes before warning and warning comes before taking anything down. And the simulation decides whether you are looking at a migration or at twelve phone calls, because the distribution across sellers almost never matches the total.

Pick one field and two categories, and demand the affected offer and seller counts before anything is saved. Building a marketplace where a new requirement can walk the catalog that is already published?

Talk to us about the build.

Frequently asked questions on marketplace catalog rules

What is a catalog rule on a marketplace?

A condition on a field that decides whether an offer may be published or stay published. It carries five things: an owner, a version with a date, a scope, a message to the seller, and a metric. Missing any of them leaves you with a validator instead.

Can a catalog rule apply to offers that are already live?

On some platforms, yes; on others, never, and the documentation is where that is stated. Where it can, the run is usually asynchronous, so filters show the old state for a while. Expect that, or the first reflex after switching on a rule that "did nothing" is to switch it off.

Should a new catalog rule block offers straight away?

No. Start in measurement mode, move to a warning with a date attached, and only then take offers down. Going straight to a block turns the next day's sales report into an outage, and you lose both the turnover and the right to a second attempt.