MAX and AdMob Mediation Build for Non-Game Apps

A mediation build here takes five weeks and is finished when a per-impression revenue row lands in your warehouse with placement, network, country and install cohort on it. Getting ads to render takes two days. The other four and a half weeks are the part that decides whether any later floor or placement decision can be made from evidence instead of a dashboard screenshot. What gets built: AppLovin MAX carries the auction. AdMob and Google bidding come in as a bidder rather than a waterfall line, Amazon Publisher Services sits alongside it, and the rest of the demand is chosen by whether the network has a live bidding adapter for your SDK version, not by the rate card its salesperson sent. Ad units are cut by format and by placement, never one shared unit reused across three screens, because a shared unit makes the revenue data useless six months later when you want to know what the settings-screen banner is actually worth. Impression-level revenue data goes in the same week as the SDK: the MAX ILRD callback into a Cloud Function, then BigQuery, keyed to your install id and joined to the attribution cohort. The same impression fires ad_impression to Firebase and to AppsFlyer or Adjust, so predicted LTV has ad revenue in it and your acquisition team is not bidding on IAP value alone. Consent runs through Google UMP or a TCF v2.2 CMP with GPP strings for the US state signals, and the ATT prompt is sequenced after the first moment of value in the app rather than on the launch screen. Kids-and-family apps get a separate build: child-directed flags set at the SDK level and again in each network dashboard, contextual demand only, no device identifiers to the attribution provider, and a written record of which networks were excluded and why, for the day store review or a school district's procurement team asks. What I will not do: I will not install a network because it promises a high eCPM in a market you do not serve. I will not ship a stack without impression-level data landing in your own warehouse; that data belongs to you and it does not live in my accounts. I will not put the ATT prompt in front of onboarding to protect an opt-in rate at the cost of day-one retention. And I will not set up mediation for an app whose ad revenue is a rounding error next to its subscription line. That is a paywall problem wearing an ads costume, and I will say so on the first call rather than after the invoice. Who this is not for: Below roughly 20,000 daily actives the auction never gets dense enough for this engagement to pay itself back. Run AdMob's own quick start, get to scale, come back. Games are out as well; I have worked only on non-game apps since 2019 and the placement economics do not transfer. How it runs: Week one, audit of what exists and a decision on account structure. Week two, SDK and adapters into a branch of your app, mediation debugger and test devices working on both platforms. Week three, the revenue pipeline and the reporting board. Week four, consent, families configuration, network-side ad review settings. Week five, staged rollout behind your own remote config flag at ten percent, then fifty, then full, with a revenue-per-active read against the previous build at each step. You get the pull request, the warehouse schema, the reporting board, and a runbook naming who to contact at each network when fill drops on a Friday afternoon.