Waterfall to In-App Bidding Migration, Split-Tested

A sixty line-item waterfall adds somewhere between 400 and 900 milliseconds to the first ad request of a session, and that latency costs more impressions than the migration is likely to win back in price. That is the honest case for in-app bidding. The revenue case is low single digits on most apps. Anyone quoting twenty percent is quoting a case study from an app that had a badly built waterfall, which may or may not describe yours. How we run it: Never as a cutover. The migration runs as a user-level split in MAX A/B testing, half the traffic on the existing waterfall and half on the bidding configuration, for a minimum of three weeks so that weekend and mid-month pricing land in both arms. We size the test against your daily actives before starting and tell you if your traffic cannot resolve a five percent difference. On many of the apps we see it cannot, and then the decision gets made on latency and operating cost instead, which is a legitimate way to decide it. Hybrid, not purity: Almost no app should end on bidding alone. Italian demand in particular still arrives partly through network-sold and direct inventory with no bidder behind it, so the target configuration is usually the bidders plus a short floor-based tail of three to five line items, kept because they price above the bidders in that market and deleted the month they stop. The tail stays short enough that one person can hold it in their head. Reading the numbers during a migration: eCPM moves for reasons that have nothing to do with price. Bidding revenue reports net where several waterfall networks reported gross. Impression counts change once cascade timeouts stop discarding requests. A network's dashboard and the mediation's figures will differ by a few percent, and both will differ from your impression-level data. We reconcile all three before the test starts, so the argument at the end is about the result rather than the source. Revenue per daily active user decides it; eCPM is a diagnostic, not a verdict. Rollback: Written before release with named thresholds: latency at p95, fill in your two largest markets, revenue per daily active user, and crash-free sessions. If a threshold breaks, the configuration reverts the same day and we go back to diagnosis. We have rolled two migrations back and both went back for latency, not revenue. Timing: We do not migrate between the second week of November and the first week of January. Q4 pricing flatters whatever configuration happens to be running, and January's drop then reads as the migration's fault. If your quarter closes in December and this has to be done by then, say so now and we will schedule February. What is not included: Network negotiation, SDK integration beyond the adapters the migration requires, creative, and user acquisition. If impression-level revenue is not already flowing into your own warehouse, that has to be fixed first. It is a separate engagement and we will not run a migration blind. Who this is not for: Publishers who want the migration finished in a week. Teams whose mediation is operated by a network's own account staff, where the arrangement will not be changed. And apps under roughly 20,000 daily active users, where the bidders will not compete hard enough for the difference to repay your engineering time. What you get at the end: The configuration, the test read with its interval, the reconciliation sheet across all three revenue sources, and a short document naming every line item still in the tail and what would justify deleting it.