リワード広告とは？動画報酬の仕組み・設計とAdMobの注意点
リワード広告は、利用者が任意に広告体験へ参加し、その条件を満たすと報酬を受け取る形式です。ただし、動画などの広告体験に報酬を付ける仕組みと、インストール等へ報酬を付ける獲得施策は同じ規則ではありません。形式、立場、報酬、計測を分けて設計しましょう。
リワード広告とは：任意の広告体験と報酬を結ぶ形式
Google AdMobのリワード広告の説明では、広告との対話に対してアプリ内の報酬を提供する形式を紹介しています。たとえば、必要な広告体験を完了すると追加ライフを得る仕組みです。利用者は参加するか判断でき、何をすると何を得るのかを事前に理解できることが重要です。
任意参加の設計は、完了率や満足度が必ず高くなるという意味ではありません。報酬の価値、案内の分かりやすさ、広告の在庫、途中終了、付与遅延によって体験は変わります。導入の効果は、実際の行動、継続、苦情などから確認します。
動画視聴型とインストール報酬型を分ける
広い意味のインセンティブ付き広告には、動画等のrewarded unitのほか、別条件を提示するofferwallなどもあります。しかし、インストールや登録への報酬を、AdMobの視聴型の付与条件へそのまま追加してはいけません。視聴完了に加えて広告クリックやインストールを必須にする設計とは分けます。
形式・立場 | 対象となる行動 | 記録するもの | 混同しないこと |
|---|---|---|---|
rewarded unit | 任意参加し必要な広告体験を完了 | 報酬獲得、付与、広告収益 | クリック・インストールを追加必須にしない |
offerwall等の獲得施策 | 契約で明示された別の条件 | 検証済みの広告主成果 | ネットワーク・ストア規則を別確認 |
広告主の評価 | 広告接触後の利用や成果 | 費用、継続、有効成果 | 広告完了を顧客獲得と呼ばない |
提供されているから自社アプリで使えるとも限りません。形式ごとの契約、対象OS、ストア規則、利用資格を確認します。
広告主・運営者・利用者・ネットワークの役割
広告主は広告費と定義済みの成果を評価し、ネットワークは広告の配信と関連する処理を担います。アプリ運営者は参加案内、表示箇所、報酬付与、エラー時の体験を設計します。利用者は提示された条件を読んで参加を選びます。立場が違えば、同じ「成果」という言葉の意味も違います。
運営者の広告収益と、広告主のインストールや継続利用は別の系列です。動画の完了数が増えたことを、そのまま広告主の有効顧客が増えた証拠にはできません。また、自然検索は質、リワードは量という固定の評価も置かず、同じ成果定義と期間でチャネルを確認します。
AdMobで認められる報酬と参加案内を確認する
報酬を提供する広告ユニットのAdMobポリシーでは、直接的な金銭報酬を認めていません。非金銭・間接報酬にも、非譲渡、運営者のプラットフォーム内での利用などの条件があります。以下はAdMob基準での教材例で、他ネットワークのルールを定義する表ではありません。
報酬例 | 扱い | 確認する理由・条件 |
|---|---|---|
非譲渡の追加ライフ | 条件を満たすか確認して検討 | 運営者内で利用、事前明示 |
現金・暗号資産・ギフトカード | 直接的金銭報酬として不可 | 別形式の規則へ一般化しない |
他人へ送れるポイント | 採用しない | 非譲渡の条件を満たさない |
視聴に加えてクリック・インストールを要求 | 視聴型の条件にしない | 形式別ポリシーを確認 |
ランダム報酬や割引には追加条件もあるため、上表だけで適否を判断しません。参加しない場合や途中で辞退する場合も、通常の利用を妨げない案内と動作を確認します。
架空例：報酬の提示・付与・エラー対応を設計する
架空の参加案内は、「広告体験を完了すると追加ライフ1個。参加しなくても通常プレイを続けられます」とします。提示時に必要行動と報酬を明示し、参加ボタンと辞退導線を用意します。在庫がない場合は、広告が表示されていないのに報酬だけを約束した状態にならないよう、待機と再試行の案内を確認します。
AdMobのサーバー側検証の説明では、署名、reward_amount、reward_item、transaction_idなどを扱います。架空の設計では、一意の取引IDと付与済み状態を台帳に保存し、再送が来ても二重付与しないようにします。クライアント側で先に付与するか、検証後に付与するかは、遅延、利用体験、不正リスクを見て決めます。SSVだけですべての不正がなくなるとは考えません。
表示・報酬獲得・付与・広告成果を別指標にする
次は同じ期間のイベントを集めた架空例です。報酬機会の提示、参加、広告表示、獲得条件の成立、実際の付与を別に記録します。読込失敗や在庫不足、重複通知は別の状態として切り分けます。
段階 | 架空件数 | 読み方 |
|---|---|---|
報酬機会の提示 | 100 | 提示の定義を固定 |
任意参加 | 60 | 60÷100＝60% |
広告impression | 50 | 参加後の読込・在庫不足は別確認 |
reward earned | 40 | 40÷50＝80% |
付与確定 | 40一意取引 | 重複callbackで二重付与しない |
80%はこの教材で定義した「報酬獲得イベント数÷広告impression数」です。公式の動画完了率や業界相場とは呼びません。40取引を40人とも言い換えず、人数を扱う場合は別の識別と重複除去が必要です。広告主の有効成果と運営者の収益も別に確認します。
ネットワーク選定と公開前の検証チェック
AdMobのほか、Unityの広告形式の公式説明にも任意参加のRewarded形式があります。現在の提供条件、対象OS・SDK、報酬ルール、審査や契約をそれぞれ確認します。過去に見かけた製品名だけを根拠に現行の主要候補として推薦しないようにします。
- 公式のテスト広告・テスト端末を使い、本番広告の自社クリックを検証手順にしない。
- 在庫なし、途中終了、アプリ中断、復帰、付与遅延を実機で確認する。
- callback、SSV、署名、取引ID、付与台帳、再送と復元を点検する。
- 公開後の収益、継続、苦情、有効成果を同条件で追う。
利用者の通常体験を守り、付与の正しさを検証したうえで導入判断をします。高い完了率や獲得効率を前提にせず、実数と未確認事項を残してください。
次に確認する内容に合わせて、Google広告の始め方｜アカウント準備と配信前の確認手順、LPOツールの比較と選び方｜機能・料金・運用条件を確認、アクセス解析レポートの作り方｜GA4指標の定義と改善提案の型、GA4の平均エンゲージメント時間｜分母・計算例・改善判断も参照してください。
