新しい実動ビルドを組み立てる前であっても、イノベーションがどのようなパフォーマンスに影響するかを理解する必要があります。 実際、新しいバージョンのゲームでは、多くのバランスが変更される可能性があります。 事前の計画がなければ、次の質問のいずれかが必然的に発生します。 たぶん、星はちょうどそのように一致しましたか？」 もちろん、更新プログラムのリリース後、結果の包括的な分析が実行されますが、事前に変更の性質を理解する必要があります。
デザインを変更
ゲームに新機能を導入する前に、いくつかの質問に答えようとします。
- どこを見ますか？ -どの指標（ 一般に受け入れられているKPIと内部品質基準の両方 ）が変更に影響すると予想されますか。
- 誰を見ますか？ -変更の対象者（ クジラ、新規プレイヤー、中国からのプレイヤー、特定のレベルのグループにこだわっているプレイヤーなど） 。
- なぜ私たちは見に行くのですか？ -関連するリスクは何か（ より困難なレベル→より多くの収益化とより多くのダンプ（解約）;より簡単なレベル→より少ない収益化とより少ないダンプ） 。
- 見るべきものはありますか？ -すべての必要な情報をゲームで追跡します。
最も重要な質問に答えると、さらに2、3が残ります。 たとえば、ゲームにどのように変更を追加しますか？ ここには2つのオプションがあります。
- ABテスト。 現在のバランスとゲームプレイの新機能または強力な変更についてABテストを実施しています。 可能な限り、予備のABテストが望ましいです。
- すぐにゲームに。 ABテストなしでゲームに新しいコンテンツを追加することは、技術的にABテストを実施できない場合、または基本的に新しいコンテンツ（新しいレベルのセット、新しい装飾など）を考慮しない場合に可能です。
ABテストについては、多くの優れたさまざまなことが書かれていますが、もう少し書こうと思います。
ABテスト計画
ABテストを使用して変更を確認する場合、主なことは重要な点を強調することです。そうしないと、テストは決定的でないか、解釈が間違っているため、役に立たなくなります。 いずれにしても、無駄なテストは必要ありません。 したがって、ABテストを計画するときは次のようにします。
- 評価用の値の選択。
例：変更は「ネジを締める」必要があり、プレイヤーはレベルを完了するためにお金を払うように奨励されると想定されています。 評価する必要があるもの：変換、ARPU、保持、ダンプ、レベルの複雑さ、ブーストの使用。 コンバージョンを増やすことで収益を増やすことは、ユーザーの潜在的な損失に見合うだけの価値があることを確認する必要があります。 さらに、落ちたユーザーの一部は、将来的に広告を見始めて収益を上げることができます。 また、レベルが十分に行われていること、ランダムではないこと、単一のブーストの形で「銀の弾丸」がないことを確認して、通過を保証する必要があります。 これらの制御されたメトリックは十分ですか、それとも追加する価値がありますか
- 意味のある結果を得るために必要な必要なサンプルの計算。
例：モデルは、選択された日に選択されたレベルにレベルアップしたグループ内の約2,000人のコンバージョンの保証された不在を予測します。 このグループのコマーシャルの表示を増やしたときにテスト結果が重要な結果をもたらすように、予測を実行するのに何日かかりますか？
- テスト起動条件の形式化。
例：大規模なテストを実行するには、コンバージョン率の高い国を見つける必要があります。 同時に、英語を話さない経験豊富なプレイヤーのみを募集します。 テストでのプレーヤーの動的分布のためにこれを形式化する方法は？
- データ収集と結果の分析のために提供されるメカニズムを理解する。
例：レベルの異なるグループに対して複数のテストを同時に実行し、便利なツールを使用して、2つのテストに同時に参加しているプレイヤーに対する一方と他方の影響を分割できますか？
- テストの完了に関する意思決定の基準の形式化。
例：メトリックが急激に低下した場合、事前にテストを停止する価値がありますか。 それとも、コホートに特有の一時的な効果ですか？それは待つ価値がありますか？
- ゲームへの変更の導入に関する決定を行うための基準の形式化。 これについては、記事の次のセクションで説明しましょう！
テスト結果に基づいて正しい決定を下す
プレイヤーを同じ割合でグループに分けたとしても、内部では異なる条件に陥ることがあります。 たとえば、ゲームに参加して月の初めにテストに参加した人は、テストの終了時に来た人よりも高いARPUを持つ場合があります。 方法論の選択-これはコホートアプローチまたはARPUデイリー（ARPDAU）の計算になります-計画段階での特定の目標と、定期的にテストに割り当てられるプレーヤーに依存します。
結果のコホート評価では、テストの終わり近くに配布されたプレーヤーがまだ「変換ポイント」に達していない可能性があることに留意する必要があります。 分析の「最後の」コホートの一部を切り捨てるか、テストでプレーヤーの分布を停止した後、適切な時間待つ必要があります。
グループの最終データの分析にさまざまな方法でアプローチすることもできます。 2つの主なアプローチを使用します。
- 周波数アプローチは、結果を測定するための古典的なアプローチです。 グループとヌルを否定する対立仮説との間に有意差はないという帰無仮説を定式化します。 この研究の結果は、母集団全体に対する2つの仮説のいずれかの妥当性に関する決定になります。 アルファレベル（1-アルファ=有意レベル）を選択し、統計的基準（z基準、t基準）を使用してテストを実施します。 次に、コントロールグループとテストグループの信頼区間を作成します。 これらの間隔が交差しない場合、結果は1-アルファの確率で信頼できます。 実際、選択されたアルファ値は、第1種のエラーの確率です。 母集団に対して帰無仮説が当てはまりますが、実験の結果から対立仮説が受け入れられる確率。
長所：十分に大きいサンプルとの有意差を決定する保証された結果。
短所：サンプルサイズ-選択した信頼レベルが高いほど、参加者のグループが募集されます。 そして、テストされた変更の重要度が高いほど、しきい値として設定した有意水準が高くなります。
- ベイジアンアプローチはあまり一般的ではない方法で、条件付き確率の計算の原理に基づいています。 人口が特定の方法で分布している場合、イベントの確率を考慮することができます。 実践の観点から、ベイジアンアプローチを使用すると、多数のメトリックのサンプル要素（ABテストの参加者）の数に対する要件を減らすことができます。 これは、分布パラメーターの最適化の特定の時点で、構築された密度がテストの実際の結果に近づかないために機能します。
このアプローチは、条件付き確率を計算する原理に基づいています。 結果を分析するときに、一般母集団の分布のタイプがわかっている場合、この分布のパラメーターを最適化することで確率密度を復元できます。
確率変数がタイプ分布の1つのタイプに対応しない場合、イベントの結合確率の原理を使用していくつかのタイプ分布を組み合わせることにより、望ましい分布を取得できます。 たとえば、ARPPUの場合、ユーザー収益の分配と有料ユーザーの分配を組み合わせます（作業のパラメーターを最適化する）。 ランダム変数の最終的な分布のモデルを記述し、構築されたモデルのフレームワーク内で、2つのサンプルを比較します。 次に、統計的基準を使用して、両方のサンプルがモデルに記述された分布に対応し、異なるパラメーターを持っていることを検証します。
長所：モデルの選択とパラメーターの最適化が成功した場合、推定の精度と信頼性を向上させることができ、場合によっては、テストのためにユーザーの小さなグループを募集することで決定を下すことができます。
短所：成功したモデルはそうでないかもしれませんし、応用用途ではかなり複雑かもしれません。
例として、Townshipプロジェクトのいくつかのテストを示します。 そこでは、周波数の代わりにベイジアンアプローチを使用して、精度を改善することができました。
最初のテストでは、支払われた通貨の量、いわゆる プレーヤーが特定のソースから取得できるキャッシュ。 これにより、収益化のわずかな改善につながることを計画しました。 その結果、違いを確立しました：
- DPU（Daily Paying Users）-テストグループはコントロールグループよりも1％多く、ベイジアンアプローチを使用すると87％の確率で、頻度アプローチを使用すると同じグループの不一致が50％の確率で真になります。
- ARPUデイリー（ARPDAU）-コントロールよりも2.55％、ベイジアンアプローチ-94％、頻度-74％をテストします。
- ARPPUデイリー-さらに1.8％、ベイジアン-89％、頻度-61％でテストします。
したがって、参加者のグループのサイズを変更することなく、精度を許容範囲に上げることができました。
別のテストでは、収益化が不十分な地域の特定のプレーヤーグループの広告表示設定を変更しました。 その時点で、一部の厳選されたプレーヤーグループでは、広告が台無しになるだけでなく、コンバージョンやARPUを改善できることも既にわかっていたため、このアプローチをより幅広いグループでテストしたいと考えました。
- コントロールグループのコンバージョンはテストグループよりも高く、97％の確率のベイジアンアプローチでは50,000人のプレーヤー、95％の確率で75,000プレーヤーの特定のアプローチで明らかでした。
- 1か月あたり97％の確率で合計に基づいてベイジアンアプローチを使用して、コントロールグループに有利なARPUの違いを推定しましたが、頻度アプローチでは信頼区間に違いはありませんでした。
結果を評価するアプローチの最終的な選択に関係なく、コントロールグループとテストグループの違いに関する情報を取得します。 結果がプロジェクトにとってプラスであると考える場合、すべてのユーザーの変更を含めます。 ゲームに変更が完全に導入される前でも、変更がプレーヤーにどのように影響するかについての考えはあります。
メトリック監視
もちろん、新しいコンテンツについては、変更の効果が予測可能な場合、ABテストを実施しない場合があります。 たとえば、新しいマッチ3レベルをゲームに追加する場合。 これらの変更には、主要なメトリックの事後制御を使用します。 ABテストの場合と同様に、このモードのデータは、自動モードのユーザーからのイベントから収集および処理されます。
キューブのオープンソースソリューションに基づいた独自のダッシュボード、内部開発があります。 アナリストだけでなく、ゲームデザイナー、マネージャー、プロデューサー、その他当社のフレンドリーな開発チームのメンバーも使用しています。 各プロジェクトのこのダッシュボード（より正確には、ダッシュボードのセット）の助けを借りて、たとえばマッチ3レベルの難易度など、主要な指標と内部メトリックの両方が追跡されます。 ダッシュボードのデータはolap-cubesの形式で準備されます。この形式には、rawイベントデータベースからの集約データが含まれます。 各チャートの追加モデルの選択により、必要なカテゴリへのドリルダウン（コンポーネントへの分解）を実行できます。 オプションで、ユーザーをグループ化またはグループ化解除して、メトリックのレンダリング時にフィルターを適用できます。 たとえば、アプリケーションバージョン、レベル設定バージョン、リージョン、ソルベンシーごとにドリルダウンし、ゲームバージョン1.8およびレベル設定バージョン4のオーストラリアの有料プレイヤーのみを残すことができます。
もちろん、デフォルトで最も興味深いのは、ゲームの最新バージョンとレベルの最新バージョンであり、以前のバージョンと比較されます。 これにより、レベル設計者は、グローバル更新分析から抽出されたプロジェクトの複雑さ曲線の現在の状態を継続的に監視し、計画されたレートからの逸脱に迅速に対応することができます。