تجزیه و تحلیل حفظ بازیکن

تجزیه و تحلیل نگهداری بازیکن

حفظ هسته اصلی اقتصاد محصول است: هرچه بازیکن بیشتر فعال باشد، LTV بالاتر است، درآمد پایدارتر و برنامه ریزی قابل پیش بینی تر است. در زیر یک چارچوب کامل است: از تعاریف صحیح به مدل های بقا و مدار فعال سازی مجدد.

1) تعاریف و واحدهای حسابداری

واحد: بازیکن (user/master_id) - به طور پیش فرض ؛ برای وظایف کوتاه مدت، «حساب/دستگاه» مجاز است، اما این را در گذرنامه متریک ثبت کنید.
فعالیت: معیار بازگشت (جلسه ≥1/نرخ ≥1/سپرده ≥1) - رکورد.
احتباس Dn: نسبت گروه بازگشت در روز n پس از تاریخ مرجع.
نورد/براکت: نورد D7 (در هر روز 1-7) در مقابل D7 دقیق (در روز 7).
ریزش: هیچ فعالیتی برای ≥T روز (به عنوان مثال، 14/30) ؛ به عنوان یک قاعده محصول تعریف شده است.
گروه ها: با تاریخ ثبت نام/اولین سپرده/اولین بازی - برای کار بازاریابی/محصول را انتخاب کنید.

2) تجزیه و تحلیل پایه: گروه ها و منحنی های نگهداری

نقشه های گرما کوهورت: D1/D3/D7/D14/D30/D60 ؛ دیاگونال ها بین انتشار و کمپین ها قابل مقایسه هستند.
منحنی بقا: نسبت فعالیت از روز 0 به N (منحنی بقا).
هندسه منحنی: «مراحل» تعطیلات/انتشار ؛ در اوایل «فروپاشی →» مشکلات onboarding، «دم بلند» → هسته وفادار است.

شبه SQL: کوهورت D7

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) مدل های بقا و خطر

کاپلان-مایر: نمره بقا غیر مدل (S (t)) ؛ مفید برای «سلب شکل» منحنی و میانه زندگی.
کاکس PH/زمان شکست شتاب: مدل توضیحی از تاثیر ویژگی های (کشور، کانال، پلت فرم، پاداش، محتوا) در خطر (خطر خروج).
خطر زمان گسسته (ورود به روز): انعطاف پذیر برای تجزیه و تحلیل محصول و ویژگی های تقویم.
مدل رویداد فعالسازی مجدد به طور جداگانه (ریسکهای رقابتی) یا به عنوان یک انتقال در زنجیره مارکوف.

4) مدل های مارکوف و نیمه مارکوف

جدید → فعال → خفته → Churned → دوباره فعال شده است.
انتقال: احتمال در هر دوره (روز/هفته).
ارزش: ضرب احتمال اقامت در «فعال» به طور متوسط چک/فرکانس - سهم انتظار می رود به LTV.

5) نگهداری بسته نرم افزاری و LTV

LTV ( تخفیف).
کشش: افزایش D7 توسط X pp → LTV افزایش Y٪ (از داده های تاریخی/مدل).
اولویت بندی: پیشرفت هایی که بر حفظ اولیه (D1-D7) تاثیر می گذارند تقریبا همیشه سودآور هستند.

6) تقسیم بندی نگهداری

Onboarding cohorts: اولین محتوا/دسته بازی/الگوی رفتاری در روز 0.
جغرافیایی/پلت فرم/کانال: UX و انتظارات تفاوت ؛ تنظیم برای تقویم/تعطیلات.
رفتار/ارزش: RFM (Recency-Frequency-Monetary)، خطر خروج، سودآوری.
پاسخ به انگیزه ها: بخش های مربوط به واکنش بالا بردن به پیشنهادات/اطلاعیه ها.

7) علیت و آزمایش

A/B: آموزش، آموزش، استراتژی های فشار ؛ متریک اصلی - احتباس D7/D14/D30، گارد محافظ - شکایات، زمان پاسخ، RG.
شبه آزمایش: کنترل DiD/مصنوعی زمانی که تصادفی امکان پذیر نیست (به عنوان مثال kickouts منطقه ای).
مدل های Uplift: سود بازگشت هدف، نه احتمال فعالیت ؛ ارزیابی Qini/AUUC.

8) دوباره فعال سازی: باعث و سیاست

سیگنال ها: افت فرکانس، بدون سپرده N روز، چک غیر طبیعی کم، تکمیل بدون جلسه 2.

جدول تصمیم گیری (مثال)

Hysteresis: آستانه ورودی/خروجی مختلف برای سیگنال ها به طوری که «چشمک زدن».
کانال ها: در برنامه، فشار، ایمیل، اس ام اس، مرکز تماس - با نرخ محدود و اولویت.

9) معیارهای نگهداری

D1/D7/D30 (نورد/دقیق)، 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، deadup.
هویت: کاربر/دستگاه/ایمیل/تلفن - پل ها و ورود طلا.

ویندوز و TZ: ذخیره سازی در نمایش محلی محلی UTC + ؛ تنها تقویم تعطیلات

فیلترها: رباتها/QA/تقلب - حذف از گروه و فعالیت.
معیارهای نسخه بندی: 'RET _ D7 _ vN' با تغییرات.

12) دستور العمل های Pseudo-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) حفظ بالا بردن هدف

مناطق: متقاعد کننده (اگر ما تماس بگیریم)، چیزهای مطمئن (بازگشت و غیره)، علل از دست رفته، مزاحم نشوید (آسیب های تماس).
معیارها: uplift @ k، Qini/AUUC ؛ سیاست - ما با بالا بردن برای بودجه با K بالا تماس می گیریم.
Guardrails: کلاه در فرکانس تماس، RG/اخلاق، توضیح علت تماس.

14) عملیات عملیاتی

SLO: به روز رسانی هیئت مدیره نگهداری ≤ قفل 06:00 ؛ تاخیر نمره ریسک ≤ 300 میلی ثانیه ؛ تصمیم گیری → عمل ≤ 5 с.
نظارت: تغییر منحنی ها توسط بخش ها، PSI رانش ویژگی، «شکستن رویداد».
Runibooks: قطره D1 (onboarding/release)، قطره D7 (محتوا/فرکانس)، شکست کانال ارتباطی محلی.

15) خطاهای مکرر

مخلوط کردن واحد (sessii↔polzovateli)، TZ، پنجره های فعالیت.
مقایسه نورد و شاخص دقیق به عنوان برابر است.
نادیده گرفتن رباتها/تقلب → D1/D7 متورم.
نتیجه گیری در مورد همبستگی بدون اعتبار علی.
بدون هیسترزیس/خنک کننده → خستگی تماس.
هیچ ارتباطی با LTV وجود ندارد - ما بهینه سازی CR، اما ارزش نیست.

16) چک لیست حلقه نگهداری قبل از انتشار

• متریک گذرنامه (ماشه فعالیت، پنجره، TZ، نسخه)
• گزارش کوهورت و بقا/خطر توسط بخش
• مدل های ریسک خروج و بالا بردن، کاپاها و کانال های گارد محافظ
• طرح A/B و/یا شبه آزمایش برای مداخلات
• تازگی/پوشش/شکایات/داشبورد RG
• Runybooks حادثه، هیسترزیس و نرخ محدودیت در سیاست
• نگهداری بسته نرم افزاری با LTV و ROMI ؛ اولویت بندی بر اساس ارزش مورد انتظار

مجموع

تجزیه و تحلیل نگهداری نه تنها یک «نقشه گرما از گروه ها» است، بلکه یک سیستم مدیریت شده است: تعاریف صحیح، مدل های بقا/خطر، ارتباط با ارزش، مداخلات هدفمند و اخلاقی، ارزیابی اثر دقیق و گارد محافظ عملیاتی. شما یک چرخه «watch → understand → decide → act → learn» ایجاد می کنید که به طور پیوسته LTV را افزایش می دهد و جریان خروجی را کاهش می دهد.