Buy Box Algorithm: How a Marketplace Picks the Winning Offer

The buy box algorithm on a marketplace is the rule that decides which seller's offer sits under the buy button on a shared product page, and it hands out revenue among your sellers every day.

A product page with five offers has one buy button. The rule that decides whose offer sits under it hands out revenue among your sellers every single day.

Most operators cannot say what it decides by.

If you are looking for what a buy box is and how it behaves for a buyer, that is covered in our guide to the marketplace buy box. This chapter is about the rule underneath it: what you weigh, how you settle a tie, and what the page does when nobody qualifies.

This article breaks down:

• Which 5 parameters decide the buy box?
• How should a marketplace settle a tie?
• What shows when no offer wins?
• How does a marketplace favour its own offers?

Key insights

• The five parameters that decide the buy box are: total price with delivery, shipping time, service quality, page completeness, and availability.
• To settle a tie, pick one method: rotate the winner between offers that tie exactly, take the oldest offer, use the higher quality score, or split the exposure.
• When no offer wins, show the reason and a next step: that the item is out of stock or the seller is suspended, plus somewhere useful to go, instead of a button that does nothing.
• A marketplace favours its own offers by weighting what describes its own operating model, such as same-day delivery and returns in store, so measure the share of your offers among the winners against their share of the supply.

Why does the buy box hand out your sellers' revenue?

One button on a page with five offers means the choice has been made for the buyer and for four sellers. The buyer gets a decision they never asked for. Four sellers get nothing.

The canonical example of this series: a €1,000 cart at a 12% commission. You take €120, the winner takes €880, the other four take €0 each.

Your commission is identical no matter who won, and for a seller the difference is everything or nothing. That is why a bad rule is felt by every seller and by nobody inside your company.

The revenue adds up, and the signal comes back as sellers leaving.

This is not a sort order setting. It is commercial policy written into code.

Most of the time, nobody wrote it on purpose. It appears as "sort by price ascending" in the storefront layer, in the week the product page had to ship, and it stays for years as the answer to the question of who you favor.

One precondition: the offers have to be structural siblings on a single page. If every seller has a listing of their own on your site, there is nothing to settle.

Is the buy box an auction or a machine for settling ties?

The picture everyone carries around is false: twenty sellers underbid one another, and the algorithm collects the lowest price. In practice, the choice usually comes down to two or three offers.

Tellingly, in the loudest antitrust case in this layer, the remedy was not "show every offer." It was to show the second competing offer: the real competition on a page comes from that one, the second.

The consequence resets the whole conversation about weights. Take four offers of the same product, all of them shipping in two days: A at €1,000 with free delivery, B at €979 plus €29 delivery, C at €1,000 with free delivery, D at €1,180.

A rule built on the price of the goods hands the win to B. A rule built on the total price produces a tie between A and C at €1,000, and B loses by €8 even though its goods are €21 cheaper.

D loses by €180, and no realistic quality coefficient reverses that.

So: the value of this layer sits in settling ties and in controlling the preference given to your own offers, rather than in squeezing price out of twenty sellers. A weight matters only where it changes the winner.

A team that spends weeks calibrating how to weigh €1,000 against €1,180 is solving a problem it does not have. The case that hands out money every day is €1,000 against €1,000.

Which 5 parameters decide the buy box, and who do they shut out?

1. Total price, meaning price with delivery

It rewards sellers with cheap logistics and a free shipping threshold. It shuts out the ones whose goods are cheaper but whose parcel costs more.

What enters the rule is the amount due. How to show it is "Showing Prices on a Marketplace: How to Keep Offers Comparable".

2. Shipping time

It rewards your own warehouse and a fast courier. It shuts out, structurally, the seller on dropship and the seller abroad, whatever their price and however careful they are. The delivery promise made to the buyer is the delivery date you promise.

3. Service quality

Cancellations, returns, response time to a message, all counted inside a time window. It rewards the large sellers because their volume is stable.

It shuts out new sellers in a way nobody plans for: a seller with zero transactions in a 30-day window has either the worst score or the best one. Which of the two it is depends on whether you count missing data as a zero or as the average.

That is why the rule needs a volume threshold: below, say, 20 orders in a 90-day window, an offer competes on price and time alone.

4. Page completeness

It rewards whoever filled in the fields, and it is the only lever you have for getting sellers to write decent descriptions (what you can enforce on content and catalog rules).

5. Availability

This is a condition of entry rather than a weight. It is also the place where the rule fails quietly.

The winner has 100 units, the buyer wants 300, the page holds three hundred units across three offers, and the purchase does not go through. The rule picks one winner, and the decision on whether you take the missing 200 units from the next offer is yours (a cart with several sellers).

On top of that comes a cross-cutting decision: one rule for the whole platform, or one rule per category. In the implementations, we know it is usually global, even though in electronics the winner is decided on price and in bulky goods on the date.

The ordering between products is a different machine (search and filtering).

How should a marketplace settle a tie between two offers?

Two offers, identical total price, identical shipping time, both sellers beyond reproach. This is the most common case in a repeatable assortment.

Every way of settling it is a decision about distributing revenue. Assume 60 purchases a month on this page at €1,000 each and a 12% commission.

Rotation gives you fairness and takes away predictability. Determinism does the opposite.

A seller who does not know when they will win cannot plan stock or price. There is also a technical trap: rotate on exact ties only.

Rotating between offers at different prices changes the amount under the button in the middle of a buyer's session: the price jumps with no markdown behind it and no author (price history and discount messages).

The important part: in every variant your commission is the same €7,200, while one seller's payout is either €52,800 or €0. That is why neither finance nor the board will ever raise this decision.

If you do not raise it, the default sort order makes it for you.

What should a product page show when no offer wins?

A page that shows only the winner is cheaper to build, and it kills the mechanism the shared page exists for. Do the arithmetic: 3,000 pages with an average of three offers each is 9,000 offers, of which 6,000 get no exposure at all, and you pay for matching them, moderating them, and syncing their stock.

An invoice for a machine you never switched on.

A collapsed list saying "other offers from €1,008" is better than nothing, though practitioners observe that buyers rarely expand it. The bar came out of an antitrust case: the second competing offer should be visible next to the winner, with the same description and the same path to purchase, if it differs on price or on delivery.

That is not a rule that binds you. It is a ready-made definition of what "visible" means.

Settle separately what the page shows when nobody wins: no offer has stock, the seller is suspended, or a field the rule requires is missing. The page then has four states: buyable; unavailable with an explanation and an alternative; unavailable with no explanation; and invisible.

The third one is the worst. A dead button does not tell the buyer whether this is an outage or an item out of stock, so the buyer retries, calls, or leaves convinced the site is broken.

Assume 12,000 pages and 3% of them in that state: 360 pages look broken.

This is the warning of this article: a rule with no default state. Teams design who wins.

Almost nobody designs what happens when nobody qualifies. The answer then comes from a storefront template rendering an empty list.

There is a side effect that is easy to forget: a quality threshold is at the same time a rule for switching sales off. You raise the requirement, some pages lose every candidate and stop selling.

Whether your platform recalculates a new rule across an already published catalog is something to check in catalog rules.

How does a marketplace end up favouring its own offers?

Nobody types a rule saying "our offer wins" into the system. The preference arrives through weights that describe your own operating model: same-day delivery, returns in store, a cancellation rate computed from your own warehouse.

Every one of those parameters is honest as value for the buyer, and every one of them is structurally out of reach for a seller shipping from a different warehouse.

In that same antitrust case, the charge was that the criteria for picking the winner privileged the platform's own retail business and the sellers using its logistics. The commitment that closed it: treat all sellers equally when ranking offers.

For the largest platforms, favoring your own products in a ranking is now prohibited outright.

Measure it with one number, because intuition does not work here. Take your mixed categories: 12,000 pages, 20,000 offers, 3,000 of them yours, so 15% of the supply.

If your offers win 4,200 pages, that is 35% of the pages. You are winning 2.3 times more often than your share of supply would predict.

The number on its own is not an accusation, since a page can be won on merit. It is still the only number you will show your board, your sellers, and a regulator.

The duty to disclose ranking parameters to sellers is the rule on decisions about sellers.

What does a platform vendor leave you to build yourself?

This is a fact about the market. In part of the solutions in this class, choosing the winning offer has neither a field in the data model nor an endpoint in the API.

What ships instead is a sample storefront implementation to copy. It gets worse: a data model that does not separate the product from the offer rules lays this layer out by definition (the catalog model).

Practitioners confirm the same thing. Every team designs the weights from scratch and discovers the subject halfway through the implementation.

The conclusion is expensive: this is your code, your responsibility, and a budget line that appears in no feature matrix. Name it in the estimate as four parts: the rule, the panel that configures it, the record of "why this offer won this page," and the screen for the losing offers.

What does the buy box rule change about the rest of your build?

1. The rule is a contract with your sellers so it needs versions

Changing a weight reshuffles winners across thousands of pages while the published description stays the same. Version the configuration with an effective date, together with the description (the rules on decisions about sellers).

2. Without a trace you cannot answer the first question you will hear

"Why did I lose that page yesterday?" needs a record of what the rule produced as well as how it was set, and adding that a year later is impossible, because the past data does not exist.

3. Per-seller commission starts to collide with the rule

With different rates, picking the winner changes your own revenue on the same transaction, so the rule stops being financially neutral. Settle that openly, before somebody proposes a "margin weight." Separately: disclosing who the seller is remains a duty independent of who wins the page (showing who the seller is).

How do you check a buy box rule with a vendor?

Six questions for the vendor, answered on screen rather than on a slide.

1. Show us a page with three offers and tell us why this one won. If the answer is "because it is the cheapest," ask about the total price with delivery.
2. Where do I configure the weights, and can I set them differently for two categories?
3. What does the system do on an exact tie, and which of the four variants from the table is the default?
4. Show us a page where no offer qualifies. What does the buyer see, and where does that message come from?
5. How do I answer a seller who asks why they lost a page last Tuesday? Is the output of the rule stored, or only recalculated on demand?
6. What is the share of your own offers among the winners in mixed categories, and will you show it in a report without an analyst doing the work?

No answer to question 1 or question 5 means you are not buying this layer. You are buying the place where you will write it yourselves.

Which mistakes do operators make about the buy box?

1. The winner picked by a storefront sort order

The choice of winner lives in a page template rather than in a layer with configuration and history. Consequence: changing commercial policy takes a code release, and you will never answer the question "why did I lose?"

2. Weights calibrated on the extremes, with no tie defined

Coefficients tuned to settle €1,000 against €1,180, with no tie defined at all. Consequence: the most common case on a page gets settled by the order of rows in a database.

3. A quality score with no volume threshold

A new seller gets a score computed from zero transactions. Consequence: either they never win their first page, or they win hundreds of them on an empty statistic.

4. A preference for your own offers discovered from outside

Nobody measures the share of your own offers among the winners, so the first person to count it is a seller or a journalist. Consequence: the conversation about trust starts from a number you do not know.

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

This chapter does not give you weights, because there are no good weights: there are only weights that match your commercial policy, measured by their effects.

It does not settle whether you have a shared product page at all (the catalog model), how to show the price (showing the price), how to order products against one another (search and filtering), or what duties you have toward the sellers whose offers lose (the rules on decisions about sellers).

Three things are worth confirming with a specialist, because they touch on law:

• whether your description of the ranking parameters is sufficient
• whether you may treat your own offers differently from seller offers
• how to label exposure that somebody paid for

The families of regulations to name to your lawyer, without settling which of them apply to you:

• regulations on transparency in platform-to-seller relations, known in the market as P2B, in the part on ranking parameters and on differentiated treatment of your own offers
• regulations on digital markets, known in the market as DMA, where favouring your own products in a ranking is prohibited outright
• competition law, if your position in a category is strong

Our thesis is narrower and independent of those answers: an operator who cannot say in one sentence what decides the winner of a page, and point to the record that reconstructs it, does not have a rule. What they have is the side effect of somebody else's technical decision.

Summary: What decides the winner of a product page?

Whatever you weighed, plus whatever the storefront decided for you in the week the page shipped. Five things are worth weighing, and each one shuts somebody out: total price with delivery, shipping time, service quality, page completeness, and availability as a condition rather than a score.

The case that hands out the money is the tie, because in a repeatable assortment two offers at the same total price is the common state, and every way of breaking it is a decision about who earns. Then there is the state nobody designs: the page where no offer qualifies and the button is dead.

Ask a vendor to open one page with three offers and say why that one won. Building a marketplace where the rule that picks the winner has weights, versions, and a record you can show a seller?

Talk to us about the build.

Frequently asked questions on the buy box algorithm

What is a buy box algorithm on a marketplace?

A buy box algorithm is the rule that decides which seller's offer sits under the buy button when several sellers share one product page. It usually weighs total price with delivery, shipping time, service quality, and page completeness, with availability as a condition of entry rather than a score.

How should a marketplace break a tie between two offers?

A marketplace should break a tie deliberately, and only when the offers tie exactly: rotate the winner, take the oldest offer, use the higher quality score, or split the exposure, and record which rule fired. Rotating between offers at different prices changes the amount under the button mid-session, which reads as a price change nobody made.

How do you tell whether a marketplace favours its own offers?

You tell whether a marketplace favours its own offers by counting the share of your own offers among the winners, against their share of the supply. If your offers are 15% of the supply in mixed categories, the share of wins is the number to watch. Nobody types a preference into the system, so it arrives through weights that describe how you operate.