ユーザーの行動ログを取る理由は大まかに分けて2つある。
- サービス改善のための分析に使うため
- カスタマーサポートのため
今回は、カスタマーサポートのための行動ログについて書く。
カスタマーサポートのために行動ログを保存する意味
必要になる、正確さと早さ
サービスを運用していると「Aというアイテムを使った記憶がないが、なくなっている」や「クエストをクリアした時に表示された経験値と実際に増えている経験値が違う」など、様々なお問い合わせを頂く。
それらのお問い合わせがきて、カスタマーサポートでは原因がわからない場合、カスタマーサポートチームから質問・調査依頼が開発陣にくる。
ユーザーの皆さんを長期間待たせる事は最悪、という文化が自分がいるチームにはあり、そういう依頼が来たらなるべく早く・正確な対応をする事を全員心がけている。
正確さ
お問い合わせでよくある「Aというアイテムを使った記憶がないが、なくなっている」では、データベースで「アイテムAを持っているか」を見て、アイテムAがあるなら解決、ではない。
そういうデータは保存してあるが、ユーザーの皆さんはゲームをプレイしているので、どんどん書き換わっていく。
書き換わってしまった後にお問い合わせを頂いた場合やお問い合わせを頂いた後に書き換わってしまった場合、正確な対応が出来ない。
なので、正確さを求めるのであるならば、「ユーザーがアイテムAを持っていたと記憶している期間からなくなったと気づいた期間まででアイテムAを消費したか?」などを見る必要がある。
つまり、正確な対応をする必要がある場合、ユーザーが取った行動をログとして保存する必要はある。
なにを保存するべきなのか・ちゃんとした行動ログとは
ユーザーの行動ログ、と言っても全てを保存する必要はない。
例えば、クエストの一覧を取得するAPIを叩いたという行動ログをとっても、カスタマーサポートで有効に使える事はほぼないと言える。
カスタマーサポートのために行動ログを保存するべきなのは、ユーザーが何かを作成・変更・削除した時である。
- 「新しくアイテムAを取得した」
- 「アイテムAを消費した」
- 「今まで入っていたギルドを抜けて、移動した」
など。
また、「アイテムを取得した」というログだけでは、カスタマーサポートでは活かせない。「いつ、誰が何を(作成|変更|削除)し、その後どうなったか」が説明出来るようなログでないといけない。
例えばユーザーAさんが「めっちゃすごいアイテム」を2014/01/01 00:00:00に取得したとする。Aさんは、「めっちゃすごいアイテム」を既に1個持っていて、取得後、2個になる。
そういった場合、このような形で行動ログを保存する。
$logger->submit({ time => "2014/01/01 00:00:00", # いつ type => "item.receive", # どういう行動をしたのか。 uid => A, # 誰の item => "めっちゃすごいアイテム", # なにが before_amount => 1, # どういう状態から after_amount => 2, # どう変化したか });
保存、閲覧
保存する内容が決まれば、保存する方法・閲覧する方法を決める。
保存するのは、fluentdに投げまくり、さらにそこから、redshift, mongodbに投げる。
最近はredshiftがアツいとのことで、redshiftに入れる流れになってきている。
https://github.com/hapyrus/fluent-plugin-redshift
ユーザーの行動ログ閲覧ツールである伊右衛門も、今までMongoDBにしか対応していなかったが、redshiftに対応させたヤツを昨日作った。
https://github.com/hisaichi5518/iyemon-redshift
https://github.com/hisaichi5518/iyemon
伊右衛門に関しては、とりあえず動くようになった、くらいなので、詳しい事はまた後日書く。
ただすぐ読めるようなコード量なので、読むのが一番手っ取り早いと思う。
まとめ
カスタマーサポートでちゃんと活用出来る行動ログを保存し活用することで、ユーザーの皆さんの満足度をアゲアゲにしていきたい。
追記
こういうことです
Redshift、別にサポート用の行動ログ入れるのがアツいとは全く思ってないけどフルマネージドなのでインフラチームにMongoDBとかElasticSearchの面倒をみてもらわなくて済むというのが良いですね
— Masatoshi Kawazoe (@acidlemon) 2014, 7月 27