Rewarded × Interstitial × App Open を3層連携させて、壁紙アプリのARPDAUを1.4倍にした設計メモ

Rewarded広告を主役に据えた3つの工夫

Rewardedを主役にすると決めたら、ユーザーが「広告を見たい」と思う瞬間を増やすことに資源を投下します。私が壁紙アプリで効いた工夫は3つです。

1つ目は「コンテンツの可視性を交換材料にする」設計です。無料ユーザーには壁紙の高解像度版が見えない状態で表示し、Rewarded広告を視聴すると48時間だけアンロックされる仕組みにしました。これは「機能制限」ではなく「視覚的なヒント」を見せておくのがコツです。低解像度のままだと「見たい」という欲求が生まれません。

2つ目は「Rewardedを成立させた回数に応じてUIが進化する」見せ方です。視聴3回でカテゴリのソート機能が解放、10回でテーマカラーの選択肢が増える、というように、視聴履歴をローカルに保存して報酬を段階化します。Firebase Remote Configで段階の閾値を変えられるようにしておくと、A/Bテストもしやすくなります。

3つ目は「Rewardedの視聴可能枠を有限にする」設計です。1日10回まで、と上限を設けると、ユーザーは「今日のRewardedを使い切ろう」という心理に傾きます。これは飲食店の「本日限定」と同じ仕組みで、視聴完了率が私のアプリでは18%上がりました。

// Rewardedの視聴枠管理（React Native + AsyncStorage）
const REWARDED_DAILY_CAP = 10;
 
async function canShowRewarded(): Promise<{ allowed: boolean; remaining: number }> {
  const today = new Date().toISOString().slice(0, 10);
  const raw = await AsyncStorage.getItem(`rewarded_count_${today}`);
  const count = raw ? parseInt(raw, 10) : 0;
  return {
    allowed: count < REWARDED_DAILY_CAP,
    remaining: Math.max(0, REWARDED_DAILY_CAP - count),
  };
}
 
async function recordRewardedView(): Promise<void> {
  const today = new Date().toISOString().slice(0, 10);
  const key = `rewarded_count_${today}`;
  const raw = await AsyncStorage.getItem(key);
  const count = raw ? parseInt(raw, 10) : 0;
  await AsyncStorage.setItem(key, String(count + 1));
}

このコードは見た目以上に重要で、ユーザーへの「残り枠表示」のためにも使います。「今日あと7回視聴できます」というUIを出すだけで、視聴開始率が変わります。

Interstitialの頻度キャップを「行動粒度」で設計する

AdMobのコンソールには、Interstitialの頻度キャップ機能があります。「1セッションあたり最大2回」「直前の表示から最低60秒」といった設定です。これだけだと不十分でした。

私が「セッション粒度」のキャップから「行動粒度」のキャップに切り替えたのは、こんな問題があったからです。ユーザーが壁紙を眺めているだけのセッションでも、設定画面を開いた瞬間にInterstitialが発火していました。ユーザー視点では「設定を開きたかっただけ」なのに、広告が割り込んでくる。これでは離脱されて当然です。

行動粒度のキャップとは、「ユーザーがアプリ内で何回意味のあるアクションを取ったか」をカウントし、その閾値を超えたらInterstitialを許可する設計です。意味のあるアクションとは、壁紙のスワイプ、カテゴリ選択、お気に入り追加など、ユーザーが能動的に行った操作のことです。

// 行動粒度のInterstitialキャップ
let meaningfulActionsThisSession = 0;
let lastInterstitialAt: number | null = null;
const ACTION_THRESHOLD = 8;       // 8アクションで1回許可
const MIN_INTERVAL_MS = 90_000;   // 直前から90秒以上経過
 
function recordAction(actionType: 'swipe' | 'category' | 'favorite' | 'share'): void {
  meaningfulActionsThisSession += 1;
}
 
function shouldShowInterstitial(): boolean {
  if (meaningfulActionsThisSession < ACTION_THRESHOLD) return false;
  const now = Date.now();
  if (lastInterstitialAt && now - lastInterstitialAt < MIN_INTERVAL_MS) return false;
  return true;
}
 
function notifyInterstitialShown(): void {
  meaningfulActionsThisSession = 0;
  lastInterstitialAt = Date.now();
}

この変更で、Interstitialの表示回数自体は1セッションあたり3回から1.8回に減りましたが、CTRは0.42%から0.71%に上がり、結果としてInterstitialのトータル収益は変わらず、ユーザー離脱率が顕著に下がりました。後で気づいたのですが、これはGoogleのHelpful Content的な発想と似ています。「量より、文脈の質」を優先したほうが、結果として収益も持続する。

App Open広告は「漏れバケツ」として扱う

App Openを「主役級」に置くと、ユーザーが起動するたびに広告が出ます。これはCrashlyticsには表れない「離脱クラッシュ」を生みます。私はApp Openを、他の2つが発火しなかったセッションへの「最後の保険」として位置づけ直しました。

具体的なルールは3つです。1つ目は「コールドスタート時に必ず出す」ではなく「セッション開始から30秒以内に Rewarded か Interstitial が発火していたらスキップする」というロジックを入れること。2つ目は「直前のセッション終了から5分未満の復帰時には絶対に出さない」こと。これはユーザーが「ちょっと別のアプリを開いて戻ってきた」場面で広告を出さないための配慮です。3つ目は「1日3回までの上限を設ける」こと。これも行動粒度のキャップと同じ思想で、ユーザーの体験を守る役割があります。

// App Openの発火可否判定（漏れバケツルール）
const APP_OPEN_DAILY_CAP = 3;
const RETURN_GRACE_MS = 5 * 60 * 1000;  // 5分
 
async function shouldShowAppOpen(
  sessionStartMs: number,
  rewardedShownAt: number | null,
  interstitialShownAt: number | null,
  lastSessionEndMs: number | null,
): Promise<boolean> {
  // ルール1: 他の2つが30秒以内に発火していたらスキップ
  const now = Date.now();
  if (rewardedShownAt && rewardedShownAt - sessionStartMs < 30_000) return false;
  if (interstitialShownAt && interstitialShownAt - sessionStartMs < 30_000) return false;
 
  // ルール2: 5分以内の復帰時はスキップ
  if (lastSessionEndMs && now - lastSessionEndMs < RETURN_GRACE_MS) return false;
 
  // ルール3: 1日3回まで
  const today = new Date().toISOString().slice(0, 10);
  const raw = await AsyncStorage.getItem(`app_open_count_${today}`);
  const count = raw ? parseInt(raw, 10) : 0;
  if (count >= APP_OPEN_DAILY_CAP) return false;
 
  return true;
}

この設計に変えてから、App Open広告のCTRは0.18%から0.34%に倍増しました。ユーザーが「邪魔だ」と感じる前のタイミングだけで出るようになったからだと思っています。

3層が同時発火しないための排他制御

3つのフォーマットの役割分担とキャップを決めても、コード上で「同じイベントで複数のフォーマットが発火する」可能性は残ります。たとえば「壁紙をお気に入りに追加した」というイベントで、Rewardedの視聴枠が空いていてかつInterstitialの行動閾値も超えていたら、両方発火してしまいます。

私が入れたのは「AdGate」と呼ぶ排他制御層です。広告フォーマットの表示を直接呼ばず、すべてこのGateを経由させます。Gateは「今このイベントで最適な広告フォーマットを1つだけ選ぶ」役割を持ちます。

// 3層排他制御のAdGate
type AdEvent = 'category_change' | 'favorite_add' | 'app_resume' | 'session_milestone';
 
async function decideAdToShow(event: AdEvent): Promise<'rewarded' | 'interstitial' | 'appOpen' | 'none'> {
  // 優先度1: Rewardedが事前にユーザーアクション（広告視聴ボタン押下等）で要求されている場合
  if (event === 'session_milestone' && await canShowRewardedOnMilestone()) {
    return 'rewarded';
  }
 
  // 優先度2: Interstitialの行動閾値を超えているか
  if (shouldShowInterstitial()) {
    return 'interstitial';
  }
 
  // 優先度3: App Openの漏れバケツルール
  if (event === 'app_resume' && await shouldShowAppOpen(/* ... */)) {
    return 'appOpen';
  }
 
  return 'none';
}

このGateを入れた瞬間、「気づいたら2つ広告が連続で表示されていた」というユーザーレポートがゼロになりました。レビュー欄での「広告が多すぎる」というコメントも、9週間で月15件から3件に減りました。

ARPDAUを測るときに見ている4つの指標

ARPDAUを上げる作業は、単純にインプレッション数を増やすことではありません。私は次の4つの指標を週次でダッシュボードに出して本番運用しています。

1つ目はフォーマット別ARPDAUの内訳です。Rewarded、Interstitial、App Openそれぞれが、1日アクティブユーザーあたりいくら稼いでいるか。合計ARPDAUを見るだけでは、どのフォーマットが伸びているか分かりません。

2つ目はリテンション×ARPDAUのマトリクスです。Day 1、Day 7、Day 30の継続率と、それぞれのコホートでのARPDAUを並べて見ます。Day 30まで残っているユーザーのARPDAUがDay 1の2倍以上あるなら、長期ユーザーの収益貢献を伸ばす設計が機能している証です。

3つ目はフォーマット別のCTRと完了率です。Rewardedの視聴完了率、Interstitialのスキップ率（=途中で閉じられた率）、App Openの即時クローズ率。これらが悪化したフォーマットは、頻度を下げる候補です。

4つ目は「広告未表示セッションの割合」です。3層キャップを入れると、広告がまったく表示されないセッションが必ず存在します。この割合が30%を超えると収益機会を逃しすぎ、5%未満だと表示しすぎです。私は15〜20%を目安にしています。

Firebase BigQuery Export と AdMobのレポートAPIを組み合わせて、これらの指標を毎朝Slackに通知させています。Claude in Chrome に「前日比で異常値が出ていたら原因仮説を3つ出してください」と依頼するワークフローも追加しました。これは別記事で書きましたが、運用負荷を実用範囲に収めるためにかなり効いています。

9週間のタイムライン — 1.4倍までの実測値

参考までに、壁紙アプリ1本（DAU約1.2万）の数値推移を残しておきます。

第0週はベースラインです。ARPDAUは0.038ドル。フォーマット別の内訳はRewarded 0.012、Interstitial 0.018、App Open 0.008でした。

第1〜2週はRewardedの3つの工夫を実装した段階。Rewarded ARPDAUが0.012から0.024へ倍増。視聴完了率は42%から57%へ。一方でInterstitialの表示機会が減り、Interstitial ARPDAUは0.018から0.014に微減しました。トータルARPDAUは0.046。

第3〜5週はInterstitialの行動粒度キャップを導入。表示回数は減ったがCTRが上がり、Interstitial ARPDAUは0.014から0.020へ回復。同時にユーザー離脱率（セッション中の途中終了率）が23%から17%に改善。

第6〜7週はApp Openの漏れバケツルールを実装。App Open ARPDAUは0.008から0.011へ。総合ARPDAUは0.055まで上昇。

第8〜9週はAdGateの排他制御を入れて、3層の発火重複をゼロに。「広告が多すぎる」レビューが激減し、評価平均が3.8から4.1に改善。最終的にARPDAUは0.053（個別最適化フェーズの第7週から微減した週もありましたが、Day 30リテンションが上がったため、月次総収益は1.4倍）。

数値だけ見ると「ARPDAU 0.053は0.038の1.4倍ぴったり」ではありませんが、私が指標として重視しているのは「DAU × ARPDAU」の月次合計値です。DAUが安定して伸びたことで、月次広告収益は元の1.4倍に到達しました。

同じ設計で気をつけたい3つの失敗パターン

最後に、私が9週間でぶつかった3つの落とし穴と回避策を書き残します。

1つ目は「Rewardedの報酬を強くしすぎる」失敗です。広告視聴で48時間アンロックではなく「永久アンロック」にした週があり、その週のRewarded視聴回数は5倍に跳ね上がったのですが、翌週の視聴回数は元の30%まで落ちました。一度永久アンロックされてしまうと、ユーザーには「次にまた広告を見る理由」が無くなります。報酬は「再消費される設計」にしておくことを推奨します。

2つ目は「行動粒度キャップの閾値を、機械学習なしで決めようとした」ことです。最初は「8アクションで1回」と決め打ちしましたが、ユーザーごとに「8回が短すぎる人」と「8回でも長すぎる人」がいました。Firebase Remote Configで A/B テストを回して、リテンションに最も寄与する閾値を「ユーザーセグメント別に」設定する必要がありました。

3つ目は「AdGateを後から入れようとして、既存の広告呼び出しコードが散らばっていた」ことです。AdGateの導入時に「広告を直接呼ぶコード」が複数画面に散在していて、すべてをGate経由に書き換えるのに3日かかりました。新しいアプリでは、最初からAdGateを必須にする設計を入れておくべきでした。

ここまでが、9週間の運用ログです。3層連携の発想は、AdMobの公式ドキュメントには明示されていません。単一フォーマットを最大化する解説はあっても、3つの相互作用を扱った設計指針は、私が探した限りでは見つけられませんでした。個人開発者として12年やってきて、この「フォーマット間の調停」こそが、収益の天井を1段上げる鍵だと感じています。

同じように壁紙アプリやエンタメ系アプリで広告収益を運用している方の参考になれば嬉しいです。