1. 1
事例で学ぶトレジャーデータ
2014/06/12
Takahiro
Inoue
(Chief
Data
Scien:st)
taka@treasure-­‐data.com

2. 2
自己紹介
• 井上 敬浩 (TwiCer:
@doryokujin
)
• チーフデータサイエンティスト
• 慶應大学院数学科統計専攻
• トレジャーデータ公式ブログ
オーサー
• MongoDBマスター
hCp://treasure-­‐data.hateblo.jp

3. 3
• トレジャーデータサービス概要
• （事例1）オンラインゲームソリューション
• （事例2）モダンWebアナリティクス
• （事例3）ECログ分析
アジェンダ
目的：数多くの事例を通してトレジャーデータサービスを知って欲しい

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

5. 5
Treasure
Data
Service
とは
ビッグデータの収集・保存・分析をワンストップで提供する、
クラウド型のデータマネジメントサービス（DMS）
“データ解析の世界をシンプルにしたい”
収集
保存
分析

6. 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. 7
分析レイヤーの詳解
4.
Data
Processing
5.
Data
Visualiza5on
3.
Data
Storage
2.
Data
Collec5on
1.
Data
Source

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

9. 9
ログインログ
Treasure
Data
Service
データ統合
オンラインゲームソリューションとは
課金ログ
招待ログ
KPI:
PV
KPI:
ARPU
KPI:
リテンション
提供するログテンプレートを活用する事で，容易に多種多様なKPI群のモニタリング
が可能に。

10. 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. 11
Data
Processing
Login
テーブル
Pay
テーブル
Inviteテーブル
ユーザー属性
情報テーブル
データ連携
KPI:
PV
KPI:
ARPU
KPI:
リテンション
異なるデータ間の連携と強力な並
列分散処理技術で，大量ログから
様々なKPIを算出。

12. 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. 13
Data
Visualiza:on
KPI:
PV
KPI:
ARPU
KPI:
レベル分布
OEM提供するダッシュボードの1つ1つのウィジェットに1つのKPIが対応。ウィジェット
に分析クエリを仕込むことによって自動的にデータが更新される。

14. 14
ソリューションテンプレート
Treasure
Data
Service
データ解析テンプレート
データ収集テンプレート
ソリューション
コンポーネント:
- Treasure
Data
Service
- 構造化ログのテンプレート
- データ収集エージェント設
定ファイルテンプレート
- 設定済みBIレポーティン
グ・ダッシュボード
初期セットアップ期間内で、業界毎に事前に定義した解析ダッシュボードも提供

15. 15
事例集

16. 16
分析
説明
a.
パス分析
ユーザー，セッションごとの行動分析を「点」ではなく「線（経路）」
で行うことが可能になる。
b.
データ横断分析
「リアル」 と 「Web」 の連携，異なるデータソースの統合分析が
可能になる。
c.
セグメント分析
任意の軸の組み合わせによるセグメントによる傾向分析が可能
になる。
トレジャーデータがもたらす3つの分析可能性
a. あるコンバージョンに対して，そこに至った直前（およびランディング）のポイント：「点」
は見る事ができたが，パス分析によってランディングからコンバージョンに至る「経路」
を調べる事でよりリアルな行動分析が可能になる。
b. 従来は様々に異なるデータソース間の統合分析は非常に面倒であった。トレジャース
トレージへのデータ一元管理は横断分析をより身近なものにした。
c. 従来の小データでは，細かいセグメントを設定すると，各々のセグメントのサンプル数
が非常に疎となっていたため，有意な分析が行えなかった。

17. 17
（事例2）モダンWebアナリティクス
〜トレジャーデータサービスが拡げる2つの可能性〜
a. パス分析：ユーザーのコンバージョンを「点」ではなく「経路」で捉える
b. データ横断分析：「ネット」と「リアル」の連携による分析

18. 18
（事例2-­‐a）点分析：従来のコンバージョンの視点
従来の「点」で捉えるコンバージョン分析
…
…
…
…
検索
サイトA
サイトB
サイトC
ホーム
サイトX
サイトY
コンバー
ジョン
コンバージョン１
1. 検索で
2. サイトAにランディング
3. リファラ：サイトX
4. コンバージョン
コンバージョン2
1. ホームにランディング
2. リファラ：サイトY
3. コンバージョン
ランディング
直前サイト

19. 19
従来の「点」で捉えるコンバージョン分析
…
…
…
…
検索
サイトA
サイトB
サイトC
ホーム
サイトX
サイトY
コンバー
ジョン
コンバージョン１
1. 検索で
2. サイトAにランディング
3. リファラ：サイトX
4. コンバージョン
コンバージョン2
1. ホームにランディング
2. リファラ：サイトY
3. コンバージョン
どのような「経路（パス）」で
来たのかは補足できない
従来のコンバージョンは
1. 最初のアクセス
2. 最後のアクセス
の2点に基づく分析だった
（事例2-­‐a）点分析：最初と最後のアクセス情報しか参照できない

20. 20
（事例2-­‐a）パス分析：ランディングからコンバージョン
に至るまでの「経路」に着目
経路（辺）で捉えるコンバージョン分析
検索
サイトA
サイトB
サイトC
ホーム
サイト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. 21
経路（辺）で捉えるコンバージョン分析
検索
サイトA
サイトB
サイトC
ホーム
サイトX
サイトY
コンバー
ジョン
コンバージョンパス1
1. 検索
2. サイトA
3. サイトB
4. サイトD
5. サイトX
6. コンバージョン
コンバージョンを一連の
「経路」で捉えられる：
1. 最初はどのサイトから
2. 中継サイトはどこで
3. 辺の長さはいくらで
4. 最後はどのサイトで
サイトD
サイトE
サイトF
コンバージョンパス2
1. ホーム
2. サイトC
3. サイトE
4. サイトF
5. サイトY
6. コンバージョン
「間接的」に寄
与したサイトも
考慮できる
（事例2-­‐a）パス分析：ランディングからコンバージョン
に至るまでの「経路」に着目

22. 22
経路（辺）で捉えるコンバージョン分析
検索
サイトA
サイトB
サイトC
ホーム
サイト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. コンバージョン
「間接的」に寄
与したサイトも
考慮できる
（事例2-­‐a）パス分析がもたらす新たな視点
サイトDはコンバージョンパスにおいて最初と最後
には出てこないが，必ず途中に通るサイトである
ことがわかる：
→
「媒介」的な役割として重要
パス2
はコンバージョンに至るまでの経路が長い：
→パスの長さが比較的長いコンバージョンはより
効率良くできるのではないか。

23. 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. 24
データソースA
データソースB
データソースC
データソースD
データ連携
データ連携によってよ
り高度で多様な分析
が可能になる。
（事例2-­‐b）データ横断分析

25. 25
（事例2-­‐b）データ横断分析（リアル×Web）
店舗の顧客をネットストアへ、
ネットストアの顧客を店舗へと相互に送客可能に
非構造化データにも
容易に対応可能
店舗の顧客は店舗へ、
ネットストアの顧客はネットストアへしか送客できない
Why?
Treasure
Data
株式会社良品計画様
POSデータ、Webアクセスログ
O2O
×
• POSデータ、Webアクセスログを収集
• アプリでユーザーIDを統一
• 横断的にユーザーの行動を可視化
Economy & Flexibility
Time to Value

26. 26
（事例3）ECログ分析
〜ECの強みを活かしたアドバンス分析〜
c.
セグメンテーション分析
c’.
セグメンテーションを活かしたリコメンデーション

27. 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. 28
（事例3-­‐c）ユーザーセグメンテーション
月間課金額
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
人
会員登録日
2012年
（オールドユーザー）
2013年
2014年1月〜6月
2014年6月〜
（新規ユーザー）
人数
100,000
人
3,000
人
5,000
人
100
人
↑ユーザーの行動情報をとることで，課金額や訪問回数，さらには招待回数やコメント回
数などの「行動」に基づくセグメントが使えるようになってきた。
↑従来のセグメントはユーザーの属性情報程度のものしか使えなかった。

29. 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
（事例3-­‐c）ユーザーセグメンテーション

30. 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
人
会員登録日
2012年
（オールドユーザー）
2013年
2014年1月〜6月
2014年6月〜
（新規ユーザー）
人数
100,000
人
3,000
人
5,000
人
100
人
1.
ヘビーユーザーで
2.
週1の頻度で
3.
30歳台で
4.
初期から遊んでくれている
1’.
無課金なのに
2’.
常連ユーザーで
3’.
若いユーザーで
4’.
最近の登録ユーザー

31. 31
（事例3-­‐c） ユーザーセグメンテーション
ユーザー「属性」情報に加えてアクセス履歴，購入履歴といった「行動」情報の取得
できるECでは柔軟なセグメンテーションが可能。
セグメント軸
値
月間課金額
5,000
円以上
1,0000
円以内
月間訪問回数
5回以上10回以内
年代
30歳以上40歳以内
会員登録日
2013年
…
…
セグメントＡ
セグメント軸
値
月間課金額
0円
月間訪問回数
1回以内
年代
20歳以上30歳以内
会員登録日
2014年
…
…
セグメントＢ
複数のセグメント軸の
組み合わせによるセグ
メンテーションが可能に。
少数のデータしか扱えない
ならば，細かいセグメントを
作るとそれぞれのサンプル
数が疎になってしまって活
用できない。

32. 32
（事例3-­‐c’）セグメントを活かしたリコメンデーション
従来のリコメンデーション：「この商品を買った人はこの商品も買っています」
商品4
商品3
商品1
商品7
商品5
商品6
商品2
商品1を買った
会員C
リコメンド
リコメンド
会員A
会員B

33. 33
（事例3-­‐c’）セグメントを活かしたリコメンデーション
セグメントを活かしたリコメンデーション：「このセグメントに属する人はこの商品も
買っています」
セグメント軸
値
月間課金額
5,000
円以上
1,0000
円以内
月間訪問回数
5回以上10回以内
年代
30歳以上40歳以内
会員登録日
2013年
…
…
セグメントＡ
セグメントＡに
属するユーザー
商品3
商品2
商品1
商品2
商品4

34. 34
Discussion & Q and A