目次

まえがき

第1章 A/Bテストを知ろう

1.1 A/Bテストの基礎知識
1.2 A/Bテストが必要な理由
1.3 A/Bテストすべき項目例
1.4 A/Bテストの流れ
1.5 A/Bテストで気をつける点

第2章 実験を使おう

2.1 実験とは
2.2 実験の登録
2.3 実験の結果を見る
2.4 タイトルデータのオーバーライド
2.5 除外グループを使おう
2.6 プログラムからのアクセス

第3章 プッシュ通知を使おう(iOS)

3.1 プッシュ通知とは
3.2 事前準備
3.3 プッシュ通知テンプレートの登録
3.4 クライアント側の実装
3.5 テスト動作確認
3.6 セグメントとプッシュ通知の連携
3.7 プッシュ通知のローカライズ
3.8 サーバー処理からプッシュ通知を送る方法
3.9 プッシュ通知のONとOFF

第4章 プッシュ通知を使おう(Android)

4.1 事前準備
4.2 クライアント側の実装
4.3 動作確認

第5章 不正プレイヤーをBANしよう

5.1 BANとは
5.2 不正の検知を自動化する
5.3 ユーザーから不正や違反を報告してもらう
5.4 不正ユーザーのデータを除外する
5.5 不正ユーザーのランキングをリセットする

第6章 おまけ

6.1 APIのエラーハンドリング

付録A 参考文献

A.1 A/Bテストを知ろう
A.2 実験を使おう
A.3 プッシュ通知を使おう(iOS)
A.4 プッシュ通知を使おう(Android)
A.5 不正プレイヤーをBANしよう
A.6 おまけ

あとがき

まえがき

 本書を手に取っていただき、ありがとうございます。

 近年、IT業界では「ノーコード」「ローコード」という言葉が流行っています。画面上の設定だけでアプリやサービスを作れるツールがどんどん出てきていて、コーディングをすることなく誰でもアプリを作成できるというものです。また、少しコーディングが必要なものは、ローコードと呼ばれます。今後はさらに発展して、もっと複雑なアプリを作れるようになるのも遠い未来ではないと感じています。「コーディングをできるだけ少なくして、同じものを作る」という動きが活発になっているのは、間違いありません。

 そんな中で、「ゼロから全部自分で実装したい」という人もいると思います。実装力が上がることは間違いありませんが、どうしても多くの時間が必要です。実装だけでなく、詳細なテストも実施しなくてはいけません。「アプリを完成させる」という目的があったとすると、できあがりが同じものなら、簡単に作成できたほうがいいですよね。これはつまり、実装量が減ってテストも減り、品質が上がり、短納期でリリースできるということです。特に、ユーザーの目に触れないバックエンドの部分については、他のアプリとの差別化ができません。差別化できるのは、UIやゲーム性の部分です。ゲーム開発において、差別化できる部分に多くの時間を割くことが重要になり、それを実現させるのが「PlayFab」ということになります。私はこれまで、「入門」「自動化編」「ソーシャル編」と書き進め、バックエンド開発がいかに簡単になるかを解説してきました。これまでの書籍をご覧になった方であれば、PlayFabを使うことがどれだけ自分の時間を増やすことになるのか、ご理解いただけていると思います。

 本書は、PlayFabを使って実際にリリースしたい人に向けて執筆しました。公式ドキュメントからは読み取りにくい内容についても、独自に調べて解説をしています。A/Bテストと実験機能の解説については、特に力を入れました。ここまで踏み込んで解説をしている人は、他にいません。正直なところ結構な時間をかけてしまいましたが、かなり濃い内容に仕上げることができました。単純な使い方だけでなく、事前に必要な知識と実際の運用も考えて解説しています。

 私はPlayFabの勉強に「160時間以上」を費やし、理解するのにかなり苦戦しました。みなさんが同じように時間を使わなくて済むように、情報を凝縮してこの本にまとめています。いろいろとつまづきながら学習した経験から、図も多めに使用し、わかりやすさと見やすさにこだわって書きました。この本を読むことで、PlayFabにかける勉強時間を少なくして、ゲーム開発の部分に時間を割くことができると思います。この本が少しでもみなさんのためになれば幸いです。

 PlayFabのことを教えてくださった方々、普段の発信をシェアしたりコメントしてくださる方々、応援してくださる方々のおかげで、本書の執筆にいたることができました。深く感謝いたします。

ねこじょーかー

本書の目的

 本書の目的は、PlayFabを使ったゲームのリリースを考えている人が、実験機能やアカウントBAN機能を理解して、使えるようになることです。実験機能については情報が少ないですが、理解しておくとリリース後により良いゲームにすることができます。基本的な機能だけでなく、運用を見据えた使い方を理解したい人にとって、この本はぴったりです。

本書で得られること

 ・A/Bテストの知識

 ・実験の知識

 ・プッシュ通知の知識

 ・アカウントBANの知識

対象読者

 ・PlayFabを使ったゲームのリリースを考えている人

 ・リリース予定はないが、知識として知っておきたい人

前提知識

 本書は、以下の知識がある前提とします。UnityやC#の説明は省き、PlayFabに特化した説明をしています。

 ・Unityのビルドまわりを理解している、または自分で調べて進められる

 ・C#の基礎文法はひと通り覚えている

 ・PlayFab の基礎知識に加え、サーバー処理を理解している

使用したソフトウェアのバージョン

 本書では以下のバージョンを使用しています。PlayFabSDKは最新のバージョンを使用して構いません。Unityのバージョンも特に揃える必要はありません。

 ・Unity 2019.4.1f1

 ・PlayFab SDK 2.89.200629

 ・PlayFabAllSDK 1.77.200730

第1章 A/Bテストを知ろう

 PlayFabでは、A/Bテストを実施することができる実験機能が用意されています。その前段階としてA/Bテストの知識が必要になるので、本章では、A/Bテストの概要について解説していきます。

1.1 A/Bテストの基礎知識

 いきなり「A/Bテスト」と言われても、ピンとこない人がほとんどでしょう。まず、A/Bテストの基礎知識についてまとめておきます。PlayFabの実験の登録方法を早く知りたい人は、読み飛ばして構いません。

 A/Bテストユーザーをランダムに振り分けて、あるユーザーにはAのパターンを見せて、別のユーザーにはBのパターンを見せるというテストのことです。AやBのことを「バリアント」と呼びます。AとB、どちらのバリアントの反応が良いのかを比較するものです。

 開発者側がユーザーにやってほしいアクションを達成する確率のことを、「コンバージョン率」といいます。ゲームであれば課金率が一般的な評価の軸です。もちろん、ゲーム性が面白いかどうかで課金率が変わってくるのは言うまでもありませんが、ゲーム性以外の部分で課金率が変わることがある、というのも事実です。例えば、ボタンの色によって変わったり、表示している画像によって変わったりなどです。こういったことは、実際に実験をしてみないとわかりませんが、簡単な変更でコンバージョン率が上がるのであれば、それに越したことはありません。むしろ、A/Bテストをせずに運営しているということは、本来取れるはずのコンバージョンを取りこぼしているということになります。A/Bテストを実施することで、コンバージョン率を高めることができるだけでなく、ユーザーの行動を理解することにも繋がる、ということです。

 A/Bテストを実施する期間は、一般に2週間以上必要だと言われています。期間が短いと取れるデータ量も少ないという理由もありますが、UIやデザインが変わったタイミングで、ユーザーが変わったことに気づき、「新しい」というだけで反応が良くなる可能性があります。つまり、Bの方が反応がいいと思って変えたものの、長期的に見ると実際はAの方がいい、という場合があるということです。

図1.1: A/Bテストのイメージ

1.2 A/Bテストが必要な理由

 「でも、A/Bテストってやる必要あるの?」という疑問に答えるため、A/Bテストはなぜ必要なのかという点について解説します。

ユーザーが感じた問題点を解決するため

 ゲームを遊んでくれているユーザーが、「わかりにくい」と感じた点について、ユーザーからフィードバックをもらうのは困難です。仮にもらえたとしても、その数はかなり少ないでしょう。また、一番やっかいなのは、「ユーザーが何も感じていないけど、反応が良くない」という場合です。例えば、あまり使用されていない機能があるとしたときに、「その機能がユーザーに認識されているか」ということも観点のひとつになります。その場合は、もう少し目立つデザインに変更をしてみるなどして、改善するかどうかテストすることができます。

既存ユーザーのコンバージョン率を高めるため

 全体の課金額を増やそうと思ったときに、一番最初に思いつくのは「ユーザー数を増やす」ということだと思います。ですが、ユーザー数を増やすのは、自分の努力だけでは難しい点もありますよね。一方で、ユーザー数を変えずにユーザーが課金する割合を増やすことでも、全体の課金額を増やすことができます。課金率を増やすことについては、ボタンの色や行動を促す文章など、簡単に変えられる部分を工夫するだけで改善がみられることが多いのも事実です。既存ユーザーのコンバージョン率を高めるためにも、A/Bテストは重要です。

継続的に遊んでくれるようにするため

 A/Bテストを繰り返し実施し、より反応のいい内容をゲームに反映し続けることで、ユーザーの満足度も上がります。そうすると、継続的に遊んでくれるユーザーが定着し、アクティブユーザーの増加にもつながります。せっかくゲームを遊びはじめてくれても、すぐにやめてしまっては意味がありません。新しいユーザーを増やすことも大事ですが、既存ユーザーを維持するのも大事です。

低リスクで変更を行うため

 ゲームの内容を変更して、前の状態に戻したいと思っても、リリースしてしまった後は簡単に戻すことはできません。A/Bテストを使うことで、最終版として確定する前に、一部のユーザーだけに対してテストができます。仮にうまくいかなかったとしても、テストした案を不採用にするだけで、ゲームには大きく影響しません。低リスクでゲーム内容に変更を加えることができるのも、A/Bテストの特徴です。

統計的に判断した改善をするため

 UIをデザインしたり、レイアウトを変更したりする場合に、「こうしたほうがいいのでは」という直感に頼っている人も多いと思います。A/Bテストは直感や予想など曖昧なものではなく、データで判断してくれます。より良い方を選んでいるのは実際に触っているユーザーなので、ユーザーが良いと思う方向に修正をする方が、確実に良い改善につながります。

1.3 A/Bテストすべき項目例

 「A/Bテストって何をテストしたらいいの?」という疑問に答えるため、A/Bテストすべき項目例についてまとめておきます。

デザインやレイアウト

 デザインやレイアウトというのは、具体的には次のようなものです。

 ・ボタンの色を変える

 ・UIの位置を変える

 ・画像を変える

 試しにボタンの色を変えてみたり、画像を差し替えてみることですね。「こんなことで、反応が変わるの?」と思う人もいるかもしれませんが、ボタンの色や画像を変えるだけで、ユーザーの反応が変わることはこれまでの実験でわかっています。簡単に変えられる部分なので、ぜひ実験をしておきたいところです。

行動を促すフレーズ

 行動を促すフレーズというのは、ユーザーに対する最後のひと押しです。「課金しようかな」と迷っているユーザーを「課金しよう」という決意にまでもっていくために、課金したくなるフレーズを用意しておくべきです。例えば、「本日限定!ジェムパック980円!」などですね。こういったフレーズが後押しになって、課金してくれるようになることもあります。せっかくいいゲームを作っていても、課金のところで取りこぼしがあると、もったいないですよね。行動を促すフレーズについては、細かくA/Bテストをしておきたいところです。

試し読みはここまでです。
この続きは、製品版でお楽しみください。