What this prompt does
This prompt turns the model into a SaaS analytics expert that defines the right KPIs for your business and gives you the SQL to compute them. You supply [product_description], [business_stage], [pricing_model], [database_type], and [current_mrr], and it prioritizes metrics by stage, defines each precisely, benchmarks them, designs a tiered dashboard, lays out cohort analysis, and sets alerting thresholds.
The structure fights metric ambiguity. For each must-track metric it writes an exact business definition, flags the common mistakes in calculating it, then gives a SQL query for your [database_type]. That matters because MRR, churn, and LTV each have several "correct" definitions, and a wrong LTV quietly distorts every downstream decision. Because you provide [business_stage], it sorts metrics into must-track, should-track, and can-wait, so an early-stage team isn't drowning in enterprise vanity metrics. Alerting thresholds are anchored to your [current_mrr] and current values rather than generic benchmarks.
When to use it
- When your team argues about how MRR, churn, or LTV are actually defined.
- Setting up an analytics dashboard and you want exact SQL before anyone trusts the numbers.
- To decide which KPIs matter at your current stage and which to defer.
- When you need stage-appropriate benchmarks to know if your metrics are good or great.
- To design cohort retention analysis and alerting thresholds tied to your real values.
Example output
You get a stage-ranked KPI list (must-track, should-track, can-wait with rationale), then precise definitions for the core metrics — MRR, NRR, churn, LTV, CAC, LTV:CAC, time to value — each with a SQL query and notes on calculation pitfalls. It includes a benchmark table (your value, good, great, best-in-class), a three-tier dashboard design (executive, operations, detailed) with visualization types per tile, a cohort analysis framework with a retention-matrix query for your database, and an alerting table with warning and critical thresholds.
Pro tips
- Set
[database_type]precisely (MySQL 8, Postgres, Snowflake) so the generated SQL — especially the cohort retention matrix — runs without rewrites. - Be specific in
[pricing_model]: list every tier and whether plans are monthly or annual, since MRR handling of annual-to-monthly conversion depends on it. - Give a real
[current_mrr]with customer count and growth rate; the alerting thresholds anchor to your numbers, not generic SaaS averages. - Pin down
[business_stage]honestly — the must-track list for an early-stage product is very different from a scaling one. - Validate each SQL definition against a known period before trusting it; I always reconcile the model's MRR query against a month I've already closed.
- Use
[additional_metric]to define a product-specific KPI, like feature adoption rate, that off-the-shelf metric lists ignore.
