読者です 読者をやめる 読者になる 読者になる

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

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

トレジャーデータで実践「離脱分析」〜 コホート分析と生存時間分析 〜

実践シリーズ 分析手法シリーズ 離脱分析

はじめに

ほとんど全ての会員制サービスには,顧客の「入会」と「退会」という概念があります。そして退会(ここでは離脱と呼びます)における分析は,それを防止するという目的において非常に重要です。本記事ではいくつかの「離脱分析」の手法を,トレジャーデータ+スプレッドシートだけで完結でき,かつ誰もが実践できる形でご紹介します。

 

「離脱分析」必要な最低限のデータセット

初めの2回で紹介する手法においては,分析に必要なデータセットはシンプルで汎用的なものです。最低限必要な項目は「ユーザーID」「入会日時」「退会日時」この3つです。また,分析実行時にサービスを継続しているユーザーは退会日時の値は入っていないことになります。

今回は後々の分析にも備えて上記の項目以外に,もう少し多くの情報を持たせたデータ(これを raw_data と呼ぶことにします)を扱っていきます。本データでは「退会日」ではなく「最終アクセス日」を採用し,「2013-01-01」を起点としてそれ以降にアクセスの無かった会員は「退会(is_cancelld=1)」とみなすことにします。また,日付や期間は全て「期(Q=3ヶ月)単位」で扱っていきます。

※ ちなみに上記の会員の姓名や年齢は「なんちゃって個人情報」から簡単にダミー作成することが可能です。

コホート分析

コホート分析は,同じ時期に入会した会員が,時間を追うごとにどれくらい離脱しているのかをテーブルで表示するものです。入会時期によって会員をセグメント分けすることで,入会時期でその後の離脱率に違いがあるのかどうかを見ていくことができます。また離脱時期も,ある時期だけに異常に会員が離脱していれば,それが顕著にあらわれるようになっています。まずは raw_data からコホート分析に必要な集計をかけます。

この集計結果は以下のようになりますが,これをスプレッドシートにインポートし,ピボットテーブルを作り,小計を加えます。

上記のコホートシートでは,X軸に入会時期,Y軸に離脱時期を並べ,セルの値に離脱した人数を示しています。下の行にある「離脱合計」は観測起点(2013-01-01)までに離脱した総数を,「継続合計」には観測起点以後もアクセスがあった会員の総数を表しています。加入時期で会員をセグメント分けした上で継続率(継続合計/当期加入者合計)を求めています。入会時期によって,継続率も異なっていることがわかりますね。

また,離脱時期については2011〜2012年においてどの入会時期の会員も多くなっていることが見受けられます。最終列の「離脱合計」は,離脱時期ごとの合計を表しています。

継続期間テーブル

コホートシートでは,Y軸に「離脱時期」を採用しましたが,替わりに「継続期間」を採用することによって,各々の入会時期の会員がどれくらいの継続期間であるかを一覧することができます。

継続期間,例えば「1Y1Q」は会員期間が1年+3ヶ月であった事を示しています。このテーブルの最後の方の列に着目してください。入会時期によらず,継続期間ごとに会員数を集計してみると,入会から時期を経るごとに,どれ位の割合の会員が離脱していっているのかの以下のような「継続率推移チャート」を作成することができます。

 

この継続率推移チャートは,段差が大きくなっている期間が離脱が多いことを意味しています。また,離脱人数チャートを同時表示することで,どの時期にどかっと離脱したのかを見ることができます。

継続率推移チャートの「違和感」

さて,継続率推移チャートは会員の離脱状況を一目で見ることのできる便利なチャートですが,このチャートにどこか「違和感」を感じないでしょうか?

今回の分析では,分析起点を「2013-01-01」に据えています。例えば「2006-01Q」に加入した会員は,7年間という十分なレンジでこの期間の離脱数を正確に計算することができますが,逆に「2012-4Q」に加入した会員においては,分析起点まで1Q(=3ヶ月)のレンジかないために,全てのユーザーが「継続」(=離脱ゼロ)という扱いになっていまっています。もしあと数年の期間で観測できていれば,それぞれの期間で離脱していく状況になるはずですが,今回は観測を「打ち切って」しまっているためにそれが見えなくなっています。

この違和感の正体は,短期の継続期間においてはそれなりに正確に集計することができても,長期の継続期間では,離脱を観測できる会員数が(最初期に加入した会員のみ)激減してしまうために,継続率は真の値よりも遙かに「大きく」見積もられていることになります。

f:id:doryokujin:20160705145737p:plain

統計的に妥当な継続率推移チャートを得る

それでは,違和感のない継続率チャートを得るためにはどうしたら良いのでしょうか?ここに一つの提案があります。直近加入の会員が将来離脱するであろう期間を統計的に「補間」することで,長期の継続期間でも妥当な値を見積もろうというものです。

生存時間分析

これを実現するための手法が「生存時間分析」になります。

先ほどと同じデータを使って,以下のクエリを実行します:

ここで得られた結果をスプレッドシートにインポートします。今回求められたF列目「km_stat」は Kaplan_Meier(積-極限)推定量でこれは「生存関数」と呼ばれ,その期間までの生存率(継続率)を表しています。

例えば加入から3ヶ月(0Y1Q)での継続率は99.9%,3年3ヶ月(3Y1Q)での継続率は94.9%,7年1ヶ月(7Y1Q)では71.9%となっています。

最後に,生存時間分析で求められた継続率推移チャート(統計的な脈略では生存関数チャートと呼びます)は下図のようになります。先ほどの継続率推移チャートでは求められなかった,期間の長いところでの継続率が妥当に見積もられていることがわかりますね。

実社会における離脱分析の中では,生存時間分析をされているケースはあまり見たことがありませんが,それを行う有効性を感じて頂ければ幸いです。

生存時間分析はなかなかに奥の深い分析です。トレジャーデータユーザーの方で試してみたいという方がいらっしゃいましたらお声かけください!

 

Data Connector for Google Analytics Reporting 徹底解説 その6

Data Connector Web アクセスログ データ収集

前回まで

 

6. GA で生データに近いものを取得する

6-1. Custom Dimension,Custom Metric について

Custom Dimension,Custom Metric は GA アカウントの既定の Dimension と Metric とほとんど同一ですが,自分で作成するという点で異なります。GA で自動的にトラッキングされないデータを収集,解析するために使用できます。

6-1-1. 制限事項と注意事項

各プロパティごとに Custom Dimension のインデックスを 20,Custom Metric のインデックスを 20 利用できます。プレミアム アカウントの場合は,Custom Dimension のインデックスを 200,Custom Metric のインデックスを 200 利用できます。Custom Dimension を削除することはできませんが,無効にはできます。

6-1-2. 設定

Custom Dimension や Custom Metricの値を GA に送るには,GA のプロパティで事前に値を定義しておく必要があります。Custom Dimension,Custom Metric を定義する際には,特定のインデックスで名前とその他の設定値を指定します。

Custom Dimension には次の設定値があります。 

  • 名前 - Custom Dimension の名前で,この名前がレポートに表示されます。
  • スコープ -  Custom Dimension または Custom Metric を適用するデータを指定します。 スコープの詳細をご確認ください。
  • アクティブ - Custom Dimension または Custom Metric の値を処理するかどうかを指定します。アクティブでない Custom Dimension もレポートに表示されますが,その値は処理されません。

カスタム指標の設定値には次のものがあります。

  • 名前 - Custom Metric の名前で,この名前がレポートに表示されます。
  • - Custom Metric の値をレポートに表示する方法を指定します。
  • 最小値,最大値 - 処理とレポート表示の対象とする値の最小値と最大値です。
  • アクティブ - Custom Metric の値を処理するかどうかを指定します。アクティブでない Custom Metric もレポートに表示されますが,その値は処理されません。 

Custom Dimension,Custom Metric は Google アナリティクスの管理画面で定義します。以下で具体的な Custom Dimension の定義の仕方を見ていきましょう。

6-1-3. 有効にするまでのステップ

Custom Dimension,Custom Metric を有効(実際に取得可能な状態)にするためには,以下の 2 ステップが必須になります。

  1. GA の ADMIN から,Custom Dimension,Custom Metric を定義する。
  2. サイトのトラッキングコードに Custom Dimension,Custom Metric を取得するためのコードを追記

特に 2. の,トラッキングコードへの追記作業が伴うことには注意してください。自身にコード編集権限が無い場合,管理者や運用者にトラッキングコードの追記の許可や依頼の必要があるかもしれません。

6-2. Client Id のトラッキング設定

GA のレポートの中ではユニークユーザー数などは簡単に見ることができますが、デフォルトでは取得できない項目となっています。Client Id は GA が cookie の中で保持しているユーザー識別ID です。カスタムディメンジョンとしてこの Client Id を設定すれば,全てのデータで Client ID の粒度での集計値が取得できます。

f:id:doryokujin:20161006132624p:plain

Custom Dimension,Custom Metric の定義は,GA の ADMIN 項目の Property の中にある「Custom Definitions」をクリックします。

f:id:doryokujin:20161006132647p:plain

既に Custom Dimension が定義されている場合にはその項目の一覧を見ることができます。重要なのは,Custom Dimension は一度作成すると削除できないこと(非アクティブ可),Data Connector で Custom Dimension を取ってくる場合には “ga:clientId” や “ga:timestamp” ではなく,”ga:dimension1” と ”ga:dimension2” とインデックスを伴う固定文字列であることです。 

f:id:doryokujin:20161006132710p:plain

Custom Dimension として ClientId を定義します。ユーザー単位での取得になりますので Scope では User としておきます。詳しくは スコープの詳細をご確認ください。

画面右の方で Custom Dimension を取得するためのトラッキングコード例が表示されますが,JS 向けのClientID トラッキングコードを以下のように追記します:

gist.github.com

新しく Custom Dimension を設定した場合には,実際にこの項目が取得できるのは次の日以降になります。

6-3. GA から Client Id を取得

さて,Data Connector の話に戻って Client Id を取得するための設定ファイルを確認しましょう。取得するカラム名はデフォルトでは「dimension1」となり,扱いにくいので「client_id」に Rename してインポートします。

gist.github.com

gist.github.com

↑ ※上記の Client ID は適当な文字列を割り振ってあります。

6-4. Timestamp のトラッキング設定

Client ID に加えて timestamp を Custom Dimension として取得する方法を紹介します。timestamp まで取得すると,GA から取得するレコード数が大きく増えることに注意してください。また,GA の標準設定で分単位までの粒度でデータ取得可能です。

Custom Dimension として Timestamp を定義します。ヒット単位での取得になりますので Scope では Hit としておきます。詳しくは スコープの詳細をご確認ください。

トラッキングコードは以下になります:

gist.github.com

6-5. GA から Client Id, Timestamp を取得

gist.github.com

gist.github.com

↑ Custom Dimension として Timestamp を設定していますので,型が文字列となっていることに注意してください。

さて,Data Connector を使って GA で取得した timestamp をトレジャーデータの time カラムとしてインポートするために,dimension1 の Rename に加えて YAML ファイルに追加の設定を行います。

gist.github.com

↑ 18〜25行目までが追加設定となります。こちらの使用方法についてはドキュメントを参照ください。「in:」で取得したカラムに対して,型や名前を変換したい場合に記述する filter 機能を活かしています。

また,この設定ファイルを使う場合は,td connector:issue コマンド内で --time-column オプションを省略します。

gist.github.com

6-6. GA に外部紐付け可能な User ID を埋め込む

6-2. では GA 内で有効な Client ID を取得しましたが,利用者が外部サービスと紐付く User ID を GA の中でもユーザー識別子として扱いたい,というケースもあると思います。これを可能にする方法は GA のドキュメントをご参照下さい。 

Data Connector for Google Analytics Reporting 徹底解説 その5

Data Connector Web アクセスログ データ収集

前回まで

5. 標準で取得できる項目とその活用方法について

5-1.  Web 分析で用いられる主要なデータ項目

GA の標準設定(トラッキングコードがオリジナルのもの)においてでも,非常に多くのデータ項目を取得することができます。その一覧が Dimensions & Metrics Explorer にありますが,ここではその中でも有用な項目をピックアップしていきます。その前に, Dimension と Metric の概念を学習しましょう。

5-1-1. Dimension と Metric

Dimesion は,ある Metric(集計値)を求める際の内訳を意味します。例えば「次でのUU」「単位のPV」「ユーザー毎の総課金額」とある場合,順に「日 - date」「分 - minute」「ユーザー - user_id」がディメンジョンとなります。

そのディメンジョンごとに合計,平均など,どんな集計を行うかが Metric に該当します。SQL の脈略では,Metric は SUM, AVG などの集約関数が適用され,かつ単位を持ちます。先の例では順に「UU - COUNT(DISTINCT user_id) 」「PV - COUNT(1) 」「総課金額: SUM(sales)」となります。

一方,GA では既に集計済のデータを取得している事になるので,GA の世界では既に集約関数が適用された項目を Metric と呼んでいます。先ほどの例では「UU - ga:users 」「PV - ga:pageviews 」「総課金額 - ga:itemRevenue」となります。

5-1-2. Metric における再集計可能性について

Metric から様々な集計値が得られますが、それらには必ず再集計「可能」なものと「不可能」なものに分類されます。再集計とは、得られたら集計値をその後さらに集計をかけることです。例えば時間単位で PV を取得した場合、日単位の PV を求めるには 先ほどの時間単位の PVの 24 時間分の和をとればよいので再集計可能と言えます。

一方、再集計不可に分類される時間単位で取得したユニークユーザー数は、そこから日単位に再集計する事はできません。Date Dimension を dateHour から date に設定し直して再 issue(Data Connector を実行)する必要があります。

5-1-3. Time Dimensions

項目名

単位(フォーマット)

説明

ga:date

yyyyMMdd

日付

ga:year

yyyy

ga:month

MM

ga:week

01 〜 53

週番号

ga:day

dd

ga:hour

HH

時間

ga:minute

mm

ga:dayOfWeekName

‘Sunday’, ‘Monday’, ...

週名

ga:dateHour

yyyyMMddHH

date + hour

ga:yearMonth

yyyyMM

year + month

gist.github.com

gist.github.com

5-1-4. Page Tracking Dimension

項目名

説明

ga:hostname

Hostname

ga:pagePath

URL + Query Parameter

ga:pagePathLevel1 (n=1-4)

pagePath の第n階層までの値

ga:pageTitle

ページタイトル

ga:landingPagePath

ランディング(セッションが始まった)ページ URL

ga:exitPagePath

離脱(セッションが切れた)ページURL

ga:secondPagePath

次のページ URL

ga:previousPagePath

前のページURL

gist.github.com

gist.github.com

( ga:pagePathLevel1 〜 ga:pagePathLevel4 )で取得できる URL の範囲を確認

gist.github.com

↑ pagePath がオリジナルの URL を取得するのに対して,page_path_level1 〜 3 までは「/」で区切った順序でレベルを表しているのがわかります。また,level4 では以下全ての残りの URL を取得していることがわかります。

5-1-5. Page Tracking Metrics

項目名

単位

再集計

説明

ga:pageviews

可能

ページビュー数

ga:entrances

可能

セッション開始回数

ga:uniquePageviews

不可能

セッション内でユニークな PV 数

ga:pageviewsPerSession

回 / session

不可能

一つのセッションにおける平均 PV 数

ga:timeOnPage

可能

滞在時間

ga:avgTimeOnPage

秒 / page

不可能

平均滞在時間

ga:exits

可能

離脱回数

ga:exitRate

%

不可能

離脱率

gist.github.com

gist.github.com

5-1-6. User Metrics

項目名

単位

再集計

説明

ga:users

不可

ユーザー数

ga:newUsers

新規ユーザー(新規セッション)数

ga:percentNewSessions

%

不可

全ユーザー数における新規ユーザー数の割合

ga:sessionsPerUser

%

不可

全ユーザー数におけるセッション数の割合

ga:1dayUsers

不可

指定した日付ディメンジョンをエンドポイントとした範囲1日内でのユーザー数

ga:7dayUsers

不可

指定した日付ディメンジョンをエンドポイントとした範囲7日内でのユーザー数

ga:14dayUsers

不可

指定した日付ディメンジョンをエンドポイントとした範囲14日内でのユーザー数

ga:30dayUsers

不可

指定した日付ディメンジョンをエンドポイントとした範囲30日内でのユーザー数

※ ga:ndayUsers を使用するには日付ディメンジョンとして,ga:nthDay, ga:date,  ga:day のいずれかのみが使用されないといけません。

gist.github.com

gist.github.com

例( ga:30dayUsers )

gist.github.com

gist.github.com

↑ 現状の ndayUsers は,Dimension として ga:nthDay, ga:date,  ga:day のどれか一つのみ,また Metric としても ga:1dayUsres, ga:7dayUsres, ga:30dayUsres は同時に使用できず,このどれか一つと他の Metric との組合せとなります。

5-1-7. Session Metrics

項目名

単位

再集計

説明

ga:sessions

セッション数

ga:bounces

直帰数

ga:bounceRate

%

不可

直帰率

ga:sessionDuration

当セッションの滞在時間

ga:avgSessionDuration

不可

全セッションにおける平均滞在時間

ga:hits

ヒット数

gist.github.com

gist.github.com

5-1-8 (a). Traffic Sources Dimensions

項目名

単位

説明

ga:referralPath

文字列

リファラ URL

ga:fullReferrer

文字列

リファラ完全URL(hostname と path を含む

ga:campaign

文字列

AdWords トラッキングにおけるキャンペーン名

ga:source

文字列

リファラのソース名

ga:medium

文字列

検索エンジン名

ga:sourceMedium

文字列

リファラの検索エンジン名

ga:keyword

文字列

検索キーワード

5-1-8 (b). Traffic Sorces Metrics

項目

単位

再集計

説明

ga:organicSearches

回数

可能

オーガニック検索回数

gist.github.com

gist.github.com

5-1-9. Platform or Devie Dimensions

項目名

単位

説明

ga:browser

文字列

ブラウザ名

ga:browserVersion

文字列

ブラウザバージョン

ga:operatingSystem

文字列

OS名

ga:operatingSystemVersion

文字列

OSバージョン

ga:mobileDeviceBranding

文字列

モバイル端末ブランド名

ga:mobileDeviceModel

文字列

モバイル端末モデル名

ga:mobileDeviceInfo

文字列

モバイル端末識別情報

gist.github.com

gist.github.com

5-1-10. Geo Network Dimensions

項目名

サンプル値

説明

ga:continent

Asia, America,…

IPアドレスから特定される大陸名

ga:subContinent

Polynesia, Northern Europe,...

IPアドレスから特定されるサブ大陸名

ga:country

Japan

国名

ga:region

New York, Tokyo

リージョン(州)名

ga:metro

Longon

Designated Market Area (DMA)

ga:city

Shinjuku

都市名

ga:latitude

 

経度

ga:longitude

 

緯度

gist.github.com

gist.github.com

5-1-11(a). App Tracking Dimensions

項目名

同義の Page Tracking Dimensions

説明

ga:appInstallerId

   

ga:appVersion

   

ga:appName

   

ga:appId

   

ga:screenName

ga:pageTitle

Google アナリティクスにおいて,スクリーンはアプリ内でユーザーに表示されるコンテンツを指し,screenName はウェブ向けアナリティクスの pagePath (pageTitle) と同等の概念です。

ga:screenDepth

ga:pageDepth

 

ga:landingScreenName

ga:landingPagePath

 

ga:exitScreenName

ga:exitPagePath

 

5-1-11(b). App Tracking Dimensions

項目名

同義の Page Tracking Dimensions

説明

ga:screenviews

ga:pageviews

 

ga:uniqueScreenviews

ga:uniquePageviews

 

ga:screenviewsPerSession

ga:pageviewsPerSession

 

ga:timeOnScreen

ga:timeOnPage

 

ga:avgScreenviewDuration

ga:avgTimeOnPage