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

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

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

トレジャーデータで実践:Path 分析(前編)

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

トレジャーデータはクラウドでデータマネージメントサービスを提供しています。

はじめに

トレジャーデータで実戦可能なパス分析ソリューションは,主にWebや広告業界向けのコンバージョン分析の応用(コンバージョン「パス」に主眼をおいた分析を行うもの)と位置付けられます。

パス分析のアイデアは新しいものではなく,むしろはるか前から多くのマーケットのニーズとして捉えられていたものです。

しかしながら現在行われているパス分析は,Google Analytics や SiteCatalyst などのUIを通じて見れるもので,より業界にピンポイントな,または詳細なパスを見るといったかゆいところまでには手が届きませんでした。

ここではトレジャーデータで実践可能なパス分析に関して,Treasure Data Web Site のアクセスログを材料として具体的に解説していきます。

パス分析とは

1. 点分析

まず,「パス」分析の対義語として「点」分析を定義します。

点分析とは,Webの脈略でいうと「ページ」という点の単位でのKPI(PVや直帰率など)を求めるものです。

一方でコンバージョンパスというのは,ユーザーの流入からコンバージョンに至るまでのすべての一連の経路(パス)を指しますが,点分析ではそういった経路全体ではなく,おのおのの点の前後の情報のみで評価するものでした。

f:id:doryokujin:20150402093806j:plain

 (図)従来のコンバージョン分析は,独立した「リファラー」と「ランディングページ」「コンバージョン直前のページ」を試行錯誤しながら分析する必要がありました。

2. パス分析

パス分析は,ユーザーごとの流入からコンバージョンに至るまでの「パス」そのものを分析の軸とする手法です。

f:id:doryokujin:20150402093845j:plain

(図)1人のユーザーであっても,複数回コンバージョンが行われるケースもあります。 その場合はユーザーAの1回目のコンバージョン,2回目のコンバージョン,…,という形でパスを切っていきます。

f:id:doryokujin:20150402093916j:plain

パス自身を見ることによって,上図のような新たな概念がいくつも生まれてきます。点分析のみを行ってきたユーザーにとっては,まさに分析の新境地となることしょう。以下にいくつか挙げてみます:

  • パス平均長:コンバージョンまでにいくつのページ・広告を踏んでリーチしたのか,コンバージョンの「効率」に関して理解する。
  • コンバージョン時間:流入からコンバージョンに至るまでの時間(数分であるものもあれば数週間であるものもある)。同様に「効率」に関して理解する。
  • パス類型:長さや組み合わせが無限大のパスに対して,特定のルールに従ってパスを分類し,その分類の中でどのパス類型がコンバージョンに寄与しているかを知る。
  • スコアリング:パスの概念をもって改めてページ・広告を評価するには,パスの中でどの位置に出現するかによって重みを変える「アトリビューションモデル」を使い分ける。

トレジャーデータの定義するパス分析とは

トレジャーデータのパス分析を紹介するにあたって,まず必要な定義を紹介していきます。

トレジャーデータにおけるパス分析の定義

「ローデータ」と「コンバージョンマスター」を元に作成した「コンバージョンパステーブル」をインプットとした様々な分析をパス分析と呼びます。例えば

  1. パス類型(X-スルーコンバージョン)を行い,
  2. その各々のパスについてののコンバージョン率を求め,
  3. コンバージョンへの寄与が大きいパス(ゴールデンパス)を発見する

ことを主要な目的としした分析となっています。

実践編

(注)ブログにおける実践編ではクエリ自身は記述しておりません。トレジャーデータのパス分析に興味を持たれた方は弊社お問い合わせページ,トレジャーデータを試されたい方は トライアルサインアップページ より登録をお願いします。

ここではTreasure Data で実戦可能なパス分析を Treasure Data Website のログを基にしたサンプルデータを使って具体的に紹介していきます。(サンプルデータは分析用に加工したものですので実際の値とは異なります。)

データフロー

トレジャーデータでパス分析を行うためのデータフローを紹介します。トレジャーデータでは以下のデータフローを手順化した「クエリテンプレート」を用意していますので難しく考える必要はありません。 

f:id:doryokujin:20150402094004j:plain

  1. 「ローデータの確保,TDインポート」:分析ツールまたはサーバーのログからローデータが取得し,TDへインポートします。今なら大規模なデータセットでも embulk が安全にバルクロードしてくれます。
  2. 「Conversion Master の作成」:Conversion と見なす項目およびポイントを定義します。
  3. 「Conversion History の作成」:Conversion が生じた時間などの情報を History Table に更新していきます。
  4. 「Conversion Path の作成」:Raw Data および Conversion History をインプットとしてメインとなる Conversion Path Table を作成します。
  5. 「Conversion Path Set の作成」:分析用に情報縮約した派生テーブルを作成します。
  6. 「レポーティング,可視化」:結果を Tableau などのツールでわかりやすくレポーティング,可視化します。

用意すべき2種類のデータソース

1. Raw Data(アクセスログ,広告配信ログ,etc.,…)

ここでは Treasure Data Web Site のアクセスログのページ情報を元にしたサンプルデータを使用します。

timeuserregioncategorypage_id
1421996813 5539 jp home /treasuredata.com/jp/home
1422599649 6415 jp case-studies /treasuredata.com/jp/case-studies
1422600780 6303 jp products /treasuredata.com/jp/products
1422598969 6543 jp products /treasuredata.com/jp/products
1422600124 6738 jp products /treasuredata.com/jp/products
1422599370 6077 en tryal /treasuredata.com/en/tryal
1422599743 5059 jp products /treasuredata.com/jp/products
1422599820 6303 jp case-studies /treasuredata.com/jp/case-studies

Raw Dataには { time, user, page_id } の3項目が必須です。page_id には正規化されたURLや広告ID などのコンバージョンパスのノードとなる項目です。

また,個人を識別できるものならば Use IDに限らず,Cookie ID,Session ID などで構いません。上の様な Raw Data ならば,多くの業界の多くの人が手に入れる事が可能ですね。

2. Conversion Master

Conversion Master は,Raw Data 内の項目の中でコンバージョンにあたるレコードを抽出したものです。

以下の例は一般的なアクセスログでコンバージョンとみなせる項目となっています。Conversion Master は後付けで再設定可能ですので,思い当たるものをピックアップしておき,後ほど絞り込んで再集計が可能です。また,レベルの設定で重要度の管理をしておくことも可能です。

cv_levelcv_categorydescription
5 signup サインアップ
5 tryal トライアル登録
4 whitepaper ホワイトペーパーDL
4 webinars webinar 参加
3 press-releases プレスリーリース参照
3 customer-stories サクセスストーリー閲覧
3 case-studies ケーススタディ閲覧
トレジャーデータでは以下の要件を満たす Raw Data と,この Conversion Master があればパス分析が可能なのです。
  • User IDなどの個人を識別できる Raw Data をもっていること。
  • Raw Data の中でコンバージョンとなる page_id (IDやURL)を抽出できること。

Conversion Path

前述の2つのソーステーブルから,以下のような Conversion Path テーブルを導出します。コンバージョンパスは Raw Data を,

  • User IDでグルーピング,時系列にソート
  • コンバージョンを示すレコードで区切ってコンバージョンパス1回目,2回目,…,とする

というロジックでテーブルを生成します。ここでは 2015-01-01 の一日を分析対象としています。下図は前述のコンバージョンマスタを参照して作られるコンバージョンパステーブルです。

f:id:doryokujin:20150331150404p:plain

さて,ここからの具体的な分析は Conversion として 「signup」の1種類のみを採用することにし,2015年1月の一ヶ月間を分析対象としています。上記の Conversion Path テーブルは Web ページの URL をおおまかにカテゴライズし,page_id カラムとしていますが,もう一つ上の分類である category カラムも残しておきました。

usercv_idnode_idcv_flagcategorycv_categorycv_levelpage_idcv_timetime
1 62 1 0 press-releases   5 /treasuredata.com/jp/press-releases 1420515421 1420080017
1 62 2 0 products   5 /treasuredata.com/jp/products 1420515421 1420080018
1 62 3 0 products   5 /treasuredata.com/jp/products 1420515421 1420080019
1 62 4 0 home   5 /treasuredata.com/en/home 1420515421 1420080021
1 62 5 0 whitepaper   5 /treasuredata.com/jp/whitepapers 1420515421 1420080022
1 62 6 0 press-releases   5 /treasuredata.com/en/press-releases 1420515421 1420080024
1 62 7 0 home   5 /treasuredata.com/en/home 1420515421 1420080025
1 62 8 0 home   5 /treasuredata.com/en/home 1420515421 1420080318
...                  
1 62 100 0 signup singnup 5 /treasuredata.com/jp/signup 1420515421 1420515421

Conversion Set

前述の Conversion Path テーブルは一つのパスでその長さ分だけレコードが存在しますが,後の分析で扱いやすくするために一つのパスを一つのレコードに情報縮約した派生テーブルを作成します。

Conversion Set は以下のテーブル定義で Conversion Path より導出された派生テーブルです。

カラム名 説明
user ユーザーID  "1"
cv_id コンバージョンID  910
landing_category ランディングしたカテゴリ名  "press-releases"
last_category コンバージョン直前のカテゴリ名  "home"
cv_category コンバージョンしたカテゴリ名  "signup"
category_set パス内に存在するカテゴリ集合  [ "home", "signup"," press-releases", "products" ]
landing_node ランディングしたノード名  "/treasuredata.com/jp/home"
last_node コンバージョン直前のノード名  "/treasuredata.com/jp/press-releases"
cv_node コンバージョンしたノード名  "/treasuredata.com/jp/signup"
node_set パス内に存在するノード集合  [ "/treasuredata.com/jp/home", "/treasuredata.com/jp/press-releases", "/treasuredata.com/jp/products",  "/treasuredata.com/en/home" ]
path_length パス長 104
landing_time ランディングタイム  1421689018
last_time コンバージョンタイム  1421690908

この時に失われてしまいかつ重要な情報は別カラム名で保持しておきます。ここでは「landing/last category」「landing/last node」がそれに該当します。

Conversion Set では Hive の COLLECT_SET という関数を使用しています。これは同一の値を除外し,かつ順番を保持しないリスト(集合)を保持するものです。

Un-Conversion Path,Un-Conversion Set

ところで,Raw Data から Conversion Path を作成した際に,失われてしまった重要な情報があります。コンバージョンに至らなかった非 Conversion Path(Un-Conversion Path)です。

コンバージョンしなかったユーザーの Un-Conversoin Path は非常に巨大であったため,今までは扱われずに捨てられてしまっていました。しかしながら,各々のパスのコンバージョン「率」を計算するためには,この Un-Conversion Path が不可欠となります。トレジャーデータでは問題無くこれらを保持することが可能で,同様に派生テーブル群を作成します。

usernode_idpage_idcategorytime
1114 1 /treasuredata.com/jp/webinars webinars 1420552562
1114 2 /treasuredata.com/jp/press-releases press-releases 1420552563
1114 3 /treasuredata.com/en/home home 1420552567
1114 4 /treasuredata.com/jp/products products 1420552568
1114 5 /treasuredata.com/jp/products products 1420552570
1114 6 /treasuredata.com/jp/home home 1420552575

(図)Un-Conversion Path はコンバージョンポイントのない,冗長なテーブルとなります。Un-Conversion Set も同様です(省略)。

1. コンバージョン回数,平均パス長,平均コンバージョン時間コンバージョンパスに特化したKPI(全体)

全体のコンバージョン回数とパスの平均パス長,平均コンバージョン時間を算出します。一般に平均パス長とコンバージョン時間は,値が小さいほどコンバージョンへの効率が良いものと判断できます。

(クエリ実行後の結果)

コンバージョン回数平均パス長平均コンバージョン時間
5359 987.456428438141 72918.3349505505

2015年1月には5359回のコンバージョン(サインアップ)がありました。また,平均的に987回のページ遷移の末にコンバージョンしました。コンバージョンまでに平均的に72981秒(≃20時間)の時間を要しました。

2. コンバージョンパス長の分布

先ほどは「平均」パス長さを求めましたが,パスの長さを「分布」として見る事でさらに多くの情報を得ることが可能です。

(クエリ実行後の結果)

path_lengthcnt
1 235
2 71
3 68
4 86
5 107
6 112
7 103
8 99

f:id:doryokujin:20150331150422p:plain

 (図)平均パス長では1000という大きな値を出しましたが,実際には100以下のパス長さのものが多いことが分布よりわかります。

f:id:doryokujin:20150331150444p:plain

 (図)一方で,平均より長パスの分布を見ていると数としては前者より非常に少なく,平均パス長は極端に大きなパス長さに引っ張られた形となっていたことがわかります。

3. コンバージョン時間の分布

同様にコンバージョン時間の分布も見てみましょう。

(クエリ実行後の結果)

xcnt
0 3100
10 935
20 346
30 259
40 54
50 105

f:id:doryokujin:20150331150457p:plain

 (図)コンバージョン時間もパス長さと同じように,大きな平均値とは反して10時間までの値(特に10時間以内が3000件以上!)が多く分布していることがわかります。

4. コンバージョン率(全体)

非コンバージョンを保持していましたので,コンバージョン率の算出が可能です。

(クエリ実行後の結果)

cv_cntuncv_cntcv_ratio
5359 46500 0.10333789699

コンバージョン率は10%と,なかなか良い数字を出していることがわかります。

ここまでが前編となります。ご紹介した通り,トレジャーデータでは生ログを活用することで自由自在な分析を実現することができます。繰り返しになりますが,トレジャーデータに興味を持たれた方はトライアルサインアップページよりご登録をお願いします。

後編ではパスを類別して,さらに踏み込んだパス分析をご紹介します,ご期待下さい!