Custom Eventについて

以前の記事ではUnity Analyticsの導入までを行いました。今回はCustom Event（カスタムイベント）について説明します。

Custom Eventとは統計を取りたいイベントを開発者が自由に決められるものです。例えばゲーム内の特定のUIを押したとかゲームをクリアしたといったところにCustom Eventを入れることでユーザーの行動を追跡できます。もちろん個別のユーザーの状況を調べることは不可能ですが、多くのユーザーの平均的な行動を推測することができます。
Analytics.CustomEventを使ってカスタムイベントを設定できます。今のところ英語のサイトのリファレンスにしか載っていないようです。
第1引数にはカスタムイベントの名前を指定します。管理サイト上で表示されるのでわかりやすい名前をつけた方が後で困らなくて良いでしょう。 「unity.」で始まらないようにだけ気をつけてください。
第2引数はオプションです。指定した名前のイベントについての補足情報をキーと値のペアで自由に与えることができます。 これのキーも 「unity.」で始まらないようにだけ気をつけてください。

Analytics.CustomEvent(“test”,
new Dictionary<string, object> { { key, value } });
このように書くと、 testという名前のイベントにnumberというパラメータがありその値が0として記録されます。

カスタムイベントは1000ポイント（Analysis Pointsと呼ばれています）まで登録できるという制限があります。ひとつのカスタムイベントを作ると最低1ポイント消費します。最大でカスタムイベントは1000個まで作れるということになります。このAnalysis Pointsはプロジェクトごとに1000ポイントになります。
このポイントの計算の詳細はここに載っています。 今のところフォーラムにしかないですが、将来的にはマニュアルの方にも載ると思います。結構わかりづらい方式だと思うので説明します。パラメータの値についてはint、bool、stringの3種しか試したことがないのでそれ以外のことについてはどうなるかは知りません。int、bool、stringで十分だと思いますけど……

【Example 1: Custom Events with No Parameters】
パラメータなしのカスタムイベントの場合
これはイベントひとつごとに1ポイントです。

【Example 2: Custom Events with Numeric Parameters Only】
数値パラメータのみ持つカスタムイベントの場合
イベントに含まれるパラメータの数が消費するポイントに等しくなります。1つの数値パラメータを持つカスタムイベントの場合は1ポイントです。3つの数値パラメータを持つカスタムイベントの場合は3ポイントとなります。
1つの数値パラメータを持つカスタムイベントの場合は、パラメータなしのカスタムイベントの消費ポイントと同じです。パラメータがあるからといってポイントが増えるわけではないことに注意してください。

 【Example 3: Custom Events with Numeric and Non-Numeric Parameters】
数値と非数値パラメータを持つカスタムイベントの場合
含まれる数値的パラメータの数 + 非数値的パラメータ（boolとstring）それぞれの取りうる値の個数の合計が消費ポイントになります。数値的なパラメータの消費ポイントはExample2と同様です。個数の分だけ消費します。
非数値的パラメータは取りうる値の数だけポイントを消費します。

boolのパラメータがひとつあったとします。取りうる値はtrueとfalseの2種類が限度です。よって、ふつうは2ポイント消費します。わかりづらいことにboolがあったら2ポイント消費ではないのです。
boolのパラメータを持つカスタムイベントがあり、trueもしくはfalseのどちらかの値が設定された状態でAnalytics.CustomEventが呼ばれます。その情報がサーバーで処理されるわけですが、そのときにtrueの情報しか来ていないならそのカスタムイベントの消費ポイントは1です。いずれfalseが設定された状態でAnalytics.CustomEventが呼ばれるでしょうから、そのときには消費ポイントが2になります。boolをパラメータにした場合ふつうはtrue/falseのどちらの値も取るでしょう。（そうでなければ統計を取る必要がありませんし）何らかのバグで片方の値しか取らないようになると、いつまでも消費ポイントが1になったりします。

stringのパラメータは無限にポイントを消費する可能性があります。string型のパラメータを使う場合は渡すデータの取りうる値がどのようなものになるかを見積もることが重要です。
例えばプレイヤー名をパラメータにして統計を取ろうとするのは使い方として間違っています。プレイヤー名が任意ではなくいくつかのうちから選ぶ方式なら統計を取っても数が決まっているので問題ないですが、自由に決められる名前だった場合はプレイヤー名はどのような値もありえます。したがって新しいプレイヤー名が設定されるたびにポイントを消費していくことになるでしょう。

このように取りうる値の数だけポイントを消費する仕組みは非数値のパラメータの特徴です。取りうる値が増えていくとそれを検知するたびにポイントを消費していくのです。非数値のパラメータは数値パラメータと違い追跡できる情報量が多いため、消費するポイントが多いのだと思われます。この後で管理サイトのスクリーンショットの解説もするのでそれを見ると納得できると思います。

ポイントをどれくらい消費しているのかを見るページがあります。管理サイトのEVENT WATCHERに今、何ポイント使っているかが表示されます。内訳は出ないので少し不便ですが、目安として使うには役に立つと思います。以下のような見た目です。

管理サイトのDATA EXPLORERに行き、Add Custom Eventを押します。Analytics.CustomEventで指定した名前が一覧になっているので見たいイベントを選びます。Segmentはどのようなユーザーを対象とするかを指定するものです。この2つを設定したら、View Parametersからパラメータの統計を見ることができます。
カスタムイベントのパラメータの種類による見え方の違いを載せておきます。

int型の場合（数値）
数値パラメータではsum、count、averageを指定することができます。これにより表示される情報が切り替わります。それぞれ合計、回数、平均を表しています。数値パラメータの特徴は個々の値を参照することができないということです。

bool型の場合（非数値）
trueとfalseのそれぞれの統計が集計されています。数値とは違い個々の統計がわかります。個別に集計しているためにポイントを多く消費してしまうのでしょう。細かく分析できるメリットの方がポイントの消費するデメリットより大きいと思います。

string型の場合（非数値）
渡される文字列ごとの統計が集計されています。個別の統計がわかります。stringの場合は際限なく指定できてしまうのが便利でもあり、ポイントを消費しすぎる危険でもあります。
以下の例はロードしたシーンの名前が何かを表しているのだと思います。

1000ポイントは使い切ろうと思ってもすぐにはなくなりません。ポイントがどれくらい使われているか把握しておくことは重要ですが、はじめからポイントが足らなくなるかもしれないという不安を持たなくても大丈夫です。足りなくなってから考えても遅くはありません。
リリースしてしまったアプリの場合でもアップデートのタイミングでUnity Analyticsを新しいプロジェクトに切り替えるといったこともできます。それを利用すれば統計が一新されるので、どのような状況でも対応できるでしょう。

調べていないけれど気になることもあります。実用上はどうでもいいことなのですが、同じイベント名で違うパラメータを指定したりしなかったりしたらどうなるのだろうということです。
つまり、