これはドリコム Advent Calendar 2017 の19日目です。
18日目は ohr486 さんによる、 escript how to です。
　
　
　

こんにちは。
2017年4月から新卒で入社した秦と申します。
普段の仕事は、サーバーサイドエンジニアとして機能開発を行ったり、
施策の分析業務を行ったりしています。

本記事では、新卒の私が感じたソーシャルゲームの新機能開発時における、
ユーザの行動分析用ログを組み込む際の考え方とその際の注意点について記していきます。

ごくごく当たり前のことかもしれませんが、
分析用ログの実装を考えている方、新人エンジニア、新人分析者の
お役に立つことができれば幸いです。
　
#はじめに
はじめにサマリーと注意点について記します。
##サマリー

1.新機能における達成したいことを把握する
2.達成したいことに必要なデータをログに落とし込む
3.定点観測も大事
4.分析者の方と相談、認識合わせをしよう

##注意点
もっと良いやり方はあるかもしれませんが、
新卒１年目の私が感じたことベースで書いていますのでお手柔らかに。
　　
　
　
　
では、本題に入っていこうと思います。
実際に組み込む際の流れと共に書いていこうと思います。

#新機能における達成したいことを把握する
まずは新機能における、達成したいことを把握します。
そうしなければ、何を見ればその新機能における
やりたいことを達成できたか確認できないからです。

例えば、キャラクターの強化機能が新機能として実装されたとします。
この時、

など、たくさん見たい項目が出てくるかと思います。
しかしこれらはひとつの指標に過ぎず、「新機能における達成したいこと」が
達成されているか判定できる指標かもしれませんし、そうでないかもしれません。
　

では関係ありそうな指標を全部出しておけば良いのではないか？
私も初めはこのように考えていたことがありましたが、これには以下のような問題点があります。

1については言わずもがなですが、
2については、ログの詳細に関わる部分です。

実際にログを組み込む際は、紐づけておかなければならないデータがあります。
代表的な例だとユーザidですね（ユーザの行動分析用ログなので当たり前ですが）。
このような紐づくデータが、必要なタイミングで必要なデータと共に
取得できていない場合があります。
　

例えば、強化画面に遷移した人数をカウントするためのログを作ろうとします。
その場合、遷移したタイミングにユーザidを取得すれば人数をカウントすることができます。

しかし分析時、ユーザのレベルごとの強化画面に遷移した人数が必要になったとします。
この場合、ログを組み込む段階でレベル情報も付け加えておかなければなりません。

このように一見、「強化画面に遷移した人数」が見たい項目だと思っていたが、
実際は「強化画面に遷移したレベルごとの人数」が見たかったということになってしまいます。
　

以上のように、見たい項目だけでなく、
それを詳細に分解した上で考えなければ必要な情報の抜け落ちにつながります。
結局は達成したいことを把握しようということにつながりますね。

ログを作る際は機能を考えた方と会話をし、
何を目的としこの機能を実装したのかを把握するようにしましょう。

#ログの状態へ落とし込む
達成したいことを把握できたら、それに必要な見るべき指標は何かを考えましょう。
また、見るべき指標が決まったら、それを取得するべきタイミングと必要なデータを考えます。

例えば、上述と同じようにキャラクターの強化機能が新機能として実装されたとします。
ここで達成したいことが、
「既存ユーザがよりゲームに定着し、高難度なステージを楽しめるようになる」
だとします。
この場合、以下の二つに分解できます。

そしてこれらは、このような指標で判断できると思われます。

このように、達成したいことを見るべき指標に落とし込みます。

また、これらを取得するタイミングと必要なデータを考えます。
強化機能により、継続率が上がったかどうかを判定するためには、
強化を行ったユーザを調べる必要があります。

ですので、この場合は強化処理時にユーザidが入ったログを
出力する必要があるということになります。

また、これらをレベルごとに分けて分析したい場合はレベル情報も必要になってきます。
このように、見たい分析項目とそれに必要なデータは何かを考えながら、
ログの状態に落とし込みます。

#定点観測したい値について考える
散々達成したいことを考えようという話をしてきましたが、
とはいえゲームバランスのためや、お問い合わせ対応のためにログを残したい場合もあります。

そこで、達成したいこととは別に、定点観測したい値については別途取る必要があります。
ここでも注意すべきはログサーバーの容量を考えつつ、
必要最低限に収まるよう考えるようにしましょう。

#ログのフォーマット、スケジュールを分析者と相談する
これには２つの理由があります。

１つ目は分析しやすいログにするためです。
ログサーバーの容量を気にするあまり、ログで出すデータを絞り、
後からたくさん結合しようとすると分析作業面でのコストがかかりすぎます。

かといって先ほどから述べている通り、必要そうなデータを全て取得してしまうと
ログサーバーの容量圧迫につながってしまいます。

必要なのはバランスです。
分析者の方に意見をもらいながら一緒に作っていきましょう。
　

２つ目は分析用スクリプト作成のためです。
事前にフォーマットを決めておかなければ、分析用スクリプトを作成することができず、
後回しにするとリリース後すぐに分析結果を見ることができません。

当たり前ですが分析者の方にもスケジュールがあるので、
いつ頃、どういったフォーマットで、ログが出力するのかを相談しましょう。

#さいごに
いろいろ書きましたが、これは私が新卒で働き始めてから感じた個人の意見です。
正しいかどうかはわかりませんが、１つだけは絶対に自信があります。
それは

「分析者の方との相談は必須」

ということです。

みなさん協力し合って良いものを作っていきましょう！！