تحلیلگر نگهداشت گروههای همدسته: دریابید کاربران در کجا و چرا ریزش میکنند
Why this prompt matters
Diagnosing a retention dip the ad-hoc way — pulling SQL, building a slide, guessing at causes in a meeting — typically takes a product team 2-3 weeks. By the time the root cause surfaces, the cohort that triggered the alarm has often already fully churned, and the next 2-3 cohorts have gone through the same broken experience unnoticed. A structured retention prompt compresses that diagnostic cycle from weeks to minutes, catching a broken onboarding flow or a bad acquisition channel before it silently degrades the next several thousand signups.
What we use it for
You're a growth PM at a 40-person B2B SaaS company. In Monday's leadership meeting, your CEO asks why the April cohort of new signups is retaining 12 percentage points worse than March's cohort at the Week 4 mark, and you have 20 minutes before your next meeting to come back with an answer that isn't 'we're not sure yet.'
Prompt
Act as a senior product analytics consultant who specializes in retention and cohort analysis for SaaS and consumer products. CONTEXT: [PASTE YOUR COHORT RETENTION DATA HERE — a table of cohort start month/week vs. % of users retained at Week 1, Week 4, and Week 12 or equivalent intervals] Product name: [YOUR PRODUCT NAME] Target user segment: [E.G., SMB FINANCE TEAMS, INDIVIDUAL DEVELOPERS, ENTERPRISE IT ADMINS] Known changes during this period: [LIST ANY PRODUCT CHANGES, ONBOARDING REDESIGNS, PRICING CHANGES, OR MARKETING CAMPAIGNS THAT OVERLAP WITH THE COHORT WINDOWS] TASK: Analyze the retention curves across cohorts to identify: 1. Which cohorts retain significantly better or worse than the others, and by how many percentage points 2. The specific week or month where drop-off accelerates most sharply across cohorts 3. Plausible causes tied to the product changes, onboarding friction, seasonality, or marketing source quality provided above 4. A ranked list of hypotheses for the single biggest retention risk, each with a confidence level and a concrete way to validate it CONSTRAINTS: - Do not just describe the data back to me — provide causal hypotheses grounded specifically in the product changes and context I gave you - Rank hypotheses by likely business impact, not alphabetically or by how confident you are - Flag any data quality issues you notice (e.g., sample size too small to trust, non-monotonic retention that suggests a tracking bug, or missing cohorts) - Limit the ranked hypotheses list to a maximum of 5 — do not pad with low-confidence guesses just to fill space - If the data doesn't support a strong conclusion, say so explicitly rather than forcing a narrative OUTPUT FORMAT: 1. Headline Finding — one to two sentences stating the single most important retention insight 2. Cohort Comparison Table — cohorts ranked best-to-worst with retention % at each measured interval 3. Drop-off Point — where retention falls off most sharply, and by how many percentage points 4. Ranked Hypotheses (up to 5) — cause, confidence level (High/Medium/Low), and how to validate it 5. Recommended Next Action — the single most valuable thing to test or fix first, and why it's the highest-leverage move
Result
Headline Finding
The April cohort's Week 4 retention (58%) is 12 points below March's (70%), and nearly the entire gap opens in the first 7 days — this looks like an onboarding regression, not a slow organic decline.
Cohort Comparison Table
| Cohort | Week 1 | Week 4 | Week 12 |
|---|---|---|---|
| February | 81% | 68% | 52% |
| March | 84% | 70% | 54% |
| April | 69% | 58% | — |
April's Week 1 retention alone is 12-15 points below both prior cohorts, and that gap persists rather than narrowing by Week 4 — the damage is happening immediately after signup, not accumulating gradually.
Drop-off Point
The steepest break is Days 1-3 post-signup. February and March cohorts lose about 6-8 points of retention in this window; April loses 19 points. Every cohort loses users in the first three days — April is losing roughly three times as many.
Ranked Hypotheses
1. Onboarding flow change shipped March 28 (Confidence: High). The new 5-step guided setup replaced a 2-step quick-start exactly 3 days before the April cohort's signup window opens. Early-days drop-off cliffs immediately after an onboarding redesign are one of the most common and well-documented causes of this exact pattern. Validate by: pulling funnel completion rates for the new 5-step flow — if completion rate is below 60%, this is very likely the primary cause.
2. Paid channel mix shift (Confidence: Medium). Marketing notes indicate an increased spend shift toward a new paid social channel starting April 2. Lower-intent traffic from a new acquisition channel commonly produces exactly this kind of front-loaded drop-off. Validate by: segmenting April's Week 1 retention by acquisition source — if the new channel's cohort retains dramatically worse than organic/existing channels, this compounds with hypothesis 1 rather than replacing it.
3. Pricing page A/B test bleed-through (Confidence: Low). A pricing experiment launched April 10 for a different user segment; possible but unlikely cross-contamination into this cohort given the targeting rules described. Validate by: confirming experiment targeting logs excluded new signups during this window.
Data Quality Note
April's Week 12 figure is missing because the cohort hasn't reached that age yet — do not treat this as a data gap requiring investigation.
Recommended Next Action
Pull the new 5-step onboarding funnel's step-by-step completion data before your next meeting. If there's a specific step with an unusually high abandonment rate, you'll likely have a concrete, fixable culprit — not just a correlation — within the hour.
داشبوردهای نگهداشت در همه ابزارهای تحلیل محصول وجود دارند، اما یک داشبورد فقط نشان میدهد که یک عدد تغییر کرده است — هرگز به شما نمیگوید چرا. بیشتر تیمها به یک منحنی نگهداشت ضعیف با انتقال دادهها به یک صفحهگسترده، خیره شدن به آن و حدسزنی با صدای بلند در یک جلسه واکنش نشان میدهند. این فرآیند کند، بدون ساختار و به شدت متمایل به هر نظریهای است که ارشدترین فرد حاضر در جلسه ابتدا از آن حمایت میکند.
این Prompt برای جایگزینی آن تمرین حدسزنی با یک تحلیل علی ساختاریافته طراحی شده است، با استفاده از همان مراحل استدلالی که یک تحلیلگر رشد با تجربه واقعاً طی میکند — اما به صورت فشرده در یک درخواست واحد.
چرا Prompt به این شکل ساخته شده است
دستورالعمل Role — «مشاور ارشد تحلیل محصول» — بیش از آنچه به نظر میرسد اهمیت دارد. بدون آن، مدلهای عمومی تمایل دارند به طور پیشفرض دادهها را توصیف کنند («Cohort A بهتر از Cohort B نگهداشت شد») به جای تحلیل علت آن. قالببندی مدل به عنوان یک مشاور که باید توصیههای خود را به یک مشتری توجیه کند، آن را به سمت استدلال علی سوق میدهد به جای بازگویی اعدادی که از قبل در مقابل خود دارید.
بخش Context عمداً فراتر از فقط اعداد نگهداشت را درخواست میکند. گنجاندن تغییرات شناختهشده محصول، بازطراحیهای فرآیند ورود کاربر و کمپینهای بازاریابی در همان بازه زمانی، چیزی است که این کار را از یک تمرین توصیف داده به یک تمرین تشخیصی واقعی تبدیل میکند — مدل فقط در صورتی میتواند فرضیههای مستدل ارائه دهد که چیزی برای استناد به آنها داشته باشد. یک Prompt نگهداشت که فقط با اعداد تغذیه شود، توضیحات عمومی («کاربران ممکن است علاقه خود را از دست بدهند») تولید میکند که برای هر محصول SaaS درست است و برای اقدام بیفایده است.
بلوک Constraints سه وظیفه مشخص انجام میدهد. اول، رتبهبندی را بر اساس تأثیر تجاری به جای ترتیب الفبایی یا ترتیب اطمینان اعمال میکند. این مهم است زیرا فرضیه با بالاترین اطمینان لزوماً فرضیهای با بالاترین تأثیر برای رفع نیست. دوم، فهرست فرضیهها را به پنج عدد محدود میکند — بدون این محدودیت، مدلها تمایل دارند برای به نظر رسیدن دقیق، حدسهای کمارزش بیش از حد تولید کنند که یک یا دو ایدهای را که واقعاً ارزش اقدام دارند، دفن میکند. سوم، دستور صریح برای علامتگذاری مشکلات کیفیت داده، یک حالت خرابی خاص دادههای نگهداشت را پوشش میدهد: منحنیهای غیریکنواخت (جایی که نگهداشت هفته چهارم بالاتر از هفته اول است، که از نظر ریاضی برای یک منحنی نگهداشت مناسب غیرممکن است) تقریباً همیشه نشاندهنده یک نقص ردیابی هستند تا یک الگوی رفتاری واقعی، و یک تحلیلگر که این را بررسی نمیکند، تمام یک روایت را بر اساس دادههای خراب خواهد ساخت.
خروجی خوب چه شکلی است
یک اجرای مفید از این Prompt باید چیزی تولید کند که بتوانید مستقیماً قبل از یک جلسه رهبری در یک پیام Slack بچسبانید: یک یافته اصلی که به عنوان یک ادعا (نه یک توصیف) بیان شده است، یک جدول مقایسه کوچک، نقطه خاصی که منحنی در آن میشکند، و — مهمتر — یک اقدام بعدی به جای تحلیل بیشتر. اگر خروجی مدل مانند یک نسخه طولانیتر از دادههای ورودی خوانده شود، Prompt شکست خورده است و احتمالاً نیاز به یک محدودیت قویتر برای جلوگیری از بازگویی دارد.
این الگو فراتر از نگهداشت در کجا کاربرد دارد
ساختار یکسان Role + Context زمینهمند + Constraints رتبهبندی فرضیه برای هر مسئله «چرا این معیار تغییر کرد» کار میکند — افزایش ریزش، کاهش نرخ تبدیل، افزایش حجم تیکتهای پشتیبانی. فیلدهای خاص تغییر میکنند، اما شکل — وادار کردن به استدلال علی، زمینهمند کردن در رویدادهای شناخته شده، محدود کردن تعداد فرضیهها، علامتگذاری کیفیت داده — هر زمان که یک سری زمانی به یک مدل میدهید و میپرسید «چرا»، قابل استفاده مجدد است.