Unity Gaming Services（UGS）データエクスプローラーを使用して、指標やイベントに基づいてデータをフィルターして使用し、プラットフォーム、国、またはバージョンでグループ化できます。
SQL（Structured クエリ Language）の基本的な知識があれば、UGS 内の SQL データ Explorer を使用して分析をレベルアップし、データを深く掘り下げることができます。この特徴を使用して、クエリをビルドおよび実行し、結果をさまざまな種類のビジュアライゼーションにプロットし、ビジュアライゼーションをカスタムダッシュボードに追加し、データをエクスポートして他の分析ツールで使用できます。Unity DashboardのUGS AnalyticsパネルでSQLデータ エクスプローラーを見つけます。
Unity のAnalyticsコンサルタントの 1 人である Russell Young 氏が、SQL データ Explorer を開始ためのヒントとアイデアを紹介します。
UGSの豊富なデータを探るには、SQL Cookbookのレシピ コレクションを参照してください。UGS は SQL の Snowflake フレーバーを利用することに注意してください。
cookbook クエリの 1 つがミッション統計を参照します。このコードを応用して、私たちのゲームのミッション失敗率を簡単に見てみましょう。これは、私たちが作成したカスタム イベントを使用して、missionIDパラメーターでプレイヤーのミッションへのエンゲージメントを追跡します。
このクエリでは、デフォルトのEVENTSテーブルを使用します。この表には、ゲーム内で記録された各イベントの細かいデータが含まれています。
ここでは日付フィルターを使用してクエリを制限し、効率性を維持しています。この制限がなければ、SQL データ Explorer のデフォルトでクエリ可能な 365 日分のデータ全体にわたってクエリが実行されます。また、SELECT * を使うよりも、どの列に注目するかを指定する方が効率的です。
event＿JSON：missionID：：INTEGER のようなフレーズは威圧的に見えるかもしれませんが、「missionID」と入力してオートコンプリートを使用すると、SQL データエクスプローラによって JSON 構文が生成されます。これは、そのパラメーターがゲームに設定されていることが前提です。
クエリを実行した後、結果をプロットしてデータ内のストーリーを確認できます。現在、グラフは最大 2 つの Y 軸と 1 つの X 軸をサポート。軸ラベルは、SQLクエリの「as」式を使用して簡単に名前を変更できます。この例では、Y軸は定義した名前になります。「プレイヤーの失敗率」。
3 人に 1 人以上のプレイヤーが最初のミッション（missionID 0）で失敗していることがわかりました。そのため、ミッションの難易度を微調整して、よりポジティブな最初の体験をユーザーに提供することができます。
ヒント：データに null 値があり、これによって軸がおかしく見える場合は、 coalesce(yourParameter, 0) を使用して空欄を埋めます。
クエリを実行すると、結果の表が取得されます。クエリにプラットフォームを追加します。上の画像では、テーブルが表示されています。右側にある「ピボット」ボタンに注目してください。これは、クエリを書き換えることなくデータを再形成するのに便利です。
この例では、ピボット ツールを使用してデータを調整し、行にプラットフォーム、列にMISSIONIDを取得しています。
表を調整すると、プラットフォーム間でミッションの失敗にほとんど差がないことがわかります。
ゲームが成功を収め、プレイヤーベースが拡大するにつれて、単純なクエリでも実行にかなりの時間がかかることに気付くかもしれません。
データに対して次の基本クエリを実行するとします。
かなり高速に実行されると思われるかもしれませんが、データセットが大規模で、必ずしもそうではないこともあります。ウェアハウスの形状とユーザーIDがハッシュとして格納されるという事実を利用して、含まれるユーザーの数を減らす迅速な方法を使用してクエリのスピードを上げます。
ここでは、ユーザーを擬似的にランダムに割り当てられた番号付きの100個のバケットに分割し、バケット番号63を確認します。
このコードをシンプルなクエリに追加しても大きな違いはありませんが、計算の複雑さが増すにつれて、この方法でデータをフィルタリングすることがますます重要になっています。この仮のゲームでも、この修正版のクエリはオリジナルよりも75%高速に実行されることがわかりました。これにより、データセット全体を処理することなく、ユーザーのサンプルサブセットに関するインサイトを取得する時間とコストを節約できます。
上記のクエリでは、count(distinct…)を使用して個々のプレイヤーの数とイベントの組み合わせを計算しました。クエリスピードを向上させる方法の 1 つとして、結果の精度を 100% にする必要がない場合は approximate_count_distinct を使用することが挙げられます。前のクエリは次のようになります。
これまでは、メインの EVENTS テーブルのみを使用していました。この表には、ゲーム内で実行されたすべてのイベントの詳細なデータが含まれているため、最も広範な表です。クエリを改善するために、より小さなオブジェクトを使用してクエリをより効率的に実行できます。
「Glossary」パネルで、クエリ可能な表を探ってみましょう。
EVENTS の他に、クエリに使用できるすべての集計テーブルがあります。これらはすべて、UGS ですぐに利用できます。
FACT_EVENT_TYPE_USERS_DAY から FACT_USER_SESSIONS_DAY までの間に、ほとんどのクエリの 80% 以上が小さなオブジェクトに対して回答できる可能性があります。
例えば、最初のクエリでは、ミッションの失敗率に注目していました。また、FACT_EVENT_TYPE_USERS_DAY を使用して、このテーブルに格納された NUMBER_OF_EVENTS の数で、日ごとの全体的な失敗率を計算することもできます。
次のクエリでも、これらのテーブルのいずれかを使用します。
このクエリを使用すると、特定の基準を満たすプレイヤーのイベント ストリームを確認できます。前述のユーザー表を使用すると、実行するたびに異なるユーザーが得られるため、QAやデバッグに役立ちます。
例えば、ゲームの特定のバージョンをインストールしたプレイヤーのイベントが正しく記録されていないと思われる場合は、以下のクエリを実行できます。戻ってくるのは、問題が発生していると思われるゲームバージョンを実行しているランダムプレイヤーのイベントストリームです。これを数回行うと、データ内のパターンの検出をすぐに開始できます。
ヒント：複数行をコメントアウトする場合は、キーボードショートカット CTRL+/
Snowflake以外の言語でSQLクエリを作成することに慣れているかもしれません。例えば、以前のdeltadnaデータ マイニング ツールを使用していた場合、クエリはVerticaで作成されていたでしょう。
事前に共通のテーブル式（CTE）に変数を含めなくても、新しく定義された変数を参照できるようになりました。例えばクエリクエリタDeltaデータた。Deltadna
SQL Explorer には多くの可能性があります。UGS Analyticsには、円グラフや積み上げ棒グラフなど、さまざまなグラフオプションが用意されています。Direct Accessでは、Snowflakeを通じてAnalyticsデータに直接アクセスできます。
インサイトを迅速に入手し、クエリとダッシュボードの構築に関するサポートを受けるには、お問い合わせください。
参考資料
