Mercur

Omnibus Directive on a Marketplace: Price History and Honest Promotions

Law and liability~15 min
Omnibus Directive on a Marketplace: Price History and Honest Promotions

The Omnibus Directive is the EU rule that makes every discount a claim about the past, and on a marketplace, hundreds of sellers create that past while your system assembles the message.

Every "-40%" on your site is a claim about the past that you have to be able to prove. In a marketplace, hundreds of sellers create that past, and your system assembles the message, so the question lands on you.

It comes from the buyer and from the authority.

This article breaks down:

  • Which 3 units could carry a marketplace price history?
  • What must your system record before you may claim a discount?
  • Who answers for the message, you or the seller?
  • What happens when two discounts land on one offer?

Key insights

  • Every "-40%" is a claim about the past, and you have to be able to prove it.
  • The price history belongs to one seller's offer. Put it on the product page and a change of winner looks like a discount nobody gave.
  • A price has to be a list of changes. Keep it in one field, overwrite it, and what the offer cost on Wednesday is gone for good.
  • Straight after a migration you have prices and no past. Those offers can sell. They cannot say "-40%" until the history catches up.
  • The seller types the number, your page makes the claim, and the buyer asks you about it. A clause in your contract splits the cost, and answers nobody.

What is a discount in data terms?

The current price is a state: there is one of it, its owner is known, and you see it in the cart. A discount is an event and does not exist on its own.

It exists only in relation to an earlier number. That is why "are we allowed to display -40%" is the wrong question.

The right question is: what do you attach the price history to? In your own store, the unit is obvious: one product, one price, one series.

In a marketplace, it disappears. The seller sets the price; one product can carry several sellers, each with its own history, and what the buyer sees on the page is the output of your selection rule.

The legal rule is simple in intent and painful in the data. When you announce a discount, you give a reference price: the lowest price from the period before the discount.

This article deliberately does not say how long that period is. Confirm it with a lawyer, because it has exceptions and national variants.

For the system, something else matters: you need the lowest price in a range. A series, kept per offer.

Which 3 units could carry a marketplace price history?

One product, three offers: A is at €1,000, B at €940, C at €820. C wins the product page, and the buyer sees €820.

C sells out and drops off the page. B wins, and the page shows €940.

A week later, C comes back, and the page shows €820 again. The price series of the page records a fall of 12.8%, and nobody discounted anything for anyone.

What changed was the winner. A message calculated from the page's history announces a markdown that never happened, and nothing can prove it: there is no seller who made it.

The same error in the other direction is worse. A comes down from €1,000 to €900, a real discount of 10%.

The page still shows €820 from C, so nothing happens in its history. The promotion is invisible, and the seller reasonably asks what they paid for out of their margin.

One product with three offers priced €1,000, €940, and €820, tracked over three days: when the cheapest sells out the page price rises and when it returns the page price falls, so a series attached to the product page records a 12.8% markdown nobody made, while a real discount on a losing offer leaves no trace at all

There is a third answer, and it is a trap because it looks like the most honest: the history of what the buyer saw. Since the duty concerns the message shown to the buyer, let us calculate from what they had in front of them.

But that is the output of your ranking and your stock availability. A series like that measures the behavior of the algorithm.

The unit of price history is the offer of a specific seller. The other two can be useful, but you must not build a commercial message on either.

What the storefront should show when a page carries several offers belongs to the chapter on the storefront.

Three candidate units for a price history compared — the seller's offer, the product page, and what the buyer saw — across what each series measures, whether you can name who changed it, the typical false signal, whether a discount on a losing offer is visible, and what happens after the seller leaves

What must your system record before you may claim a discount?

A price has to be an event. A field overwrites the previous value: if a seller changes price three times a week, on Friday you do not know what it was on Wednesday, and you never will.

An event carries at least the offer, the amount, the currency, a timestamp with a time zone, the price type, and the change source.

A price held as a field, overwritten on every change and unable to say what an offer cost on Wednesday, set against a price held as a series with one row per change, carrying the offer, amount, currency, timestamp with time zone, price type, and source of the change

The time zone is not pedantry. If the seller sits in a different zone from your server and your market, the boundary of the day (and therefore of the reference period) moves by hours.

On one offer, a curiosity. On forty thousand, a systematic error in one direction.

You have to keep price types apart, because not everything belongs in the same series. Base price, promotional price, volume price, logged-in price, B2B segment price, and loyalty price are six different things.

The rules carve out some genuinely individual discounts, but they do not carve out a discount called individual that everybody gets. Confirm this with a lawyer before marketing names a campaign "an offer just for you."

Retention has to be longer than the period the rules require. They tell you where the reference price comes from.

They do not tell you how long you have to be able to prove it. And proof is sometimes needed months later.

The strongest conclusion concerns migration: you have no history, so you may not claim anything. Move a catalog from another platform and forty thousand offers arrive with an empty series.

The current prices are there. The past is not.

For as many days as the reference period lasts, you will not calculate a reference price for any of those offers. And that is exactly the week marketing has the opening campaign scheduled, because traffic is at its highest.

The answer here is engineering: promotional silence on offers with no cover in the history, enforced by a gate in the system. Such an offer can sell.

It just cannot carry a message about a discount. You may load history from the previous platform if you can show where it came from, and only during the migration, never after.

Practitioners observe that some platforms cannot enforce a new rule on an already published catalog: validation catches new offers while old ones live on with an empty field. Here you do not have that luxury.

A missing series cannot be worked around. It can only be waited out.

What a catalog migration does to price history: current prices arrive and the past does not, so for the length of the reference period the offers sell while carrying no discount message, until the series finally covers the period

Who answers for the discount message – you or the seller?

The seller supplies the number, you design the rule, the buyer reads the message in your interface. Data sits in the first layer, the decision in the second, the effect in the third, and the question is about the third.

The duty to announce a discount sits with whoever sells. But the rules on unfair commercial practices reach wider: a platform answers for its own practices toward the buyer, and the definition of a trader covers anyone acting in the name of or for another trader.

If your rule assembles the sentence "-40%", it is your message, even though the input number is somebody else's. Where the line runs in your model is a question for a lawyer ("Marketplace Liability: Are You an Intermediary or a Seller?").

"The seller typed it in" is a settlement between you and the seller. A contractual recourse recovers the cost.

It does not remove the question. A contract is a tool for splitting costs ("Marketplace Seller Agreement and Terms: Which Documents Do You Need?").

Three layers behind a discount message — the seller supplies the number, your rule assembles the "-40%", the buyer reads it in your interface — with the two mechanisms that keep it honest: an entry gate that blocks a message with no cover in the series, and a recurring divergence report

You need two mechanisms in the system. The first is an entry gate: an offer whose declared reference price has no cover in the series does not publish a discount message.

The second is a divergence report: a recurring comparison of seller declarations against what the system recorded. Practitioners treat it as the cheapest control they have: verifying nine hundred promotions a week by hand is not a process.

It is a wish.

Design the sanction separately: you take away the right to a promotional message and leave the right to sell. Suspending sales over an error in a reference price is disproportionate.

"P2B Regulation on a Marketplace: Ranking, Terms Changes, and Suspension" describes your duties toward a seller in decisions of that kind.

What happens when two discounts land on one marketplace offer?

The seller comes down from €1,000 to €900. You add a category campaign of minus 10%.

The buyer pays €810. Your system needs one answer: what the message is calculated from.

There are three candidates. From €1,000, which gives -19%.

From €900, which gives -10%. Or from €850, because that is what this offer cost two weeks ago in the previous campaign.

In that last case, the only defensible message is -4.7%, even though the campaign was configured as "-19%". The rule of the lowest price in the period points to the third, which means the message is calculated from the series.

The same series governs claims like "best price" and graphic call-outs. If they emphasize a price benefit, they have to refer to the same reference price.

Two discounts on one offer and three possible percentages: -19% from the list price, -10% from the price before the campaign, or -4.7% from the lowest price in the period, which is the only defensible one, plus the three safeguards that keep the combination under control

A message nobody designed is what you get when nobody owns the whole. The seller writes the seller's rule, your marketing writes the category rule, the engine decides the stacking order, and the storefront template assembles the sentence.

Four decisions, no owner of the result. Stacking makes it worse: combining promotions without a limit can slide to zero and produce a free cart.

That is a known failure mode, so a default of "they do not stack, the best one wins" is a safer start than flexibility.

There are three safeguards, and all are cheap at the beginning: one layer calculates the final price and the message; a price floor per offer; an explicit decision about what the system shows when the combination breaks that floor.

Who funded the discount does not change what the buyer sees. A discount out of your own pocket is, toward them, a reduction in the price of that offer, and it enters its series exactly like a discount from the seller.

Who pays, and how that affects the commission, is covered by "How Marketplace Split Payments Work and Who Pays the Fees?" and the chapter on promotions.

What must a marketplace label about paid placements?

Price history is about how much something costs. Labeling paid placements is about why it is here.

If an offer stands higher because somebody paid, the buyer has to see it. Separately, they have a right to know which main parameters decide the order.

There is one product consequence: "this placement is paid" has to come back in the response to a listing query. Operators discover this at their first retail media campaign: monetization is ready, and the labeling needs a change to the API contract.

What does the Omnibus directive change about your platform?

1. You order the data schema together with the pricing model

Price as a series of events per offer is an architectural decision you make once; almost everything else in this article can be changed later.

2. The launch plan gets a new item

Promotional silence on offers with no history is part of the schedule and not an incident. Marketing has to know about it while planning the opening.

3. Refunds are calculated from the price paid

If two discounts from two different parties can land on one line, then the refund amount and the commission base have to follow from the same breakdown. "Marketplace Refunds: Who Pays for Them and Out of What?" and "Who Keeps the Marketplace Commission on a Refunded Order?" develop the thread.

4. Pricing policy toward sellers is a separate conversation

The chapter on pricing describes who sets the price and whether you may require parity.

How do you check price history with a platform vendor?

In a feature table, "promotions" and "price history" look like one line item, which is why the gap gets discovered after go-live. Ask to be shown on screen.

  1. Show me the price series of one offer on a product with three offers. Is it a series of events, or the last value with a modification date?
  2. Does the record carry a time zone and a price type? Separate base, promotional, and logged-in prices in one view.
  3. How long do you keep the history, and can it be longer? What happens to it when the offer disappears, and the seller leaves?
  4. Where does the storefront take the reference price from? Does it calculate it from the series, or read a field the seller filled in?
  5. Stack an operator promotion on a seller promotion and tell me what the percentage is calculated from, and what the system does when the combination falls below zero.
  6. What does the import do with an offer whose reference price has no cover in the history? Does it reject it, accept it silently, or publish the message?

If question 1 or 4 has no answer that can be shown on a screen, you are discussing a feature that does not exist.

Which mistakes do operators make about the Omnibus directive?

Four mistakes in marketplace price history that cannot be patched later: price kept as a field, history attached to the product page, a campaign in the launch week after a migration, and the reference price kept as a field the seller types in

1. Price as a field instead of a series of events

The only completely irreversible mistake here. An overwritten price cannot be reconstructed even from a backup, because a backup holds state.

2. History attached to the product page

A change of winner looks like a markdown and generates a message nobody made, while a real discount on a losing offer generates none.

3. A promotional campaign in the launch week after a migration

A claim with no proof, made across the whole catalog at once, at peak traffic.

4. The reference price as a field the seller types in

A stored answer where there should be a fact. Without a series, you cannot validate it, and with a series it is redundant.

5. Retention equal to the period the rules require

The question about proof arrives later than the campaign, so the proof has to outlive it.

What do you still have to settle yourself about the Omnibus directive?

This guide is a map of mechanisms, and it deliberately carries not a single date, period length, threshold or provision number. Those change faster than documents like this one.

Before you launch your first promotion, walk a lawyer through six points and ask for the answers in writing. Four of the six are inputs to your configuration:

  1. How long the period is that you take the lowest price from, and which goods are excepted from it. The team needs a number.
  2. Whether you may apply the simplified treatment on progressive discounts, and what the second and the third step of such a campaign are calculated from.
  3. Whether the party announcing the discount is you, the seller or both. And what that means for your terms and for your recourse.
  4. How to treat loyalty prices, segment prices, and genuinely individual prices, and where an individual discount ends and a campaign merely called individual begins.
  5. How long to keep the proof, and in what form it has to be reproducible on request.
  6. How to label paid placements, and how to describe the main parameters of the ordering so that the description is understandable rather than formally complete.

The families of regulation to name to your lawyer, without settling which apply to you: the rules on price information and the announcement of discounts (known in the market as the modernization directive, or Omnibus), on unfair commercial practices, on digital services in the part on advertising labels and recommender systems (in the market: DSA), on transparency in platform-to-seller relations (in the market: P2B) in the part on suspension and the statement of reasons for decisions, and on the protection of personal data wherever your audit trail records who changed a price. "Marketplace GDPR: Controller, Processor, or Joint Controller?" covers the roles.

Our claim is narrower than any of those answers and independent of them: a platform that cannot reconstruct the price of every offer for any day in the past has no right to display any percentage. That is the only part of the problem you settle on your own, before launch.

Summary: What earns you the right to display a percentage?

Being able to reconstruct the price of any offer on any past day. That means a series of events per offer rather than a field, a time zone on every record, price types kept apart, retention longer than the rule requires, and a gate that keeps a discount message off an offer whose history cannot cover it.

Ask your platform to show the price series of one offer on a product that has three. Building a marketplace that has to reconstruct any offer's price on any past day? Talk to us about the build.

Frequently asked questions on the Omnibus directive

What does the Omnibus directive require when announcing a discount?

That you state a reference price: the lowest price from a defined period before the discount. How long that period is, and which goods are excepted, has national variants – confirm both with a lawyer. What is yours to settle is whether your data can produce that number at all.

Who is responsible for a discount claim on a marketplace, the platform or the seller?

The duty to announce a discount properly sits with whoever sells, and the rules on unfair commercial practices still reach you. Your interface assembles the message, and a platform answers for its own practices toward the buyer. A clause in your seller terms splits the cost; it does not answer the buyer.

Can a marketplace run promotions right after migrating its catalog?

Not on the migrated offers, because they arrive with current prices and no history. Until the reference period has passed, those offers can sell but cannot carry a discount message. Loading history from the previous platform is possible where it is complete and verifiable.

Ready to build?

We build marketplaces that keep a price series per offer, so any past day can be reconstructed before you display a percentage.