広告の本当のeCPMを自分で測る — Impression-Level Ad Revenue を計測基盤に流し込む実装記録

paidEventListener で1インプレッションごとに収益を取る

まずは収益イベントを取りこぼさずに受け取る部分です。広告をロードするたびに paidEventListener を登録します。インタースティシャルの例で示します。

import {
  InterstitialAd,
  AdEventType,
  TestIds,
} from 'react-native-google-mobile-ads';
import { logAdRevenue } from './adRevenue';
 
const adUnitId = __DEV__ ? TestIds.INTERSTITIAL : 'ca-app-pub-XXXXXXXX/YYYYYYYY';
 
export function createInterstitial(placement: string) {
  const ad = InterstitialAd.createForAdRequest(adUnitId);
 
  // 1インプレッションごとの収益を受け取る
  const unsubscribePaid = ad.addAdEventListener(
    AdEventType.PAID,
    (payload) => {
      // payload: { value, currency, precision } とメディエーション情報
      logAdRevenue({
        placement,            // 'interstitial_home' など自分で決めた枠の名前
        format: 'interstitial',
        valueMicros: payload.value,     // マイクロ単位の整数
        currency: payload.currency,     // 'USD' / 'JPY' ...
        precision: payload.precision,   // 推定精度
      });
    },
  );
 
  const unsubscribeClosed = ad.addAdEventListener(AdEventType.CLOSED, () => {
    unsubscribePaid();
    unsubscribeClosed();
  });
 
  ad.load();
  return ad;
}

ポイントは、placement を「自分のアプリの中で意味のある枠名」として渡していることです。AdMob の広告ユニットIDは機械的すぎて、後から集計するときに「これはどの画面の広告だっけ」が分かりません。interstitial_home、appopen_cold_start、banner_article_footer のように、人間が読める枠名を必ず添えておくと、後の分析が一気に楽になります。

通貨とマイクロ単位を取り違えた失敗と、その直し方

ここが私が最初にしくじったところです。最初の実装で、私は収益をこう記録していました。

// Before（壊れていた実装）
function logAdRevenue(e) {
  analytics().logEvent('ad_revenue', {
    placement: e.placement,
    value: e.valueMicros,   // ← マイクロのまま記録してしまった
    currency: e.currency,   // ← 通貨を混在させたまま合計してしまった
  });
}

これで集計すると、収益の合計がダッシュボードの実額の100万倍になりました。マイクロ単位を割り戻していなかったからです。さらに厄介だったのは、USD のインプレッションと JPY のインプレッションが同じ value 列に混ざって合計されていたことです。USD建ての0.01と JPY建ての1.5が単純に足され、数字としては意味を成していませんでした。

直したのが次の実装です。マイクロ単位を割り戻し、すべてを基準通貨（私の場合は JPY）に正規化してから記録します。

// After（正規化してから記録する）
import { getRate } from './fxRates'; // 日次で更新する為替レート表
 
function logAdRevenue(e: {
  placement: string;
  format: string;
  valueMicros: number;
  currency: string;
  precision: string;
}) {
  const amount = e.valueMicros / 1_000_000;        // マイクロ → 通貨単位
  const amountJpy = amount * getRate(e.currency);  // 基準通貨(JPY)へ正規化
 
  analytics().logEvent('ad_revenue', {
    placement: e.placement,
    format: e.format,
    value_jpy: Number(amountJpy.toFixed(4)),  // 正規化済みの金額のみを集計列に
    src_currency: e.currency,                  // 元通貨は監査用に別フィールドで保持
    precision: e.precision,
  });
}

為替レートは厳密である必要はありません。私は日次の概算レートを Remote Config に置いて、起動時に取得しています。広告収益の分析で見たいのは「どの枠が相対的に稼ぐか」であって、会計上の正確な円換算ではないからです。大事なのは、集計に使う列（value_jpy）の通貨を1つに統一しておくことです。元通貨は別フィールドに残し、おかしな数字が出たときに遡れるようにしておきます。

重複・サンプリング・PII — 計測イベントの設計

イベントを流す前に、3つだけ決めておくと後で困りません。

まず重複です。paidEventListener は基本的に1インプレッション1回ですが、リスナーの登録が広告の再ロードで二重になると、同じインプレッションを2回記録してしまいます。私は広告オブジェクトの生成時にだけリスナーを張り、CLOSED で確実に解除する形にして、登録と解除を1対1に保っています。先ほどのコードで unsubscribePaid() を CLOSED の中で呼んでいるのはこのためです。

次にサンプリングです。収益イベントは量が多く、解析サービスによっては従量課金です。ただ、ad_revenue を間引くと当然ながら収益分析が狂います。私は ad_revenue だけはサンプリングせず全量送り、代わりに画面遷移などの細かいイベントの方を間引くことで全体の送信量を抑えています。お金に直結するイベントは間引かない、という線引きです。

最後に PII です。収益イベントに個人を特定できる情報（メールやデバイス固有ID）を載せる必要はありません。地域はストア国や IP由来の粗い国コードで十分で、ユーザー単位の特定は不要です。プライバシーマニフェストや ATT の観点でも、収益分析に必要なのは「集計可能な粒度」だけだと割り切っておくと、審査でもユーザー説明でも安全側に倒せます。

ネットワーク×プレースメント×地域で本当のeCPMを出す

正規化済みのイベントが貯まれば、本当のeCPMは単純な割り算で出せます。インプレッション数を別途カウントしておき（paidEventListener の発火回数がそのままインプレッション数になります）、収益合計をインプレッション数で割って1,000倍するだけです。

-- 枠×国ごとの「本当のeCPM」(基準通貨JPY)
SELECT
  placement,
  country,
  COUNT(*)                      AS impressions,
  SUM(value_jpy)                AS revenue_jpy,
  SUM(value_jpy) / COUNT(*) * 1000 AS ecpm_jpy
FROM ad_revenue_events
WHERE event_date BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY placement, country
HAVING impressions >= 500       -- 少なすぎる組合せはノイズなので除外
ORDER BY ecpm_jpy DESC;

HAVING impressions >= 500 を入れているのは、インプレッションが数十件しかない組合せの eCPM はブレが大きすぎて判断に使えないからです。私は最低500、できれば1,000インプレッション貯まるまではその数字を信じないことにしています。

この集計を初めて出したとき、冒頭の「Pangle は低い」という管理画面の印象が、ある地域では完全に逆転していました。日本のインタースティシャルでは確かに Pangle のeCPMは低かったのですが、東南アジアのバナーでは Pangle が他ネットワークの2倍近い数字を出していました。混ぜた平均では絶対に見えなかった事実です。

その数字を入札フロアと優先度に反映する

本当のeCPMが枠×地域で出れば、操作は具体的になります。私が今まわしている運用ルールはこうです。

第一に、eCPMが基準を大きく下回る「枠×地域×ネットワーク」の組合せには、その地域向けのフロアを設定して、安値での落札を拒否します。ただし在庫を空にしないよう、フロアは段階的に上げ、フィルレート（充填率）が急落しないかを毎回確認します。第二に、明確に高いeCPMを出すネットワークは、その地域のメディエーション優先度を上げます。第三に、500インプレッションに満たない組合せは触りません。データが足りない場所をいじるのは勘に戻るのと同じだからです。

宮大工だった祖父たちは「手を動かすことが一つの信心だ」とよく言っていました。私はこの数字を出すまで、広告の調整を「手を動かさずに勘で決める」例外にしていたのだと思います。1インプレッションごとに測るようにしてから、ようやく他の実装と同じ手触りで広告も扱えるようになりました。

Claude in Chrome で管理画面操作を半自動化した運用メモ

最後に、いま進行中の取り組みを1つ。本当のeCPMが出ても、それを AdMob の管理画面のフロアやメディエーショングループに反映する作業は、ブラウザ上のクリックの連続で、6アプリ分やると地味に時間を食います。私はこの「数字は出たが、画面に反映するのが面倒」という部分を、Claude in Chrome にブラウザUIを操作させる形で半自動化しています。

具体的には、上の SQL で出した「フロアを上げるべき枠×地域」のリストをそのまま渡し、AdMob の該当メディエーショングループを開いてフロア値を入力していく操作を任せます。最終的な値の確定は必ず自分の目で確認しますが、画面を辿ってフィールドを開くまでの単純作業がなくなるだけで、6アプリの見直しが現実的な時間に収まるようになりました。個人開発でこの規模の最適化を続けられるかは、こういう単純作業をどれだけ削れるかにかかっていると感じています。

次の一歩

もし今、メディエーションの調整を管理画面の平均eCPMだけで決めているなら、まず paidEventListener を1つのプレースメントに付けて、value をマイクロ単位として割り戻し、基準通貨に正規化したイベントを解析基盤に流すところから始めてみてください。最初の1枠で集計が回り始めると、「平均では見えなかった地域差」が必ず出てきます。そこからフロアと優先度を動かすのは、その後の話です。

同じように複数アプリの広告収益と向き合っている方の参考になれば嬉しいです。お読みいただきありがとうございました。