First in line isn't always the highest bidder

Let’s head back to the fish market from the previous article . You’ve got a crate of fish and four buyers inside the building. There are two very different ways to sell it.

The first is to go from stall to stall. You start with the buyer who, in your experience, usually pays the most, and ask if they want it. If they say yes, it’s theirs. If they say no, you move on to the next one, and so on until somebody buys it or you run out of buyers. It’s simple and predictable, but it has an obvious flaw: the first person to say yes walks away with the crate, even if the third buyer would have paid twice as much for it that day.

The second is to step up onto a platform, show the crate to everyone at once and ask each of them to call out a price. You take the highest offer. You’re no longer relying on your memory of who tends to pay best, because every buyer tells you what that particular crate is worth to them, right now. But for this to work, everyone has to be in the room, ready to bid and clear on the rules of the auction.

In digital advertising, the first approach is called a waterfall. The second is called bidding. And, just like in plenty of real fish markets, these days the usual thing isn’t to pick one or the other, but to combine them.

This is the sixth article in our series on ad monetization. In the first we looked at how the advertising market works. In the second , which monetization model suits each product. In the third , how to place ads without ruining the experience. In the fourth , how to read the numbers. And in the fifth , what mediation is, what it’s for and when it’s worth it. That article ended with a question we deliberately left hanging:

When mediation asks several buyers, how does it decide who gets each slot?

Today we’re answering it. By the end, you should be able to explain what happens under the hood in each type of setup, why so many of them combine both models, which technical pieces can quietly cost you money and how to compare setups without being fooled by a single number.

One impression, several possible sources

What we already know about mediation

A quick recap, just the essentials. Mediation doesn’t bring in users or create ad slots. What it does is coordinate several buyers, the ad networks, so they compete for every slot your app already has. Within mediation, each of those buyers is usually called a demand source or ad source (in AdMob, literally ad source). It can be an external network or the mediation platform’s own network, as we saw with AdMob, which runs the fish market and also buys in it.

Everything we’ll cover today happens after your app has already decided that an ad fits at that moment. If the decision to show it is a bad one, no mediation model is going to fix it.

The journey of a request, in a nutshell

To follow each model we’ll use a single slot in our usual app, the one with 20,000 daily users. A user in Spain finishes a game and the app wants to show them an interstitial. It asks mediation for an ad, and mediation checks its setup, decides which sources to ask and in what order, and returns an ad, or nothing.

What changes from one model to another is exactly that middle part: who gets asked, when, and what each answer is compared against.

The figures we’ll use are round and made up. They’re there to show how the mechanism works, not as a reference for what any network actually pays. The real order and outcome depend on the platform, the inventory, the setup and what each source has available at any given moment.

Waterfall: sources get their turn one at a time

How sources are ranked and what the configured eCPM means

In a waterfall, mediation has a ranked list of sources. It asks the first one. If it has an ad, it gets the slot. If not, mediation drops down to the second, and so on, like water falling from one ledge to the next. Hence the name.

The interesting question is who decides that order. In a waterfall, sources are ranked by an assigned eCPM for each one. That value isn’t what the network is offering for this particular slot. It’s an estimate of what it usually pays on average, which in some cases you enter by hand and in others the platform works out itself from historical data. AdMob’s documentation, for instance, puts it this way: the waterfall calls sources one by one based on the average eCPM that has been configured, not on what the source is willing to pay.

That difference is the key to the whole model. Let’s say our mediation has three sources in its waterfall:

And let’s say that, for this particular user’s slot at this particular moment, Network A has an ad it would pay the equivalent of €2.50 for, while Network B has an advertiser who’d pay €5.00. What happens? Mediation asks Network A, which has an ad, so it takes the slot. Network B never even finds out the slot existed. We’ve just sold something for €2.50 that someone would have paid twice as much for.

This isn’t mediation failing. It’s doing exactly what it was told: ask in order, based on an average. And averages, by definition, get plenty of individual cases wrong.

Waterfall with three sources ranked by assigned eCPM: Network A (€4.00), Network B (€3.00) and Network C (€1.00). Mediation asks Network A first, which has an ad worth €2.50 for this slot, so it takes it. Network B, which would have paid €5.00, never gets asked. Below, a note: the order is set by a historical average, not by what each network is offering right now.

What happens when a source doesn’t respond, has no ad or can’t serve it

Each step of the waterfall can end in one of three ways, and it’s worth telling them apart:

• The source replies that it has no ad. This is the cleanest case. Mediation moves on to the next step.
• The source doesn’t reply in time. Mediation won’t wait forever: there’s a time limit, a timeout, after which it gives up on that answer and keeps going down. That time has already been spent.
• The source says yes, but the ad never gets served. For example, because its content fails to load. Depending on the platform and the format, mediation may or may not be able to try the next step, but either way time has been lost.

Notice the pattern: every “no” costs time. If Network A takes a while to say it has nothing, and then Network B takes a while to say the same, by the time Network C finally delivers its ad the user may already be in their next game. In the previous article we saw how those waits could eat up almost half of what mediation had gained. In a long waterfall, that risk grows with every step.

Strengths and limitations

The waterfall has real strengths, which is why it’s still around:

• Control. You know exactly what order sources are asked in and you can reason about it.
• Conceptual simplicity. It’s easy to explain and easy to debug: if something goes wrong, you can walk down the list step by step.
• Compatibility. Almost any network can take part in a waterfall, even if it can’t bid in real time.

And it has limitations that are just as real:

• The order is imperfect by design. It’s based on averages, and each individual slot is worth what it’s worth, not the average. We’ve already seen the result: selling cheap when someone further down the list was willing to pay more.
• Waiting times add up. Every source without an ad adds time before reaching the next one.
• It needs upkeep. Market prices shift with the season, the country or the campaign. An order that made sense in September might be out of date by December, and if the assigned values aren’t reviewed, the waterfall keeps asking in an order that no longer reflects reality.

If you had to sum it up, the waterfall trades accuracy for control: you know what it does, but it does it based on what used to happen, not on what’s happening now.

Bidding: sources compete for the opportunity

What it means for a source to bid in real time

With bidding, mediation doesn’t ask in turns. It sends the opportunity to every participating source at once, and each one responds with a bid: how much it’s willing to pay for that specific slot, at that moment, given what’s known about it (format, country, platform, consent and so on). The highest offer wins.

The difference from the waterfall is fundamental. You’re no longer comparing one historical average with another. You’re comparing real offers for this impression. If Network B has an advertiser today who’d pay €5.00 for this user, it says so, and it wins.

A quick note on terminology that clears up a lot of confusion. In the first article we saw that, inside each network, advertisers already compete against each other through auctions. Mediation bidding is another layer on top: networks compete against each other, each bringing the best it’s found internally. It’s the “competition of competitions” from the previous article , only now it happens in real time rather than in a queue.

How a bid is compared with the other participating sources

Back to our slot. Let’s say three sources take part through bidding:

Mediation receives all three bids, compares them and Network B wins. Sources that don’t have an ad simply don’t bid, so an “I’ve got nothing” no longer adds another step of waiting, because they’re all asked at the same time.

Some details vary from platform to platform, and it’s better to check them in the documentation than to take them for granted: exactly what price the winner pays, how long the auction waits for bids to come in, or what happens if the winning ad then fails to load. What matters, at our level, is the idea: each impression goes to whoever values it most at that moment, among those who are able to bid.

Bidding with three sources asked at the same time for the same slot: Network X bids €3.20, Network Y bids €2.90 and Network B bids €5.00. Mediation compares all three offers at once and Network B wins. Below, a note: sources without an ad don't bid, so they don't add extra waiting steps.

Strengths and limitations

The strengths are easy to spot in the example:

• A price that fits each impression. No more selling to whoever’s first on the list when someone else would have paid more.
• Less manual upkeep of the order. There’s no need to assign and review eCPMs for sources that bid; they set the price themselves in every auction.
• Fewer chained waits. Sources are asked in parallel, not one after another.

But bidding doesn’t come for free, and its limitations are less obvious:

• Not every source can bid. The network needs to support it, the mediation platform needs to support it too and, in many cases, you need an agreement with the network before it starts receiving requests. If a network that matters for your country or format only works through a waterfall, it won’t be in the auction.
• Technical requirements. Each network’s components need to be on compatible versions and properly initialized before ads are requested; otherwise that network won’t bid, even if it’s configured.
• Privacy and policy dependencies. To bid, a network needs information about the slot, which means it has to be listed in your consent notice and meet certain conditions. For example, AdMob currently states that bidding sources don’t serve ads in apps or requests aimed at children. If that’s your audience, bidding becomes a very different proposition.
• Less visibility into the “why”. With a waterfall, you can reason about the order. With an auction, you know who won and for how much, but you have less control over how each network decides what to bid.

Put simply, bidding trades control for accuracy: it’s better at competition, but only among those who can and know how to bid.

Waterfall and bidding together: the hybrid model

Why the same mediation setup can combine both

If bidding is better at competition, why not use bidding alone? Because, in practice, the sources you care about are rarely all in a position to bid. A network that performs really well in your second country might only work through a waterfall. Or you might have a direct deal with an advertiser that runs at a fixed price. Giving up those sources to have a “pure” auction could mean more empty slots.

That’s why the most common setup today is a hybrid model: some sources bid, others are called in a waterfall, and mediation brings them together in the same decision. It’s the term AdMob, for example, uses for this setup.

How bidding sources and waterfall calls work side by side

The exact implementation depends on the platform, but the most widespread approach, and the one AdMob’s documentation describes, works like this:

1. First, the bidding sources run their auction. A winner comes out of it, with its bid.
2. That winner is slotted into the waterfall based on the value of its bid, as if it were just another step, alongside the waterfall sources ranked by their assigned eCPM.
3. Mediation goes down the waterfall from the top. If the auction winner ends up first, it takes the slot without anyone else being asked. If a waterfall source ends up above it, that source gets asked first.

Let’s see it with our slot. In the auction, Network X bids €3.20 and Network Y bids €3.40; Network Y wins. In the waterfall we still have Network A, with an assigned eCPM of €4.00, and Network C, with €1.00. The resulting order looks like this:

Mediation asks Network A first. If it has no ad, Network Y takes the slot and Network C never even gets asked. But if Network A does have an ad, it keeps the slot, and remember what we saw earlier: its €4.00 is an average. If its ad is actually worth €2.50 for this slot, we’ve just sold for less than the firm offer Network Y had put on the table.

Hybrid mediation in two phases. In the first, Network X bids €3.20 and Network Y bids €3.40; Network Y wins. In the second, the winner is slotted into the waterfall based on its bid: Network A (assigned eCPM €4.00) first, Network Y (€3.40 bid) second and Network C (€1.00) third. If Network A has an ad, it keeps the slot even though it's only worth €2.50 for this slot; if not, Network Y wins and Network C is never asked.

What extra complexity it adds and what it doesn’t guarantee

The example shows both what the hybrid model adds and what it leaves unsolved:

• It inherits the waterfall’s problems for the waterfall sources. An assigned eCPM that’s too high can place a network above better real bids. One that’s too low leaves it with no opportunities. The assigned values still need reviewing.
• It inherits bidding’s requirements. Compatible versions, proper initialization, consent and agreements with every source that bids.
• It’s harder to read. When something changes in your revenue, it could be coming from the auction, from the waterfall or from how the two interact.

And, above all, it doesn’t guarantee you’ll earn more. A well-configured hybrid usually gets the best of both worlds; a badly configured one can end up with the worst of both. The model doesn’t decide the outcome: how it’s set up does.

Don’t confuse the model with the setup

So far we’ve been talking about models: ways of organizing competition. But you won’t find a button labelled “waterfall” or “bidding” in any platform’s dashboard. You’ll find groups, units, sources, mappings and adapters. It’s worth keeping each piece clearly separate, because this is where most people get lost.

Ad network, mediation platform and demand source

Three terms that overlap and are worth getting straight:

• Ad network: the company that buys with its advertisers’ money. We’ve met it before.
• Mediation platform: the tool that organizes the competition. AdMob, for example, offers mediation as well as being a network.
• Demand source (ad source): how the mediation platform sees each participant within its setup. The same network can show up as a bidding source, as a waterfall source or even, depending on the platform, as both at once.

In other words, “Network B” is a company, but inside your mediation setup it’s one or more sources with specific rules.

Mediation groups, ad units and mappings

An ad unit is the identifier your app uses when it requests an ad, as we saw in the first article . Each technical slot in your app points to one.

A mediation group is the set of rules that says: “for requests that meet these conditions, these are the sources that compete and this is how they do it”. The conditions are usually the format, the platform, the country and the ad units included. Our app could have one group for Android interstitials from Spain, with four sources, and another for banners in the second country, with two.

Two details that tend to catch people out, at least in AdMob:

• If a request matches several groups, only one applies, the one with the highest priority. Groups aren’t chained: if none of the sources in the chosen group has an ad, it doesn’t fall through to the next group.
• If a request doesn’t match any group, it’s handled by a default group that only uses the platform’s own network. In other words, if you make a mistake defining a group, that whole chunk of your traffic could be running without mediation and you’d never notice.

Finally, a mapping is the piece that links your ad unit to its equivalent in each external network. Every network has its own identifiers, and the mediation platform needs to know, for each unit, which identifier it should request from each network. A missing mapping, or one pointing to the wrong unit, usually shows up as a network that never wins, with no visible errors.

Adapter: what it connects and why its version matters

An adapter is a small component you add to your app so that the mediation platform’s SDK can talk to each network’s SDK. The platform “speaks” its own language; each network speaks its own. The adapter translates: it passes the request to the network, picks up its response and hands it back in a format mediation understands.

That’s why, in a setup with several networks, your app doesn’t just carry the mediator’s SDK, but also, for each external network, that network’s SDK and its adapter. And each one has its own version. If the adapter isn’t compatible with its network’s SDK version, or with the mediator’s, that network will usually fail silently: it’s in the setup, but it doesn’t bid, doesn’t serve ads or does so worse than it could.

A good habit is to treat SDK and adapter versions as a single unit: update them together, following the compatibility tables each platform publishes, and check them before releasing a new version of your app.

The operational cost of each setup

In the previous article we said that mediation adds technical and management work. Now we can see in more detail where that work is hiding.

SDK initialization and adapter loading

Before requesting the first ad, the mediator’s SDK has to initialize, and the adapters for each network along with it. If the app requests an ad before that process finishes, some networks may not take part in the first few requests. AdMob’s Android guide, for example, recommends waiting for initialization to complete before loading ads, precisely so that every network takes part from the very first request, and points out that bidding sources require that explicit initialization.

Initialization also reports the status of each adapter, along with how long it took to start up. That’s really useful information during development: an adapter that doesn’t start, or takes too long, is a network that won’t compete even though it shows up in the dashboard.

This ties in with what we saw in the third article about app open ads and preloading: the first few seconds of a session are a delicate moment, and slow initialization can hurt both revenue and experience.

Latency, timeouts, errors and ads that never get shown

Each model has its own waiting profile:

• In a waterfall, latency grows with every source that has no ad or doesn’t respond in time before reaching one that does.
• With bidding, sources are asked in parallel, but the auction doesn’t close until the bids arrive or the allotted time runs out.
• In a hybrid setup, you get both: first the auction, then whatever part of the waterfall sits above the winner.

That wait matters because users don’t sit still. With formats that get preloaded, like interstitials or rewarded ads, a bit of extra latency may go unnoticed if loading starts early enough. With formats that are requested right when they’re about to be shown, like a banner when a screen opens, every fraction of a second counts. And across all of them, an ad that’s found but never shown earns nothing. That’s the show rate metric we covered in the fourth article : the one that best exposes a setup that wins auctions but loses impressions.

A practical tweak: when a network is managed through mediation, it’s a good idea to switch off some of the features the network handles on its own in its dashboard. The classic example is automatic banner refresh: if both mediation and the network are controlling it, behavior can become unpredictable.

Updates, compatibility and reporting across SDK, mediator and network

Maintenance doesn’t end with the first integration. Networks release new versions of their SDKs; mediators, new versions of their adapters; app stores change their requirements; privacy rules evolve. With several networks, one of those pieces changes almost every month.

Then there’s reporting. Each piece reports what it sees:

• The SDK in your app knows what was requested, what loaded and what was shown.
• The mediator knows who it asked, who won and for how much, and usually offers a mediation report broken down by source.
• Each network reports what it billed, using its own criteria and, sometimes, with a delay of several days.

It’s normal for the figures not to match exactly, as we saw in the fourth article . What isn’t normal is a large, persistent gap for a specific network, because it usually points to a wrong mapping, an outdated adapter or a network that counts impressions differently. Checking those gaps regularly is part of the job of keeping a mediation setup running.

How to compare setups without being fooled by eCPM

Sooner or later you’re going to change something: move a network from the waterfall to bidding, add a new source, reorder the waterfall. And you’ll want to know whether it worked. This is where the most common trap lies.

Read revenue alongside requests, impressions, show rate and latency

eCPM is the most tempting number to look at, and on its own, the most misleading. If you drop the low-paying sources from your waterfall, the average eCPM goes up, but you might fill far fewer slots and end up earning less. If you add a network that fills cheap slots, eCPM goes down, but you might earn more overall.

That’s why, when comparing setups, you should always look at the whole picture:

A better setup is one that raises revenue per user without hurting show rate or the experience, not the one with the highest eCPM.

Compare equivalent segments: country, platform, format and period

Comparing “before” and “after” across the board mixes up too many things. The sensible approach is to compare equivalent segments: Android interstitials in Spain before and after the change, not “the whole app”. And over comparable periods. A setup change rolled out at the end of November will coincide with the seasonal price rise we mentioned in the fourth article , and it’ll be very tempting to give it credit it doesn’t deserve.

It also helps to change one thing at a time and log it, with the date, in the changelog we talked about in the metrics article . If on the same day you move one network to bidding, add another to the waterfall and update three adapters, when revenue changes you won’t know why.

Some platforms let you run A/B tests on your mediation setup, splitting traffic between two variants at the same time. It’s the cleanest way to compare, because it strips out a good deal of the seasonal noise. How to design those experiments without fooling yourself deserves an article of its own, and that’s exactly what the next one in the series will be about.

Don’t credit mediation when it was the volume or the user mix that changed

The most common mistake when evaluating mediation is not realizing that it was the traffic that changed, not the setup. If a campaign brings in lots of users from a high-paying country, the average eCPM will go up even if mediation hasn’t improved at all. If an app update means users reach the end of a level more often, there’ll be more interstitial requests and more total revenue, without the split between networks having changed one bit.

The question you should always ask is: in the same segment, with comparable volume, is each request earning more than before? If the answer is yes, the improvement probably comes from the setup. If you can’t answer it, you don’t know anything yet.

When is it worth reviewing your setup?

Signs that your waterfall is out of date or poorly ordered

• The assigned eCPMs haven’t been touched in months, and in your reports the real eCPM of some sources is drifting far away from their assigned value.
• A source near the top wins almost every impression, but with a real eCPM clearly below its assigned one.
• There are sources at the bottom that hardly ever get asked, or sources that get asked a lot and hardly ever have an ad.
• Load latency or lost ads are growing for a particular format or country.

Many platforms offer to adjust assigned eCPMs automatically based on historical data. It helps narrow the gap, but it doesn’t close it: it’s still an average.

When a bidding setup might be worth looking into

• You work with networks that support bidding on your mediation platform and are currently in your waterfall.
• Your volume is high enough for several sources to genuinely compete in your main countries and formats.
• You spend too much time keeping the waterfall in order and still suspect you’re selling cheap.
• Your product isn’t aimed at children and your consent flow is properly sorted, because whether bidding sources can take part depends on it.

When the extra complexity probably isn’t worth it

• Your app is small, with users concentrated in a country where a single network already covers your slots well. As we saw in the previous article , you might not even need mediation.
• You don’t have the time or the team to keep SDKs, adapters and mappings up to date. A poorly maintained advanced setup can perform worse than a simple, well-kept one.
• You’re not yet measuring the basics properly: requests, impressions, show rate and revenue per user. Without that, you won’t know whether the change made any difference.

Mediation organizes the competition; the outcome depends on the whole system

Back to the fish market. Going from stall to stall or putting the crate up on a platform are two ways of selling the same fish. Neither one is always better. The first gives you control and works with any buyer, but depends on your memory of who pays best still being right. The second puts a fairer price on every crate, but only among those who can and want to bid. And most real fish markets do both at the same time, with everything good and messy that comes with it.

If you only keep three ideas from this article, make them these. In a waterfall, sources are asked in order based on an average, and the first one to say yes gets the slot even if another would have paid more. With bidding, sources bid at the same time on each specific impression, but only those that meet the requirements can take part. And in a hybrid model, both approaches share the same decision, which can add up their strengths or their mistakes depending on how it’s set up.

And underneath all that sit the pieces that really decide whether the setup works: well-defined groups, properly mapped units, up-to-date adapters, correct initialization and a reading of the data that goes beyond eCPM.

But let’s not lose sight of the bigger picture of the series. Mediation decides who buys each slot; it doesn’t decide whether the slot is well placed, whether it comes at a good moment or whether the user will come back tomorrow. Everything we covered on monetization models , formats and placements and metrics still matters more than any tweak to your waterfall.

There’s one question, though, that has probably been nagging at you as you read, and that anyone with an ad-supported product runs into sooner or later. Picture opening your dashboard with everything we’ve covered fresh in your mind. You suspect your waterfall has been out of order for months, or that the network still sitting in it would do better bidding. But your current setup works, it brings in revenue you count on every month, and touching it feels a bit like a leap into the unknown. What if you change it and start earning less? What if you earn more, but not because of your change, just because December has arrived? How long would you have to wait to be sure, and how much money would you be willing to lose in the meantime?

In other words: is there a way to know whether a change would improve your revenue before rolling it out to all your users, instead of tweaking your setup blindly and keeping your fingers crossed? There is, and it isn’t about guessing or trusting your gut. It’s about letting some of your users try the change while everyone else carries on as before, and comparing both groups on a level playing field. It’s what’s known as an A/B test, and when it’s done right, it turns every doubt like this one into a decision backed by data. How to design one, what to measure and how to read the results without fooling yourself will be the topic of the next article in the series.

Happy earning!