メディエーションプラットフォームを移行すべき時期とは？
広告メディエーションプラットフォームの切り替えは、モバイルパブリッシャーが行う最も重要な決定の一つです。メディエーションレイヤーは、ユーザーが見る広告、インプレッションごとの収益、広告体験のスムーズさを制御します。移行にはリスクが伴いますが、最適でないプラットフォームに留まるコストは日々増加します。
移行を検討すべき明確なシグナル：
- 市場の説明なくeCPMが低下： 業界のベンチマークが安定しているにもかかわらずeCPMが低下している場合、現在のプラットフォームにデマンドギャップや最適化の問題がある可能性があります。
- 他所でのより良いビッディングサポート： 現在のプラットフォームが3つのビッディングパートナーをサポートし、競合が8つをサポートしている場合、オークション密度（と収益）を逃しています。
- SDKの終了または非推奨： メディエーションプラットフォームがSDKのサポート終了を発表した場合、移行は任意ではありません。いつやるかの問題です。
- 欠けている広告フォーマット： プラットフォームがアプリオープン広告、リワード付きインタースティシャル、ネイティブビッディングをサポートしていないのに競合がサポートしている場合、欠けているフォーマットごとに収益を失っています。
- レポートの制限： ネットワーク、地域、広告ユニット、フォーマット別の詳細なeCPMデータを取得できない場合、盲目的に運営していることになります。現代のプラットフォームはこれを標準として提供します。
移行計画：並行テストアプローチ
メディエーション移行の基本ルールは、ハードカットオーバーを絶対に行わないことです。並行テストアプローチは、新しいプラットフォームのパフォーマンスを実トラフィックで検証しながら、収益の下限を守ります。
並行戦略は次のように機能します：
- フェーズ1（セットアップ）： 既存のSDKと並行して新しいメディエーションSDKを統合します。両プラットフォームで同一の広告ユニット、デマンドソース、フロア価格を設定します。
- フェーズ2（トラフィック分割）： トラフィックの10〜20%を新しいプラットフォームに振り分け、80〜90%は既存プラットフォームに維持します。分割を制御するためにリモート設定フラグまたはA/Bテストフレームワークを使用します。
- フェーズ3（モニタリング）： 両プラットフォームを少なくとも2週間同時に実行し、eCPM、フィルレート、レイテンシー、クラッシュレートを分割全体で比較します。
- フェーズ4（スケール）： 新しいプラットフォームが既存のものと同等またはそれ以上であれば、トラフィックシェアを段階的に増やします：20%→50%→80%→100%。
- フェーズ5（クリーンアップ）： 安定したパフォーマンスで100%のトラフィックが新しいプラットフォームで少なくとも1週間稼働した後、古いメディエーションSDKと関連設定を削除します。
切り替え前に必要なデータ
移行を開始する前に、現在のプラットフォームから包括的なベースラインデータをエクスポートして文書化してください。このデータには2つの目的があります：新しいプラットフォームを評価するための比較ベンチマークを提供し、新しいウォーターフォールまたはビッディング設定の初期構成を通知します。
必須データポイント
- ネットワークおよび地域別の過去のeCPM： 少なくとも、国または国グループ別に分類された各デマンドソースの過去90日間の日次eCPM。これにより、どのネットワークがどの市場でパフォーマンスが良いかがわかり、新しいウォーターフォールの順序が決まります。
- ネットワークおよび広告フォーマット別のフィルレート： eCPMが高くてもフィルレートが5%のネットワークは、中程度のeCPMでフィルレートが90%のネットワークとは異なる貢献をします。正確な設定には両方の指標が必要です。
- 広告ユニット別のインプレッション数： どの広告配置が最も多くのインプレッションを生成するかを把握します。これらが最も影響の大きいユニットであり、リスクを最小化するために最後に移行すべきです。
- レイテンシーデータ： 利用可能であれば、ネットワーク別の平均広告読み込み時間とタイムアウト率を文書化します。これにより、新しいプラットフォームで適切なタイムアウト値を設定できます。
- 曜日および時間帯別の収益： 広告市場には週次および日次サイクルがあります。このパターンを文書化しておくことで、通常の周期的変動を移行関連の変化と誤認しないようになります。
あれば望ましいデータ
- コホート別のユーザーレベルARPDAU
- セッションレベルの広告頻度データ
- 広告SDK活動と相関したクラッシュおよびANRレート
- 現在のプラットフォームが提供する場合の詳細なビッドレベルログ
ステップバイステップの移行プロセス
ステップ1：新しいメディエーションSDKをインストール
プロジェクトに新しいメディエーションSDKと必要なすべてのアダプターSDKを追加します。古いSDKはまだ削除しないでください。両方が並行テスト期間中に共存します。主なアクション：
- コアメディエーションSDK依存関係を追加する
- 使用予定の各デマンドソース用アダプターSDKを追加する
- リモート設定フラグでゲートされた状態で、ApplicationクラスまたはAppDelegateで新しいSDKを初期化する
- 古いSDKと新しいSDKの間で競合なくビルドがコンパイルされることを確認する
ステップ2：広告ユニットとデマンドソースを設定
新しいプラットフォームのダッシュボードで広告ユニット設定を再作成します：
- 既存のプレースメントに一致する広告ユニットを作成する（バナーの場合は同じフォーマット、同じリフレッシュ間隔）
- それぞれのアプリIDとプレースメントIDで全デマンドソースを追加する
- 旧プラットフォームの過去のeCPMデータに基づいて初期フロア価格を設定する
- サポートするすべてのソースのビッディングを有効にし、残りはウォーターフォールエントリーとして設定する
ステップ3：トラフィック分割を実装
リモート設定システム（Firebase Remote Config、独自のフィーチャーフラグシステム、またはシンプルなサーバーサイドトグル）を使用して、各セッションを処理するメディエーションSDKを制御します：
- アプリ起動時に、このセッションでどのSDKがアクティブかをリモートフラグで確認する
- セッション全体を通じて、アクティブなSDKのみを通じて広告をリクエストする。セッション内でSDKを混在させないこと。
- パフォーマンスデータをクリーンにセグメント化できるよう、アナリティクスにどのSDKがアクティブかをログに記録する
ステップ4：最低2週間の並行運用
2週間は最低評価期間です。この期間により、平日と週末のパターンが把握でき、需要の変動が考慮され、ビッディングアルゴリズムがインベントリを学習する時間が確保されます。この期間中：
- 両グループの日次eCPM、フィルレート、総収益を毎日モニターする
- 両グループのアプリ安定性指標（クラッシュレート、ANRレート）を追跡する
- ユーザー体験の問題（広告の読み込みが遅い、空白の広告フレーム、予期しないフルスクリーン広告）を監視する
- 明らかに問題がない限り、この期間中にどちらのプラットフォームの設定も変更しない
ステップ5：比較して決定
並行期間の後、これらの観点から2つのプラットフォームを比較します：
- DAUあたりの収益： 主要指標。新しいプラットフォームが日次アクティブユーザーあたり同等またはより高い収益を生成する場合、コアテストに合格します。
- フィルレート： フィルレートが高いほど、より多くのインプレッションが収益化されます。フィルレートが5%高くeCPMが同程度の新しいプラットフォームは明確な勝者です。
- レイテンシー： 広告の読み込みが速いほど、ビューアビリティとユーザー体験が向上します。
- 安定性： 新しいSDKがクラッシュレートを上げる場合、収益の増加に見合わない可能性があります。
ステップ6：カットオーバーとクリーンアップ
新しいプラットフォームへの移行を決定したら、トラフィックを100%に増やし、さらに5〜7日間モニターしてから、古いSDKを完全に削除します。依存関係リストを更新し、古い初期化コードを削除し、トラフィック分割に関連する条件分岐ロジックをクリーンアップします。
メディエーション移行でよくある失敗
よく計画された移行でも問題が発生します。よくある落とし穴を知っておくことで、素早く回避・回復できます：
- 過去の最適化データの喪失： 旧プラットフォームのビッディングアルゴリズムには、インベントリに関する数か月のデータがあります。新しいプラットフォームはゼロから始まります。アルゴリズムが学習する間、1〜2週間のパフォーマンス低下を想定してください。
- SDKの競合： 2つのメディエーションSDKを同時に実行すると、特に両方が異なるバージョンで同じデマンドソースSDKを含む場合、依存関係の競合が発生する可能性があります。本番環境にデプロイする前に、ステージングビルドで徹底的にテストしてください。
- フロア価格の不一致： 新しいプラットフォームのフロアを高く設定しすぎるとフィルレートが低下します。低く設定しすぎると収益を逃します。過去のデータを出発点として、最初の週の後に調整します。
- 不均等な期間の比較： 広告市場は変動します。3か月前の旧プラットフォームの第1週と新しいプラットフォームの第1週を比較することは有効な比較ではありません。並行テストがこの問題を解消します。
- タイムラインの急ぎ： 早期に結果を出したいというプレッシャーが早計な結論につながります。2週間の並行データが最低限です。トラフィックが多いパブリッシャーには4週間がより適切です。
AdMobメディエーションからGoogle Ad Managerへの移行
最も一般的な移行パスの一つは、AdMobメディエーションから完全なGoogle Ad Managerプラットフォームへの移行です。このアップグレードは、規模の大きなパブリッシャー向けのGAMの優れた機能によって推進されます：
- ダイレクトディールのサポート： GAMは直接販売キャンペーンがプログラマティックデマンドと競合することを可能にしますが、AdMobメディエーションはこれをサポートしていません
- 高度なレポーティング： GAMはラインアイテム、広告主、クリエイティブ、カスタムディメンション別の詳細なレポートを提供します
- Open Bidding： GAMのサーバーサイドビッディングは、AdMobのクライアントサイドメディエーションよりも広範な取引所パートナーをサポートします
- 統一価格ルール： 単一のインターフェースから全デマンドソースにわたって地域、デバイス、フォーマットの粒度でフロア価格を設定
この特定の移行はRevenueFlex が頻繁に処理するものです。AdMobメディエーションから完全管理GAMセットアップへの移行は、GAMでの広告設定全体の再作成、デマンドソースのマッピング、過去のパフォーマンスに基づく新しいフロア価格の設定、収益の中立性または改善を確認するための並行評価の実施を含みます。適切な計画でこの移行を行ったパブリッシャーは、GAMウォーターフォールが完全に最適化された後、通常10〜25%の収益増加を実現します。
メディエーション移行は週末のプロジェクトではありません。慎重な計画、規律ある並行テスト、そして新しいアルゴリズムがインベントリを学習する間の忍耐を必要とする数週間のプロセスです。しかし、パフォーマンスが低いプラットフォーム上のパブリッシャーにとって、切り替えによる長期的な収益への影響は、短期的な努力を価値あるものにします。