トレジャーデータで実践「離脱分析」〜 コホート分析と生存時間分析 〜
はじめに
ほとんど全ての会員制サービスには，顧客の「入会」と「退会」という概念があります。そして退会（ここでは離脱と呼びます）における分析は，それを防止するという目的において非常に重要です。本記事ではいくつかの「離脱分析」の手法を，トレジャーデータ＋スプレッドシートだけで完結でき，かつ誰もが実践できる形でご紹介します。
「離脱分析」必要な最低限のデータセット
初めの2回で紹介する手法においては，分析に必要なデータセットはシンプルで汎用的なものです。最低限必要な項目は，「ユーザーID」「入会日時」「退会日時」この３つです。また，分析実行時にサービスを継続しているユーザーは退会日時の値は入っていないことになります。
今回は後々の分析にも備えて上記の項目以外に，もう少し多くの情報を持たせたデータ（これを 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列目「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. 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 ステップが必須になります。
- GA の ADMIN から，Custom Dimension，Custom Metric を定義する。
- サイトのトラッキングコードに Custom Dimension，Custom Metric を取得するためのコードを追記
特に 2. の，トラッキングコードへの追記作業が伴うことには注意してください。自身にコード編集権限が無い場合，管理者や運用者にトラッキングコードの追記の許可や依頼の必要があるかもしれません。
6-2. Client Id のトラッキング設定
GA のレポートの中ではユニークユーザー数などは簡単に見ることができますが、デフォルトでは取得できない項目となっています。Client Id は GA が cookie の中で保持しているユーザー識別ID です。カスタムディメンジョンとしてこの Client Id を設定すれば，全てのデータで Client ID の粒度での集計値が取得できます。
Custom Dimension，Custom Metric の定義は，GA の ADMIN 項目の Property の中にある「Custom Definitions」をクリックします。
既に Custom Dimension が定義されている場合にはその項目の一覧を見ることができます。重要なのは，Custom Dimension は一度作成すると削除できないこと（非アクティブ可），Data Connector で Custom Dimension を取ってくる場合には “ga:clientId” や “ga:timestamp” ではなく，”ga:dimension1” と ”ga:dimension2” とインデックスを伴う固定文字列であることです。
Custom Dimension として ClientId を定義します。ユーザー単位での取得になりますので Scope では User としておきます。詳しくは スコープの詳細をご確認ください。
画面右の方で Custom Dimension を取得するためのトラッキングコード例が表示されますが，JS 向けのClientID トラッキングコードを以下のように追記します：
新しく Custom Dimension を設定した場合には，実際にこの項目が取得できるのは次の日以降になります。
6-3. GA から Client Id を取得
さて，Data Connector の話に戻って Client Id を取得するための設定ファイルを確認しましょう。取得するカラム名はデフォルトでは「dimension1」となり，扱いにくいので「client_id」に Rename してインポートします。
↑ ※上記の Client ID は適当な文字列を割り振ってあります。
6-4. Timestamp のトラッキング設定
Client ID に加えて timestamp を Custom Dimension として取得する方法を紹介します。timestamp まで取得すると，GA から取得するレコード数が大きく増えることに注意してください。また，GA の標準設定で分単位までの粒度でデータ取得可能です。
Custom Dimension として Timestamp を定義します。ヒット単位での取得になりますので Scope では Hit としておきます。詳しくは スコープの詳細をご確認ください。
トラッキングコードは以下になります：
6-5. GA から Client Id, Timestamp を取得
↑ Custom Dimension として Timestamp を設定していますので，型が文字列となっていることに注意してください。
さて，Data Connector を使って GA で取得した timestamp をトレジャーデータの time カラムとしてインポートするために，dimension1 の Rename に加えて YAML ファイルに追加の設定を行います。
↑ 18〜25行目までが追加設定となります。こちらの使用方法についてはドキュメントを参照ください。「in:」で取得したカラムに対して，型や名前を変換したい場合に記述する filter 機能を活かしています。
また，この設定ファイルを使う場合は，td connector:issue コマンド内で --time-column オプションを省略します。
6-6. GA に外部紐付け可能な User ID を埋め込む
6-2. では GA 内で有効な Client ID を取得しましたが，利用者が外部サービスと紐付く User ID を GA の中でもユーザー識別子として扱いたい，というケースもあると思います。これを可能にする方法は GA のドキュメントをご参照下さい。
Data Connector for Google Analytics Reporting 徹底解説 その５
前回まで
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
|
項目名 |
単位（フォーマット） |
説明 |
|
yyyyMMdd |
日付 |
|
|
yyyy |
年 |
|
|
MM |
月 |
|
|
01 〜 53 |
週番号 |
|
|
dd |
日 |
|
|
HH |
時間 |
|
|
mm |
分 |
|
|
‘Sunday’, ‘Monday’, ... |
週名 |
|
|
yyyyMMddHH |
date + hour |
|
|
yyyyMM |
year + month |
例
5-1-4. Page Tracking Dimension
|
項目名 |
説明 |
|
Hostname |
|
|
URL + Query Parameter |
|
|
pagePath の第n階層までの値 |
|
|
ページタイトル |
|
|
ランディング（セッションが始まった）ページ URL |
|
|
離脱（セッションが切れた）ページURL |
|
|
次のページ URL |
|
|
前のページURL |
例
例（ ga:pagePathLevel1 〜 ga:pagePathLevel4 ）で取得できる URL の範囲を確認
↑ pagePath がオリジナルの URL を取得するのに対して，page_path_level1 〜 3 までは「/」で区切った順序でレベルを表しているのがわかります。また，level4 では以下全ての残りの URL を取得していることがわかります。
5-1-5. Page Tracking Metrics
|
項目名 |
単位 |
再集計 |
説明 |
|
回 |
可能 |
ページビュー数 |
|
|
回 |
可能 |
セッション開始回数 |
|
|
回 |
不可能 |
セッション内でユニークな PV 数 |
|
|
回 / session |
不可能 |
一つのセッションにおける平均 PV 数 |
|
|
秒 |
可能 |
滞在時間 |
|
|
秒 / page |
不可能 |
平均滞在時間 |
|
|
回 |
可能 |
離脱回数 |
|
|
% |
不可能 |
離脱率 |
例
5-1-6. User Metrics
|
項目名 |
単位 |
再集計 |
説明 |
|
人 |
不可 |
ユーザー数 |
|
|
人 |
可 |
新規ユーザー（新規セッション）数 |
|
|
% |
不可 |
全ユーザー数における新規ユーザー数の割合 |
|
|
% |
不可 |
全ユーザー数におけるセッション数の割合 |
|
|
人 |
不可 |
指定した日付ディメンジョンをエンドポイントとした範囲1日内でのユーザー数 |
|
|
人 |
不可 |
指定した日付ディメンジョンをエンドポイントとした範囲7日内でのユーザー数 |
|
|
人 |
不可 |
指定した日付ディメンジョンをエンドポイントとした範囲14日内でのユーザー数 |
|
|
人 |
不可 |
指定した日付ディメンジョンをエンドポイントとした範囲30日内でのユーザー数 |
※ ga:ndayUsers を使用するには日付ディメンジョンとして，ga:nthDay, ga:date, ga:day のいずれかのみが使用されないといけません。
例
例（ ga:30dayUsers ）
↑ 現状の ndayUsers は，Dimension として ga:nthDay, ga:date, ga:day のどれか一つのみ，また Metric としても ga:1dayUsres, ga:7dayUsres, ga:30dayUsres は同時に使用できず，このどれか一つと他の Metric との組合せとなります。
5-1-7. Session Metrics
|
項目名 |
単位 |
再集計 |
説明 |
|
回 |
可 |
セッション数 |
|
|
回 |
可 |
直帰数 |
|
|
% |
不可 |
直帰率 |
|
|
秒 |
可 |
当セッションの滞在時間 |
|
|
秒 |
不可 |
全セッションにおける平均滞在時間 |
|
|
回 |
可 |
ヒット数 |
例
5-1-8 (a). Traffic Sources Dimensions
|
項目名 |
単位 |
説明 |
|
文字列 |
リファラ URL |
|
|
文字列 |
リファラ完全URL（hostname と path を含む） |
|
|
文字列 |
AdWords トラッキングにおけるキャンペーン名 |
|
|
文字列 |
リファラのソース名 |
|
|
文字列 |
検索エンジン名 |
|
|
文字列 |
リファラの検索エンジン名 |
|
|
文字列 |
検索キーワード |
5-1-8 (b). Traffic Sorces Metrics
|
項目 |
単位 |
再集計 |
説明 |
|
回数 |
可能 |
オーガニック検索回数 |
例
5-1-9. Platform or Devie Dimensions
|
項目名 |
単位 |
説明 |
|
文字列 |
ブラウザ名 |
|
|
文字列 |
ブラウザバージョン |
|
|
文字列 |
OS名 |
|
|
文字列 |
OSバージョン |
|
|
文字列 |
モバイル端末ブランド名 |
|
|
文字列 |
モバイル端末モデル名 |
|
|
文字列 |
モバイル端末識別情報 |
例
5-1-10. Geo Network Dimensions
|
項目名 |
サンプル値 |
説明 |
|
Asia, America,… |
IPアドレスから特定される大陸名 |
|
|
Polynesia, Northern Europe,... |
IPアドレスから特定されるサブ大陸名 |
|
|
Japan |
国名 |
|
|
New York, Tokyo |
リージョン（州）名 |
|
|
Longon |
Designated Market Area (DMA) |
|
|
Shinjuku |
都市名 |
|
|
経度 |
||
|
緯度 |
例
5-1-11(a). App Tracking Dimensions
|
項目名 |
同義の Page Tracking Dimensions |
説明 |
|
Google アナリティクスにおいて，スクリーンはアプリ内でユーザーに表示されるコンテンツを指し，screenName はウェブ向けアナリティクスの pagePath (pageTitle) と同等の概念です。 |
||
5-1-11(b). App Tracking Dimensions
|
項目名 |
同義の Page Tracking Dimensions |
説明 |
