プレーヤーの保持分析

プレーヤー保持分析

リテンションは製品経済の中核です。プレーヤーが活動を続ける時間が長くなるほど、LTVが高くなり、収入が安定し、計画が予測可能になります。以下は完全なフレームワークです：正しい定義からサバイバルモデルと再活性化回路まで。

1）定義および会計単位

単位：プレーヤー（user/master_id）-デフォルトで；短期タスクでは「アカウント/デバイス」が許可されますが、これをメトリックパスポートに記録します。
アクティビティ：リターン基準（≥ 1セッション/≥ 1レート/≥ 1デポジット）-レコード。
Retention Dn：参照日の後のDay nに返されるコホートの割合。
ローリング/ブラケット：ローリングD7 （1-7のいずれかの日）と正確なD7 （7日目）。
チャーン：≥ T日間の活動はありません（例えば、14/30）。プロダクトルールとして指定されます。
コホート：登録日/最初の預金/最初のゲーム-マーケティング/製品タスクを選択します。

2）基本的な分析： コホートと保持曲線

コホートヒートマップ：D1/D3/D7/D14/D30/D60；対角線は、リリースとキャンペーンの間で比較可能です。
生存曲線：0日目からN日目までの活性の割合（生存曲線）。
カーブジオメトリ：休日/リリースの「ステップ」；初期の「collapse→」オンボーディングの問題、「long tail」→core loyal。

Pseudo-SQL： コホートD 7

sql
WITH regs AS (
SELECT user_id, DATE_TRUNC('day', ts) AS cohort_day
FROM event_register
),
act AS (
SELECT user_id, DATE_TRUNC('day', ts) AS act_day
FROM event_activity
),
d7 AS (
SELECT r. cohort_day,
COUNT(DISTINCT r. user_id)              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. act_day = r. cohort_day + INTERVAL '7 day'
THEN r. user_id END)       AS retained_d7
FROM regs r
LEFT JOIN act a ON a. user_id = r. user_id
GROUP BY 1
)
SELECT cohort_day, cohort_size,
retained_d7::decimal / NULLIF(cohort_size,0) AS cr_d7
FROM d7
ORDER BY cohort_day;

3）生存および危険モデル

Kaplan-Meier：非モデル生存スコア（S （t））；曲線と生命の中央値の「形状除去」に便利です。
Cox PH/Accelerated Failure Time：ハザード（流出リスク）に対する特性（国、チャネル、プラットフォーム、ボーナス、コンテンツ）の影響の説明モデル。
離散時間ハザード（日次ログ）：製品分析およびカレンダー機能に柔軟に対応します。
再活性化イベントモデル別々に（競合リスク）またはマルコフチェーンの移行として。

4）マルコフとセミマルコフのモデル

New→Active→Dormant→Churned→Reactivated。
トランジション：期間（曜日/週）ごとの確率。
値：「アクティブ」に滞在する確率に平均チェック/頻度を掛けます-LTVに期待される貢献を得る。

5）束の保持およびLTV

LTV （ 割引）。
弾力性：X pp→LTVでD7がY％増加（履歴データ/モデルから）。
優先順位付け：早期保持（D1-D7）に影響を与える改善は、ほとんどの場合、最も収益性の高いものです。

6）保持セグメンテーション

オンボーディングコホート：1日目のコンテンツ/プレイカテゴリ/行動パターン0。
Geo/platform/channel： UXと期待の違い；カレンダー/休日のために調節して下さい。
行動/価値：RFM （Recency-Frequency-Monetary）、アウトフロー・リスク、収益性。
インセンティブへの対応：オファー/通知へのアップリフト反応に関するセグメント。

7）因果関係と実験

A/B：オンボーディング、チュートリアル、プッシュ戦略；メインメトリック-D7/D14/D30保持、ガードレール-苦情、応答時間、RG。
準実験：ランダム化が不可能な場合のDiD/合成制御（例：地域のキックアウト）。
アップリフトモデル：目標リターンゲイン、アクティビティ確率ではありません。Qini/AUCを評価します。

8）再活性化： 制動機および方針

信号：頻度低下、沈殿物なしN日、異常に低い点検、第2セッションなしで完了されたオンボーディング。

決定表（例）

ヒステリシス：「点滅」しないように、信号の入出力しきい値が異なります。
チャンネル：アプリ内、プッシュ、電子メール、SMS、コールセンター-レート制限と優先順位。

9）保持指標

D1/D7/D30 （Rolling/Exact）、 WAU/MAU、粘着性（DAU/MAU）。
生存期間中央値/分位数；間隔で危険。
再起動率（R30）、休眠シェア。
ROMI再活性化、NNT （1リターンあたりの連絡先の数）。
公平性：国/プラットフォームによるメートルの違い；無効な特性をポリシーから除外します。

10）保持ダッシュボード

コホートヒートマップ+トレンドラインD1/D7/D30。
セグメント別の生存/ハザードグラフ。
初期のライフファネル：インストール→reg→KYC→1 igra→1番目の預金。
アクションマップ：signal→resheniye→kanal→iskhod（リターンへの変換）。
ガードレール：データの鮮度、イベントのカバレッジ、苦情、RG指標。

11）データと品質

イベント：正規スキーム（UTC、バージョン）、idempotency、デッドアップ。
アイデンティティ：ユーザー/デバイス/電子メール/電話-ブリッジとゴールドエントリ。
WindowsとTZ： UTC+ローカルビューに格納；休日の単一カレンダー。
フィルタ：ボット/QA/詐欺-コホートとアクティビティから除外します。
バージョン管理メトリクス：'RET_D7_vN'とchangelog。

12）疑似SQL/pythonレシピ

コホートによる圧延D30

sql
WITH base 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 d
FROM event_activity
),
roll30 AS (
SELECT b. cohort_day,
COUNT(DISTINCT b. user_id)                              AS cohort_size,
COUNT(DISTINCT CASE WHEN a. d BETWEEN b. cohort_day AND b. cohort_day + INTERVAL '30 day'
THEN b. user_id END)                      AS any_1_30
FROM base b LEFT JOIN act a ON a. user_id = b. user_id
GROUP BY 1
)
SELECT cohort_day, any_1_30::decimal/cohort_size AS rolling_d30
FROM roll30;

カプラン・マイヤー（スケッチ）

python t_i - time to outflow or censorship; e_i - event indicator
S(t) = Π_{t_i ≤ t} (1 - d_i / n_i)

離散ハザード（日別ログ）

python
For each user, create records before the event/censorship by day:
target = 1 if there was an outflow on that day; characteristics: calendar, activity, promo, etc.
Training logistic regression/GBM; forecast p_t - probability of outflow on day t.

13）アップリフトターゲティングの保持

ゾーン：Persuadables（私たちが連絡すれば戻ります）、確かなこと（そう戻ります）、失われた原因、邪魔しないでください（コンタクトの害）。
メトリクス：uplift@k、 Qini/AUUC；政治-我々は予算のために上昇によってトップkに連絡します。
ガードレール：接触頻度のキャップ、RG/倫理、接触の原因の説明。

14）運用業務

SLO：保持ボードの更新≤ 06：00ロック。；リスクスコアリングの遅延≤ 300ミリ秒；Decision→Action ≤ 5。
モニタリング：セグメントごとのカーブのシフト、フィーチャードリフトのPSI、「イベントブレイク」。
Runibooks： D1ドロップ（初期登録/リリース）、D7ドロップ（コンテンツ/頻度）、ローカル通信チャネル障害。

15）頻繁なエラー

ユニット（sessii↔polzovateli）、 TZ、アクティビティウィンドウの混合。
ローリングと正確な指標を等しく比較します。
ボット/詐欺→膨らんだD1/D7を無視します。
因果検証なしの相関に関する結論。
ヒステリシス/クールダウン→接触疲労なし。
LTVとのリンクはありません-CRを最適化しますが、値はありません。

16）リリース前の保持ループのチェックリスト

• メトリックパスポート（アクティビティトリガー、ウィンドウ、TZ、バージョン）
• セグメント別のコホートレポートと生存/危険性
• アウトフローとアップリフトリスクモデル、カパスとガードレールチャネル
• 介入のためのA/Bおよび/または準実験を計画する
• 新鮮さ/カバレッジ/苦情/RGダッシュボード
• インシデントRunybooks、ヒステリシスとポリシーのレート制限
• LTVおよびROMIとのバンドル保持；期待値による優先順位付け

合計

保持分析は「コホートのヒートマップ」だけでなく、正しい定義、生存/ハザードモデル、価値との関連、目標と倫理的介入、厳格な効果評価、運用ガードレールなどのマネージドシステムです。あなたは着実にLTVを増加させ、流出を減少させる「ウォッチ→理解→決定→行為→学習」サイクルを構築します。