تشخیص‌دهنده نشتی قیف: دریابید کدام مرحله از قیف واقعاً بیشترین هزینه درآمدی را دارد
چرا این پرامپت اهمیت دارد
Teams default to fixing whichever funnel stage has the scariest-looking percentage drop, which is usually the top of the funnel where casual browsers never intended to convert anyway. A mid-funnel stage with a smaller percentage drop but a much larger user base often hides the bigger dollar opportunity. Picking the wrong stage burns an entire sprint of engineering time for a fix that doesn't move revenue, and the team doesn't find out it was the wrong call until the next month's numbers come in unchanged.
ما از آن برای چه استفاده می‌کنیم
A product or growth manager at a B2B SaaS company notices overall trial-to-paid conversion dropped this month. They have stage-by-stage funnel counts from their analytics tool and one sprint of engineering capacity before the next planning cycle, and need to decide which single stage to fix rather than spreading effort across three plausible-looking problems.
پرامپت
Role: You are a senior product analyst who specializes in conversion funnel diagnostics for [TYPE OF PRODUCT, e.g., B2B SaaS signup flow]. You have run hundreds of funnel analyses and know that teams usually fix the wrong stage because they chase the biggest percentage drop instead of the biggest absolute business impact. Context: - Funnel stage data: [PASTE EACH STAGE NAME, USER COUNT AT THAT STAGE, AND THE TIME PERIOD, e.g., Visited Pricing Page: 10,000 / Started Signup: 3,200 / Completed Signup: 1,850 / Activated (connected first data source): 740 / Converted to Paid after trial: 210 — all for the last 30 days] - Average revenue or lifetime value per converted user: [INSERT VALUE, e.g., $1,800 average first-year contract value] - Recent changes in the period that might explain shifts: [LIST ANY CHANGES, e.g., new onboarding wizard shipped 3 weeks ago, pricing page redesign 10 days ago, a marketing campaign started 2 weeks ago] - Known constraints on what can realistically be fixed this sprint: [LIST CONSTRAINTS, e.g., engineering has roughly 1 sprint of capacity, cannot touch the billing system, cannot change pricing] Task: 1. Calculate the stage-to-stage conversion rate and drop-off percentage for every transition in the funnel. 2. Identify two candidate stages: the stage with the single largest percentage-point drop, and separately the stage where a modest improvement (assume a conservative 10% relative lift) would produce the largest absolute increase in revenue, using the value-per-converted-user figure provided. 3. For the revenue-impact stage specifically, propose at least two distinct, competing hypotheses for why users are leaking out there. Do not default to the obvious explanation — consider at least one hypothesis tied to the recent changes listed and at least one unrelated to them. 4. For each hypothesis, specify one concrete, cheap way to confirm or rule it out this week, before any engineering work starts (for example: a short user survey, a funnel-stage recording review, a cohort comparison against a time period before a recent change, or a support-ticket keyword search). 5. Recommend exactly one stage to focus the sprint on, with a one-sentence justification that references the revenue math, not the percentage-point drop, unless they happen to be the same stage. Constraints: - Do not recommend fixing more than one stage in this sprint, even if several stages look broken — the point is forcing a single, defensible priority call. - Do not state a hypothesis as fact. Every hypothesis must come with its cheap validation method attached. - If the revenue-per-user figure or stage counts are missing or clearly inconsistent, ask for the missing number specifically rather than estimating it yourself. - Keep the tone analytical and skeptical of the first obvious-looking answer, not reassuring. Output Format: 1. Funnel Table — stage name, user count, conversion rate from the previous stage, and drop-off percentage, for every stage. 2. Two Candidate Stages — a short head-to-head comparison: the biggest percentage-point drop vs. the biggest absolute revenue-impact opportunity, stated as a dollar range. 3. Hypotheses for the Recommended Stage — 2-3 competing explanations, each paired with its one-week validation method. 4. Final Recommendation — one stage, one sentence, tied explicitly to the revenue math.
نتیجه
**1. Funnel Table** | Stage | Users | Conversion from Previous | Drop-Off | |---|---|---|---| | Visited Pricing Page | 10,000 | — | — | | Started Signup | 3,200 | 32.0% | 68.0% | | Completed Signup | 1,850 | 57.8% | 42.2% | | Activated (connected first data source) | 740 | 40.0% | 60.0% | | Converted to Paid (post-trial) | 210 | 28.4% | 71.6% |
**2. Two Candidate Stages** The largest percentage-point drop is Visited Pricing Page → Started Signup (68.0% drop). That looks alarming, but it's largely top-of-funnel browsing behavior, not a broken product experience — a 10% relative lift there (320 more signups) flows through the existing downstream conversion rates to roughly 7 additional paid customers, worth about $12,600 at $1,800 average contract value.
The largest absolute revenue opportunity is Completed Signup → Activated (60.0% drop). A 10% relative lift here means 111 additional activated users. Applying the existing Activated → Paid rate of 28.4%, that's roughly 31 additional paid customers — worth approximately $55,800. This is nearly 4.5x the revenue impact of fixing the pricing-page stage, despite having a smaller percentage-point drop. This is the stage to focus on.
**3. Hypotheses for Completed Signup → Activated** - Hypothesis A (tied to recent change): The onboarding wizard that shipped 3 weeks ago may be asking users to connect a data source before they've understood the product's value, front-loading a high-friction step too early. Validate by comparing activation rates for users who signed up in the 3 weeks before the wizard shipped against the 3 weeks after — if activation dropped sharply right at the ship date, this is likely the cause. - Hypothesis B (unrelated to recent changes): Users may not have the specific data source credentials on hand at signup time (e.g., they signed up without admin access to connect their CRM or warehouse). Validate with a 10-question exit survey triggered for users who abandon at this exact step, asking directly what stopped them. - Hypothesis C: The "first data source" step may require a data format or integration your current customer base doesn't actually have, filtering out a segment that was never a good fit. Validate by pulling the top 20 support tickets mentioning "connect" or "integration" from the last 30 days and checking whether a specific integration type comes up disproportionately.
**4. Final Recommendation** Focus this sprint on the Completed Signup → Activated stage — a 10% relative lift there is worth roughly $55,800 in projected first-year revenue, about 4.5 times the impact of fixing the stage with the largest raw percentage-point drop.
گزارش‌های قیف تبدیل به‌طور فریبنده‌ای به‌راحتی اشتباه خوانده می‌شوند. مرحله‌ای که بیشترین افت درصدی را دارد در داشبورد توجه را جذب می‌کند، اما افت درصدی و تأثیر دلاری یک چیز نیستند — و یکی‌گرفتن این دو یکی از رایج‌ترین روش‌هایی است که یک تیم محصول کل یک اسپرینت را روی اصلاحی هزینه می‌کند که درآمد را تغییر نمی‌دهد.
این پرامپت یک مقایسه ساختارمند دومرحله‌ای می‌سازد: ابتدا هر افت مرحله‌به‌مرحله در قیف شما را محاسبه می‌کند، سپس به‌طور مجزا مراحل را بر اساس درآمد واقعی که یک بهبود متوسط می‌تواند آزاد کند، با استفاده از عدد ارزش هر کاربر تبدیل‌شده خودتان، رتبه‌بندی می‌کند. این پرامپت این دو رتبه‌بندی را کنار هم مقایسه می‌کند، چون آن‌ها اغلب به مراحل متفاوتی اشاره می‌کنند — و رتبه‌بندی درآمدی تقریباً همیشه همان چیزی است که ارزش عمل کردن دارد.
چرا این روش کار می‌کند
این ساختار عمداً تشخیص را از اولویت‌بندی جدا می‌کند. بیشتر پرامپت‌های تحلیل قیف در «اینجا کاربران خارج می‌شوند» توقف می‌کنند، که توصیفی است اما آماده تصمیم‌گیری نیست. این پرامپت یک محدودیت اضافه می‌کند که باید یک مرحله واحد برای اسپرینت انتخاب شود، که یک تصمیم مبادله واقعی را به‌جای یک فهرست آرزوها از سه چیز برای اصلاح، الزامی می‌کند.
این پرامپت همچنین حداقل دو فرضیه رقیب برای مرحله انتخاب‌شده را الزامی می‌کند — یکی مرتبط با تغییر محصول اخیر، یکی مستقل از آن — چون بزرگ‌ترین نقطه شکست در عیب‌یابی قیف، تثبیت روی اولین داستان قابل‌قبول است بدون بررسی اینکه آیا توضیحی ساده‌تر و غیرمرتبط هم به همان اندازه با داده‌ها مطابقت دارد یا نه. هر فرضیه باید با یک روش اعتبارسنجی ارزان و یک‌هفته‌ای همراه باشد، تا تیم قبل از ساختن، آزمایش کند نه اینکه بر اساس یک حدس بسازد.
چگونه از آن استفاده کنیم
شمارش کاربران مرحله‌به‌مرحله را از هر ابزار تحلیلی که استفاده می‌کنید بیرون بکشید — Amplitude، Mixpanel، یک کوئری SQL در برابر جدول رویدادهای شما، یا حتی یک خروجی صفحه‌گسترده هم کار می‌کند. شما نیاز دارید: نام مراحل و شمارش‌ها برای دوره‌ای که تحلیل می‌کنید، میانگین درآمد یا ارزش عمر مشتری به ازای هر مشتری تبدیل‌شده، فهرست کوتاهی از هر چیزی که اخیراً تغییر کرده، و یک توصیف یک‌خطی از محدودیت واقعی ظرفیت مهندسی خود برای اسپرینت. همه این‌ها را در فیلدهای کروشه‌دار قرار دهید و آن را اجرا کنید.
خروجی به شما یک جدول قیف، یک مقایسه رو‌در‌رو از دو مرحله نامزد، دو تا سه فرضیه قابل‌آزمایش برای مرحله پیشنهادی، و یک جمله نهایی مرتبط با محاسبات دلاری می‌دهد. آن جمله نهایی چیزی است که به برنامه‌ریزی اسپرینت می‌برید — قابل‌دفاع است چون یک عدد است، نه یک گمان.