これまで、広告マネタイズに関わる重要な施策は、どれもアプリのリリースサイクルに縛られていました。リワード広告をもう1件プリロードしたい、ネイティブ広告枠のデザインを変えたい、特定の国だけフリークエンシーキャップを緩めたい。そう思っても、最短ルートでさえコード変更、ストア審査待ち、2週間の段階的ロールアウトを経て、ようやく数値の変化を確認する流れでした。
今回のリリースでは、そのうち3つの施策をApps Kit SDKのポータルから実行できるようになりました。広告プリロード、ネイティブ広告デザイン、地域別設定をリモートで変更し、すでにインストールされているアプリに適用できます。アプリの更新も、ストアへの申請も不要。旧バージョンを使い続けるユーザーのアップデートを待つ必要もありません。
1. ポータルから広告をプリロード — コード不要でフィルレートを最適化
広告が返らない「ノーフィル」は、必ずしも広告需要の不足が原因ではありません。多くの場合、広告リクエストの開始が遅すぎるだけです。ユーザーが広告表示ポイントに到達してからSDKがオークションを開始し、有力な入札元が応答する前にタイムアウト。結果として、単価の低い補完用の広告を表示するか、何も表示できずに終わります。プリロードが解決するのは、需要ではなくタイミングの問題です。
ポータルから広告枠ごとにプリロードを設定できるようになりました。広告フォーマット別に待機させる広告数、広告取得を開始するトリガー、キャッシュ済み広告を破棄して再取得するまでの有効期間を指定できます。朝9時に設定を変えれば、その日のコホートで効果を確認できます。
- フォーマット別のプリロード数 — インタースティシャル広告を1件、リワード広告を2件待機させるなど、広告枠ごとに調整可能
- 取得トリガー — アプリ起動時、画面表示時、レベル開始など特定のアプリ内イベント後にプリロード
- キャッシュTTL — 古くなったクリエイティブは配信前に期限切れにし、20分前に入札が無効になった広告を表示しないように管理
- 補充ポリシー — 広告表示直後に再取得するか、次のトリガーまで待ってリクエスト数を節約するかを選択
設定と同じくらい重要なのが、過剰なプリロードを防ぐ仕組みです。あらゆる広告枠ですべての広告をプリロードすると、低スペックのAndroid端末でメモリを消費し、実際には表示されない広告のリクエストが増加します。その結果、気づかないうちにフィルレートや広告ネットワークからの評価を下げてしまいます。ポータルでは、プリロードを有効にした広告枠ごとにリクエスト数とインプレッション数の比率を確認できます。プリロード数が多すぎると分かれば、その日の午後に減らすことも可能です。
最初は、収益性の高い広告枠、つまりリワード広告とセッション内で最初に表示するインタースティシャル広告だけを対象に、プリロード数を1件、TTLを短めに設定するのがおすすめです。まず計測し、比率が健全に保たれている広告枠だけプリロード数を増やしましょう。
2. ポータルでネイティブ広告をデザイン — アプリ更新は不要
ネイティブ広告は、アプリに自然になじむ見た目でこそ効果を発揮します。ただ、それこそが改善を重ねにくい理由でもありました。これまでは、見出しのサイズ、アイコンの配置、CTAの色、角丸の半径といった細かな変更も、アプリのバイナリに含まれるレイアウトファイルの修正が必要で、テストのたびにリリースが発生していました。
ネイティブ広告テンプレートをポータル上で作成・編集できるようになりました。標準のネイティブ広告アセットであるアイコン、見出し、本文、メディア、広告主、CTAを組み合わせてレイアウトを作成。独自のフォント、色、余白、角丸を設定し、公開中のアプリに配信できます。SDKが実行時にテンプレートを描画するため、次回の設定取得時に、インストール済みユーザーにもデザイン変更が反映されます。
- ドラッグ操作で配置できるレイアウト — フィード、バナー型、全幅のネイティブ広告枠に対応
- テーマ設定 — タイポグラフィ、色、余白、角丸、CTAの見せ方を調整でき、ライトモードとダークモードの個別デザインにも対応
- 広告枠別テンプレート — フィード内と結果画面で、異なるネイティブ広告デザインを使用可能
- バリエーションテスト — 2つのテンプレートを比較し、CTRとeCPMを確認してから成果の高い方を本採用
- ポリシー遵守を支える設計 — 必須の広告表記と広告主情報はすべてのテンプレートに組み込まれ、スタイル変更で非表示にすることは不可
これにより、ネイティブ広告のデザイン変更は、開発チームへの改修依頼ではなく、マネタイズ施策のテストとして進められるようになります。四半期に1つのレイアウトしかリリースできなかったチームでも、毎週新しいデザインを検証できます。こうした改善の積み重ねこそが、ネイティブ広告のeCPMを継続的に伸ばす原動力になります。
3. 地域別設定 — 市場ごとに広告体験を最適化
世界共通の広告設定では、必ずどこかの市場で無理が生じます。米国のユーザーが許容するインタースティシャル広告の表示頻度でも、セッションが短く通信速度も遅い新興市場では、ユーザー離脱につながります。Tier 1市場でeCPMを守る最低入札価格も、Tier 3市場では広告在庫が埋まらない原因になります。
ほぼすべての広告設定を、地域、国、または複数の国をまとめたグループ単位で適用できるようになりました。リクエスト時には、対象範囲が最も具体的な設定が優先されます。国別設定が地域別設定に優先し、地域別設定がグローバルのデフォルト設定に優先する仕組みです。
- 広告枠ルール — 市場ごとに広告の有効化・無効化やフォーマットの切り替えが可能
- フリークエンシーキャップとクールダウン — セッションが短い市場では表示頻度の制限を厳しく、長い市場では緩やかに設定
- 最低入札価格（フロア価格） — 国別に設定し、Tier 1市場のeCPMを守りながら、Tier 3市場のフィルレート低下を回避
- プリロード数とタイムアウト — 低速回線ではプリロード数を増やしてタイムアウトを長くし、高速回線では必要最小限に調整
- ネイティブ広告テンプレート — 現地の書体や言語ごとの文字列の長さに合わせて、市場別のテンプレートを適用
具体例を見てみましょう。米国、英国、ドイツでは、リワード広告とインタースティシャル広告を使い、クールダウンを90秒、最低入札価格を明確に設定し、プリロード数を2件にします。一方、インド、インドネシア、ブラジルではリワード広告を維持しつつ、インタースティシャル広告を3分に1回に減らします。固定の最低入札価格を外して落札しやすくし、低速回線に合わせてオークションのタイムアウトを延長。低スペック端末でもすばやく描画できる軽量なネイティブ広告テンプレートを使います。同じアプリのバイナリで、まったく異なる2つの広告体験を提供できます。
3つの機能を組み合わせるには
これらの機能は、組み合わせることで真価を発揮します。地域別設定で各市場に表示する広告を決め、プリロードで表示タイミングに間に合うよう広告を用意し、ポータルで作成したネイティブ広告テンプレートで、その市場に自然になじむ見た目に整えます。
出発点としておすすめなのは、全世界でリワード広告のプリロード数を1件に設定し、成熟市場と新興市場の2つの地域グループにそれぞれ表示回数の上限と最低入札価格を設定して、各グループに1つずつネイティブ広告テンプレートを配信する構成です。ポータルでの変更は3つ、コード変更はゼロ。細かな調整に時間をかける前に、これらの施策がアプリのARPDAUに効果をもたらすかを確かめるには十分です。
最適な広告設定とは、火曜の午後に変更して、木曜までに評価できる設定です。
導入チェックリスト
- まずリワード広告でプリロードを有効化する — 収益性が最も高く、効果も測定しやすいフォーマットです
- どの広告枠でも、プリロード数を増やす前にリクエスト数とインプレッション数の比率を1週間確認する
- アプリの文字サイズ体系に合ったネイティブ広告テンプレートを1つ作り、現在のレイアウトとA/Bテストで比較する
- 上位10か国は個別に設定せず、2〜3つの地域グループに分ける
- 各グループで一度に変更する変数は1つにする — 複数を同時に変えると、ARPDAUの変化がどの施策によるものか判断できません
- 各変更は少なくとも7日間運用してから評価する — コホートによる影響や曜日ごとの変動を見極めるには、丸1週間が必要です
3つの機能はすべて、14日間のトライアルを含む全プランで、今すぐポータルから利用できます。すでにSDKを導入済みなら、次回の設定取得時に反映されます。アプリの更新も、ストアへの再申請も不要です。
