Rork プロジェクトに AppLovin MAX を後付けした実装ノート — 初期化順序・ATT 同意・eCPM 検証の三軸メモ

ATT ダイアログと AppLovin の同意フラグの整合

ATT のステータスを取ったあと、AppLovin MAX 側にも同意状態を伝える必要があります。ALPrivacySettings 経由で hasUserConsent と isAgeRestrictedUser、isDoNotSell を設定するのが基本フローです。ATT の応答が .authorized のときは hasUserConsent = true、それ以外は false に揃えるシンプルな運用にしていますが、欧州 EEA 向けには Google UMP 側で CMP 同意を取得して別フラグで上書きしています。

func syncPrivacySignals(att: ATTrackingManager.AuthorizationStatus, isEEA: Bool) {
    let consent = (att == .authorized)
    ALPrivacySettings.setHasUserConsent(consent)
    ALPrivacySettings.setDoNotSell(!consent)
    ALPrivacySettings.setIsAgeRestrictedUser(false)
 
    if isEEA {
        // UMP 同意取得後にここで GDPR フラグを正式化する
        let cmp = CMPStore.shared.latestPurposes
        ALPrivacySettings.setHasUserConsent(cmp.consentForPurpose1)
    }
}

落とし穴として、ATT の応答取得後に syncPrivacySignals を必ず呼ぶ運用にしておかないと、AppLovin 側に古い false が残ったままになります。私の手元では、最初の実装で「初期化中に一度フラグを書いて、ATT 応答時には書き直していなかった」せいで、AppLovin 経由のリワード広告が同意 OK ユーザーに対してパーソナライズなしの低 eCPM 帯に固定される事象を確認しました。AdsBootstrap.bootstrapMax の初期化完了コールバック内で syncPrivacySignals を必ず呼ぶように修正し、ATT 応答時にも再呼び出しする二重ガードにしてから現象が消えました。

AdMob メディエーション経由で MAX を回す並走判断

AppLovin MAX を「メインメディエーションサーバー」として使う運用と、AdMob メディエーションの中の 1 アダプタとして並走させる運用は、見た目は同じに見えても運用負荷が異なります。私の場合、すでに AdMob メディエーションで複数ネットワークを回している壁紙アプリ群を急に MAX 中心に切り替えるとリスクが大きすぎるため、最初は AdMob メディエーション内の入札アダプタとして MAX を追加する構成から始めました。

AdMob 管理画面の入札（Bidding）グループに AppLovin を追加し、対象広告ユニットに紐付けて配信を開始する流れです。Bidding グループに入れるか Waterfall に入れるかで動きが変わり、Bidding の方が在庫消化のスピードは速いものの、AppLovin 側のレポートと AdMob 側のレポートを突き合わせる作業負荷は増えます。最初の 1 週間は Waterfall に低めの eCPM フロアで入れて挙動を見て、安定したら Bidding に昇格させるのが、私の中では現実的な進め方です。

App Store と Google Play 双方で同じアプリを運用している場合、iOS で先にこの構成を試してから Android に展開すると、AppLovin の管理画面の運用感も両プラットフォーム横断で揃えやすくなります。

eCPM 比較を取るための最小 A/B 計測の組み方

並走の意味は、数値で意思決定するための比較材料を集めることにあります。私は Firebase Remote Config と AdMob のフロア設定を組み合わせて、ユーザーを 2 群に分割する最小構成を作りました。

• A 群: AdMob 既存セットアップのみ
• B 群: AdMob メディエーション内に AppLovin MAX 入札を追加

Remote Config で ads_variant を A または B で配り、AdsBootstrap の初期化時に B のときだけ AppLovin SDK の初期化を行います。AdMob 側でも対象広告ユニットを A 用と B 用で 2 系統用意し、Crashlytics のカスタムキーに ads_variant を埋めて、クラッシュ率がどちらの群で増えたかを切り分けられる状態にしています。

let variant = RemoteConfig.remoteConfig().configValue(forKey: "ads_variant").stringValue ?? "A"
Crashlytics.crashlytics().setCustomValue(variant, forKey: "ads_variant")
 
if variant == "B" {
    AdsBootstrap.shared.startAfterActive()
} else {
    // 既存の AdMob 単独初期化
    AdMobOnly.shared.startAfterActive()
}

実体験として、SDK バイナリサイズが増えると Android 側の dex 制限や iOS 側のアプリサイズ閾値に効いてくるため、A 群と B 群でアプリバイナリ自体を分けるのではなく「同一バイナリ内でランタイム切替」する構成が個人開発者にとっては現実的でした。アプリストア審査も 1 本で済みます。

評価指標は次の 4 つに絞っています。

1. 100 インプレッションあたりの eCPM（USD）
2. リクエスト数に対する fill rate（%）
3. クラッシュフリー率（Crashlytics ベース、Day 1 と Day 7）
4. 起動から最初のバナー表示までの所要時間（秒、計測点を実装）

2 週間程度の観測で eCPM の差分が信頼区間に収まるなら、安心して Bidding 昇格や A/B のロールアウト比率変更に進めます。逆に差分が誤差レベルのときは、撤退判断も視野に入れて切り戻し計画を準備します。

起動直後のバナーが沈黙する事象への対処

AppLovin MAX を入れた直後によく起きるのが、起動から 2〜3 秒の間にバナーをロードしようとして埋まらない事象です。AdMob 単体だったときには起こらなかったタイミング問題が、メディエーションのアダプタ初期化を待つ分だけずれて顕在化します。

対処として、AdsBootstrap.isReady が true になるまで広告ビューのインスタンス化自体を遅延させる構造に変更しました。React Native 側のフックは以下のように Suspense 風の待機 API になっています。

import { useEffect, useState } from 'react';
import { NativeEventEmitter, NativeModules } from 'react-native';
 
const emitter = new NativeEventEmitter(NativeModules.AdsBootstrap);
 
export function useAdsReady() {
  const [ready, setReady] = useState<boolean>(false);
 
  useEffect(() => {
    NativeModules.AdsBootstrap.isReady().then(setReady);
    const sub = emitter.addListener('AdsBootstrapReady', () => setReady(true));
    return () => sub.remove();
  }, []);
 
  return ready;
}

バナーを描画するコンポーネント側は const ready = useAdsReady(); を見て、ready === false の間はプレースホルダー UI を出すだけにしてあります。これにより起動直後の 1〜2 秒間に「広告枠が空っぽに見える」状態を防ぎ、レイアウトジャンプも避けられます。

Before のコードは「マウント時に即時 load を呼ぶ」設計でしたが、After では「ready を待ってから load を呼ぶ」に変更しています。広告 SDK が成熟するほどこの種の待機 API は重要度が増す体感です。

Firebase Crashlytics に流れてきたクラッシュをどう切り分けるか

並走を始めた最初の 3 日間で、Crashlytics に AppLovin 由来のスタックトレースが少量混じり始めました。多くは「リワード広告のクローズタイミングで Notification のリスナー解除順序が逆」というよくあるパターンでしたが、AdMob 由来のクラッシュと切り分けるには、先述の ads_variant カスタムキーが効きます。

私は Claude in Chrome のセッションを開いて、Crashlytics の管理画面を読ませながら「ads_variant=B のスタックトレースのみ抜き出して、上位 3 件をシグネチャごとに要約し、AppLovin 公式の Known Issue リストと突き合わせて」と作業を依頼しました。手動でブラウザを操作するより時間が圧縮でき、AppLovin の管理画面と Crashlytics の管理画面を横断する作業の体感が一段軽くなります。

ここでも書いておくと、Claude in Chrome に AppLovin 管理画面のスクリーンショットを読ませて「この週の eCPM トップ 3 地域とフィルレートを表にして」と依頼するのも有効でした。アプリ開発の本流から外れた運用作業をエージェントに渡せると、コードを書く時間が確実に増えます。

リワード広告の Mediation 設定とデリゲートの差分

バナーと AppOpen 以外に、リワード広告でも AdMob メディエーションから AppLovin MAX を回す構成を試しました。GADRewardedAd の API は AdMob 側で抽象化されているため、コード上は何も変える必要がありませんが、AppLovin の管理画面側で rewarded 用のプレースメントを別途作る必要があります。

注意点として、AdMob の userDidEarnRewardHandler は AppLovin 経由でも発火しますが、ネットワーク間で GADAdReward の amount と type の値の正規化が完全ではなく、自前で amount = 1、type = "coin" のように後段で正規化するレイヤーを挟む方が安全です。最初の実装で AppLovin 経由のときだけ amount がゼロで降ってきたケースがあり、ゲーム性のあるアプリで報酬が二重付与されたりゼロ付与になるリスクの芽になりました。

rewardedAd.present(fromRootViewController: vc) { [weak self] in
    let raw = rewardedAd.adReward
    let amount = max(1, raw.amount.intValue)
    let type = raw.type.isEmpty ? "coin" : raw.type
    self?.rewardLedger.grant(amount: amount, type: type, source: variant)
}

メディエーションを増やしたら「報酬計算の正規化」を必ず挟む、というのが個人開発の現場で得た教訓です。

個人開発者の現実的な投下時間と切り戻し計画

ここまでをまとめると、AppLovin MAX の後付けは技術的に難しい作業ではないものの、初期化順序・同意フラグ・並走時の運用負荷の三軸で時間を取られます。私の場合、Beautiful HD Wallpapers の iOS 版に組み込み、A/B を 2 週間回して結果を見るまでの実工数が、設計から検証までで概算 18〜22 時間でした。これは Rork で骨格を作ったアプリだからこその短さで、ゼロから手書きで広告レイヤーを作っていたらこの倍は掛かったと感じます。

切り戻し計画は最初から準備しておくのが望ましいです。私は Remote Config の ads_variant を A 固定に切り替えるトグルだけで AppLovin MAX を実質的に停止できる構成にしました。これにより、万一クラッシュ率が悪化したり eCPM が逆に下がるパターンが見えても、ストア審査を待たずに数分で切り戻せます。個人開発者にとってこの安全装置は精神衛生上の意味でも大きいです。

導入そのものより、撤退も含めた「並走を続けるか、片方に寄せるか、両方やめるか」の判断材料を集める姿勢が肝心だと、12 年やってきて感じています。AppLovin MAX を入れること自体が目的化しないよう、Remote Config と Crashlytics の数値を毎週見直す習慣を組み合わせるところまでセットでの設計にしておくのが安心です。

同じ題材で取り組んでいる個人開発者の方の判断材料になればうれしいです。お読みいただきありがとうございました。