Running AdMob and AppLovin MAX side by side with an Antigravity sub-agent that compares them daily

Calling the AdMob Reporting API from Antigravity

On the AdMob side I use googleads-nodejs-client. The two things that bite people the most are the service account scopes and the report granularity, so the core of collector-admob looks like this:

// agents/collector-admob/index.ts
import { GoogleAuth } from "google-auth-library";
 
const SCOPES = ["https://www.googleapis.com/auth/admob.readonly"];
 
interface AdMobRow {
  date: string;        // YYYY-MM-DD
  country: string;     // ISO-3166 alpha-2
  adUnit: string;
  impressions: number;
  estimatedEarnings: number; // micro-units, divide by 1e6
  matchRate: number;   // 0..1
}
 
export async function fetchAdMobDaily(
  publisherId: string,
  dateRange: { start: string; end: string }
): Promise<AdMobRow[]> {
  const auth = new GoogleAuth({ scopes: SCOPES });
  const client = await auth.getClient();
  const url = `https://admob.googleapis.com/v1/accounts/${publisherId}/networkReport:generate`;
 
  const body = {
    reportSpec: {
      dateRange: { startDate: parseDate(dateRange.start), endDate: parseDate(dateRange.end) },
      dimensions: ["DATE", "COUNTRY", "AD_UNIT"],
      metrics: ["IMPRESSIONS", "ESTIMATED_EARNINGS", "MATCH_RATE"],
      localizationSettings: { currencyCode: "USD", languageCode: "en-US" },
    },
  };
 
  const res = await client.request<unknown>({ url, method: "POST", data: body });
  return normalizeAdMobResponse(res.data);
}
 
function parseDate(iso: string) {
  const [year, month, day] = iso.split("-").map(Number);
  return { year, month, day };
}

The crucial bit is pinning currencyCode: "USD". AdMob lets you switch currency per call, but I also lock AppLovin MAX to USD, so any FX drift stays out of the comparison signal. Around 40% of my users are domestic in Japan so it would be tempting to look at yen directly, but currency noise is bad for daily deltas. I make the call in USD and bolt yen on at the presentation layer.

The second pragmatic choice is using MATCH_RATE as the fill-rate proxy. AdMob's docs draw a careful line between fill rate and match rate, but when you actually want to compare what got served after mediation, match rate is closer to the field-level intuition.

Pulling AppLovin MAX reports and matching units

AppLovin MAX exposes its reports as CSV with a slightly different shape than AdMob. collector-applovin first pulls CSV, then turns it into JSON that mirrors the AdMob schema:

// agents/collector-applovin/index.ts
import { parse } from "csv-parse/sync";
 
interface MaxRow {
  date: string;
  country: string;
  adUnit: string;
  impressions: number;
  estimatedEarnings: number; // USD float
  fillRate: number;          // 0..1
}
 
export async function fetchMaxDaily(
  apiKey: string,
  dateRange: { start: string; end: string }
): Promise<MaxRow[]> {
  const url = new URL("https://r.applovin.com/maxReport");
  url.searchParams.set("api_key", apiKey);
  url.searchParams.set("start", dateRange.start);
  url.searchParams.set("end", dateRange.end);
  url.searchParams.set("columns", "day,country,ad_unit_name,impressions,estimated_revenue,fill_rate");
  url.searchParams.set("format", "csv");
 
  const res = await fetch(url.toString());
  if (!res.ok) throw new Error(`MAX report failed: ${res.status}`);
  const csv = await res.text();
  const rows = parse(csv, { columns: true, skip_empty_lines: true });
  return rows.map((r: Record<string, string>) => ({
    date: r.day,
    country: r.country,
    adUnit: r.ad_unit_name,
    impressions: Number(r.impressions),
    estimatedEarnings: Number(r.estimated_revenue),
    fillRate: Number(r.fill_rate) / 100,
  }));
}

The MAX report column fill_rate ships as a percentage, while internally I store ratios in the 0–1 range. Forgetting that division by 100 produced a beautiful bug in the first iteration where the comparator believed AdMob was crushing it because MAX's fill rate looked like "75 versus 0.78". This kind of unit mismatch is, by a wide margin, the most common source of cross-network analysis errors.

Absorbing naming drift in the normalizer

Even when the underlying ad unit is the same, the names registered in AdMob and in AppLovin MAX rarely match. AdMob might be carrying Wallpaper_App_iOS_Native_Home while MAX has the same unit registered as home_native_ios. Without flattening, you cannot compare them.

The normalizer agent uses a static alias table that projects both into a canonical key:

// agents/normalizer/aliases.ts
export const AD_UNIT_ALIASES: Record<string, string> = {
  "Wallpaper_App_iOS_Native_Home": "ios_home_native",
  "home_native_ios": "ios_home_native",
  "Wallpaper_App_iOS_Interstitial_Detail": "ios_detail_interstitial",
  "detail_interstitial_ios": "ios_detail_interstitial",
};
 
export function canonicalAdUnit(raw: string): string {
  return AD_UNIT_ALIASES[raw] ?? raw.toLowerCase().replace(/\s+/g, "_");
}

The lesson from 90 days here is: do not let the agent "guess" similar units. Antigravity is happy to fuzzy-match, and it will confidently merge two units that look alike but are actually different, which makes the revenue verdict swing wildly. With six apps in production I have roughly 50 ad units to manage, and the alias map still fits in about 300 hand-written lines.

A threshold design that watches three metrics at once

Once the normalizer emits its merged table, the comparator writes the daily verdict. The thresholds I settled on are:

1. eCPM gap: AppLovin MAX wins as a candidate if it is +10% or more above AdMob.
2. Fill-rate gap: if AppLovin MAX is more than -5% below AdMob on fill rate, MAX is disqualified from the "winning" bucket regardless of eCPM.
3. ARPDAU gap: the migration recommendation only fires when the 7-day moving average ARPDAU gap is +5% or more in MAX's favour.

The fill-rate guardrail is the part that actually carries the design. eCPM can rise while real revenue falls; ARPDAU plus fill rate together stop that lie. The core comparator looks like this:

// agents/comparator/index.ts
interface MergedRow {
  country: string;
  adUnit: string;
  admob: { ecpm: number; fillRate: number; arpdau: number };
  max: { ecpm: number; fillRate: number; arpdau: number };
}
 
export function classify(row: MergedRow): "max-superior" | "admob-superior" | "tie" {
  const ecpmDelta = (row.max.ecpm - row.admob.ecpm) / row.admob.ecpm;
  const fillDelta = row.max.fillRate - row.admob.fillRate;
  const arpdauDelta = (row.max.arpdau - row.admob.arpdau) / row.admob.arpdau;
 
  // Fill rate guardrail
  if (fillDelta < -0.05) return "admob-superior";
 
  if (ecpmDelta >= 0.10 && arpdauDelta >= 0.05) return "max-superior";
  if (ecpmDelta <= -0.10 && arpdauDelta <= -0.05) return "admob-superior";
  return "tie";
}

The logic itself is unremarkable. What matters is that it runs with the same rules every day. When I used to do this by hand, my conclusion drifted depending on which units I happened to look at first, or how the day was going. Letting the agent apply a fixed rule every morning is what makes seasonality, weekday effects and small unit-level wobbles add up into something you can read.

What I escalate to a human and what I deliberately do not

Every daily summary lands in a dedicated Slack channel, but I quickly learned that pushing everything in just buries the signal. Antigravity's comparator now prioritises notifications only when one of these is true:

• the same (country, adUnit) pair has the same winner for seven consecutive days
• ARPDAU swings more than ±15% week over week
• either collector has failed twice in a row

When I first dumped every comparison into Slack I stopped reading the channel. Cutting the daily noise to "top three units" plus "up to three warnings" pulled my reaction time on real anomalies from about three days back down to half a day. With AI agents, reducing output volume earns more than adding more checks.

There is one boundary I deliberately keep on the human side: the agent only proposes migration candidates. It does not disable AdMob units or change MAX waterfalls on its own. Pausing an ad SDK has staged rollout and release timing implications that I am not willing to delegate to an agent. That call partly reflects running six apps solo; at a different scale I might draw the line elsewhere.

What the 90 days actually showed and what I decided

A few patterns from my own ops log over the 90-day window. I am keeping individual networks, countries and unit names private, but the shape of the result was:

• North American interstitial units: AppLovin MAX at +18% eCPM, -2% fill rate, +12% ARPDAU vs AdMob — past the guardrails and decisively in MAX's favour.
• Japanese native units: AppLovin MAX at +4% eCPM, -8% fill rate, -3% ARPDAU — disqualified by the fill-rate guardrail.
• Monthly revenue across all six apps was running 4–6% higher on average. I read that mostly as the lift from running mediation at all, not as a single-network win.

After 90 days I decided not to do a full migration. Instead, I am gradually rebalancing the North American interstitial waterfall toward AppLovin MAX. The Antigravity sub-agent fleet keeps running, and I plan to have it emit the same kind of report every quarter.

Looking back at having anchored an indie business on AdMob since 2014, I think systems that let me observe with the same ruler over months are more durable than systems that produce a verdict. The real value of AI agents in monetisation work, at least from where I sit, is not the conclusion. It is the daily, consistent scaffolding that makes a real conclusion possible later. Thanks for reading.