How do I track AdMob ad revenue per app?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Track AdMob revenue per app by keeping app-level ad unit IDs clean and separate (never shared across apps), then pulling data either from the AdMob UI's per-app filter, the AdMob API/BigQuery linking for raw export, or a mediation/reporting layer that tags each row with app ID. The fastest fix for most solo founders is just discipline in ad unit naming — the reporting problem mostly disappears once your ad units map 1:1 to apps.

If you run one app, AdMob's dashboard is fine as-is. The pain shows up at app three or four, when you're tabbing between properties, exporting CSVs with different column orders, and trying to remember which ca-app-pub-xxxx/yyyy belongs to which app.

Why AdMob reporting gets messy with multiple apps

AdMob is organized around ad units, not apps, in its exports. Each ad unit lives inside an app in the console, but once you're pulling data programmatically or via CSV, you're looking at rows of ad unit IDs and impression/revenue numbers — not a clean "App A: $X, App B: $Y" summary unless you built that mapping yourself.

This gets worse in a few common scenarios:

• You reused an ad unit across a rebrand or app clone. Revenue from two apps lands in one bucket and you can't split it after the fact.
• You're using mediation (AppLovin MAX, ironSource, etc.) on top of AdMob. Now revenue is split across AdMob's own reporting and your mediation network's dashboard, and they don't always reconcile to the same number on the same day.
• You have both Android and iOS versions of the same app. If they share an AdMob app entry (not recommended) or you just haven't separated reporting by platform, you lose the ability to see which platform is actually carrying the ad revenue.

The underlying issue: AdMob was built assuming you'd check it a few times a week for one app. It wasn't built as a portfolio tool, and it still isn't.

Fix the data model first: one app, one set of ad units

Before you touch any dashboard or export, make sure your AdMob account structure is actually separable by app. This is the 80% fix:

1. One AdMob "app" entry per actual app, and never share ad unit IDs between two codebases, even "temporarily" during a rebrand or fork.
2. Name ad units with the app name baked in, e.g. appname_banner_home, appname_interstitial_exit. It sounds obvious, but six months later when you're staring at a CSV of 40 ad units, you'll be grateful.
3. If you have Android + iOS versions of one app, keep them as separate AdMob app entries too, with a platform suffix in the ad unit name. You want to be able to answer "is iOS or Android carrying this app's ad revenue" without guessing.

If your ad units are already a mess, you can't retroactively fix historical data, but you can fix it going forward — and the sooner you do, the sooner your trend lines become trustworthy.

Getting the data out: three options, in order of effort

Option 1 — AdMob UI, filtered by app. The console lets you filter the main reporting view by app. For one or two apps checked a couple times a week, this is genuinely enough. Export to CSV if you want to keep a manual log.

Option 2 — AdMob API or BigQuery linking. Google lets you link AdMob to BigQuery for a near-real-time raw export, or query the AdMob Reporting API directly with an app/ad-unit filter. This is the right call once you're checking revenue daily or want to join it against other data (like your Play Console installs or Stripe/RevenueCat subscription revenue for apps that also sell IAP). It requires OAuth setup and some comfort with SQL or scripting — not hard, but not a five-minute job either.

Option 3 — A mediation dashboard. If you're running AppLovin MAX, ironSource, or similar on top of AdMob, check whether your mediation layer's own dashboard already breaks revenue out per app and per network. Often it does, and it saves you reconciling two sources of truth. The tradeoff is that mediation-reported AdMob revenue can lag or round differently than AdMob's own console, since mediation networks report what they're paid, not always what AdMob shows pre-payout.

Whichever option you pick, decide on one canonical source per app and stick with it for trend purposes — don't average AdMob's number with your mediation network's number, since they measure slightly different things (gross vs. network-adjusted revenue, different time zones for the reporting day, etc.).

Where ad revenue fits next to your other numbers

Ad revenue is rarely the whole story for an app — most solo-built apps with ads also have some mix of IAP, subscriptions, or at least an App Store/Play Console install trend you're watching. The real question isn't "what did AdMob pay me," it's "is this app's total revenue per install trending up or down, and is that still worth the maintenance time."

That's a portfolio-level question, and it's genuinely hard to answer from AdMob's console alone, because AdMob doesn't know about your Stripe subscriptions or your RevenueCat IAP events for the same app. If you're manually reconciling ad revenue against subscription revenue in a spreadsheet every month across five or more apps, that reconciliation cost is itself worth measuring against the ad revenue you're actually pulling in.

AdMob is on SoleOS's connector roadmap but isn't live yet — today SoleOS pulls store, subscription, and web metrics (App Store Connect, Google Play, RevenueCat, Stripe, GA4, and more) into one portfolio view, so an app's ad-supported economics would sit next to everything else about that same app, rather than in a separate tab. (Disclosure: SoleOS writes about its own space here, and this isn't the only honest answer — if you run one or two ad-supported apps and check them weekly, AdMob's own filtered view is probably all you need.) See what SoleOS connects to for the current connector list and auth model, or look at the live demo to see how connected metrics get laid out once AdMob joins the list.

In the meantime, if you're already pulling Stripe or RevenueCat revenue into a dashboard, read tracking Stripe and RevenueCat together for how to avoid double-counting when an app has both subscriptions and ads. And if you're trying to decide whether a small ad-supported app is worth keeping alive at all, real numbers from a 10-app portfolio is a useful gut-check on what "worth it" actually looks like once you count your own time.

Frequently asked questions

Can I export AdMob revenue broken out by app automatically?

Yes, via the AdMob Reporting API or by linking AdMob to BigQuery, both of which let you filter or group by app ID programmatically. The console UI also supports filtering by app manually, which is enough if you're not automating anything yet.

Why does my mediation network show different AdMob revenue than AdMob itself?

Mediation networks (AppLovin MAX, ironSource, etc.) often report what they were paid, with their own time zone for the reporting day and sometimes a different revenue attribution model than AdMob's own console. Pick one source as canonical per app for trend tracking rather than reconciling the two numbers daily.

Should I combine ad revenue and subscription revenue into one "total revenue" number per app?

For a quick health check, yes — total revenue per install or per active user is a reasonable single number to glance at. But keep the components visible underneath, since an app can look fine on total revenue while its ad revenue quietly declines and subscription revenue masks it, or vice versa.

Does separating ad units by app actually matter if I only have two or three apps?

It matters less at small scale, but it costs you almost nothing to do it right from the start, and it saves a real headache the day you add a fourth or fifth app, or clone an existing app into a new niche. Retroactively splitting commingled ad unit data isn't possible, so the cheap time to fix this is now.

Is there a single dashboard that shows AdMob revenue next to App Store and subscription metrics today?

Not yet inside SoleOS specifically — AdMob is a planned connector, not a live one. Today you'd combine AdMob's own export with a tool like SoleOS for your store, subscription, and web metrics, and do the ad-revenue join manually until that connector ships.