トレジャーデータ(Treasure Data)ブログ

トレジャーデータ(Treasure Data)ブログです。

本サイトは移転しました。新サイトにリダイレクトします。

Treasure Data Analytics 第7回 〜Social Gaming Analytics Vol.1: イントロダクション〜

本記事は移転しました。新サイトにリダイレクトします。

 

はじめに

今回から数回に渡って Social Gaming Analytics シリーズが始まります。本シリーズの目的は,特定のゲームに依存しない,一般的なアクションログから実行可能な,有用な解析手法をいくつか紹介する事です。前回のようにサンプルデータセットや解析クエリの紹介は省略することにします。

なお,紹介する解析手法はどれも有用で魅力的なものですが,それらは全て Treasure Data Cloud Warehouse 上で実行可能となっていますので,実際に解析を行ってみたい方はそちらの方でぜひ。

 

イントロダクション

Social Gaming Analytics はここ数年の間に非常に大きな発展を遂げてきました。継続的にゲームパラメータを変更可能なソーシャルゲームにおいては「ユーザー個々のアクションに基づいた解析」を行い,その結果を即座にゲームデザインに反映していかなければなりません。しかしながら,数百万〜数千万に及ぶユーザーの大規模なアクションログを収集し,解析することは容易ではありません。さらにイベント等の反響を即座に確認し,必要ならすぐに修正できるようにするためには Daily の解析インターバルでは手遅れで,Hourly より短いインターバルで解析が実行されなければなりません。

f:id:doryokujin:20120709104926p:plain

図1:Social Gaming Analytics では旧来のアクセスログに基づく Daily の解析のみでは不十分な点が多くあります。その他多くのアクションログと共に短いインターバルで解析を実行しつつける事が求められます。構造化ログのメリットは短いインターバルでの解析処理を効率良く行えることと,アクションログのフォーマットを制御する事で,後の解析において統一的な扱いが可能になります

第 2 回で紹介しましたが,解析においてはこのようなアクションログの取得,ストリーミング技術などが要求される「ログ収集」の段階こそ非常に重要かつ困難なフェーズとなっているのです。

Treasure Data Clound Warehouse では,アクションログのストリーミングでの取得に関しては 第6回で紹介した Heroku Addon または fluentd ( + fluend-logger ) によって容易に実現することができます。詳細は 第6回 を参照ください。

※ ところで,高度な Social Gaming Analytics を駆使して早期に市場で成功を納めたのは,ご存じ Zynga です。Zynga は近年最も成功した Data Driven/Mining Company の 1 つに挙げられると僕は考えております。彼らは数千万のユーザーとそのアクションに基づいた非常に多くの Metrics を定義し,たいていの Metrics が 5 分後には参照できるような大規模なアーキテクチャを構築しています。

f:id:doryokujin:20120709105850p:plain

図2:Zynga の解析プラットフォームの概略(資料発表当時)。彼らの資料:Actionable Analytics at Zynga: Leveraging Big Data to Make Online Games More Fun and Social は一読に値します。また余談ですが,Zynga History は彼らの成功を知る上で大いに参考に成る長編記事です。併せてどうぞ。

 

導入するアクションログ

今後取り扱うアクションログは特定のソーシャルゲームに依存しない,ごく一般的なものを対象とします。さらに言えば紹介する解析手法もアクションログという概念も,ソーシャルゲームという領域に限ること無く広く応用可能であることを意識しておいて下さい。

今回導入するアクションログは "login", "register", "pay" といった 5, 6 種類の基本アクションとそのステータスです。

各々のログの取得形式は必要な時に紹介しますが,例えば先ほどの 3 つのアクションをユーザーごとに取得しておくだけでも,いわゆるソーシャルゲーム界隈での基本的な KPI (Key Performance Indicator:「重要業績指標」)である「アクティブユーザー数」,「ARPU」,「ARPPU」などが任意のインターバルで見れるのは当然のこと,さらに進んで "Survival Analysis" や "Cohort Analysis" といったより価値のある統計的手法を導入することもできます。

基本的な KPI はそれ自身の値を見てもアクショナブルなものではありませんが,例えば 「level(レベル)」,「virtual_money(仮想通貨所持数)」 といったユーザーのステータスをセグメントにして観察することによって,最もゲームに活発な/貢献している好ましいセグメントを特定することができるようになり,今度はこの好ましいセグメントへの遷移を他のセグメントユーザーに促すような施策を打ち出すことができます。

f:id:doryokujin:20120709191501p:plain

 図3:最も基本的なアクションログを導入した Property Graph。"user" というノードは他の "user" ノードと種々のコミュニケーションアクションをとりつつ,pay というアクションなどによって "item" といったノードとも関係を持ちます。全てのノードおよびアクションがステータスを持つことは既に何度か説明しました。

僕は業種を問わず,あらゆるのログを「グラフ」の上で考えています。特に多くのログのクラスはノード,アクション,ステータスという概念によって図3 のような "Property Graph" (厳密には category を色づけしたエリアでグルーピングしている部分はこの概念にあてはまりません)として表現することが可能です。また,一対一の辺の概念を拡張した "Hyper Graph" などの概念によってより広いクラスのログをグラフ上で扱うことができるようになります。(今回のシリーズではこういったグラフを極力意識する必要が無いような構成としています。)
※ 元々 Property Graph は Graph DB の分野で導入された概念です。Property Graph と Graph DBに関する僕の資料はこちら(日本語)こちら(英語:最新版)に置いてありますので興味のある方はぜひ。

さて,前述のグラフはグローバルな表現を重視しており,解析の種類によってはよりマクロなグラフ表現が必要になってきます。例えば Register (本登録)というアクションには,実はその登録に至るまでに Tutorial の各ステップを途中離脱することなく全てクリアしたユーザーのみが行うアクションです。この Tutorial というアクションはその "step" という順序を持ったステータス値によってノード分解され,よりマクロな表現を持った以下の "Funnel Graph" (仮称)が作れます。

f:id:doryokujin:20120709192849p:plain

図4:Tutorial というアクションは全ユーザーが step=1 のスタートページから入り,途中多くのユーザーが離脱しながら step=10 のゴール,つまり本登録というコンバージョンに至ります。このようなアクションにおいての重要な関心事は,各 step でどれくらいのユーザーが「離脱している」という部分であり,これを調べる手法はファンネル分析などと呼ばれます。

今後のエントリーでは,少しずつアクションを増やしていきながら解析の種類も増やすような方針で進めていきます。次回はまず Tutorial というアクションログのみを導入し,ファンネル分析を行っていくことにしましょう。

今日はここまで。