コホート分析
コホート分析
コホート分析は、単一の開始イベントによってオブジェクト（通常はユーザー）をグループ化し、アクティブで価値のある状態をどのくらいまで維持するかを比較します。このアプローチは、システム内の時間の影響（季節、株）とコホートの年齢の影響（開始からの日）を分離します。
1）基本的な定義
コホート：イベント「誕生」で結ばれた多くのプレイヤー-登録、最初の預金、最初のゲーム、最初の購入。
カレンダーの時間軸：実際の日付（2025-10-01、……）。
コホート年齢軸：出生から数日/週（D0、 D1、……）。
保持指標：D1/D7/D30（正確かつローリング）、WAU/MAU、 Stickiness （DAU/MAU）。
収益化：ARPU/ARPPU、累積LTV （D7/D30/D90）。
会計単位：ユーザー（user/master_id）-パスポートに記録します。
2）コホートの種類とそれらを選択するタイミング
取得コホート：登録/最初の訪問日までに-採用とオンボーディングチャネルの評価。
活性化/収益化-コホート：最初の預金/購入によって-早期収益化評価とプロモーション。
フィーチャーのコホート：フィーチャー/ゲームカテゴリの最初の使用-リリースの効果。
動作コホート：RFM/startパターン（例：「night mobile」）。
3）軸および格子： 行列を見る方法
コホートマトリックス：行-コホート（カレンダー）、列-年齢（D0..。D90）。
季節性：対角線（同じ暦の日）を比較して、季節の効果を分けます。
正規化：相対メトリック（CR、分数）+累積（LTV）、両方を表示します。
4）コホートパスポートとメトリック（テンプレート）
5）疑似SQL： 保持行列（正確なDn）
sql
WITH regs AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register
GROUP BY 1
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS act_day
FROM event_activity
),
ages AS (
SELECT r. user_id, r. cohort_day, a. act_day,
(a. act_day - r. cohort_day) AS age_days
FROM regs r
JOIN act a ON a. user_id = r. user_id
),
exact AS (
SELECT cohort_day,
age_days,
COUNT(DISTINCT user_id) AS users_active
FROM ages
GROUP BY 1,2
),
coh_size AS (
SELECT cohort_day, COUNT(DISTINCT user_id) AS cohort_size
FROM regs GROUP BY 1
)
SELECT e. cohort_day,
e. age_days,
e. users_active::decimal / NULLIF(c. cohort_size,0) AS exact_retention
FROM exact e
JOIN coh_size c USING (cohort_day)
WHERE age_days IN (1,7,30,90)
ORDER BY cohort_day, age_days;ローリングDn （1日目のアクティビティ……n）
sql
WITH days AS (... as above...),
roll AS (
SELECT cohort_day,
CASE WHEN age_days BETWEEN 1 AND 7 THEN 7
WHEN age_days BETWEEN 1 AND 30 THEN 30 END AS bucket,
COUNT(DISTINCT user_id) AS any_active
FROM days
WHERE age_days BETWEEN 1 AND 30
GROUP BY 1,2
)
SELECT r. cohort_day, r. bucket AS Dn,
r. any_active::decimal / s. cohort_size AS rolling_retention
FROM roll r
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM regs GROUP BY 1) s USING (cohort_day)
ORDER BY cohort_day, Dn;6） コホートLTVと収益化
累積LTV （Dn）： Dnによるコホートユーザーあたりの収入の合計。
ARPU/ARPPU：ユーザーあたり/Dn支払者あたりの収益。
％支払い：Dnへの≥ 1支払いで共有します。
sql
WITH reg AS (
SELECT user_id, DATE_TRUNC('day', MIN(ts)) AS cohort_day
FROM event_register GROUP BY 1
),
pay AS (
SELECT user_id, amount, DATE_TRUNC('day', ts) AS pay_day
FROM fact_payments
),
ltv AS (
SELECT r. cohort_day,
(pay_day - r. cohort_day) AS age_days,
SUM(amount) AS rev
FROM reg r JOIN pay p USING (user_id)
WHERE pay_day >= r. cohort_day
GROUP BY 1,2
),
cum AS (
SELECT cohort_day, age_days,
SUM(rev) OVER (PARTITION BY cohort_day ORDER BY age_days ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS rev_cum
FROM ltv
)
SELECT c. cohort_day, c. age_days,
c. rev_cum::decimal / NULLIF(sz. cohort_size,0) AS ltv_per_user
FROM cum c
JOIN (SELECT cohort_day, COUNT(DISTINCT user_id) cohort_size FROM reg GROUP BY 1) sz USING (cohort_day)
WHERE age_days IN (7,30,90)
ORDER BY cohort_day, age_days;7）保持のための存続/危険
Kaplan-Meier：非モデル生存曲線（S （t））-「排水」しない割合。
ハザードモデル：流出リスクに対する特性（チャネル、国、プラットフォーム、ボーナス、コンテンツ）の影響。
練習：KMをセグメントごとに構築し、ハザードモデルとの違いを説明します。
8）季節性、TZおよびカレンダー
TZ： UTCでイベントを保存し、市場のローカルTZで分析します。一貫していること。
カレンダー：休日/給与/マッチ/リリース-フラグのような；同じような週のコホートを比較しなさい。
スライドウィンドウ：毎週/毎月のコホート-休日とレポート期間の多彩さ。
9）セグメンテーションとアトリビューション
セグメント：アトラクションチャネル、プラットフォーム/OS、地理、最初のコンテンツ、価格/限度額、支払い方法。
Cohortアトリビューション：「誰が」ユーザーをもたらしたのか-アルゴリズムを修正します（最後の直接ではないデータ駆動）。
LTV計量：CRだけでなく、チャネル/セグメント別にLTV （D30/D90）も比較します。
10）ビジュアリゼーション
コホートマトリックス（CR/LTV）のヒートマップ。
トレンドラインはカレンダーでD1/D7/D30します。
サバイバル/ハザードチャート。
ブリッジ「D30にLTVを変更したもの」：支払者の貢献、頻度、平均チェック。
11）実験と因果関係
A/B：オンボーディング、チュートリアル、ペイウォール、オファー。主な指標は、D7/D30保持とLTV （D30）です。
準実験：市場へのロールアウトのためのDiD/合成制御。
アップリフトモデル：リターンゲイン（Qini/AUUC、 uplift@k）をターゲットにします。
12）運営とガバナンス
バージョン管理：'RET_D7_vN'、 'LTV_D30_vN'；アクティビティ/通貨定義を変更するときのchangelog。
SLOの新鮮さ：毎日のコホート-06：00ロックまでの準備；データログ≤ 1時間です。
品質：イベントのカバレッジ、重複の割合、コホート外のボット/詐欺の割合。
アクセス：RLS/CLSのPIIのマスキング；export-集計のみ。
ランブック：D1ドロップ（オンボーディング）、D7（コンテンツ）、イベント/アイデンティティのスクラップ。
13）頻繁なエラー（アンチパターン）
軸の混合：調節なしで異なった季節のコホートの異なった年齢を比較して下さい。
Rolling vs Exact：同じものとして扱われます。
ミキシングユニット：分母のセッション、分子のユーザー。
「平均」の集計：数値/分母を集計する代わりに。
TZ/カレンダーを無視：日/休日の境界にD1オフセット。
ボット/詐欺/QAフィルタはありません。
未使用の再起動：IDブリッジなしでアカウントを分割/マージします。
14）コホートレポート発行前のチェックリスト
- 誕生イベント、ユニット、TZ、アクティビティウィンドウ定義
- 除外されたボット/詐欺/QA；アイデンティティの混合（ゴールデンレコード）
- D7/D30/D90用のCR （Exact/Rolling）およびLTV行列を構築
- カレンダー/祝日を考慮しました。チャンネル/プラットフォーム/ジオセグメント
- サバイバル/ハザードグラフィックスとブリッジLTVを追加
- 文書化されたメトリックバージョンとアトリビューションアルゴリズム
- フレッシュSLO構成、カバレッジ/重複/エラー監視
- D1/D7のドロップとイベントブレイクのための準備ができたランブック
合計
コホート分析は、固定された「誕生の瞬間」、正しいウィンドウとTZ、保持とLTV行列、セグメンテーション、および変更の因果関係の検証の2つの軸と規律です。このアプローチは、カーブを観察するだけでなく、オンボーディングをどこで修正するのか、どのチャンネルをスケールするのか、どのコンテンツと提供するのか、プレーヤーを長くしてLTVを増やすのに役立ちます。