データの探索を始める
Unity Gaming Services（UGS）データエクスプローラーを使用すれば、指標やイベントに基づいてデータをフィルタリングして使用したり、プラットフォーム、国、またはバージョンでグループ化したりできます。
SQL (構造化クエリ言語) の基本的な知識があれば、 UGS内の SQL データ エクスプローラーを使用して分析のレベルを上げ、データをさらに深く掘り下げることができます。この機能を使用して、クエリを構築および実行し、結果をさまざまな種類の視覚化にプロットし、視覚化をカスタム ダッシュボードに追加し、他の分析ツールで使用するためにデータをエクスポートします。Unity DashboardのUGS Analyticsパネルで SQL Data Explorer を見つけます。
Unity のAnalyticsコンサルタントの 1 人である Russell Young が、SQL Data Explorer の冒険を始めるためのヒントとアイデアを紹介します。
UGSの豊富なデータを探索するには、SQL クックブック のレシピのコレクションを参照してください。UGS はSQL の Snowflake フレーバーを使用することに注意してください。
クックブッククエリの 1 つは、ミッションの統計を調べます。このコードを調整して、架空のゲームでのミッション失敗率を簡単に確認してみましょう。これは、missionID パラメータを使用して、プレイヤーのミッションへの関与を追跡するために作成したカスタム イベントを使用します。
このクエリでは、デフォルトの EVENTS テーブルを使用します。この表には、ゲームで記録されたすべてのイベントの詳細なデータが含まれています。
ここでは、クエリを制限して効率性を保つために日付フィルターを使用していることに注意してください。この制限がない場合、クエリは、SQL データ エクスプローラーでデフォルトでクエリ可能な 365 日間のデータ全体に対して実行されます。また、SELECT * を使用するよりも、関心のある列を指定する方が常に効率的です。
EVENT_JSON:missionID::INTEGER のようなフレーズは難しそうに思えますが、「missionID」と入力してオートコンプリートを使用すると、SQL Data Explorer によって JSON 構文が生成されます (独自のゲームでそのパラメーターが設定されていることが前提)。
クエリを実行した後、結果をプロットしてデータのストーリーを確認できます。チャートは現在、最大 2 つの Y 軸と 1 つの X 軸をサポートしています。軸ラベルは、SQL クエリの 'as' 式を使用して簡単に名前を変更できます。この場合、Y 軸には定義した名前が付けられます。「プレイヤーは%に失敗しました」。
最初のミッション (missionID 0) では 3 人中 1 人以上のプレイヤーが失敗していることがわかったので、ミッションの難易度を微調整して、ユーザーにもっとポジティブな初回体験を提供できるようになりました。
ヒント：データに NULL 値が含まれており、軸がおかしく見える場合は、coalesce(yourParameter, 0) を使用して空白を埋めます。
クエリを実行すると、結果のテーブルが表示されます。クエリに PLATFORM を追加します。上の画像では、テーブルがどのようになっているかがわかります。右側の「ピボット」ボタンに注目してください。これは、クエリを書き直すことなくデータを再形成するのに役立ちます。
この例では、ピボット ツールを使用してデータを調整し、行に PLATFORM を、列に MISSIONID を取得できます。
表を微調整すると、プラットフォーム間でミッションの失敗にほとんど違いがないことがわかります。
ゲームが成功し、プレイヤーベースが拡大するにつれて、単純なクエリでも実行にかなりの時間がかかることがあります。
データに対して次の基本的なクエリを実行するとします。
かなり速く実行されると期待されるかもしれませんが、データセットが大きい場合は必ずしもそうとは限りません。ウェアハウスの形状と、user_id がハッシュとして保存されるという事実を利用して、含まれるユーザーの数を減らす簡単な方法を使用し、クエリ速度を向上させます。
ここでは、ユーザーを疑似ランダムに割り当てられ番号が付けられた 100 個のバケットに分割し、バケット番号 63 を調べています。
このコードを単純なクエリに追加しても大きな違いはありませんが、計算の複雑さが増すにつれて、この方法でデータをフィルタリングすることがますます重要になります。私たちの仮想ゲームでも、クエリのこの修正バージョンは元のバージョンよりも 75% 高速に実行されることがわかりました。これにより、データセット全体を処理することなく、ユーザーのサンプルサブセットに関する洞察を得るための時間とコストを節約できます。
上記のクエリでは、count(distinct…) を使用して、個々のプレーヤーとイベントの組み合わせの数を計算しました。結果に 100% の精度が必要ない場合にクエリ速度を向上させる 1 つの方法は、approximate_count_distinct を使用することです。以前のクエリは次のようになります。
これまでは、メインの EVENTS テーブルのみを使用していました。このテーブルには、ゲーム内で発生したすべてのイベントに関する詳細なデータが含まれているため、最も広範なテーブルとなります。クエリを改善するには、より小さなオブジェクトを使用してクエリをより効率的に実行します。
用語集パネルを見て、クエリに使用できるテーブルを調べてみましょう。
ここでは、EVENTS の他に、クエリに使用できる集計テーブルがすべて見つかります。これらはすべて、 UGSですぐに使用できます。
- USERS テーブルには、イベント数、合計プレイ時間、合計支出など、ゲーム内でのプレイヤーの生涯指標とともに、プレイヤーごとに 1 行ずつ保持されます。
- FACT_USER_SESSIONS_DAY には、各プレーヤーの各セッションのデータが含まれます。
- FACT_EVENT_TYPE_USERS_DAY は、プレイヤーが毎日送信した各イベントの行と合計数で構成されます。
- FACT_WAU_USERS と FACT_MAU_USERS には、特定の日に前週または前月内にプレイしたユーザーのプロファイル データが含まれます。
FACT_EVENT_TYPE_USERS_DAY と FACT_USER_SESSIONS_DAY の間では、おそらく、小さいオブジェクトに対するほとんどのクエリの 80% 以上を回答できるでしょう。
たとえば、最初のクエリでは、ミッションの失敗率を調べていました。また、このテーブルに保存されている NUMBER_OF_EVENTS カウントを使用して、FACT_EVENT_TYPE_USERS_DAY を使用して各日の全体的な失敗率を計算することもできます。
次のクエリでもこれらのテーブルのいずれかを使用します。
このクエリを使用して、特定の条件を満たすプレイヤーのイベント ストリームを表示します。上記の USERS テーブルを使用すると、実行するたびに異なるユーザーが取得されるため、QA およびデバッグに役立ちます。
たとえば、ゲームの特定のバージョンをインストールしたプレイヤーのイベントが正しく記録されていないと思われる場合は、以下のクエリを実行できます。返されるのは、問題が発生していると思われるゲーム バージョンを実行しているランダム プレーヤーのイベント ストリームです。これを数回実行すると、データ内のパターンをすぐに見つけられるようになります。
ヒント：複数の行をコメントアウトしたい場合は、キーボードショートカットCTRL+/を使用します。
Snowflake 以外の言語で SQL クエリを記述することに慣れているかもしれません。たとえば、以前の deltaDNA データ マイニング ツールを使用していた場合は、Vertica でクエリを記述していた可能性があります。
新しく定義された変数を、最初に共通テーブル式 (CTE) に含める必要なく参照できるようになりました。たとえば、このクエリは SQL データ エクスプローラーでは正常に実行されますが、元の deltaDNA では、「列 'rice' が存在しません」というエラーが発生します。
SQL Explorer には大きな可能性があります。UGS Analyticsには、円グラフや積み上げ棒グラフなどの多くのグラフ オプションをはじめ、さらに多くの機能があります。Direct Access を使用すると、Snowflake を通じてAnalyticsデータに直接アクセスできます。
洞察を迅速に追跡し、クエリとダッシュボードの構築に関するサポートを受けるには、 お問い合わせください。
さらなる参考情報