「VPAID-i」と「VAST Interactive Templates」
IABテックラボが2017年11月9日にブログで、今後の動画広告の仕様に関して重要な発表がありました。
2017年にやっとVAST3.0に対応できた〜と思っていたら、4.0どころかさらに進化するわけね。
動画広告市場は右肩あがりで順調に推移していて、
2017年はアドフラウド問題で広告業界がざわつきましたが、透明化が叫ばれる中でこうした健全化も含めた仕様が急ピッチで策定されていくのは歓迎されるべきことかと思う。
順番が前後するけど、AdExchangerによるIABテックラボのブログに対する記事で、こんな記載が。簡単に実装できそうなのは大歓迎だけど、Moat, IASの利用料はどうなるんだろう?
VPAID-Iは、視認性レポートなどの意図しないVPAIDのアクションをOpen Measurementに移動することで、広告配信の負担を軽減するようにも設計されています。
Open Measurementイニシアチブは検証を管理します。 検証プロバイダにオープンソース測定を提供することにより、ベンダーは異なるデバイスやビデオ環境に異なるSDKを活用する必要はありません。
Buchheim氏は、「Moat、DoubleVerify、IASからの新しいSDKへの更新やVPAIDへのコードの織り込みが必要だったすべてのメディアは、これをより簡単に進めることができるだろう」と語った。
以下が本題
Simplifying Video Ad Delivery – IAB Tech Lab
ざっくりGoogle翻訳+少し整形して読みやすくしました。
IABとそのメンバーは、Digital Video Ad Serving Template VAST)とVPAID(Video Player Ad Interface Definitions)仕様を組み合わせて、標準化されたスケーラブルな方法でビデオ広告を配信します。 9年目になると、成長と革新により、当初意図していなかった用途でこれらの標準(特にVPAID)が採用されました。
このため、IAB Tech Labでは、デジタルビデオ標準の展望を簡素化し、クリーンアップするために重要な動きをしてきました。
メディアは自分のページに未知の/壊れたコードを許可することを心配していて、 未知のコード、事前キャッシュできないことや、ウォーターフォール広告を要求するコードが原因でUXが壊れてしまうことを心配しています。一方、検証ベンダーと広告主は、信頼できる仕事をするためにメディアへのアクセスを増やしたいと考えています。検証ベンダーとサイト運営者は、プレーヤではなく再生コントロールを処理するためにVPAIDがどのように必要なのか一様ではありません。 クリエイティブは柔軟性が高く、インタラクティブ広告を作成する方法の制限が少ないことが好まれている。これらすべての課題を抱えて、私たちは業界として、さまざまなユースケースの明確な道筋を設定する必要があります。
VPAIDに関する注意:VPAIDはその柔軟性とその上に構築された革新性から愛されていますが、それはまた正当な理由で恐れられています。
VPAIDの2つの大きな問題は、透明性と信頼性です。
サイト運営者は、再生コントロールをVPAID広告ユニットに引き渡す必要があり、ユーザーエクスペリエンスをコントロールできなくなります。
また、ラッパーがこのミックスに追加されると、サイト運営者は広告がどこから来ているのかもわかりません。
VAST 4.0は、実行可能コードと実行可能コード(AdVerificationおよびInteractiveCreativeノード)の目的をはっきりと特定することにより、これらの懸念の一部をカバーするために昨年、大きな前進を遂げました。
現在、私たちは、デジタルビデオテクニカルワーキンググループのビジョンを完成させるために、機能固有の標準(検証とインタラクティビティのための特定の仕様)を構築し、プレーヤー中心のアーキテクチャをサポートしています。
そのために、VPAID仕様は廃止され、2つの別々の仕様に置き換えられます。
検証はOpen Measurement(OM)の傘でカバーされます。 インタラクティブな仕様にはまだ名前はありませんが、ブログ投稿では一時的にVPAID-iと呼んでいます。
配信:VAST
特に、VAST 4とそのすべての実行可能コードからのメディアファイルの分離
透明性と信頼性の問題に対処します。パブリッシャは、実行可能ファイルの目的(検証/対話性)とスクリプトのソースを識別し、実行するかどうかを決定することができます。 また、これらのスクリプトに提供されるアクセスのレベルを制御することもできます。
プリキャッシングを可能にすることによってレイテンシの問題に対処する
SSAIをサポート1つのタグがモバイル/ OTT /デスクトップで動作するようにすることで、配信を簡素化できます。
検証:オープン測定
サイト運営者と確認ベンダーのVPAIDや関連する問題はもうありません。
すべてのプラットフォーム(モバイルアプリ内だけでなく、デスクトップ/モバイルウェブ向け)の単一タグモバイルアプリ内ビデオ検証では、Open Measurement SDK(ソフトウェア開発キット)を使用して検証が行われます。
Web(デスクトップおよびモバイル)では、Open Measurement HTMLライブラリを使用してビデオ検証が行われます
目標は、モバイルとウェブの両方(そして今後のOTT)が、対応するSDK /ライブラリが自動的に取得された単一のタグを使用してサポートされることです。これは、全面的な検証を簡素化する大きな一歩となるでしょう。
検証スクリプトはVAST 4検証ノード経由で配信されるため、信頼性は容易に確立されます。
インタラクティブ機能:「VPAID-i」と「VAST Interactive Templates」
VASTインタラクティブテンプレート - エンドカードのような基本的なインタラクティブな体験。
これらはスクリプト可能ではなく、UIアセットを取得しインタラクティブな体験を提供するためにパブリッシャーのサポートが必要です。私はこれらの拡張機能のいくつかを標準化し、これらを拡張して利用できるようにする提案を見ている。
ここでの大きな利点は、UXを管理しているためにパブリッシャーが公開しやすくなり、JSが利用できないOTTやその他のプラットフォームへのアクセスが可能になることです。
「VPAID-i」を使用して、高度な/没入型のインタラクティブな体験を構築します。
「VPAID-i」は、いくつかのコアアーキテクチャーの目標を念頭に置いて取り組んでいます。
サイト運営者がユーザーエクスペリエンスをコントロールし、そのページで何が実行されるのかを示すVAST 4ベースの「プレーヤー中心」モデル。広告ユニットがページ/アプリを「引き継ぐ」ことはないと確信できます。SSAIのサポート
モバイルとOTTを含むすべてのプラットフォームをサポート
VPAIDの検証やその他の非公式な使用をサポートするための制約がなくなり、要件が大幅に簡略化されます。
すべてのプラットフォーム用の単一タグ
「VPAID-i」とVASTテンプレートの両方の目標は、広告主様がインタラクティブな動画広告用に1つのタグを作成できるようにすることです。
私たちが目指す方向性の主なテーマは、透明性、信頼性、クロスプラットフォームのサポートです。
サイト運営者はページやユーザーエクスペリエンスをより適切に管理できます。
レイテンシの問題と壊れたコードの問題を大幅に改善します。
また、ブラックボックスのミステリーコードがページ上でフルアクセスで実行されることはありません。
また、検証や対話性、あるいはその両方をサポートすることもできます。
検証ベンダーは不要なコード(VPAID)の実装について心配する必要はありません。彼らは今、メディアがコードへのアクセスをより多く提供できる「信頼できる」ベンダーになるプロセスを持っています。購入者にとってより簡単なフロー、視認性データへのアクセスの向上
すべてのプラットフォームで機能するインタラクティビティの方が優れています。
どのユースケースにどのテクノロジー/標準を使用するかについての明確さ。
今、企業は何をすべきか?
配信:VASTに変更していない場合は、VASTに変更します。
VPAIDがVASTタグ内に埋め込まれていることを確認します。
VAST 4を早急にサポートすること。OMはVAST 3.0 / 2.0(拡張機能を使用)でも動作しますが、コード分離をネイティブにサポートしているため、VAST 4のサポートを同時に開始することは理にかなっています。インタラクティブと認証コードからメディアファイルを分離するだけでなく、ユーザーエクスペリエンスは向上しますが、OTTデバイスとSSAIをサポートすることができます。
インタラクティブ機能:可能な場合はVPAID 2.0(JS)を使用し、アウトストリームのシナリオについてはMRAIDを使用します。並行して、エンドカードなどの簡単なインタラクティブな体験のためのVAST拡張機能をご覧ください。あなたの課題を特定し、「VPAID-i」と「VAST対話型テンプレート」を構築するのに役立ちます。
検証:すぐにOpen Measurementに移行する作業を開始します。私たちが最近リリースしたモバイルSDKと、まもなくリリースされるWebビデオ提案を見てください。
OTT:OTTテクニカルワーキンググループは、2018年初頭に検証と相互作用を検討しています。私たちと一緒に、OTTの規模を拡大する準備をしてください!
動画リワードにおけるeCPM基準、Viewableとは?
動画リワードで各アドネットワークの収益性を判断する一つの基準として、eCPMがある。
静止画と動画の違いだけでなく、動画リワードという特殊な広告の場合、どのようなポイントが重要となるのか考えてみる。
静止画広告の時代
まだモバイルバナー(320x50)全盛の時代、各アドネットワークSDKをメディエーションしていた頃(その後JSやAPI連携が主流に)アドネットワークが集計したレポートを元にeCPMを計算して、その収益性からアドネットワークの配信割合が決定されていた。
ところが、広告の表示回数を意味するインプレッション(IMP)が、アドネットワーク各社で10倍〜100倍違っていたようだ。
まさかと思うが、本当にそれぐらいの差異がでていたようで、一体何を信じて収益性を判断すればいいのか?と悩みながら、辿り着いた答えが自ら広告が表示される際にインプレッションを計測すれば、どのアドネットワークが何回表示したのか公平に把握できたそう。
自ら計測したIMPとアドネットワークのレポートから取得した収益を元に、eCPMの比較が公平にできた。
Viewablility
昨今、Viewabilityが重要ということが声高に叫ばれているかと思います。
モバイルアプリのガイドライン
50% of the ad’s pixels for 2 continuous seconds for video
動画の場合は、50%以上の領域でクリエイティブが表示され、2連続秒再生されればViewableと、IABは定義しています。
表示領域50%以上で2連続秒表示されればOKというのは、あくまでもクリッカブルであるということが前提であり、重要だと思われます。
動画再生中は画面をタップしてもストア・LPに遷移できない動画リワードのViewableはどう判定されるべきでしょうか?
動画リワードのViewableの定義は?
動画リワードは勝手に表示される広告ではなく、ユーザーの同意を得て表示されるタイプの広告です。
視聴完了してインセンティブをもらうことを約束して観るのに、途中で離脱、スキップ、キャンセルするのであれば、それは広告を観なかったとみなしてもいいのではないでしょうか?
強制的に観せられた広告(インセンティブを貰えるというポジティブな感情で広告を観ていない)を途中で閉じるのとは意味が違う。
動画視聴完了に至らないケース
1.ユーザーが自らの意志で動画視聴をキャンセルする(インセンティブ放棄)
2.電話やLINEなどの通知があり、他のアプリに切り替えて忘れる。電車の乗り換えで端末をスリープにして、ロック解除&復帰してもPUSHノーティフィケーションなどで他のアプリに移動されてしまう。(忘却)
3.動画再生プレーヤーなどの不具合、通信環境による問題。
4.不正(ad fraud)
出稿側の立場からすると、「全画面表示で100%視聴完了するから効果が高い」と説明されるのに、最後まで視聴完了しなければストア・LP遷移できない数字を元にCV、CVRなど計算されても意味がない。
※一部アドネットワークでは途中キャンセルしてもストア・LPに遷移可能なアドネットワークもある。途中キャンセル自体が普通に動画をみているだけでは表示されないので特殊な事例。
それはクリックできない画面領域外で表示されたモバイルバナーの価値を認めないのと同じで、動画リワードでクリックできない(Viewableでない)のを指標にされても意味が無いということ。
やはりクリッカブルでストア・LPに遷移して、コンバージョン達成できる状態である視聴完了をベースにしたeCPM計算が正しいのではないか。
ただし、一つだけ注意しなければいけないことがある。視聴完了率だ。
動画リワードは完全視聴が条件で観るので、95%以上の視聴完了率なのが当たり前で、あまり気にしたことがなかった。
2016年真夏の猛暑日に、メディアさんから相談があるとランチミーティングをした。
自社メディエーションツールでマネタイズしていて、アドネットワークの配信比率を計算していたようなのだが、あるアドネットワークが収益性が高いので配信割合を多くしたのに売上があがらず、様々なデータを調べたところ視聴完了率が80%になっていて、気がつくまで時間がかかって損をしてしまったと。
アドネットワーク各社のIMPの基準はどこなのか?教えてと言われたことがきっかけで真剣にeCPMの基準は視聴完了にすべきでは?と考え始めた。
アドネットワークの仕様をみていても、eCPM算出根拠としている数値は3つある。
表示開始(SHOW)、視聴開始(START)、視聴完了(FINISH)の3つ。
表示開始(SHOW)
動画がまだ再生されていない状態。アドネットワークによってはエンドカードを組み立ててから(表示は一瞬で気がつかないレベル)動画が再生される。動画再生プレーヤーがクラッシュなどで視聴完了しなかった時は、表示開始だけしか発生していない状態になる。
視聴開始(START)
動画再生プレーヤーで動画が流れ始めた状態。視聴完了する前までに、ホームボタンを押下したり他のアプリに切り替える、端末スリープする、割り込み(電話、LINEなど)があった場合は動画再生が一時停止する。アプリに復帰すれば、自動で動画再生が再開する。
視聴完了(FINISH)
ここまで到達できるとユーザーにインセンティブが付与される。エンドカードが表示されて、タップしてストアやLPに遷移するか、閉じるボタンでアプリに戻る。
※エンドカードを閉じないと視聴完了通知がこないアドネットワークもある。
収益性が高いからと言って、配信割合を増やしても売上が増えなかったとしたら視聴完了率を確認する必要がある。
95%以下になったらアラート、90%以下になったら何か不具合が起こっている可能性があるので要注意。
視聴完了率の低くなったアドネットワークがあったら、手動で配信比率固定にして様子を見たほうが良く、クラッシュログが取れているのであれば、端末やOSバージョンを特定して、アドネットワークに報告すると検証してくれる。
動画リワードの初期化メディエーション
正式名称:アプリ起動時 アドネットワークSDK 初期化メディエーション
という長い名前の機能が生まれたきっかけはこちらの記事を読んでください。
動画リワード広告はモバイルバナー広告とは違い、広告を表示する回数が極端に少なくなる。
広告を視聴するかわりにインセンティブ(アイテムやポイント)を得られることにユーザーが同意しなければ表示されないというのが1番大きな理由である。
表示される回数が限られていて少ない上に、せっかくユーザーの同意が得られたのに在庫が無い状況だとしたら、その機会損失は大きい。
メディアが広告収益を得られなかったという直接的な金銭的ロスだけではなく、ユーザーにインセンティブを与えることでアプリの起動回数・継続時間が伸びて、結果LTVが向上していくことに繋がるチャンスを失ったかもしれないということ。
例えば、アプリが1日に1回しか動画リワード広告を表示するチャンスがないケースも考えられる。
・1日1回ログインボーナス:動画視聴すれば更に2倍!
必要とされたときに、広告在庫が無かったでは困る。
広告在庫があるという状況を確かなものにするには、事前にアドネットワークのSDKを初期化しておくことが重要です。
アプリ起動時に、アドネットワークSDKを初期化する意味
マネタイズだけではなく、アドネットワークの管理画面から広告を出稿している場合、アドネットワークSDKがサードパーティーの計測ツールを使わずに、コンバージョン計測可能。
コンバージョンを計測するには、アプリ起動時に初期化しなければいけない。
初期化メディエーション3種類のモード
何も考えずに 初期化してしまうと、ユーザーはパケ死してしまうので注意が必要。
この機能は実装が必須ではないので、使う場合はよく理解したうえで使ってもらいたい。
【ALL】全て初期化する
全てのアドネットワークSDKを指定された間隔(4秒〜60秒)で実行します。
Wi-Fiかキャリア回線かを考慮しないで、とにかく全てのアドネットワークを初期化することを優先するモード。
動画ファイルの読み込みに時間がかかった場合は、以下のように処理が被る。
【WEIGHT】配信比率の1番高いものを1つ選んで初期化する
サーバーでeCPMを元に決定されたアドネットワークの配信比率から、最も収益性の高いアドネットワークを1つ初期化する。
配信比率が全く同率だった場合はどうなるか?
広告リクエストする度にサーバーで表示する順番を決めてくれているので、1番上を優先して選択するようになっている。
特定のアドネットワークだけを初期化したい場合は、管理画面にて手動で配信割合を1番大きくしておけば、毎回必ず最上位で返却されるので、特定のアドネットワークを初期化できる。
【AUTO】接続環境によって、ALLかWEIGHTを自動的に切り替える
以上で、3つのモードについての説明は終わり。
ここからは開発していく上での仕様上悩んだところや、今後の更なる最適化についての考えなど。
ALLについて、各アドネットワークを初期化するタイミングで回線チェックし、Wi-Fiでなければ初期化せずにスキップするよう実装したのだが、ALLというモード名から期待される動作(全てのSDKが初期化される)が違うのもどうかと言うのと、AUTOとの機能差があまり無くなってくることから回線チェックはしないように戻した。
この辺の細かい仕様に関しては、メディアさんからの要望によって変えていくかもしれない。
一定間隔での初期化実行
一定の間隔(4秒〜60秒)で初期化していくことに関してすぐに思いつくことが、初期化完了したかどうかをリスナーで受け取ってから、次のアドネットワークを初期化したほうが重複して処理が行われないので安全ではないか?というつっこみ。
ネットワーク回線状態が悪く、初期化に時間がかかりすぎていた場合、初期化メディエーションを作った理由の1つである、コンバージョンを計測する意味から遠くなる(アプリ起動時から時間が経ちすぎる)ので、ある程度の秒数以上は設定できないように最大60秒とした。最小値4秒は初期化が同時に動いてもクラッシュしないギリギリの数字。
AppLovinのコンバージョン計測に特化した機能を使う場合は、
・WEIGHTモード
・最小値0秒
・管理画面にて手動でAppLovinを配信比率1位に固定
にする必要がある。
さらに、マネタイズはせずAppLovinの広告出稿だけにしか使わないケース(計測ツールとしての機能。そんなケースがあるのかわからないが。。無いとも言い切れない)があれば、AppLovinが持っている機能で、初期化時に素材をダウンロードしないという(Android)setAutoPreloadTypes、(iOS)autoPreloadAdSizesにNONEを設定で可能となるが、これが必要になるケースがあまり想像できなかったので実装はしなかった。
※初期化時に素材をダウンロードさせなくできる機能はAppLovinだけに存在する機能。
動画リワードのアドネットワークSDKを初期化メディエーションするに至ったきっかけ
動画リワードのSDKを初期化するタイミングについて、アドネットワークさんと議論している時に、メディエーションできるのではないか?と、気づかされて機能を作るまでにいたったきっかけを忘れないように書いておく。
動画リワード広告の大きな特徴として、動画ファイル(1ファイルにつき2M〜6M)を事前にダウンロードしておくことで、広告表示するときにスムーズな動画再生が可能にしている。
せっかく見てもらう広告が回線状況が悪く、少しずつ動画ファイルを読み込みながらカクカクとコマ送りで再生されるのであれば、ユーザーはストレスを感じながら広告をみるので広告の魅力は半減してしまうし、広告効果(コンバージョン)にも影響があるだろう。
なので、事前にアドネットワークSDKを初期化して重い動画ファイルを読み込んでおけば、広告を表示したいタイミングでスムーズに再生される。
しかし、アドネットワークのSDKを初期化するタイミングは難しい。
何も考えず、アプリ起動時に全てのアドネットワークSDKを初期化してしまうと、動画リワードを利用しないユーザーにとっては不要なファイルを読み込まされてしまう。接続がWi-Fiでなければ、パケ死してしまうかもしれない。
インセンティブを与える機会が多いアプリの場合、例えば1日に見ようと思えば100回以上も動画リワード広告を視聴できるゲームもある。
このようなアプリの場合は、最初の何回か読み込みに失敗したとしても、そのうち時間が経てばアドネットワークSDKの初期化が完了するので、ユーザーも数分後に動画を見れることからクレームになりづらい。
逆に、1日に1、2回しか動画リワード広告を出すタイミングが無いアプリだった場合は?
動画を視聴することで、1日1回限り「ログインボーナスでポイント2倍!」、「1時間有料機能が開放!」など
このようなインセンティブ付与の場合、動画が読み込めませんでしたでは済まない。もしそのタイミングで広告在庫が無かったら、ユーザーのがっかり感からストアのレビューが低くなってしまうかもしれないし、サポートへお問合せが殺到するかもしれない。
今まではアドネットワークのSDKを初期化するタイミングというのは、アプリによってケースバイケースで、メディアさん側で決めることとして、求められればアドバイスする程度であった。
アプリ起動時に初期化するなら、アプリで使用するダウンロードしなければいけない重い処理やデータを読み込むことがあれば注意しなければいけなく、初期化するタイミングは少しずらしたほうがよいとか、
ゲームであればゲーム完了時に動画リワード出すのであれば、ゲームがスタートしたと同時に初期化するでも良いなどアドバイスしていた。
まだ動画リワードの市場が小さく、アドネットワークの数も広告在庫も少ない、フリクエンシーキャップが厳しくかかっていた時代であれば、複数のアドネットワークをユーザーのパケ死リスクを多少犠牲にしてでも呼び出す必要があったが、昨今の動画リワード市場の盛り上がり、在庫の豊富さや、フリクエンシーキャップをより細かく設定できる機能があることから、もっと最適化できる部分があることにやっと気がつけた。
メディエーションツールを作っていく過程で、メディアさんに提供するサンプルアプリを作って動作確認するのだが、過剰に動画ファイルを読み込まないようツールとして気を遣えば遣うほど、動画ファイルの読み込みを待たなければいけないジレンマに陥ることになる。
各アドネットワークが提供するサンプルアプリやAPI Referenceを読み解いていると、AppLovinのサンプルにはこう書かれている。
iOS-SDK-Demo/ALDemoAppDelegate.m at master · AppLovin/iOS-SDK-Demo · GitHub
// Initializing our SDK at launch is very important as it'll start preloading ads in the background.
アプリ起動時にAppLovinのSDKを初期化するのは、バックグラウンドで広告を事前に読み込み始める為に重要なことです。
さらに、AppLovin SDKはマネタイズだけでなく、AppLovin管理画面から広告出稿を行う場合に計測ツールとして使うことも出来る (サードパーティSDKでのトラッキングも可能) 、アプリ起動時にSDK初期化をしておく必要があるケースもあるとのこと。
これがきっかけで、事前にアドネットワークを初期化したらどうなるのだろうと、全てのアドネットワークをアプリ起動時に初期化を実行したところ、あまりの広告表示の快適さにユーザーのパケ死を無視したくなりそうな、禁断の果実っぷりを体験することになる。
この体験を元に、もう少し踏み込んでツールとしてSDKを初期化すること自体メディエーションできるのではないか?と、考えた結果が「アプリ起動時 初期化メディエーション」という長い名前の機能を開発するきっかけ。
細かい機能の説明については、セミナーで発表予定。
【小ネタ】テストでハマったしょうもないこと
開発しながらシミュレーターや実機端末で、再現するまで時間をかけてテストを繰り返すことは避けられない業種である。
人間は疲れた状態だと普段はすぐに気がつけるのに、度々しょうもないことで何時間、ときには何日もハマってしまうことがある。
こんなことでハマったのかよと、笑われるの覚悟で公開。
1.Android端末でモバイルデータ通信がOFF
ステータスバーの電波強度がMAXなのに、インターネットに繋がらない。なぜ?
※iPhoneならダイアログが表示されて、モバイルデータ通信がOFFですよと設定に誘導してくれる。
動画を視聴する機会が増え(視聴しなくてもバックグラウンドで読み込んだり)、パケ死対策としては、モバイルデータ通信をOFFにしておけば、勝手にキャリア回線に切り替わって、大量のデータ通信が発生しないので安全である。
パケ死対策としては最強だけど、見た目でモバイルデータ通信がON/OFFどちらなのかわかりにくい機種もある。
モバイルデータ通信がOFFになっているのか切り分ける方法としては、WIFIをOFFにして、キャリア回線で繋がるはずなのにインターネットに通信するアプリ(ブラウザとか)が動かなかったら、モバイルデータ通信がOFFになっていないか疑えば良い。
SO-02Hの場合、設定→その他の設定→モバイルネットワーク→モバイルデータ通信
という深い階層までたどらないとON/OFF設定を切り替えできないので、この機能のことを知らずに(家族とか友だちが)設定をOFFにしたら、気づきにくいと思う。
ただし、ステータスバーにモバイルデータ通信が無効ですと表示してくれるのが救い。
2.機内モードでもネットに繋がる
機内モード(airplane mode)に切り替えると、WIFIやキャリア回線、ブルートゥース、GPSなど電波系の機能はOFFになる繋がらなくなると、長年思っていたのですが。。
機内モードにした後に、WIFI接続することが可能なのですね。。
どういう利用が想定されるのかというと、
・飛行機内で提供されるWIFIに接続する
・ゲームに集中したいので、電話に出たくない
などでしょうか。
久しく飛行機に乗っていないので、飛行機内でWIFI接続できるのかわかりませんが、日常生活において利用できそう。
例えば、仕事の打ち合わせ中は機内モードにしてWIFIだけ接続しておくとか、アプリの挙動確認はできるのでいいかもしれません。
SDK開発のときに、機内モード判定して、機内モードがONだったらインターネット通信できない(と思い込んでいた)から、外部サーバへのリクエストをしないという処理にしようとしていたのですが、エンジニアからの指摘で気がつけた。
その他思い込み系
設定系ファイルAndroidManifest.xml記載漏れ。マニュアル通りに記載済みだと思いこんで、もう一度確認すると、あれ??ということもよくある。
記載のとおりにコピペしたんだから、書いてないわけないだろうとダブルチェックすると、書いてない。。
全画面ではない動画リワードの独特な観せ方 SWAMP ATTACK
動画リワードで珍しい見せ方をしているアプリがあったので紹介。
タワーディフェンス系のゲームのSwamp Attack。
キャラを出動させて相手の城を攻め落とすということではなく、攻撃から耐えるのみで防戦する一方なのだが、武器やアイテムをせわしく切り替えながらモンスターを倒して殲滅するのは爽快。
動画リワードがでてくるのは、常設のポイントが貰える枠と、ゲームをクリアした後に取得したコインを2倍にできるという2箇所。
ゲーム終了後にコイン2倍にするのは頻度をコントロールしながら、5回に1回とかだしてもいいと思うのだが、最初だけ数回トライアル的に出てきて、以降はほとんどでなくなってしまった。コイン2倍にするのは有料アイテムとして売っているからかもしれない。
5回に1回でも動画視聴で2倍のチャンスをくれれば、みんな喜んで動画リワード観ると思うけど、課金と動画リワードでマネタイズ比べた結果かもしれないのでなんとも言えない。
以下は「常設ポイント枠」の説明と、ゲーム終了後に「コイン2倍」を分けて説明します。
スワンプアタック (Swamp Attack) - Google Play の Android アプリ
メディエーションはmopub。
動画リワードのアドネットワークはAppLovin、Bee7、Supersonic、Vungle、Chartboost、UnityAdsが入っている模様。
常設ポイント枠
赤で+50となっているのが、動画視聴すると50コイン貰えるという意味。
1度視聴すると、+50の表記が消えて以降は何回観ようがコインは貰えない。
インタースティシャルのような領域で動画が再生される。
音声ON/OFF、秒数カウントダウンもあり。
バツボタンがついているので終了すると、
動画を最後まで観るように促され、見続けるボタンで動画を再開。
最後まで視聴すると、50コインゲット。
どこのアドネットワークが配信しているのか調べてみると、Bee7という初めて聞くアドネットワーク。
アプリインストール後に、ユーザーが毎日アプリを起動したかチェックして、起動しなかったらインセンティブ(コインなど)をプッシュ通知でお知らせするという、リエンゲージメントが特徴だそう。
動画配信はHLS(HTTP Live Streaming)形式。
スマホ端末はWIFIで繋いでいる状態で、動画を再生する時点では低回線向けのtsファイルが2つほど読み込まれて、その後ファイル容量の重いものに切り替わって再生されていた。
1.最初に低回線向けを再生
stream-1-90000/index.m3u8
stream-1-90000/frag-1.ts ←ファイル容量 50K
stream-1-90000/frag-2.ts
2.途中から帯域幅(Bandwidth)の大きい高回線に切り替わる
stream-1-1300000/index.m3u8
stream-1-1300000/frag-1.ts ←ファイル容量 300〜400K
stream-1-1300000/frag-2.ts
〜
stream-1-1300000/frag-11.ts
ただ、インタースティシャルの小さい枠で動画を再生されると、普段フルスクリーンで観ているので、どうしても見劣りしてしまい、訴求力が全然違うんだなというのが良くわかる。コンバージョンが少し悪くなるのではないだろうか。
ゲーム終了後に動画視聴でコイン2倍
ゲームをクリアすると、おそらくおためし的な意味合いとして広告をみると、獲得したコインを2倍にできるよ?というインセンティブが提示される。
「広告を見る」で、フルスクリーンでの動画視聴が始まる。
今回は、アドネットワークVungleが選択されて、「WAR OF DRAGON」の案件が再生された。
Vungleの動画クリエイティブのクオリティが高いのはもちろんのこと、エンドカードもアニメーションするようになっていて、デザインが綺麗。
動画リワードの広告を閉じると、2倍の報酬がもらえる。
そして、AdmobかどうかはわからないがGoogleの動画も配信されていた。
iOSとAndroidの両方共、フッターにApp Store(Google play)のバナーとインストールを促すボタンが表示され続ける。
iOSに限っては動画再生される領域が、左にアプリアイコンレビューなどが表示されていて、さらに狭くなっている。
動画再生と同時に画面右上で5秒間のカウントダウンが始まる。
5秒後はいつでも動画を閉じることができる。完全視聴しなくてもいいのが他社とは違うところ。
エンドカードはこのような感じ。
動画再生領域が全画面ではない動画リワードという意味では、Bee7とGoogleを紹介した。
メディアにとって収益性が高く、広告主にとっても広告効果が高いという理想に近づけるのか、やはり今までの全画面で強制的に100%視聴させるのがいいのか、興味深い。
動画リワードを激推しNo.1アプリFlip Diving
動画リワードを視聴させるのにここまでやるか〜という、最たる例のアプリを見つけたのでご紹介しよう。
動画リワードを人に説明する時に、実際に動画再生できるインセンティブを得られる状態にするまで時間がかかってしまいやきもきするが、このアプリならすぐに動画再生されるのでオススメ。
Flip Diving - Google Play の Android アプリ
ゲームは至ってシンプル。崖や木の高い所から飛び込みをして、水面に足、頭から着水すればOK。腹や背中から落ちるとアウト。また、1回も回転しないで着水するのと、タップしたままで回転しっぱなしで着水も失敗となる。
失敗したければ、ワンタップで放置すれば飛び込み失敗する。
Spin Now!(ガチャ)、Activate(飛び込んだときに空中に浮かんでいるコインが吸い寄せられてゲットできる)があるが、まずはActivateを選択。
動画を読み込むローディングが表示され、読み込まれた時点で広告が表示される。
※タイムアウトか、在庫が無かったら表示できる広告無いよというダイアログが表示される。
メディエーションはfyberを使っていて、設定されている動画リワードのアドネットワークは5社。
AdColony、ChartBoost、SponsorPay、UnityAds、Vungle。
今回は動画視聴を完了すると、インセンティブである5分間コインを吸い寄せる磁石アイテムをもらえる。
普通に高いところから回転しながら飛びこんでいくと、すぐに失敗する。
すると、いま動画をみると木箱がもらえて2倍のコンテンツになるよ?と、猛烈アピールされる。※木箱がどんな効果なのかよくわからないが。
動画を視聴した後でも、Watch Anotherでまだまだ視聴を進めてくる。
ふー、やっと動画を勧めて来なくなったかなとおもいSpin Now!を選択すると、
ガチャがメインではあるが、
右下にView Videoのボタンが。。どんだけ動画再生させたいんだ!
気を取り直してゲームを進めていくと、3回着水に成功すると次のRoundに行けるが、次のRoundで失敗すると、体感2〜3秒以内にSave Me押さないと1Roundからやり直しになってしまうローディングがカウントダウンする。
焦らされるので、つい押して動画を再生してしまう。
最初からやり直すの面倒くさいし、即決で判断しないと1ステージに戻されてしまうという脅迫めいたやりかたがえげつない。
みんな押してしまうと思う。
※動画をみすぎると、有料アイテムのTicketでないとSAVEできないときもある。
その後、意地になって動画在庫が枯れるかキャップにかかるまで観まくってやろうと思ったけど、50回は観たけどダメだった。
これだけ動画みせまくると広告効果としてのコンバージョンは悪いと思うんだけど、このレベルまで動画を観させられる実装は逆に清々しささえある。