ゲーム内広告には「2つの流行」がある　カジュアルゲームマネタイズの最前線

カジュアルゲーム、多段配信の流行

林雅敏 氏（以下、林）：次は最前線編ですね。ここからは直近で海外で流行っている事例を紹介できればなと思います。

まず1個目が「多段配信の流行」と書いてあるんですけど、先ほども言った通り、アプリの広告配信は基本的にはウォーターフォールという仕組みを取りまして、複数のネットワークを順番に当てていく方式です。

ですが、そこに何か工夫を加えるために……ネットワーク1はその中に3ついると思うんですけど、それぞれにフロアプライスを設定します。フロアプライスとは何かと言うと、3,000円でフロアプライスを設定すると、3,000円より低い広告は出さない設定をしてあります。

なので、ネットワーク1だと3,000円、2,000円、フロアプライスがなし。この3つの広告を同じ1つの事業社……Aだったら3,000円のA、2,000円のA、フロアなしのAの3つ呼びます。それをネットワークを5個入れるんだったら、5×3で全部で15個を1つのウォーターフォールの中に入れて、上から順番にリクエストを送っていく配信手法が海外で流行っています。

日本のデベロッパーもけっこう取り入れたりしているんですが、これがなぜ高いかの説明をします。買い叩かれるのを防ぐことが基本的な思想です。具体的な例で言いますと、スライド上は何もフロアを設定していないパターンですね。基本的には単価が高いものから低いものにウォーターフォールをさせていくので、上の例だと過去実績が2,300円、2,000円、1,900円だとこの順番で並べるのがセオリーです。

ですけど、それはあくまで過去実績であって、その瞬間の実際の単価はわからないわけですね。なので実際の単価価格が2,100円と2,200円だったら、この場合だと2,100円で買われちゃいますよね。ですけど、この場合だと実際に次に2,200円が待っているわけですよ。それだともったいないですよね。「なんとか2,200円を出させる方法はないのか」ということでフロアプライスを設定します。

スライド下の例ですと、フロアプライスを上げて一番上だと2,300円に敷いています。過去実績が2,300円を出すために、2,300円以下の価格はいらない設定をします。そうするとネットワーク1は2,100円しか返せないので、ここでは広告なしという結果になりますね。

ネットワーク2には2,000円でフロアプライスも2,000円で設定をしていて、実際の単価が2,200円ですと。なので2,200円が出る仕組みですね。なので究極なことを言ってしまえば、1円単位で2,000個ぐらい作ってそれを上から1個づつぐらいあてていけば、ほぼ1円単位の単価を捕捉できる。究極の話ですけどね。

ただ、そんな2,000個もやっていると広告配信が遅くなりすぎるので、実際にそんなことはしないですけど、より細かくフロアプライスを設定してなるべく買い叩かれないようにする仕組みです。これをやっている海外の事業者ですと、この1つのChainの中に40個くらいうまく入れるみたいです。40個くらいを一個一個ウォーターフォールして、なるべく買い叩かれないようにします。よりリアルタイムに単価を捕捉をするためですね。

このように過去実績でしか並び替えることができない状況の中で、リアルタイムの入札単価を把握する方法が流行っています。一応弊社でもこういう仕組みがありまして、すでに取り入れている業者も多いです。

多段配信の最適化

林：1つ気になるのが、これだけSDKを連続で呼んで広告配信が遅れないのかということですけど、この多段配信をするのは基本的には動画リワードとインターステイシャルなんですね。そのフォーマットの特徴は、動画リワードはユーザーがアプリを起動して遊び始めて、リワードを見るアクションを起こすまでに数十秒間あるんですね。

実は広告の読み込みはアプリを起動した瞬間に始まっています。なので20秒ぐらいタイムラグというか余裕がある。インターステイシャルもアプリを起動した瞬間に読み込みを始めるのでラグがあります。なので、もちろん普通の配信に比べれば、すごく時間が掛かってしまうんですけど、そのフォーマットの特性を生かしてレイテンシーに対応できます広告の配信が遅れるのをカバーしている感じです。

しかし、バナーというフォーマットは、ユーザーが広告を見た瞬間に広告の読み込みを始めるというフォーマットです。その場合だとこの配信が難しいんですが、カジュアルゲームは基本的に全画面インターステイシャルと動画リワードがメインのフォーマットですので、とくにカジュゲーに特化した配信構成になる感じですね。

多段配信をやるのはいいんですけど、そこにも最適化が必要です。何を最適化するのかと言いますと、フロアのラインをどこに引くかという話になってくるわけですよね。1,000個並べて1,000回フロアを引ければ、考えなくてもいいかもしれないんですけど、実際にフロアを引けるのは3回ぐらいです。広告配信が遅れることを考えたときには1事業者2～3回が限界です。

なので、どのフロアの引き方が収益が高いのかはもちろん検証する必要があります。これもフリークエンシーで説明したように、トラフィックを切り分けまして、どちらの敷き方が高いのかを検証して、しかもそれが日ごとに変わったりするので「どのフロアが高いのかな？」ということを日々検証します。

このへんの最適化は人がやるとものすごく大変ですので、機械的にA/Bテストを繰り返す機能を使うのがおすすめです。なので、より最適化をしようとすると、また別のパラメータが出てくる感じですね。

ヘッダービッディングの流行

多段配信が流行としてあるんですけど、その次をいくものがヘッダービッディングです。これは「ウォーターフォールを止めましょう」ということですね。上から順番に呼び出していくことは、先ほども言った通りレイテンシーも大きくなってしまいますし、なんと言ってもその広告表示の単価が何円なのかは結局わからないわけですね。

過去の実績を基にしか並び替えることができないので、それならば広告表示の度にオークションして一番高いのを出すという、シンプルと言えばシンプルな話です。なので広告表示のあったタイミングで上から順番に呼び出すのではなくて、一気に4つ呼び出します。4つ呼び出して単価がそれぞれ何円とわかるのでその中で一番高いやつを出すということですね。

これをすると、一番高いのが勝つシンプルな話なので、買い叩かれるリスクは一切ないです。こういったヘッダービッディングと呼ばれる広告配信手法がここ1年ぐらいで出てきましたね。一番良いのが、まずヘッダービッディングを行って、その次に多段配信することが、今あるベストプラクティスという感じですね。

ヘッダービッディングはGoogleもやられています。GoogleのAdMobというプロダクトもオープンビッディングというヘッダービッディングの機能を持っていたりしますし、あとはMoPubもやられています。まだ日本の事業者でやられているところはないですかね。しかし、よりリアルタイムのインプレッションごとに、正確に単価を見て一番高いものを出す流れになってきていますね。ウォーターフォールは古いという流れが徐々に出てきています。

最後、これは急に違う話になってくるんですけど、ハイパーカジュゲーは基本的にLTVとCPIのどちらが高いかを見ていますけど、それはユーザーごとにぜんぜん違うわけですよね。なので今までの場合は全ユーザー、デイリーアクティブユーザーの平均LTVとその日に取れたユーザーの平均CPIを見ていたんですけど、最近はもっと進んでいます。ユーザーごとにLTVを一つひとつ捕捉していきます。

実際にはユーザーごとにバラつきがあるわけですよね。めちゃくちゃ広告を見てくれるユーザーには高いCPIを出してもいいわけですし、広告をぜんぜん見てくれないユーザーはCPIを下げないといけないのでユーザー単位でより最適化するプロダクトが、海外だと増えてきていますね。

LTVの捕捉は、けっこう課金モデルのゲームだとストア内課金というわかりやすい指標があります。このLTVを捕捉しやすいんですけど、広告収益は捕捉が大変で、そこの部分の課題があるんです。今年に入ってから、そこを解決して捕捉できるようにしたプロダクトが海外でけっこう出てきました。

流れとしては平均LTVはもう見なくなっていって、ユーザーごとにどのユーザーがお金を落とすのか、どのユーザーが落とさないのかを一つひとつ細かく見ていく時代になるかなという感じですね。このLTVが高いユーザーを特定したあとにどうするかはあるんですけど、スライド下に書いてある通り、いわゆる優良ユーザーをセグメント化して、そのユーザーは広告をいっぱい見てくれるので、より広告を出すなどが考えられます。

LTVが低いユーザーで、あまり遊んでくれないんだったら、プッシュ通知を出してより遊んでくれるようにします。そういった打ち手に結び付けていく感じですね。

ユーザー獲得でもぜんぜんお金を落としてくれないユーザーを取るよりは、より遊んでくれてより楽しんでくれてよりLTVが高いユーザーを取るほうが効率的です。そういうユーザーをセグメント化して、そういうユーザーだけを取ることや、機械学習を使ってそういったユーザーを推定して、より長く遊んでくれるユーザーを探すという流れになってきています。

フロア設定やヘッダービッディングについて

林：いったんこんなところですかね？　ここまでで何か質問とかある人はいますでしょうか？

質問者2：さきほどのフロア設定のところなんですけど、単純に過去実績より上回ったらヒットするということですか？

林：過去実績……フロアプライスが2,300円だと、その瞬間の単価は今回だと2,100円なので2,300円を上回れなかったから出ません。

フロアが2,000円で2,200円は出せるから出します。こんな感じで、フロアプライスは過去実績と一致する必要はまったくありません。1つの指標として「これくらい出せるだろう」と。

質問者2：なるほど。

林：なので、過去実績が2,300円のところがフロア2,500円のところでも別に問題ありません。

質問者2：フロアの設定の方法はどうしますか？

林：そこがけっこう難しくて正直正解はないので、テストをする感じですかね。フロアをどこに引くべきなのかを計算で出せるのかもしれないんですけど、おすすめの方法としてはテストをする感じですね。とはいえ、それぞれの事業者ごとに出せる価格帯はある程度決まっているんですね。

低フィル高単価だと「この指標だとだいたいこのぐらい、このゲームだと出せる」みたいな実績が出てきます。「だいたい2,000円ぐらい出せますよ」みたいなところにフロアを500円とかにしていてもしょうがなくて、2,000円付近に敷くことにはなるんですけど、それがどれが良いのかは計算で出すのは難しいかなと思いますね。

最適な設定はけっこう日によっても変わると思いますので、弊社としては常にテストをすることが現状で一番良いと思っているところですね。

質問者2：ありがとうございます。あともう1点あります。ウォーターフォールで単純に全部でよーいドンでリクエストをして、それをヘッダービッディングで比較をするんですよね。これは単純にヘッダービッディングというやり方をSDKが用意したわけじゃなくて、ウォーターフォールのやり方をやめて、全部にバッと投げて取ってきて、それで比較して一番高いのを選ぶだけの話なんですか？

林：ヘッダービッディングは、SDKからネットワークのSDKを呼び出しているのではなくて、サーバ間連携をしているという感じですね。なので、これは同時に4つのSDKを呼び出しているというわけではなくて、サーバ間連携しているネットワークが4つあって、そこに通信を投げている。

なぜサーバ間連携をするかと言うと、それをしないと単価の情報が返せないんですね。単にSDKを呼び出すだけだと、呼び出したときに「何円出せますよ」という返答が……呼び出したネットワークのSDKから返す術がないので、サーバ間が連携することによってリクエストを投げてレスポンスで「何円出せるよ」と返ってくる仕組みにしているんですね。そのためにサーバ間連携をしています。

この書き方だとSDKを呼び出しているように見えてしまうんですけど。

質問者2：そうですよね。SDKを一斉に呼び出すのとどう違うんだろうと思いました。

林：そうですね。なのでこれはSDKではなくて、各ネットワークのサーバに問い合わせているみたいな感じですね。

質問者2：ありがとうございます。

単価＝CPM

質問者3：「ここまで聞いておいて、お前わかってなかったのか」と言われるかもしれないんですけど。

林：ぜんぜん大丈夫ですよ。

質問者3：一番最初のスライドで、広告のフォーマットがバナーと動画リワードと全画面インターステイシャルの3つあるとうかがったんですけど、「単価」という言葉が出てきたじゃないですか。500～3,000円みたいな単価です。あの単価のイメージが実は持てていなくて、表示されただけで単価が入るのか、クリックされて単価が入るのか、実質クリックして遷移したあとにコンバージョンされた時点で入るのか。そのイメージがわからなかったんですけど、解説をお願いします。

林：そうですね。単価は、まずこの1,000円と言っているのは、広告の場合だとCPMという概念がありまして、1,000回表示させたときに何円になるのかという指標があります。その単価はCPMなので、1,000円のものは1,000回表示させたら1,000円入ってくる。要は1回表示させたら1円入ってくるということですね。それがCPMです。

しかし、どのタイミングでお金になるかはネットワークによって違います。表示させるだけでお金をあげるネットワークもいますし、クリックして遷移したらお金をあげるネットワークもいます。クリックしてちゃんとインストールしたらお金をあげる事業者もいます。課金ポイントがいろいろありますね。

そうなんですけど、そういうものを取っ払って結局1,000回表示したときに何円になったのかがeCPMという指標です。それがスライドの1,000～3,000円、500～1,000円ですね。なので課金ポイントはネットワークによって違うんですけど、それをならしてみるために表示して結局何円になったのか、1,000回表示して結局何円になったか、その共通の指標で比較するという感じですね。

質問者3：ありがとうございます。フロア設定の表を1回出してほしいんですけど、過去実績と入札単価がリアルタイムだとズレる話だったんですが、フロアを設定する部分で、現実問題で過去実績と入札単価のズレは何パーセントぐらい変動があるんでしょうか？

林：それで言うと、そこをリアルタイムで捕捉して何円にするのかは程度的には難しいです。いくらかは正確にはわからないですね。そこが捕捉できるのであれば、そこを調整するという方法になるので。

質問者3：そうなんですよね。それが1パーセントぐらいなら別にそこまで……みたいな話になるので、フロアの設定をどれだけ細かくするかじゃないですか。

林：そうですね。フロアを設定することによってどれくらい上がるのかは他のネットワークでも実績がありまして、フロアを設定すると20～30パーセント上がった事例はありますね。なので、あるのとないのとでは単価は違う。でも、どれだけズレているかと言うと、把握は少し難しいです。

質問者3：30パーセント上がるとけっこうズレる可能性もあるということですか？

林：そうですね。それも事業者によって異なってきます。

質問者3：わかりました。ありがとうございます。

林：はい。いったん最後に、簡単にまとめさせていただきます。

「ユーザーごとの最適化」がカギ

林：基礎編のまとめとしては、フォーマットとしては3つ。1つ目はバナーと、リワード、インステがありまして、それぞれのフォーマットの特性を理解して利用するところ。

2つ目は、ネットワークの事業者に関しても基本原則、これの単価が高いものから低いものを呼び出す特性を理解してメディエーションしましょう。

3つ目はハイパーカジュゲーは、特徴としては広告ファーストのビジネスモデルです。LTVとCPIの関係性が重要となるビジネスモデルで、データドリブンで1つずつCPIを見て、次にリテンションを見て、最後にLTVを見るというデータドリブンな開発手法が特徴的です。

最前線編のまとめとしては、多段配信でフロアプライスを複数設定してそれを運用するニーズが高まってます。海外だとヘッダービッディング、サーバ間で同時にリクエストを投げてリアルタイムな単価を得る。要はフラットなオークションで、同時に戦う流れが来ています。

最後、ユーザー獲得の部分でも平均のLTVではなくてユーザーごとにLTVを出して、ユーザーごとに施行単価を変える、ユーザーごとの最適化がプロダクトとして出現しています。では、以上で発表を終わります。ありがとうございました。

（会場拍手）