事例で学ぶトレジャーデータ 20140612

1

事例で学ぶトレジャーデータ

2014/06/12

Takahiro Inoue (Chief Data Scien:st) taka@treasure-‐data.com

2

自己紹介

•  井上　敬浩 (TwiCer: @doryokujin )

•  チーフデータサイエンティスト

•  慶應大学院数学科統計専攻

•  トレジャーデータ公式ブログオーサー

•  MongoDBマスター

hCp://treasure-‐data.hateblo.jp

3

•  トレジャーデータサービス概要

•  （事例1）オンラインゲームソリューション

•  （事例2）モダンWebアナリティクス

•  （事例3）ECログ分析

アジェンダ

目的：数多くの事例を通してトレジャーデータサービスを知って欲しい

4

トレジャーデータサービス概要

5

Treasure Data Service とは

ビッグデータの収集・保存・分析をワンストップで提供する、クラウド型のデータマネジメントサービス（DMS）

“データ解析の世界をシンプルにしたい”

収集保存分析

KPI

データ可視化・共有

分析ツール連携

他製品連携

RDBMS, Google Docs, AWS S3, FTP Server, etc.

Mo:on Board, Metric Insights, etc.

Tableau, Dr.Sum, Power BI, Excel, etc.

6

Treasure Data Service

Result Output クエリ結果自動書込

データ収集データ分析データ保管

収集・保存・分析をワンストップに、柔軟なインターフェイスで提供。

データ集計 SQL, Pig

ストレージ Flexible, Scalable, Columnar

Storage

バッチ型分析

アドホック型分析

分析エンジン Hadoop, Treasure Query Accelerator

データ抽出 REST API

ODBC/JDBC （SQL, Pig）

Webログ

Appログ

センサー

CRM

ERP

RDBMS

TD Toolbelt

並列バルク　　インポーター

Treasure Agent

ストリーミング　　ログコレクター

POS

7

分析レイヤーの詳解

4. Data Processing

5. Data Visualiza5on

3. Data Storage

2. Data Collec5on

1. Data Source

8

（事例1）オンラインゲームソリューション〜オンラインゲーム分析のソリューションをもとにトレジャーデータサービスを知る〜

9

ログインログ


データ統合

オンラインゲームソリューションとは

課金ログ

招待ログ

KPI: PV

KPI: ARPU

KPI: リテンション

提供するログテンプレートを活用する事で，容易に多種多様なKPI群のモニタリングが可能に。

10

Data Source / Storage / Collec:on # Applica5on Ruby Code TD.event.post( ’login', { :uid => 123, :device => ’smart phone’, :5me => 138959673 }) TD.event.post( ’pay', { :uid => 123, :name => ’ItemA’, :sub_category => ’a’, :category => A, :count => 2, :price => 300, :5me => 138959673 }) TD.event.post( ’invite', { :uid => 123, :invited_uid => 456, :campaign_name => ’event2’, :5me => 138959673 })

※ 各言語向けに収集ツール Treasure Data Library を提供 Java, Ruby, PHP, Perl, Python, Scala, Node.js , JS Tag Library

Login テーブル Pay テーブル

Inviteテーブルユーザー属性情報テーブル

Treasure-‐Agent （Fluentd）を通じて発生したログを定常的にトレジャークラウドにアップロードされる

11

Data Processing

Login テーブル Pay テーブル

Inviteテーブルユーザー属性情報テーブル

データ連携

KPI: PV

KPI: ARPU

KPI: リテンション

異なるデータ間の連携と強力な並列分散処理技術で，大量ログから様々なKPIを算出。

12

Category KPI Example

Ac:veness ゲームをの活況度を判断するKPI群。アクティブユーザー数，新規ユーザー数，etc…

Funnel ( Conversion ) Analysis コンバージョンまでの経路の離脱率を図るKPI群。コンバージョン，チュートリアルのステップ毎の離脱度，etc…

Sales Revenue 課金周りのKPI群。売り上げ，ARPU, ARPPU, etc…

Distribu:on ユーザー数や課金額の分布を様々なセグメントで切った分布。課金額の分布，レベルの分布，所有ポイント数の分布，etc…

Inflow / Ouilow Equilibrium 流入と流出の平衡を見るためのKPI群。仮想通貨の提供量/消費量，etc…

Reten:on 初回登録から再ログインまでの期間やリピート回数, etc…

これらのカテゴリーに属するKPI群を導入時から参照できるKPIテンプレートを用意

KPI カテゴリ

13

Data Visualiza:on KPI: PV

KPI: ARPU

KPI: レベル分布

OEM提供するダッシュボードの1つ1つのウィジェットに1つのKPIが対応。ウィジェットに分析クエリを仕込むことによって自動的にデータが更新される。

14

ソリューションテンプレート


データ解析テンプレート

データ収集テンプレート

ソリューションコンポーネント: -  Treasure Data Service - 構造化ログのテンプレート

- データ収集エージェント設

定ファイルテンプレート

- 設定済みBIレポーティン

グ・ダッシュボード

初期セットアップ期間内で、業界毎に事前に定義した解析ダッシュボードも提供

15

事例集

16

分析説明

a. パス分析ユーザー，セッションごとの行動分析を「点」ではなく「線（経路）」で行うことが可能になる。

b. データ横断分析「リアル」と「Web」の連携，異なるデータソースの統合分析が可能になる。

c. セグメント分析任意の軸の組み合わせによるセグメントによる傾向分析が可能になる。

トレジャーデータがもたらす3つの分析可能性

a.  あるコンバージョンに対して，そこに至った直前（およびランディング）のポイント：「点」は見る事ができたが，パス分析によってランディングからコンバージョンに至る「経路」を調べる事でよりリアルな行動分析が可能になる。

b.  従来は様々に異なるデータソース間の統合分析は非常に面倒であった。トレジャーストレージへのデータ一元管理は横断分析をより身近なものにした。

c.  従来の小データでは，細かいセグメントを設定すると，各々のセグメントのサンプル数

が非常に疎となっていたため，有意な分析が行えなかった。

17

（事例2）モダンWebアナリティクス〜トレジャーデータサービスが拡げる2つの可能性〜

a.  パス分析：ユーザーのコンバージョンを「点」ではなく「経路」で捉える

b.  データ横断分析：「ネット」と「リアル」の連携による分析

18

（事例2-‐a）点分析：従来のコンバージョンの視点

従来の「点」で捉えるコンバージョン分析

…

…

…

…

検索サイトA サイトB

サイトC ホーム

サイトX

サイトY

コンバージョン

コンバージョン１ 1.  検索で 2.  サイトAにランディング 3.  リファラ：サイトX 4.  コンバージョン

コンバージョン2 1.  ホームにランディング 2.  リファラ：サイトY 3.  コンバージョン

ランディング直前サイト

19

従来の「点」で捉えるコンバージョン分析

…

…

…

…



サイトX

サイトY


コンバージョン１ 1.  検索で 2.  サイトAにランディング 3.  リファラ：サイトX 4.  コンバージョン

コンバージョン2 1.  ホームにランディング 2.  リファラ：サイトY 3.  コンバージョン

どのような「経路（パス）」で来たのかは補足できない

従来のコンバージョンは 1.  最初のアクセス 2.  最後のアクセス

の2点に基づく分析だった

（事例2-‐a）点分析：最初と最後のアクセス情報しか参照できない

20

（事例2-‐a）パス分析：ランディングからコンバージョンに至るまでの「経路」に着目

経路（辺）で捉えるコンバージョン分析



サイトX

サイトY


コンバージョンパス1 1.  検索 2.  サイトA 3.  サイトB 4.  サイトD 5.  サイトX 6.  コンバージョン

サイトD

サイトE

サイトF

コンバージョンパス2 1.  ホーム 2.  サイトC 3.  サイトE 4.  サイトF 5.  サイトY 6.  コンバージョン

21




サイトX

サイトY



コンバージョンを一連の

「経路」で捉えられる： 1.  最初はどのサイトから 2.  中継サイトはどこで 3.  辺の長さはいくらで 4.  最後はどのサイトで

サイトD

サイトE

サイトF


「間接的」に寄与したサイトも考慮できる

（事例2-‐a）パス分析：ランディングからコンバージョンに至るまでの「経路」に着目

22




サイトX

サイトY



サイトD

サイトE

サイトF


「間接的」に寄与したサイトも考慮できる

（事例2-‐a）パス分析がもたらす新たな視点サイトDはコンバージョンパスにおいて最初と最後には出てこないが，必ず途中に通るサイトであることがわかる： → 「媒介」的な役割として重要

パス2 はコンバージョンに至るまでの経路が長い： →パスの長さが比較的長いコンバージョンはより効率良くできるのではないか。

23

Send to FTP

FTP Server

op://op.treasure-‐data.com/

Push to API via Bulk Import

デイリーでファイルをSync，モニタリング

Receive / Process

クエリのスケジューリング機能で集計を自動化。複数のデータソースを横断した集計も可能。

Store, Query, & Analyze BI Connec5vity

Data Feeds DWH

Dashboard: Metric Insights

BI: Tableau

サイトカタリストの手の届かなかった部分を強力にサポートする。

（事例2-‐a）その他の強み：従来のWeb分析ツールを協力に補完

24

データソースA データソースB

データソースC データソースD

データ連携

データ連携によってより高度で多様な分析

が可能になる。

（事例2-‐b）データ横断分析

25

（事例2-‐b）データ横断分析（リアル×Web）

店舗の顧客をネットストアへ、ネットストアの顧客を店舗へと相互に送客可能に

非構造化データにも容易に対応可能

店舗の顧客は店舗へ、ネットストアの顧客はネットストアへしか送客できない

Why? Treasure Data

株式会社良品計画様

POSデータ、Webアクセスログ O2O ×

•  POSデータ、Webアクセスログを収集 •  アプリでユーザーIDを統一 •  横断的にユーザーの行動を可視化

Economy & Flexibility

Time to Value

26

（事例3）ECログ分析〜ECの強みを活かしたアドバンス分析〜

c. セグメンテーション分析

c’. セグメンテーションを活かしたリコメンデーション

27

（事例3-‐c）ユーザーセグメンテーション

年代〜 20歳 20 〜 30歳 30 〜 40歳〜 40歳

人数 10,000 人 20,000 人 15,000 人 5,000 人

会員登録日 2012年（オールドユーザー）

2013年 2014年1月〜6月 2014年6月〜（新規ユーザー）

人数 100,000 人 3,000 人 5,000 人 100 人

↑従来のセグメントはユーザーの「属性」情報程度のものしか使えなかった。

28


月間課金額 0 円以内（無課金ユーザー）

〜1,000 円（ライトユーザー）

〜10,000 円（プレミアムユーザー）

10,000円〜（ヘビーユーザー）

人数 10,000 人 5,000 人 1,000 人 10 人

月間訪問回数 1 回（月1ユーザー）

〜4 回（週1ユーザー）

〜 8 回（週2,3 ユーザー）

〜 8回（常連ユーザー）

人数 10,000 人 5,000 人 1,000 人 10 人

年代〜 20歳 20 〜 30歳 30 〜 40歳〜 40歳

人数 10,000 人 20,000 人 15,000 人 5,000 人


2013年 2014年1月〜6月 2014年6月〜（新規ユーザー）

人数 100,000 人 3,000 人 5,000 人 100 人

↑ユーザーの行動情報をとることで，課金額や訪問回数，さらには招待回数やコメント回数などの「行動」に基づくセグメントが使えるようになってきた。

↑従来のセグメントはユーザーの属性情報程度のものしか使えなかった。

29

RFM分析（R=Recency, F = Frequency, M=Monetary ）のように2種類の軸，例えば「直近のアクセス日（R）」 ×「月間課金額区分」でのセグメントも活用されつつある。

R/M 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000

0 119 70 57 41 44 38 32 21 32 29

1 199 66 60 32 40 38 27 31 26 27

2 128 92 80 57 56 43 50 41 32 29

3 122 76 71 51 50 38 36 31 27 20

4 151 62 51 33 36 39 35 34 39 29

5 142 86 52 59 36 40 33 34 39 30

6 202 140 113 91 96 72 71 61 58 53

7 282 180 120 98 81 86 76 69 51 35

8 355 161 117 88 70 68 50 43 35 33

9 249 133 90 77 61 42 51 46 42 29

10 237 93 67 64 33 39 33 27 28 23

11 186 119 100 49 52 42 37 40 21 27

12 212 61 47 42 44 38 29 30 24 14

13 225 162 120 108 110 104 73 71 69 56

14 454 170 126 79 88 62 63 59 53 38

15 375 189 129 99 93 96 56 52 44 41

16 164 119 74 63 58 45 46 37 17 25

17 242 100 80 44 34 33 32 24 21 20

18 317 154 79 62 46 40 35 18 23 11

19 200 135 74 60 50 36 29 33 21 23

20 268 146 98 97 73 69 49 48 40 40

21 249 128 87 61 47 47 47 43 37 19

22 202 150 101 71 51 50 35 40 26 25

23 177 100 70 64 33 42 35 25 18 22

24 132 93 54 40 26 20 22 22 20 13

25 208 121 82 44 36 35 23 21 18 16

26 170 113 66 69 37 36 36 20 15 17

27 228 141 106 84 74 61 37 58 51 29

28 154 119 71 58 40 44 27 25 18 13

29 163 96 86 44 44 26 30 17 11 14

30 273 113 79 58 44 31 34 27 22 20


30

•  週末のみのアクセスで大量の買い物をしてくれる中年ファン（お金にゆとりのある）セグメント •  毎日アクセスしてくれるけど，買い物をしてくれない，最近登録した若いユーザーセグメント

トレジャーデータサービスを使えば，任意のセグメントの組み合わせ，および任意の区切り方で独自のセグメントを作ることができる。

月間課金額 0 円以内（無課金ユーザー）

〜1,000 円（ライトユーザー）

〜10,000 円（プレミアムユーザー）

10,000円〜（ヘビーユーザー）

人数 10,000 人 5,000 人 1,000 人 10 人

月間訪問回数 1 回（月1ユーザー）

〜4 回（週1ユーザー）

〜 8 回（週2,3 ユーザー）

〜 8回（常連ユーザー）

人数 10,000 人 5,000 人 1,000 人 10 人

年代〜 20歳 20 〜 30歳 30 〜 40歳〜 40歳

人数 10,000 人 20,000 人 15,000 人 5,000 人


2013年 2014年1月〜6月 2014年6月〜（新規ユーザー）

人数 100,000 人 3,000 人 5,000 人 100 人

1. ヘビーユーザーで

2. 週1の頻度で

3. 30歳台で

4. 初期から遊んでくれている

1’. 無課金なのに

2’. 常連ユーザーで

3’. 若いユーザーで

4’. 最近の登録ユーザー

31


ユーザー「属性」情報に加えてアクセス履歴，購入履歴といった「行動」情報の取得

できるECでは柔軟なセグメンテーションが可能。

セグメント軸値

月間課金額 5,000 円以上 1,0000 円以内

月間訪問回数 5回以上10回以内

年代 30歳以上40歳以内

会員登録日 2013年

… … セグメントＡ


月間課金額 0円

月間訪問回数 1回以内



… … セグメントＢ

複数のセグメント軸の組み合わせによるセグメンテーションが可能に。

少数のデータしか扱えないならば，細かいセグメントを作るとそれぞれのサンプル数が疎になってしまって活用できない。

32

（事例3-‐c’）セグメントを活かしたリコメンデーション

従来のリコメンデーション：「この商品を買った人はこの商品も買っています」

商品4 商品3

商品1

商品7

商品5

商品6

商品2

商品1を買った会員C

リコメンドリコメンド

会員A 会員B

33

（事例3-‐c’）セグメントを活かしたリコメンデーション

セグメントを活かしたリコメンデーション：「このセグメントに属する人はこの商品も買っています」


月間課金額 5,000 円以上 1,0000 円以内

月間訪問回数 5回以上10回以内



… … セグメントＡ

セグメントＡに属するユーザー

商品3 商品2 商品1

商品2

商品4

34

Discussion & Q and A

事例で学ぶトレジャーデータ 20140612

Technology

Transcript of 事例で学ぶトレジャーデータ 20140612