What is in-app bidding?

What changed

The waterfall asked networks one at a time in an order based on historical averages. In-app bidding asks all of them at once and takes the highest actual bid for that specific impression.

It is the mobile app equivalent of header bidding on the web, and it fixes the same two problems: price discovery based on real-time competition rather than history, and a single round trip instead of a sequence of them.

What it improves

• Yield. Every source prices the actual impression, so the highest willingness to pay wins rather than the highest historical average.
• Latency. One parallel auction instead of sequential calls, which improves both fill and user experience.
• Operational load. No waterfall tiers to maintain and re-rank as network performance drifts.
• Transparency. The publisher sees what every source bid, not only what the winner paid.

What it does not fix

Bidding improves price discovery among the demand you already have. It does not create demand, and a publisher with three networks bidding will not out-earn one with twelve in a waterfall purely by switching mechanism.

It also introduces its own complexity. Every participating source needs an SDK or an adapter, each of which adds weight to the app and a potential point of failure. And auction dynamics can be gamed — bid shading and inconsistent floor enforcement both exist here as they do in web programmatic.

In practice most publishers run a hybrid: a bidding auction for sources that support it, with a short waterfall beneath for those that do not.