Treasure Data Platform で始めるデータ分析入門 〜5. Data Processing〜

本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)

  1. Data Collection
  2. Data Storage
  3. Data Management
  4. Data Processing
  5. Data Processing Design Part.1 Part.2 Part.3 Part.4 Part.5 Part.6
  6. Data Visualization Treasure Viewer, MetricInsights, Tableau
  7. Data Visualization Patterns Part.1 Part.2 Part.3

本日は「4. Data Processing」にフォーカスを当てます。

 

f:id:doryokujin:20140115160517p:plain

 "Data Processing"と聞いて,多くの人は具体的な集計クエリの内容に言及するものだと期待されていたかもしれませんが,本章ではその内容は次回に譲り,もっと大枠の Processing から Visualization に繋げるためのアーキテクチャについて考えて行きたいと思います。

 

f:id:doryokujin:20140116121235p:plain

Hadoop ファミリーを初めとした様々なオープンソースまたは MapR などの製品によって構築される Big Data Infrastructure は上図のように非常に複雑であり,相応のスキルおよび人材リソースが必要になります。

 

f:id:doryokujin:20140115160552p:plain

上図は先ほどと少し切り口を変え, Hadoop ファミリーの Batch Aggregator 達(MapReduce, Hive, Pig)または Ad-hoc Aggregator(Impala) を用いた集計プロセスを経て Business Goal(Visualization やレポーティング)に持って行くためのフローとなっています。

Batch Aggregator は大規模で無数のカラムを持った複雑なローデータに対するバッチ集計なので,大がかりで時間がかかるものになってしまいます。

一方で Business Goal フェーズに求められるのは,インタラクティブなデータ操作であり,前述の大規模集計では時間がかかりすぎて(分単位以上)そのニーズを充足させる事はできません。

よってこれらを結びつけるためには Intermediate Data(中間データ)を挟ませないといけません。バッチ処理によってある程度スマートになったデータをデータベースやメモリに保存しておき,Dashboad や BI からはその中間データを参照することでインタラクティブな操作が可能になるのです。

近年登場した Impala は特定の条件の下でこのバッチ処理を数秒単位で終えてしまうことで,中間データをすっとばして直接 Dashboard や BI と結びつくことを可能にしました。つまり巨大で複雑なローデータに対してUI側からインタラクティブな操作を行う事ができるようになったのです。

 

f:id:doryokujin:20140116115724p:plain

しかしながら,ケースによって Hive, Pig と Impala を使い分けるためには,各々の運用・管理が必要であり,これは骨の折れるところでありました。Treasure Data Platform では,処理の実行時にこの Batch 処理と Ad-hoc 処理を簡単に切り替えることができるメリットがあります。

 

f:id:doryokujin:20140115161439p:plain

f:id:doryokujin:20140115161458p:plain

f:id:doryokujin:20140115161532p:plain前回紹介した Management Console から各種クエリの実行が可能です。データベース名を選択し,どの処理(Hive, Pig, Impala)を行うかを選択し,クエリを記述してSubmitボタンを押すだけで処理が走ります。

 

f:id:doryokujin:20140115161050p:plain

Treasure Data の提供するアドホック型のクエリエンジンは最近のアップデートによって実装されました。その性能はバッチ型に比べて10〜50倍の高速化を可能にします。

 

f:id:doryokujin:20140115161258p:plain

各々の Business Goal におけるバッチ型とアドホック型の使い分けは上の表のようになります。

 

f:id:doryokujin:20140115161318p:plain

 

また, 各業界におけるバッチ型とアドホック型の使い分けは上の表のようになります。

 

f:id:doryokujin:20140117120728p:plain

最後に改めて Treasure Data Processing のまとめた図になります。

 

次回は数回にわたって Data Processing Design を紹介します。サンプルデータを用いながら Data Process の基本パターンを理解しましよう。

 

Treasure Data Platform で始めるデータ分析入門 〜4. Data Management〜

本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)

  1. Data Collection
  2. Data Storage
  3. Data Management
  4. Data Processing
  5. Data Processing Design Part.1 Part.2 Part.3 Part.4 Part.5 Part.6
  6. Data Visualization Treasure Viewer, MetricInsights, Tableau
  7. Data Visualization Patterns Part.1 Part.2 Part.3

本日は「3. Data Management」にフォーカスを当てます。とてもライトな内容です。

f:id:doryokujin:20140115150932p:plain

f:id:doryokujin:20140115150950p:plain

Treasure Data Cloud 上のデータの把握および管理は,実は最近までコマンドラインベースのツールしかありませんでした。ドキュメントを参考にしながらデータベース・テーブルの作成・参照やクエリの実行などを行うことは,日々黒画面に向き合っているエンジニア勢ならまだしも,純粋な分析者やマネージャーがそれを使うには多少なりともの障壁がありました。

f:id:doryokujin:20140115151943p:plain

そこで Treasure Data では Web UI 上でデータの管理やクエリの実行が行える Treasure Management Console をデフォルトで提供することにしました。それではManagement Console の機能を見ていきましょう。

 

f:id:doryokujin:20140115151013p:plain

今までに作成されたデータベースの一覧です。データベース名のリンクをクリックすることでテーブル一覧に移動します。また,右上の「Create」ボタンによって新しくデータベースを作成することも可能です。

 

f:id:doryokujin:20140115151029p:plain

特定のデータベース下に作成されたテーブル一覧です。テーブル名のリンクをクリックすることでテーブル内のレコードサンプルページに移動します。また,右上の「Create」ボタンにテーブルの作成が可能です。(同じく削除も。)

 

f:id:doryokujin:20140115151105p:plain

特定のテーブル下に格納されているレコードのサンプル一覧です。ここでレコードを眺めることはとても重要で,どのような項目を持っているか,値は正確な形で入っているか,などを確認します。データ分析を始める事は「データを眺める」事と同意です。また,ここからスキーマ変更などの設定を行う事ができます。

 

f:id:doryokujin:20140115151137p:plain

実際に抽出・集計を行うためのクエリを作成したら,多くの場合それは特定のインターバル(Monthly, Daily, Hourly,...)でバッチとしてスケジューリングされます。そのスケジューリングをこのページから行えます。記述方法はCRONに準じており,また過去のスケジューリングによって実行されたジョブのステータス(Success or Fail)を確認することができます。

 

f:id:doryokujin:20140115151121p:plain

 

現在実行されているジョブおよび過去のジョブは Jobs より確認することができます。各ジョブについてどのデータベース・テーブルに対するどのようなクエリであるか,またステータス(Running, Finished, Failed, Slow)別に見る事もできます。何かあったときの問題解決に役立つ情報を提供してくれます。

 

f:id:doryokujin:20140115151154p:plain

今どのくらいのレコード数・データ量であるかは Utilization から参照できます。また,計算コアの稼働状況を時系列グラフで確認することができます。このグラフが常時上限を張っているような場合は明らかな計算コア不足でjobが詰まっている状況ですのでプランの変更がマストになってきます。

この Utilization から多くの人が得られるであろう気づきは,多くの人が想定している以上に(圧縮された)データ量は遙かに小さいと言うことです。

現在「ビッグデータ」は数十TB以上のデータと定義されていますが,それがどれくらい壮大なモノであるかをあらためて実感し,何より多くの場合どれだけ頑張って蓄積しても身構えるような量ではなく,大規模な環境構築なんて必要無いということを身をもってしるのはとてもとても重要です。

自分たちのデータ規模を知らずしてセールスの言われるがまま,いきなりオンプレミスの大きな箱を買うなんていうのは非常にもったいない話です。それらを検討する前に,まずは圧倒的なスピードかつスモールスタートできる Treasure Data Platform に登録することから始めてみませんか?

 

さて,次回より本質的な話に入っていきます。4. Data Processing にご期待下さい。

 

Treasure Data Platform で始めるデータ分析入門 〜3. Data Storage〜

本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)

  1. Data Collection
  2. Data Storage
  3. Data Management
  4. Data Processing
  5. Data Processing Design Part.1 Part.2 Part.3 Part.4 Part.5 Part.6
  6. Data Visualization Treasure Viewer, MetricInsights, Tableau
  7. Data Visualization Patterns Part.1 Part.2 Part.3

本日は「2. Data Storage」にフォーカスを当てます。

f:id:doryokujin:20140115132500p:plain

 

Treasure Cloud Storage は,前回紹介した源泉である種々のデータソースから Bulk Loader,Treasuer Agent 収集され流されてくるログを無限に貯める大きな湖のようなものです。

 

f:id:doryokujin:20140115132658p:plain

 

Treasure Data の Collection ツールによって収集されるログはキーバリューの集合であるJSON形式(入れ子構造も可能だが,パフォーマンス・後の使いやすさのため,フラットな構造を推奨しています。)であり,Treasure Cloud Stotrage ではそのキーとバリューの対応を保持したそのままの形式で格納されていきます。

Treasure Cloud Storage ではクラウド上に列指向データベースを構築しており,「行方向」の一行一行のレコードのスキャンよりも,カラムごとの「縦方向」のスキャンに特化しています。これによって非常に多数のカラムを持った大規模データであっても,もしデータの抽出・集計範囲が少数のカラムのみを参照するのであればこの時は非常に効率良く処理を実行すす事ができます。

 

f:id:doryokujin:20140115132814p:plain

 

それでは従来のストレージやSQLと比較をしてみましょう。

一般に(クラウド)ストレージとよばれるものはデータをテキストやCSVなどのファイルとして保存されます。これは非常に手軽なものですが,データ分析段階において何度もそのファイルを参照する時には毎回ファイルのオープンクローズが必要になってしまいます。また,圧縮・解凍もマニュアル入出力の差違にマニュアルで実行する必要があり,データ量節約のために圧縮されたファイルは読み込みの前に解凍処理が伴うため,データ分析はいっそう面倒なものになってしまっていました。

一方,SQLとよばれるデータベースでは,データを構造化されたテーブルの形式で保存するため,SQLクエリで必要なデータの抽出・集計が可能になっています。また,インデックスを作成しておけば特定のクエリに対して非常に高いパフォーマンスを発揮します。しかしながら,SQLではデータ量が多ければ多いほどクエリの実行および列の追加が大きな負荷となってきてしまいます。また,ノードの分散に特化していないので,その運用管理には専門スペシャリストの手が必要になります。

近年,そんなSQLの悩みを解消するために(正確には特定の目的に限定特化することで弱点を克服した)No SQLが登場してきました。Mongo DB は柔軟な入れ子も許容されたJSONライクなBSON形式での保存が可能で有り,Riak はデータの分散を容易にかつ高い次元で実現してくれています。Treasure Data Cloud も思想的には彼らと同じ分類に入るということができます。

 

f:id:doryokujin:20140115132914p:plain

 

ではここで改めて Treasue Data Cloud のメリットを考えてみましょう。上図はあえてメリットしか書きませんでしたが,

  • スキーマの変更に強い。
  • データは自動圧縮されて保存されるので容量の節約ができる。
  • データの管理運用を任せておけるので人材コストが節約できる。

また課金体系もレコード数に応じたものであり,価格設定も非常にリーズナブルな設定となっているのも見逃せません。(あまり言いたくありませんが,無料ユーザーでも十分な容量を格納することができます。)もはやストレージに多大なコストかける時代は終わったのです。

もちろんサービス提供側にとってはストレージにコストを乗せれない分,その後にいかにそのデータを活用してくれるか, i.e. 計算ノードを消費し,APIをたくさん叩いてもらい,自社のレポーティングサービスを利用してもらうところを工夫することが肝になってきます。

 

f:id:doryokujin:20140115132939p:plain

 

 

次章で紹介する Treasure Management Console は,データを最大限活用してもらうために創意工夫された Web UI ツールです。Treasure Cloud Storage の情報,例えばデータベース名,テーブル名の一覧や格納されているレコードの参照,またクエリの実行やスケジューリングがここから可能になっています。

 

f:id:doryokujin:20140115133142p:plain

 

ここであえて弊社のサービスポジショニングを振り返ってみることにします。Treasure Data が自社データセンターなどのオンプレミスを補完関係にあるといったのは,オンプレミス上では保持が難しい(データ形式・量的な意味で)「新しい」データソース(全章参照)をTreasure Cloud Storage で運用することで効果的な連携が可能になるからです。

 

f:id:doryokujin:20140115133156p:plain

 

さらにもう一点,データ分析というプロセスは試行錯誤の繰り返しの上にゴールが達成されるものです。そのためには何度も何度もデータをこねくり回し,処理不可が大きくならないように中間データやテンポラリデータを別途保持していく必要があります。もしそのデータ群をオンプレミスで運用するとするならば,それらの恐ろしいデータ量のために新しい「箱」をたくさん積み上げないといけません。それをクラウド上で行う際とのコストの差違は圧倒的に変わってくるのです。

 

Treasure Data Storage は大規模なデータに対しても高いパフォーマンスをはじき出すために設計・チューニングされた「先進的」なストレージであると同時に,分析者がデータ管理・運用の心配をすることなく,かつコストを気にかけず試行錯誤してもらえることに最大限に配慮された「親切で経済的」なストレージでもあるのです。

 

Treasure Data では Treasure Cloud Storage およびその先の処理を試してもらうための無料プランを提供しています。まだの人は是非ともサインアップして頂き,体感してもらえればと思います。

次回は Data Management についてです。

Treasure Data Platform で始めるデータ分析入門 〜2. Data Collection〜

本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)

  1. Data Collection
  2. Data Storage
  3. Data Management
  4. Data Processing
  5. Data Processing Design Part.1 Part.2 Part.3 Part.4 Part.5 Part.6
  6. Data Visualization Treasure Viewer, MetricInsights, Tableau
  7. Data Visualization Patterns Part.1 Part.2 Part.3

本日は「1. Data Collection」にフォーカスを当てます。

f:id:doryokujin:20140115132619p:plain

f:id:doryokujin:20140114164352p:plain

一連のデータ分析プロセスにおけるそのまさに源流となるのが"Data Collection"です。Treasure Data ではこのフェーズを非常に重要と考え,上記のフレーズを掲げています。その信念に基づいて生まれてきたのが今やログコレクションツールの世界的なスタンダードになった Fluentd です。

 

f:id:doryokujin:20140114165305p:plain

Treasure Dataではデータソースの種類に合わせて2つのインポートメソッドを用意しています。

Bulk Import

既にストレージやデータベースに大量に蓄積されているデータ("従来"のデータソースと呼ぶことにします)に対してはその全てを一度にTreasure Data Cloudにインポートする必要があります。この時に使用するのが「Bulk Import」メソッドです。

f:id:doryokujin:20140114170040p:plain

コマンドラインから一連の Bulk Import メソッド,具体的には

  1. prepare: 元データを適切なサイズで分割し,Message Pack形式で圧縮します。
  2. upload: 分割したデータを並列にアップロードしていきます。
  3. commit: アップロードされたデータを指定したデータベース,テーブルに書き出します。

を実行することで短時間で効率良くデータをインポートすることができます。

Streaming Capture

f:id:doryokujin:20140116115530p:plain

一方で"新しい"データと定義される,各自のアプリケーションからリアルタイムに生成される "Event Base Logs" に対しては, Treasure Agent と Treasure Data Library を使用したストリーミングメソッドで容易かつ効率良くデータを収集していきます。

f:id:doryokujin:20140114170238p:plain

このメソッドによって,Event Based Log が発生した時点で定常的にそれをストリーミングで流すことによってネットワークに負荷をかけず,かつほぼリアルタイムにデータを収集することが可能になります。

ここでEvent Base Logs の各業界における取得例を見ていきましょう。

f:id:doryokujin:20140114170704p:plain

f:id:doryokujin:20140114172240p:plain

アプリケーション各々のソースコードまたはHTMLソース内に "Td.event.post" メソッドを"login", "pay" などの一つのイベント名とそれに付随する情報を引数にして該当箇所に埋め込んでいきます。こうすることで「イベント名」=「テーブル名」となる形で,そのイベントが発生する度に随時 Treasure Data Cloud にストリーミングでイベントログを流すことが可能になります。

このようなイベントベースのデータに基づけば,ユーザーの詳細な ”行動分析” を実行することができます。(ここでは実際の分析事例は "Data Processing Design" に譲ることにします。)

また,Herokuアプリケーションを活用されている方には Add-on として上記の Event Based Log を取得することが可能になります。

f:id:doryokujin:20140114172733p:plain

Fluentd

f:id:doryokujin:20140114173336p:plain後者に紹介した,Treasure Agent で利用しているストリーミングによるデータ収集は "Fluentd"と呼ばれるオープンソースをベースにしています。

f:id:doryokujin:20140114173421p:plain

Fluentd 導入以前では,それぞれ異なるデータソースに対しては,別の手段で収集することしかできませんでした。

f:id:doryokujin:20140114173926p:plain

Fluentd はこれらの異なるデータソースに対して,プラグインを提供しその差違を設定ファイルによって吸収することで,一元的に収集・運用することが可能になりました。しかもそれがストリーミングで収集することができるのですから,その有用性と利便性は他に比べて圧倒的に高いものであり,それ故に世界的なスタンダードツールになることができたのです。

f:id:doryokujin:20140114173956p:plain

また,Fluentd のモニタリングサービスが最近ローンチされました。詳細は以下のスライドを参照して下さい。

まとめ 

最後にまとめです。

f:id:doryokujin:20140114174942p:plain

ざっくり言えばこれまで蓄積された大量のログは Bulk Import によるワンタイムメソッドで,今後蓄積されるログは Streaming Capture の定常的な収集メソッドで,という使い分けでデータ収集が従来よりはるかにシンプルに行えるようになったということです。いかにも簡単に紹介しましたが,これほどシンプルかつ実用的な収集手段を提供しているのは Treasure Data 以外にはありません。

 

次回は 2. Data Storage について紹介します。

Treasure Data Platform で始めるデータ分析入門 〜1. イントロダクション〜

はじめに

これから全7回に渡ってTreasure Data Platformを使ったデータ分析の紹介をします。教科書はこちらになります。

本シリーズの目的は2つ。

  1. Treasure Data Platform Service の概要を理解してもらう。
  2. 本シリーズを理解すればデータ分析が誰でも容易にレポーティングが可能になる。

今やデータサイエンティスト() という言葉は,高度な分析手法を駆使してあらゆる問題を解決するプロフェッショナル集団という響きがありますが,それは本質ではありません。データサイエンティストの本質は,

  • 意思決定者(経営者,ディレクター,マネージャー)が容易に理解できるようなシンプルかつ説得力のある分析結果を提供することができること,
  • データ収集からレポーティングまでの,分析のあらゆるレイヤーを深く理解し,適切なツールで一気通貫した分析プラットフォームを構築すること,

にあります。

前者について,データ分析のゴールは高度な分析結果を導き出すことではありません。その分析結果をもって意思決定者がサービスや経営の改善につながる示唆を与えることです。意思決定者は分析に精通しているとは限りません。よって分析結果はシンプルかつアクショナブルなものでないといけません。いくら高度な手法をもって有効な分析結果をもたらせるものでも,彼らに理解してもらえなければそれは単なる時間の浪費でしかありません。

後者について,「データ分析」という言葉は「データを分析ツールに取り込んでレポーティングすること」という意味合いで使われますが,実はもっと多くの含みを持っています。そもそも分析に使うデータはどこからやってくるのでしょうか?それらのデータはデータベースなどのストレージからクエリを投げて切り出されたものです。ではストレージに蓄えられているデータはどこからやってくるのでしょうか?それはアプリケーションなどのあらゆるデータソースから発生するローデータをインフラエンジニアがネットワークを通してストレージに定期的に流すことによってやってくるのです。データ分析を行うというのはそういったデータの源泉および上流を理解し,インフラエンジニア,データベースエンジニアと連携して進めていくものであるのです。

本シリーズではデータ分析を以下の6つのレイヤーに分解し,各々について解説していくものとします。

本シリーズではデータ分析を以下の7つのレイヤーに分解し,各々について解説していくものとします。(Slide Shareの資料は常時更新されます。)

  1. Data Collection
  2. Data Storage
  3. Data Management
  4. Data Processing
  5. Data Processing Design Part.1 Part.2 Part.3 Part.4 Part.5 Part.6
  6. Data Visualization Treasure ViewerMetricInsightsTableau
  7. Data Visualization Patterns Part.1 Part.2 Part.3

データ分析のツールとして Treasure Data Platform を用いるモチベーションは,この6つのレイヤーを一気通貫して提供できる唯一の存在であり,最低限の人的リソースでデータ分析を完結できることによるものです。

f:id:doryokujin:20140110162617p:plain

Treasure Data Platform は分析に必要なあらゆるレイヤーを一気通貫して提供します。

サービス紹介

f:id:doryokujin:20140110164159p:plain

Treasure Dataはクラウド上に巨大なデータストレージと分散可能な計算ノードを持ち,あらゆる業種のデータ分析を協力にサポートします。

f:id:doryokujin:20140110164348p:plain

Treasure Dataを使うメリットは,データ収集からレポーティングまでのツールを全て提供すること,クラウド上にサービスを展開することによって即座に分析が開始できること,コストも大幅に削減することができることにあります。

Value Proposition は以下の3つ。

  • Faster time to Value
  • Cloud Flexibility and Economics
  • Simple and Well Supported

f:id:doryokujin:20140110164530p:plain

f:id:doryokujin:20140110164544p:plain

f:id:doryokujin:20140110164631p:plain

 

サービスの詳細な説明は弊社CTOのインタビューをご覧下さい。

【連載・視点】ビッグデータ収集から解析まで一手に行う注目株……トレジャーデータ | RBB TODAY

次回は,1. Data Storage について解説します。

祝・future-study発足。〜future-studyのすばらしさをMongoDB勉強会の歩みの写真で振り返る〜

f:id:doryokujin:20120727210802p:plain

facebook の松尾さんの投稿future-study の発足を知り,僕は胸が熱くなりながら「いいね」を押しておりました。

フューチャーアーキテクト(以下略してフューチャー)の有志の皆さん,future-study の発足おめでとうございます。僕とMongoDB JPの成長は,フューチャーアーキテクトの支え無しには有り得ないものでございますよ。

感謝の気持ちを込め,過去の僕ともんごとフューチャーの歩みを振り返ってみるオレオレ的なエントリーですが書いてみました。

f:id:doryokujin:20120727230811j:plain

f:id:doryokujin:20120727231920j:plain

f:id:doryokujin:20120727221208j:plain

図1:フューチャーのエントランスと,140人ほど収容できる勉強会ルームの外にある休憩ルーム(最下)。お菓子やジュース,懇親会が近くなるとたくさんのデリバリーがここにいつも並んでいます。

 

何も制度が無いところから始まった future-study

僕ともんごとフューチャーの出会いは「第1回 MongoDB Conference in Japan」で当時フューチャーにおられた(現AWS Japan)松尾さんがサポートに来てくれたことから始まりました。

当時フューチャーには外部の勉強会をホスティングする制度など全く無かったのですが,松尾さん( @understeer )・廣瀬さん( @uorat )・小田桐さん( @ixixi )・難波さん( @kulikala )らを初めとしたフューチャー社内および外部の有志達がそうした何も無い状況から,それこそ初めは周囲を気にしながらこそこそと,ネットや電源設備・USTなどの設備を整えてくれながらフューチャーオフィスでMongoDB 勉強会を開催してくれていたのでした。

f:id:doryokujin:20120727220652j:plain

図2:第2回 MongoDB 勉強会より会場をフューチャーに移しての開催となりました。初めての会場にも関わらずたくさんの人が来て下さり,フューチャーの有志達は完璧なオペレーションを持って会をサポートしてくれました。

彼らは大事な休日を丸1日割いて,しかも完全に裏方に徹して勉強会を支え続けてくれました。そのおかげで主催者の僕は会の進行や自分の発表に専念するだけで済みました。そういった彼らの姿勢が無ければ僕は途中で疲れて間違いなく続けて来れなかったでしょう。

f:id:doryokujin:20120727222232j:plain

図3:第3回MongoDB勉強会より会場をフューチャーに移しての開催となりました。ちょうど当日僕は26歳誕生日だったので,懇親会にサプライズで誕生日を祝ってもらえた事は非常に良い思い出です。ありがとうございました。

※ 第4回MongoDB勉強会は写真が無かったのでtogetterのリンクでも張っておきます。

 

第5回 MongoDB 勉強会 〜真夏の大Mongo祭り〜 とかめちゃ良かったよ

真夏の大Mongo祭りはタイムテーブルも豪華で,盛大に開催されたのでした。スポンサー様の Redbull の提供もございまして,懇親会のオードブルも豪華でした。

Twitter にもたくさん Redbull タワーが投稿されておりましたですよ。

f:id:doryokujin:20120727223554j:plain

f:id:doryokujin:20120727223623j:plain

f:id:doryokujin:20120727223731j:plain

図4:第5回MongoDB勉強会はフューチャー社内,および外部からのたくさんの有志がスタッフとして協力してくれました。みんなで積み上げたRedbullタワーに一同盛り上がっておりました。

 

安心の勉強会運営

その後の勉強会も,完璧なオペレーションの元での運営を行ってくれるフューチャーの有志の皆さん。何も気にすること無くどんどんと勉強会を開催し,コミュニティを盛り上げていくという目的に徹することができたことには大変感謝しております。

f:id:doryokujin:20120727225504j:plain

図5:第6回MongoDB勉強会は定番の io-fusion セッションで本社のエンジニアが来日して説明されるというサプライズセッションも。

f:id:doryokujin:20120727225817j:plain

図6:第6回ではCouchDBのコミュニティの佐々木さんにもお話しして頂きました。

 

f:id:doryokujin:20120727230256j:plain

f:id:doryokujin:20120727234155j:plain

図7:記念すべき第1回GraphDB勉強会も,もちろんフューチャーさんで開催しました。3本発表してしんどかったです。

 

f:id:doryokujin:20120727231845j:plain

図8:僕がTreasure Dataに入った後も,常に勉強会などのイベントで支えてくれたフューチャーまじフューチャー。第1回 Fluentd Meetup Japan の開催も快く引き受けてくれました。上の写真はFluentdの開発者であり,Treasure Data のインフラを支える古橋貞之( @frsyuki )氏。その他全ての発表者が豪華過ぎました。

 

最後に

これまで100人を超える規模の勉強会を継続できてきたのは,フューチャーの会場提供および有志の方々の協力があったからです。

また,元々何の制度も仕組みも無いところから,勉強会のホスティングを今回の様に広く告知できる(社内に公式に認められる)まで地道にねばり強く活動を続け来られたフューチャーの有志の皆様には感服いたします。

彼らのそういった熱意と勉強会場での徹底したサポート,これらは決して表に出ることも認められることも少ないですが,僕たち主催者・発表者・参加者は彼ら無しにはそういった場は存在しないという認識と,彼らへの敬意は常に持っておくべきだと今回改めて感じました。

フューチャーの有志の皆様,今まで本当にありがとうございました。また future-study 発足おめでとうございます。そして今後ともよろしくお願いします。

また色々とやっていきたいです。

f:id:doryokujin:20120727232011j:plain

 

※ ブログにて掲載した写真は以下からお借りしました。写真を提供して頂いた松尾さん,小山さん,ありがとうございました。

Treasure Data Analytics 第9回 〜Social Gaming Analytics Vol.3: 退会ユーザーに関する分析〜

 

はじめに

前回はチュートリアルの全ステップを通過し,登録に至るまでの状況をファンネル分析で見てきました。

その後,Register (本登録)という(ゲームを通じてたった 1 回の)アクションを経て以降は,ユーザーは日々そのゲームにログインして様々なアクションを取っていきます。

しかしながら登録したその日以降,全くアクセスしなくなってしまうユーザーは実は想像以上にたくさんおり,またその後に数回アクセスしてくれたユーザーも様々な要因で日々ゲームから離れていってしまいます。そういったユーザーの「退会」というアクションに対しては,

  • どのセグメントのユーザーが退会しやすいのか
  • ユーザーの継続期間で,退会のリスクが大きくなるポイントはあるのか
  • システムメンテナンスや障害は退会というアクションに影響を与えるのか

といった様々な観点からこの分析を行い,食い止める施策を見いださねばなりません。

また,日々の登録数にも増して退会数の方が大きければ明らかにそのゲームは衰退の一途をたどっていることになりますので,そのような状況は手遅れになる前に早期の段階で検知すべきです。

特に退会したユーザー(および継続しているユーザー)から導き出される継続(生存)期間に関する分析は「生存時間分析」と呼ばれており次回で集中的に扱うことにします。

さらにユーザーが生涯にお金を払った総額(ゲームへの貢献)を踏まえ, Customer Lifetime Value を算出する(こちらは定義も算出もやや複雑で多様で一意ではありません)ような試みは現在広い分野で行われています。本シリーズでも課金というアクションが加わった時に Customer Lifetime Value について考えることにしましょう。CLV に興味のある方には少し古いですが以下の本をお薦めします。

Customer Lifetime Value (Foundations and Trends(R) in Marketing)

Customer Lifetime Value (Foundations and Trends(R) in Marketing)

 

準備

今回の解析は Register と Login というアクションログさえ取れていれば十分です。以下の様なフォーマットでアクションログが蓄積されていることを前提としています。

どちらも最低限そのイベントが起こった主体であるユーザーのID: "uid" とタイムスタンプ "timestamp" があれば十分です。さらにセグメント毎に比較する場合したい場合を想定して Register の方に「登録のきっかけ」,ここでは motivated_by キーに招待(invitation)かそれ以外(direct_access)の情報を持たせています。他にもこれらのアクションと同時に取得可能なステータスを含ませて置くと有効です。もちろん集計の際に他のアクションテーブルと JOIN する事もできます。

$ td table:tail your_app register  # register アクションテーブルへの tail コマンド
{ "motivated_by": "invitation",    "uid": "01234", "time": 1342110399 } 
{ "motivated_by": "direct_access", "uid": "56789", "time": 1342110413 }
{ "motivated_by": "direct_access", "uid": "03482", "time": 1342110417 }

$ td table:tail your_app login # login アクションテーブルへの tail コマンド
{ "uid": "01234", "time": 1342110399 } 
{ "uid": "56789", "time": 1342110413 }
{ "uid": "56789", "time": 1342110417 }

※ 今回は 2012/01/01〜2012/07/20 の期間におけるデータを生成して使用しています。

 

退会の定義

ソーシャル/オンラインゲームでは明示的な退会手続きが無かったり,そのステップを経ずに二度とアクセスしなくなってしまう事の方が多いので,この「退会」というアクションはこちら側で定義する必要があります。ゲームにもよりますが,現在を起点にして最終ログイン日が 7 〜14 日以上前のユーザーは退会したと考えるのが妥当でしょう。

ここではもう一歩進んで,その妥当な「ユーザーの退会」を定義するための材料としてユーザーがどれくらいの(日にち)間隔でゲームにアクセスしているのかを表す「ログインインターバルの分布」を見てみることにします。

ログインインターバルの分布

ユーザーごとのログインインターバルを「平均的に何日に 1 回の割合でアクセスしているのか」で定義し,以下の式で求めます:

ログインインターバル = 
    { (最終ログイン日) - (登録日) + 1} /(ログインした日数)

ログインした日数は,同じ日の複数回のログインを 1 回とカウントしています。また,1 回しかログインしていないユーザー(登録日に辞めた)は Query 0.1 では対象から外しています。

Query 0.1

f:id:doryokujin:20120722183356p:plain

図1:ログインインターバルの分布と左からの累積分布曲線。全体の80%が 7日以内のインターバルで,全体の 95% が 30日以内のインターバルでログインしています。今回のログインインターバルの分布はポワソン分布にそこまで近い形ではないですが( また x=1 で左打ち切りされています),一般にある時間間隔に到着するユーザーの分布はポワソン分布に従うといわれています。

さて,(現在辞めた人も含めて過去 2  回以上ログインしていた)ユーザーの 80% が平均的に 1 週間以内のインターバルでゲームにアクセスしていることがわかりました。ここではこの 1 週間を基準にすることにし,

ある時点から遡って1週間以内にアクセスしていないユーザーを「退会した」と定義

ことにします。

※ 本来なら平均では無く,ユーザー毎のMaxログインインターバルの分布を見る方が良いのかもしれません。今回はそのような Hive クエリがすぐに思いつきませんでした。

 

退会ユーザーに関する分析

上記の定義より退会ユーザーを特定することができまるようになりました。

まずは調査期間(2012/01/01〜2012/07/20)において,現在既に退会してしまったユーザー数を見ていくことにしましょう。ここでは 2012/07/20 を起点にし,定義に基づいてこれより過去 1 週間以内にログインしていないユーザーを退会したと見なします。

Query 0.2

Result     :
+----------+---------------+-----------+
| dead_cnt | survaival_cnt | dead_rate |
+----------+---------------+-----------+
| 51463    | 4815          | 91.4      |
+----------+---------------+-----------+

6ヶ月以内に登録したユーザーは現在では実に 90% 以上が退会してしまっている現状が見て取れます。ここでさらなる関心は,「ユーザーはどれくらいの期間で辞めてしまうのか?」等になるかもしれませんが,これは次回の「生存時間分析」によって深掘りしていくことにします。

さて,退会してしまったユーザーは現在も継続(生存)しているユーザーと比べて何が違っていたのでしょうか?「退会」というアクションに関して,ここでは以下の 4 つの視点を採用することにします。

  1. ログイン回数 [times]:生涯におけるログイン回数の退会/生存ユーザー間での比較
  2. ログインインターバル [days/times]:先ほどのログインインターバルの退会/生存ユーザー間での比較
  3. 退会日 [yyyy-MM-dd]:退会日をセグメントにした退会ユーザー数分布,および日付毎の退会/登録の比率
  4. 生存時間 [days]:登録から退会するまでの期間(生存時間)に関する分析

今回は前者 3 つを見ていきましょう。

1. ログイン回数

まずは退会/生存ユーザーの双方で生涯のログイン回数の分布を見てみましょう。ここでも同日内の複数回のログインは 1 回と見なします。このログイン回数の分布は主に両者の比較と言うよりも主に退会ユーザーに関して

  • 即日退会ユーザー:退会ユーザーでログイン回数が 1 のユーザー

が全体のどれくらいを占めるかを知る目的が大きいです。即日退会ユーザーは当日登録しただけでゲームを楽しむことなく辞めてしまったユーザーで,退会ユーザーの中でも性質が異なります。結果は以下の様になります。

この即日退会ユーザーは想像以上に多く,下の例の結果では 50% 以上が即日退会ユーザーであることがわかります。

Query 1.1

interval    dead    survival	dead_total	survival_total	rate_dead	rate_survival
1    27,843	2	51,461	4,817	54.1	0.0
2	8,742	257	51,461	4,817	17.0	5.3
3	3,771	152	51,461	4,817	7.3	3.2
4	2,144	117	51,461	4,817	4.2	2.4
5	1,288	105	51,461	4,817	2.5	2.2
...

f:id:doryokujin:20120723045440p:plain

図2:ログイン回数の分布(左)と対称エリアチャート(以降,きのこチャートと呼びます)による退会/生存ユーザーのログイン回数の比較。退会ユーザーに関しては実に 55% 近くが即日退会であることがわかります。一方,生存ユーザーに関してはログイン回数はばらついています。ログイン回数についてはプレイ期間に依存しますのでそれも考慮した分布はログインインターバルとして次に登場します。

2. ログインインターバル

先ほど紹介したログインインターバルについて,今度は退会/生存というユーザーのセグメントで分けて見てみることにしましょう。結果は以下の様になります。

ここでは生存ユーザーの 70% はほぼ毎日ログインしており,その他ほとんども 1 週間以内のインターバルを持っています。一方,退会ユーザーのインターバルに関しては相対的にそれほど短く無い傾向にあったようです。

Query 2.1

interval    dead	survival	dead_total	survival_total	rate_dead	rate_survival
1	3,068	3,189	15,834	4,655	19.4	68.5
2	2,113	555	15,834	4,655	13.3	11.9
3	1,324	217	15,834	4,655	8.4	4.7
4	1,138	128	15,834	4,655	7.2	2.7
5	976	111	15,834	4,655	6.2	2.4
...

f:id:doryokujin:20120723050851p:plain

図3:ログインインターバルの分布(左)ときのこチャート(右)による退会/生存ユーザーのログインインターバルの比較。生存ユーザーの方は 70% のユーザーが毎日ログインし,93% の生存ユーザーが 1 週間以内のインターバルを持っています。

3. 退会日

日付ごとに退会ユーザー数を見ていくことは,メンテナンスやシステムダウンがトリガーとなって退会ユーザー数が増えていないか,または退会アクションと日付にはなんらかの傾向があるのかを知る上で重要です。

さらにこれに登録ユーザー数も併せて見ていくことで,退会/登録ユーザー数の比率を同時に参照でき,これによりゲーム全体でユーザーが増加/減少傾向にあるのか,またその傾向がどれくらいの速度で進行しているのかを知ることができます。

Query 3.1

f:id:doryokujin:20120723061551p:plain

図4:日付毎に見る登録ユーザー数(左)および退会ユーザー数(右)の格子型バブルチャート。ユーザー数の多さをバブルの半径と色で同時に表現しています。登録ユーザー数に関しては,全体的に月始めに多い傾向と3月末に顕著な増加が見られます。一方,退会ユーザー数に関しては特定の2つの日付において多数のユーザーが退会しています。これがメンテナンスやダウンの日付と一致していればそれが原因とわかるが,そうで無い場合は原因の特定が必要です。

f:id:doryokujin:20120723071308p:plain

f:id:doryokujin:20120723071035p:plain

図5:月毎の登録/退会の差(上)および比率(下)のチャート。正の値はその日付に置いて登録ユーザー数が退会ユーザー数を上回っている事を示し,その程度を差(絶対的)と比率(相対的)で表しています。全体的に負の値を占める日付が多く,また上の方の図では3つの日付で大きく退会者ユーザー数が登録ユーザー数を上回っているのが簡単に見て取れます。

f:id:doryokujin:20120723071605p:plain

図6:全日付を通しての登録/退会のの遷移チャート(赤点線)。実線のチャートは 2012/01/01 の登録/退会の差の累積曲線であり,この累積曲線はスタートから徐々に下がり続け,途中一点で大きな負の累積を持つことになります。その後徐々に回復しつつも観測最終点ではトータルで 1000人を超えるのユーザー数を始点の時から失ってしまったことがわかります。

 

このように登録とログインという 2 つのアクションログが取れていれば,退会に関する様々な分析を行う事ができます。次回は生存時間分析を行っていきます。

 

今日はここまで。

Treasure Data Analytics 第8回 〜Social Gaming Analytics Vol.2: チュートリアルにおけるファンネル分析〜

 

f:id:doryokujin:20120709192849p:plain

図1:チュートリアルのアクションを表現したファンネルグラフ。入口である step=1 には 8 人の user が流入したのにもかかわらず途中でどんどん離脱していき,出口である step=10 に達した user は user3 のみであることを表しています。また,チュートリアルの出口まで達した user はゲームへの本登録:register が完了したことになります。

今回は図1 のようなチュートリアルアクションに関する分析を行います。前回の続きですのでまだの方は先に前回の記事を読んでおいて下さい。

チュートリアルにはユーザー名登録,アバター選択などいくつものステップを経て登録というコンバージョンに至ります。今回は全 30 のステップを用意し,チュートリアルに入ったユーザーは順番にステップを進んでいくものを想定しています。またチュートリアルを終えた人が本登録: "register" を行う想定となっています。

もちろん入口に入った全てのユーザーが出口まで行ってくれるわけでは無く,途中でどんどん離脱していってしまいます。故にチュートリアルアクションの解析において重要なのは「どのステップが離脱ポイントとなっているか」という部分にあります。ここでは離脱ポイントを見るための解析・可視化手段を併せてファンネル分析と呼ぶことにします。

ファンネル分析を行うにあたって,今回想定されている tutorial ログのフォーマットの一例を以下に記述しておきます。これを行うための fluent_logger や Heroku Addon の説明は第6回を参照してください。

$ td table:tail your_app tutorial
{ "motivated_by": "invitation",    "step":  9, "uid": "01234", "time": 1342110399 } 
{ "motivated_by": "direct_access", "step": 11, "uid": "56789", "time": 1342110413 }
{ "motivated_by": "direct_access", "step": 12, "uid": "56789", "time": 1342110417 }

このアクションログは "step" という順序を持ったステータスを持ち,ユーザーは必ず入口:step=1 から入り,出口:step=30 に向かって進んでいきます。

また,"motivated_by" はチュートリアルの入口にやってきた動機を表すステータス値で,セグメントとして使用するステータスの例として使用しています。2 種類の値をもち, "invitation" は他ユーザーからのアプリインバイトによってチュートリアルにやってきたユーザー,"direct_access" は他の紹介なしに直接チュートリアルにやってきたユーザーを意味します。

まずはファンネル分析の対象となるアクションのクラスを定義しておきます。これは図1 を言葉で説明した程度の単純なものです。

定義

-----

以下の条件を満たすアクションを「ファンネル分析可能である」と定義する:

  1. "step" などの順序を持ったステータス(順序ステータスと呼ぶ)を持つ。
  2. 明示的な「入口」と「出口」が存在し,アクションは必ず入口から出口へ,順序に従って進行する。
  3. 全てのユーザーはアクションの進行途中で離脱する事ができる。つまり順序ステータス値の増加に伴ってユーザー数(アクセス数)は減少(正しくは単調非増加)する性質を持つ。

 -----

ファンネル分析可能なアクションの例は,

  • 「イベント」:途中のいくつかの課題(ステップ)を乗り越えながらゴールへの到達を目指す各イベントのステップ毎の到達ユーザー数についてファンネル分析
  • 「会員登録」: (1) メールアドレス登録→ (2) 住所登録→ (3) クレジット登録→ (4) 登録完了ページへのコンバージョン の各アクセス数についてファンネル分析

など,いくらでも挙げることができます。

 

ファンネル分析(全ユーザーに対して)

それでは早速上記の Tutorial アクションログに対して step 毎に集計する Hive クエリを書きましょう。いつものようにサンプルクエリへの gist link を貼っておきます。

Query 1.1

step uu prev_uu rate_from_enter rate_from_prev normed_rate_from_prev
1	33,695	33,695	100.00	100.00	0.00
2	32,894	33,695	97.62	97.62	2.44
3	32,375	32,894	96.08	98.42	1.60
4	31,168	32,375	92.50	96.27	3.87
5	27,836	31,168	82.61	89.31	11.97
6	25,335	27,836	75.19	91.02	9.87
7	24,448	25,335	72.56	96.50	3.63
8	23,629	24,448	70.13	96.65	3.47
9	22,819	23,629	67.72	96.57	3.55
10	22,094	22,819	65.57	96.82	3.28
11	21,823	22,094	64.77	98.77	1.24
12	21,388	21,823	63.48	98.01	2.03
13	21,163	21,388	62.81	98.95	1.06
14	20,978	21,163	62.26	99.13	0.88
15	20,817	20,978	61.78	99.23	0.77
16	20,371	20,817	60.46	97.86	2.19
17	11,279	20,371	33.47	55.37	80.62
18	9,147	11,279	27.15	81.10	23.31
19	8,581	9,147	25.47	93.82	6.59
20	8,327	8,581	24.71	97.04	3.05
21	7,706	8,327	22.87	92.53	8.07
22	7,458	7,706	22.13	96.78	3.32
23	6,698	7,458	19.88	89.82	11.34
24	6,472	6,698	19.21	96.62	3.49
25	6,153	6,472	18.26	95.06	5.19
26	5,972	6,153	17.72	97.06	3.03
27	4,272	5,972	12.68	71.53	39.79
28	4,110	4,272	12.20	96.20	3.95
29	3,923	4,110	11.64	95.47	4.75
30	3,653	3,923	10.84	93.12	7.39 
図2:チュートリアルの step ごとの到達ユニークユーザー数をはじめとした集計テーブル。

Query1.1 から得られる図1のテーブルには次のカラムが含まれています:

  • step: チュートリアルステップ(1,2...,30 までの順序を持つ)
  • uu: ユニークユーザー数
  • uu_prev: 前ステップでのユニークユーザー数
  • rate_from_enter: 入口(step=1) の uu と比較して,どれくらいの割合のユーザーが生存しているか
  • rate_from_prev: 前ステップ の uu と比較して,どれくらいの割合のユーザーが生存しているか
  • normed_rate_from_prev: 前ステップからの離脱人数を prev_uu で割った値(割合)。この値が高ければ高いほど,前ステップからの離脱が激しいといえる

定義の1つであった,uu は順序ステータスである step 数の増加と共に減少している(厳密には増加しない:単調比減少)性質が,結果テーブルより確認することができます。

ここで,uu は絶対的な値であるのに対し,最後 3 つの rate は相対的な値です。ファンネル分析に関して絶対的な値を用いるのか相対的な値を用いるのかに関しては概ね以下の様に分類できます。

  • 絶対的な値:先月と今月のチュートリアル比較のように uu の値自身も併せて比較しなければならない場合
  • 相対的な値:セグメント毎のチュートリア比較のように uu の値自身は比較対象にならず,離脱状況の相違に興味がある場合

今回紹介する2種のファンネル分析(全体,セグメント別)はともに後者の相対的な値:割合を参照しています。その理由は生存時間分析で用いられる生存曲線とハザード比曲線を模倣して使用しているからです。

早速上記の結果テーブルを可視化してみましょう。

f:id:doryokujin:20120713004723p:plain

図3:チュートリアルの step を順に並べ,各ステップ生存率を(片側)バーチャートで表したもの。早期 step 4->5, 5->6 で入口 uu の 5% 以上の減少が起こり,中期 step 16->17 で 15% 近い減少が確認できます。また後期 step 26->27 においても顕著な減少が見られます。顕著な減少の原因となっているこれらの step においてはその理由と改善のための解析・アクションを続いて行う必要があります。

f:id:doryokujin:20120713004702p:plainf:id:doryokujin:20120713022042p:plain

図4:図3 のバーチャートを両側に表示したもの。「ファンネル」は元々「じょうご」という意味ですが,この両側バーチャートが必ず下に向かってしぼんでいく形になることからその名前がついています。じょうごの形をより意識すると右の Fusion Chart ライブラリのファンネル図 のようになります。

さて上記の(片側 or 両側)バーチャートの他にもこのファンネル分析可能なクラスの結果の特徴を良く表現する図を紹介します。これらはセグメントで分けた結果を比較する場合に非常に強力な手段となります。

f:id:doryokujin:20120713004821p:plain

図5:各step において,step=1 の uu を 100 とした場合の割合をプロットし線でつないだ図。入口からの「生存率」を表すこのグラフは生存時間解析の脈略で「生存曲線」と呼ばれており,図5 はそれを模倣したものです。step 16->17 の段差が大きく,この時点で多くが離脱していること,またこの時点で入口の 50% 以上の人が離脱してしまったことが把握しやすくなっています。

f:id:doryokujin:20120713004839p:plain 

図6:今度は 1 つ前の step と比較しての離脱率を元にした図を描いてみます。図6 はその step に至る前に離脱した人数を前 step の uu で割った値をプロットした図です。図5 で段差が大きかった step ほどこの値が大きくなり,注目すべき離脱ポイントであることがわかります。このように離脱ポイントが山の高さで特定できる意味でこの図は有用です。これも生存時間解析の脈略では「ハザード比(直前まで離脱せずに生存していたユーザーが,続く瞬間に離脱する確率)」に基づくプロットを(確率では無いですが)模倣してみたものです。

 

ファンネル分析(各セグメントに対して)

次は「入口への流入動機」を表すステータス:"motivated_by" の値をセグメントにしたファンネルを見ていくことにしましょう。今回の例では,チュートリアルの参加が,他ユーザーからインバイトされた場合とそうでない場合では,離脱状況・離脱ポイントに違いがあるのかを確認することを目標にします。

Query 1.2

motivated_by    step	uu	prev_uu	rate_from_enter	rate_from_prev	normed_rate_from_prev
direct_access	1	20,098	20,098	100.0	100.0	0.0
direct_access	2	20,040	20,098	99.7	99.7	0.3
direct_access	3	19,698	20,040	98.0	98.3	1.7
direct_access	4	19,385	19,698	96.5	98.4	1.6
direct_access	5	16,113	19,385	80.2	83.1	20.3
direct_access	6	14,332	16,113	71.3	88.9	12.4
direct_access	7	13,814	14,332	68.7	96.4	3.7
direct_access	8	13,601	13,814	67.7	98.5	1.6
direct_access	9	13,345	13,601	66.4	98.1	1.9
direct_access	10	13,172	13,345	65.5	98.7	1.3
direct_access	11	13,117	13,172	65.3	99.6	0.4
direct_access	12	12,933	13,117	64.3	98.6	1.4
direct_access	13	12,755	12,933	63.5	98.6	1.4
direct_access	14	12,612	12,755	62.8	98.9	1.1
direct_access	15	12,533	12,612	62.4	99.4	0.6
direct_access	16	12,419	12,533	61.8	99.1	0.9
direct_access	17	6,113	12,419	30.4	49.2	103.2
direct_access	18	4,332	6,113	21.6	70.9	41.1
direct_access	19	3,814	4,332	19.0	88.0	13.6
direct_access	20	3,601	3,814	17.9	94.4	5.9
direct_access	21	3,345	3,601	16.6	92.9	7.7
direct_access	22	3,172	3,345	15.8	94.8	5.5
direct_access	23	3,117	3,172	15.5	98.3	1.8
direct_access	24	2,933	3,117	14.6	94.1	6.3
direct_access	25	2,755	2,933	13.7	93.9	6.5
direct_access	26	2,612	2,755	13.0	94.8	5.5
direct_access	27	1,233	2,612	6.1	47.2	111.8
direct_access	28	1,219	1,233	6.1	98.9	1.1
direct_access	29	1,200	1,219	6.0	98.4	1.6
direct_access	30	1,172	1,200	5.8	97.7	2.4

図7:チュートリアルの {"motivated_by": "direct_access"} ユーザーにおける,step ごとの到達ユニークユーザー数をはじめとした集計テーブル。

motivated_by    step    uu    prev_uu	rate_from_enter	rate_from_prev	normed_rate_from_prev
invitation	1	13,597	13,597	100.0	100.0	0.0
invitation	2	12,854	13,597	94.5	94.5	5.8
invitation	3	12,677	12,854	93.2	98.6	1.4
invitation	4	11,783	12,677	86.7	92.9	7.6
invitation	5	11,723	11,783	86.2	99.5	0.5
invitation	6	11,003	11,723	80.9	93.9	6.5
invitation	7	10,634	11,003	78.2	96.6	3.5
invitation	8	10,028	10,634	73.8	94.3	6.0
invitation	9	9,474	10,028	69.7	94.5	5.8
invitation	10	8,922	9,474	65.6	94.2	6.2
invitation	11	8,706	8,922	64.0	97.6	2.5
invitation	12	8,455	8,706	62.2	97.1	3.0
invitation	13	8,408	8,455	61.8	99.4	0.6
invitation	14	8,366	8,408	61.5	99.5	0.5
invitation	15	8,284	8,366	60.9	99.0	1.0
invitation	16	7,952	8,284	58.5	96.0	4.2
invitation	17	5,166	7,952	38.0	65.0	53.9
invitation	18	4,815	5,166	35.4	93.2	7.3
invitation	19	4,767	4,815	35.1	99.0	1.0
invitation	20	4,726	4,767	34.8	99.1	0.9
invitation	21	4,361	4,726	32.1	92.3	8.4
invitation	22	4,286	4,361	31.5	98.3	1.7
invitation	23	3,581	4,286	26.3	83.6	19.7
invitation	24	3,539	3,581	26.0	98.8	1.2
invitation	25	3,398	3,539	25.0	96.0	4.2
invitation	26	3,360	3,398	24.7	98.9	1.1
invitation	27	3,039	3,360	22.4	90.4	10.6
invitation	28	2,891	3,039	21.3	95.1	5.1
invitation	29	2,723	2,891	20.0	94.2	6.1
invitation	30	2,481	2,723	18.2	91.1	9.8

図8:チュートリアルの {"motivated_by": "invitation"} ユーザーにおける,step ごとの到達ユニークユーザー数をはじめとした集計テーブル。

f:id:doryokujin:20120713004918p:plain

図9:実は2 つ以上のファンネルを比較したい場合,図9 のようなメジャーなファンネル図では区別が行いにくいのです。どちらも必ず尻すぼみのじょうごの形となっているので,両者の差の程度が読み取りにくくなっているからです。

f:id:doryokujin:20120713004939p:plain

図10:そこでチュートリアルにおける擬生存曲線を見てみましょう。2つのセグメントの離脱状況の違いがより鮮明に浮かび上がってきます。例えば,step 16->17 への落差が invitation ユーザーの方が小さく,またその後の生存割合の減少具合も daily_access より小さくて最終的に本登録する(入口からの)割合は大きな違いがある,という事がすぐにわかります。

f:id:doryokujin:20120713004949p:plain

図11: さらにチュートリアルにおける擬ハザード比曲線を使って離脱インパクトの大きかった step をセグメントごとに確認してみましょう。direct_access の方が step 16->17 の離脱インパクトが大きく,また,step 26->27 においては invitation ユーザーには見られない大きな山がみられます。確かにこの時点では direct_access ユーザーの半数近くがここで離脱してしまっているという大きな離脱ポイントとなっていますが,invitation ではポイントにはなっていません。図6 によってユーザー全体でのファンネル分析でも確認できたこの離脱ポイントは,実は direct_access ユーザーのみによって引き起こされたものであったことがここで判明しました。

 

最後に

チュートリアルにおけるファンネル分析は他にも週や月といった時間をセグメントに比較するのも有効です。その際には前述した通り各月でのチュートリアル参加人数,離脱人数といった絶対値での比較が可能となります。そういう意味では下のような出発点が揃わない曲線図も加える事ができます。

f:id:doryokujin:20120713040616p:plain

図12: 絶対値である UU を元に月別の離脱状況を比較するための曲線。今までの生存曲線とは違って初期値 step=1 が異なっている。2012-06 におけるユーザーは 2012-07 のそれより入口にやってユーザー数が多いのにもかかわらず,出口では 2012-07 のユーザー数より少なく,途中でより激しく離脱していることがわかる。

さらにこの解析を進めるためには,各 step におけるユーザーの平均滞在時間を見るのが有効です。チュートリアルのログには各 step,各ユーザーのタイムスタンプがとれているので,ユーザー毎に隣接する step 間でのタイムスタンプの差分をとって集計すれば平均滞在時間がわかります。基本的にチュートリアルはさくさく進むべきものであるものなので,意図せず他より滞在時間の長い step はやや問題があるのかもしれません。次はそいういった部分を掘り下げていくのが良いでしょう。

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 というアクションログのみを導入し,ファンネル分析を行っていくことにしましょう。

今日はここまで。

 

Treasure Data Analytics 第6回 〜Heroku Addon からアクションログを取得する〜

 

はじめに

今回は Treasure Data が提供している Heroku Addon を利用して,任意のアクションログを取得する方法を紹介します。また,アクションログの取得については td-logger-ruby または td-logger-java を利用することによって Heroku 上のアプリケーションに限らず任意の Ruby および Java アプリケーションから同じようにアクションログを取得することができます。はじめにアクションログを取得することの有用性について触れ,その次に Heroku Addon の紹介およびアクションログを取得するまでの流れを説明します。

アクションログをフルに活用した解析は次回から始まる Social Gaming Analytics にて詳しく紹介します。

 

アクションログについて

つい最近までの Web サービスにおける解析というのは,アクセスログに基づく解析とほぼ同義でありました。アクセスログに基づく伝統ある解析は現在に至るまでに非常に多くのナレッジが蓄積されており,無料のツールも多々用意されていますので利用価値は現在でも非常に高いものです。

しかしアクションという枠組みで考えるならば,アクセスログとは『(あるページから)あるページへの「アクセス」』という 1 つのアクションのみから成るログに過ぎないことがわかります。

今までこの「ページ」という対象への「アクセス」というアクションのみのログで非常に多くの KPI が作られ,活用されてきた事は非常にすごい事だと思います。逆に言えばアクションのバリエーションを増やすことができ,かつそれらを用いた解析手法を精錬させることができれば,解析の秘める可能性は大きく拡がっていくことになります。

※ もちろん,アクセスログの中で他のアクション,いわゆる「ログイン」や「登録」といったログも参照できる場合がありますが,それはあくまでログインや登録を表す「ページ」が存在する場合に,そのページへの「アクセス」というアクションが「ログイン」として代替されているに過ぎません。

f:id:doryokujin:20120627193736p:plain

図1:「ユーザー」「ブック」というノードとそれらの関係が "Review" というアクションによって表現されている Book-Crossing Dataset の例。ノード・アクションの持つステータスに基づいてセグメントを作成し,その「切り口」からデータを俯瞰するのが前回のテーマでした。

f:id:doryokujin:20120704192034p:plain

図2:アクセスログもまた「ページ」というノードとそれらの関係が "Access" というアクションによって表現されることになります。また,アクセスログの他にページ毎にステータステーブルを持たせておくと有用です。コンバージョンページとなり得るか,などのフラグを複数持たせておくと解析に色々役立ちます。


Heroku-Addon Treasure Data Hadoop について

f:id:doryokujin:20120801090422p:plain

図3:Treasure Data の Heroku Addon は 2012/08/01 より一般公開されました。料金プランなどはリンク先をご確認下さい。

それでは上記のアクションログを容易に取得する方法について簡単に紹介します。Heroku Addon の導入に関しては他のアドオンと変わらず非常に簡単ですのでここでは省略します。こちらのドキュメントを参照下さい。第3回のチュートリアルではアカウント取得後Treasure Data Toolbelrt をインストールするとコマンドラインから

$ td
usage: td [options] COMMAND [args]
...
コマンドが使えるようになりましたが,同じように
$ heroku plugins:install https://github.com/treasure-data/heroku-td.git
$ heroku td
usage: heroku td [options] COMMAND [args]
...
であなたの heroku アプリケーションから Treasure Data Storage に収集された構造化ログに対してアクセスできるようになります。
それでは heroku アプリケーション内から任意のアクションログを収録する方法を紹介します。(これと同じ内容はこちらのドキュメントにもあります。)まず Gemfile に
gem 'td', "~> 0.10.22"

と記述した上で

$ bundle install

しましょう。これによってあなたの Rails プロジェクト内で td-logger-ruby の各種メソッドが使えるようになります。

最も活用されるのは TD.event.post() コマンドです。このコマンドはアプリケーション内から発生したアクション(イベント)を補足し,引数で与えられた JSON 形式の構造化ログを Treasure Data Storage にアップロードするコマンドです。(実際には約 5 分に 1 回のインターバルでその間に収集されたログがまとめてアップロードされるようになっています。)

コード内の任意の箇所にこの TD.event.post() コマンドの 1 行を追記することによってあらゆるアクションログを取得することが可能になるのです。第一引数には "login" や "register" などのアクション名を,第二引数にはそのアクションのステータス情報を JSON 形式で与えます。

言い換えると,第一引数に与えたアクション名がテーブル名に対応し,そのテーブル内のレコードとして第二引数で与えた構造化データが蓄積されていく形になります。例えば "login" というアクションが起こったときに post するようにするのならば該当するコード箇所で

TD.event.post('login', {:uid=>123, :member_type=>'paying',...})

と記述します。"login" アクションに関しては最低限,ユーザーを特定するための :uid があれば十分ですが,ここでは :member_type (有料会員/無料会員/非登録会員)の識別もアクションステータスとして与えています。そうしておけば,会員タイプをセグメントとして login UU を数える場合にはこの "login" テーブルだけを参照して集計すれば良いことになります。

※ 第二引数で与える login に対するステータス情報は,後の集計に利用するかどうか関わらずできるだけ多い情報を含ませておく方が望ましいと僕は考えています。また,ステータス情報には post 毎に過不足があっても構いません。これに関しては,

  • とりあえず利用可能な情報を併せて記録しておく
  • レコードによって項目に過不足があっても構わない

という,いわゆるスキーマレスな NoSQL である MongoDB 的な思想と同じです。その後の集計の際にできるだけ JOIN せずに 1 つのテーブルで集計できてしまう方が効率は良いですし,必ずしも他のテーブルが最新に更新されているとも限りません。また,アプリケーションから集計結果を参照する場合には集計効率は重要になってきます。

話が少しそれてしまいましたが,post された "login" アクションログはデフォルトでは 'rails_production' という db 名に記録され,

$ heroku plugins:install https://github.com/treasure-data/heroku-td.git
$ heroku td tables
+------------------+--------+------+-------+--------+
| Database         | Table  | Type | Count | Schema |
+------------------+--------+------+-------+--------+
| rails_production | login  | log  | 10    |        |
+------------------+--------+------+-------+--------+

として参照することができ,

$ heroku td table:tail rails_production login
{"action":"login","uid":"123","member_type":"paying","time":1320857514}

として生ログにアクセスできます。レコード内の "action" と "time" は自動で付与されます。"time" に関しては post 時に自動で付与されますが,第二引数のステータスに :time キーとして付与しておけばそちらの値が優先して利用されます。

集計クエリも同じように,

$ heroku td query  -w -d rails_production "
SELECT v['member_type'] AS member_type, COUNT(distict v['uid']) AS cnt
GROUP BY v['member_type']
ORDER BY cnt DESC
"

などと実行することができます。

また, Rails アプリケーション内からクエリを実行→結果を取得→利用することももちろん可能で,その場合には

require 'td'
require 'td-client'
cln = TreasureData::Client.new(ENV['TREASURE_DATA_API_KEY'])
job = cln.query('rails_production', 'SELECT member_type, COUNT(distict v['uid']) AS cnt GROUP BY member_type ORDER BY cnt DESC')
until job.finished?
  sleep 2
  job.update_status!
end
if job.success?
  job.result_each { |row| p row }
end

などと記述します。バックグラウンドでは Hadoop が実行るので結果はすぐに返ってきませんので, job.finished? を定期的にジョブの終了を確認しながら待機することになります。

ただ集計処理自身は別スレッドで非同期に行われますのでアプリケーション自身に大きな負荷を与えることはありません。

以上より,クライアントからアドホックにクエリを実行するのではなく,アプリケーション側がバックグラウンドで定期的に集計ジョブを実行するようにしておき,結果を Postgres Addon に書き込むようにしておく(クライアントは Postgres に結果を参照する)使い方のが良いでしょう。

有用な活用方法として,例えば 第5回の「6. 同時参照されているブックペアに関する分析(共起分析)」 で紹介したように,検索キーワードや購入アイテムの共起度計算などを定期的に実行して更新しておくようにすれば,大規模データセットに基づくレコメンデーション機能を構築することも可能かもしれません。

 

最後に

"login" の他にも様々なアクションが考えられますが,ほとんどのアプリに利用できそうな代表的なものを最後に紹介しておきます。

TD.event.post('register', {:uid=>123,...}) # 登録
TD.event.post('pay', {:uid=>123, :category=>'gacha', :item_name=>'comp_gacha', :unit_price=>'300', 'count'=> 10,...}) # 課金
TD.event.post('first_access', {:uid=>123,:page_id=>3,...}) # 最初のページアクセス
TD.event.post('search', {:uid=>123, :keyword=>['word1','word2'], :type=>'AND', ...}) # 検索
TD.event.post('follow', {:uid=>123, :to_uid=>456,...}) # フォロー
TD.event.post('invite', {:uid=>123, :to_uid=>456,...}) # 招待
TD.event.post('step_tutorial', {:uid=>123, :step=>1,...}) # チュートリアルの進捗

あなたのテーブルには多種多様のアクションログが日々蓄積されることになります。

$ heroku td tables
+------------------+---------------+------+-------+--------+
| Database         | Table         | Type | Count | Schema |
+------------------+---------------+------+-------+--------+
| rails_production | login         | log  | 10    |        |
| rails_production | register      | log  | 10    |        |
| rails_production | pay           | log  | 10    |        |
| rails_production | first_access  | log  | 10    |        |
| rails_production | search        | log  | 10    |        |
| rails_production | follow        | log  | 10    |        |
| rails_production | invite        | log  | 10    |        |
| rails_production | step_tutorial | log  | 10    |        |
+------------------+---------------+------+-------+--------+

どのようなアクションログ(とそのステータス)を取得し,複数のアクションをどう組み合わせて解析していくかはあなたの自由です。

次回からは Social Gaming Analytics シリーズとして,アクションログを最大限に活用した解析ユースケースを紹介します。

今日はここまで。