SaaS Metrics & Analytics in Django

These eight metrics tell you whether your SaaS is healthy, growing, or dying. Each metric has a specific calculation method, benchmark, and Django/PostgreSQL implementation.

1. Monthly Recurring Revenue (MRR)

• Formula: Sum of all active subscription monthly values. Annual plans: divide by 12. MRR = SUM(subscription.plan.monthly_price) WHERE subscription.status = 'active'
• MRR components: New MRR (new customers), Expansion MRR (upgrades), Contraction MRR (downgrades), Churned MRR (cancellations). Track each separately — total MRR hides critical trends.
• Django query: Subscription.objects.filter(status="active").aggregate(mrr=Sum("plan__monthly_price")). For annual plans: mrr=Sum(F("plan__annual_price") / 12).
• Benchmark: Healthy B2B SaaS grows MRR 10-20% month-over-month in early stages (pre-EUR 100K MRR).

2. Churn Rate (Customer and Revenue)

• Customer churn: (Customers lost in period / Customers at start of period) x 100. A SaaS with 200 customers losing 10 per month has 5% monthly churn.
• Revenue churn (more important): (MRR lost from cancellations + downgrades) / MRR at start of period x 100. If you lose 10 customers on EUR 29/month plan but retain 5 enterprise customers on EUR 299/month, revenue churn is lower than customer churn.
• Benchmark: B2B SaaS: target <2% monthly churn (< 22% annual). B2C SaaS: <5% monthly churn is good. Below 1% monthly is excellent (best-in-class).

3. Customer Lifetime Value (LTV)

• Simple formula: LTV = ARPU / Monthly churn rate. If ARPU = EUR 79/month and churn = 3%, LTV = EUR 2,633.
• Cohort-based LTV (more accurate): Track actual revenue per customer cohort (customers who signed up in the same month) over time. Shows how LTV changes as your product improves.
• Benchmark: LTV should be at least 3x CAC (Customer Acquisition Cost). LTV:CAC ratio below 3:1 means you are spending too much on acquisition or churning too fast.

4. Customer Acquisition Cost (CAC)

• Formula: CAC = (Sales + Marketing spend) / New customers acquired in the same period.
• Blended vs. Paid CAC: Blended includes organic signups (lower). Paid CAC counts only paid channels (higher, but more actionable for ad spend decisions).
• Benchmark: B2B SaaS: EUR 200-1,500 CAC depending on ARPU. Rule of thumb: CAC payback should be under 12 months.

5. Net Revenue Retention (NRR)

• Formula: NRR = (MRR at start + Expansion - Contraction - Churn) / MRR at start x 100
• Significance: NRR > 100% means you grow even without acquiring new customers (existing customers spend more over time). This is the single best indicator of product-market fit.
• Benchmark: Best-in-class SaaS: 120-140% NRR. Good: 100-120%. Below 100%: existing revenue is shrinking.

6-8. Additional metrics:

• ARPU (Average Revenue Per User): MRR / Active customers. Track monthly — rising ARPU indicates successful upselling.
• CAC Payback Period: CAC / (ARPU x Gross margin %). How many months until a new customer becomes profitable.
• Quick Ratio: (New MRR + Expansion MRR) / (Churned MRR + Contraction MRR). Above 4.0 is excellent. Below 1.0 means your SaaS is shrinking.

A SaaS metrics dashboard pulls data from Stripe (billing events), your application database (user activity), and marketing tools (acquisition data). Here is the architecture for computing metrics efficiently in Django.

Data model for metrics:

• MRR snapshots: Create a MRRSnapshot model: date, total_mrr, new_mrr, expansion_mrr, contraction_mrr, churned_mrr. Computed daily by a Celery Beat task at midnight UTC.
• Subscription events: Log every subscription change in a SubscriptionEvent model: tenant, event_type (created, upgraded, downgraded, cancelled, reactivated), old_mrr, new_mrr, timestamp. Populated from Stripe webhook events.
• Cohort tracking: Store signup_month on each tenant/customer record. Use for cohort analysis queries.

MRR calculation (PostgreSQL query):

• Daily MRR snapshot task queries active subscriptions and computes MRR components by comparing today's state with yesterday's snapshot.
• New MRR = SUM(mrr) WHERE subscription created today
• Expansion MRR = SUM(new_mrr - old_mrr) WHERE event_type = 'upgraded' AND today
• Contraction MRR = SUM(old_mrr - new_mrr) WHERE event_type = 'downgraded' AND today
• Churned MRR = SUM(old_mrr) WHERE event_type = 'cancelled' AND today
• Store as snapshot for historical charting. Never recalculate historical MRR — snapshot it daily for immutable records.

Churn calculation with cohort analysis:

• Monthly churn: count customers active at month start vs. month end. SELECT signup_month, COUNT(*) FILTER (WHERE status = 'active') as retained, COUNT(*) as total FROM tenants GROUP BY signup_month
• Cohort retention matrix: for each signup month, track what percentage is still active 1, 2, 3, ... 12 months later. Visualise as a triangular heatmap — the single most insightful SaaS chart.
• Django implementation: Tenant.objects.values("signup_month").annotate(total=Count("id"), retained=Count("id", filter=Q(status="active")), churned=Count("id", filter=Q(status="cancelled")))

LTV calculation with Stripe data:

• Pull total revenue per customer from Stripe: stripe.Invoice.list(customer=cust_id, status="paid"). Sum all invoice amounts. This is actual LTV, not projected.
• With dj-stripe: Invoice.objects.filter(customer=djstripe_customer, status="paid").aggregate(ltv=Sum("amount_paid"))
• Projected LTV using current ARPU and churn rate: store in TenantMetrics model, updated weekly.

Performance considerations:

• Metrics queries on large datasets (10,000+ subscriptions, 100,000+ invoices) should use materialised views or pre-computed tables, not real-time aggregation.
• Create a metrics_daily PostgreSQL materialised view refreshed nightly: CREATE MATERIALIZED VIEW metrics_daily AS SELECT date_trunc('day', created) as day, SUM(mrr) as total_mrr, ... FROM subscriptions GROUP BY 1;
• Dashboard loads from materialised view (< 50ms) instead of scanning full subscription table (2-5 seconds).

A SaaS metrics dashboard should answer three questions at a glance: Are we growing? Are we retaining? Are we profitable? Here is the dashboard design and technical implementation.

Dashboard layout (4 sections):

• Top row — Key metrics cards: MRR (with month-over-month change %), Active customers, Monthly churn rate, LTV:CAC ratio. Green/red indicators for positive/negative trends.
• MRR chart: Stacked area chart showing New MRR, Expansion MRR, and total MRR as a line overlay. Time range: 6-12 months. Use Chart.js or Plotly (free, no backend dependency).
• Cohort retention heatmap: Rows = signup months, columns = months since signup, cells = retention percentage. Colour gradient from red (low retention) to green (high retention). This is the most actionable chart — it shows whether your product is improving at retaining users over time.
• Revenue breakdown: MRR by plan (pie chart), MRR by customer segment (bar chart), top 10 customers by revenue (table). Identify revenue concentration risk — if one customer is 20%+ of MRR, that is a business risk.

Technical implementation:

• Backend: Django view or DRF endpoint that queries MRRSnapshot model and returns JSON. Cache response in Redis with 5-minute TTL. @cache_page(300) def metrics_api(request): ...
• Frontend: Chart.js for charts (150KB, no dependencies). Fetch data from API endpoint. Update every 5 minutes via JavaScript setInterval. For real-time updates: Server-Sent Events (SSE) or WebSocket via Django Channels.
• Filtering: Date range picker (last 7 days, 30 days, 90 days, 12 months, custom). Plan filter (show metrics for specific plan only). Segment filter (by company size, industry, acquisition channel).

Automated reports and alerts:

• Weekly metrics email: Celery Beat task sends a summary email every Monday with: MRR change, new customers, churned customers, notable events. Use django-templated-email with an HTML template.
• Churn alerts: Notify via Slack/email when: a customer with MRR > EUR 200 cancels, monthly churn exceeds 5%, NRR drops below 100%. Implement with Django signals on SubscriptionEvent model.
• Milestone notifications: Celebrate growth — "You hit EUR 10,000 MRR!" Automatic notification when MRR crosses defined thresholds (EUR 1K, EUR 5K, EUR 10K, EUR 25K, EUR 50K, EUR 100K).

Third-party alternatives:

• ChartMogul: SaaS analytics platform that connects to Stripe directly. EUR 100/month for up to EUR 120K MRR. Good option if you want metrics without building a dashboard.
• Baremetrics: Stripe analytics with benchmarking. EUR 108/month for up to EUR 100K MRR.
• ProfitWell (by Paddle): Free Stripe analytics. Limited customisation but EUR 0 cost.
• Custom dashboard advantage: Full control over calculations, tenant-level metrics (not just company-wide), integration with your application data (feature usage correlated with churn), and no monthly SaaS fee beyond development cost.

Revenue metrics tell you what happened. Product analytics tell you why — and predict what will happen next. Connecting feature usage to churn and expansion is the key to data-driven SaaS growth.

Event tracking architecture:

• Event model: ProductEvent: tenant, user, event_name (e.g., "report_generated", "team_member_invited", "api_key_created"), properties (JSONField for metadata), timestamp.
• Tracking method: Django middleware logs page views automatically. Feature usage tracked via explicit calls: track_event(request, "report_generated", {"report_type": "monthly", "format": "pdf"}). Keep events lightweight — fire-and-forget via Celery task.
• Storage: For under 1 million events/month: PostgreSQL with partitioned tables (partition by month). For higher volumes: ClickHouse or TimescaleDB. PostgreSQL handles 10M+ events but queries slow down — use materialised views for aggregation.

Engagement scoring:

• Assign points to product actions based on correlation with retention. Example scoring: daily login = 1 point, create project = 5 points, invite team member = 10 points, connect integration = 15 points, generate report = 3 points.
• Health score formula: Health = (events_last_7_days / expected_events) x 0.4 + (features_used / total_features) x 0.3 + (team_members_active / team_size) x 0.3
• Score ranges: 0-30 (at risk — likely to churn within 60 days), 31-60 (needs attention), 61-80 (healthy), 81-100 (champion — expansion opportunity).
• Compute weekly via Celery task. Store in TenantHealthScore model. Alert customer success team when a paying customer drops below 30.

Churn prediction model:

• Leading indicators of churn (identify from historical data): Login frequency drops 50%+ week over week, no new content created in 14 days, support tickets increase (frustration), admin user stops logging in (champion left), payment method about to expire.
• Simple prediction: Rule-based scoring using the indicators above. No ML needed for early-stage SaaS — rules capture 80% of at-risk customers.
• Advanced prediction: Train a scikit-learn classifier (Random Forest or XGBoost) on historical data: features = product events, support tickets, billing history, login patterns. Label = churned within 90 days. Retrain monthly. Typical accuracy: 75-85% AUC.

Feature adoption tracking:

• Track which features each tenant uses. Create a FeatureAdoption report: for each feature, show percentage of customers using it, correlation with retention, and correlation with plan upgrades.
• Insights this reveals: "Customers who use the API integration feature have 85% 12-month retention vs. 45% for those who do not." This tells you to invest in API integration onboarding and to nudge non-users toward adoption.
• Activation metrics: Define "activated" as completing 3-5 key actions within the first 7 days (e.g., create first project, invite team member, generate first report). Track activation rate per cohort. Activated users convert from trial to paid at 3-5x the rate of non-activated users.

Essential Metrics Dashboard (EUR 3,000-5,000):

• MRR tracking with daily snapshots (total, new, expansion, contraction, churned)
• Customer churn rate (monthly and annual)
• LTV and ARPU calculations
• MRR chart (12-month history) with Chart.js
• Key metrics cards (MRR, customers, churn, ARPU) with trend indicators
• Weekly metrics email report
• Stripe data integration (via dj-stripe or direct API)
• Timeline: 3-4 weeks

Advanced Analytics Dashboard (EUR 5,000-8,000):

• Everything in Essential
• Cohort retention analysis with heatmap visualisation
• Net Revenue Retention (NRR) tracking
• Revenue breakdown by plan, segment, and acquisition channel
• Product event tracking infrastructure
• Engagement scoring with health score per tenant
• Churn risk alerts (Slack and email notifications)
• CAC tracking with marketing spend integration
• Filterable dashboard (date range, plan, segment)
• Timeline: 5-7 weeks

Enterprise Analytics Suite (EUR 8,000-15,000):

• Everything in Advanced
• Churn prediction model (ML-based)
• Feature adoption tracking and correlation analysis
• Customer journey analytics (signup to activation to expansion)
• Revenue forecasting (12-month projection with confidence intervals)
• Executive PDF report generation (monthly)
• Custom metrics and calculated fields
• Data warehouse integration (BigQuery, Snowflake) for advanced analysis
• Timeline: 8-12 weeks

Infrastructure costs for analytics:

• Under 1,000 customers: PostgreSQL on existing server handles all analytics queries. EUR 0 additional cost.
• 1,000-10,000 customers: Add a read replica for analytics queries (EUR 30-80/month). Materialised views refresh nightly.
• 10,000+ customers with event tracking: Dedicated analytics database (TimescaleDB or ClickHouse). EUR 50-150/month.

Build vs. Buy comparison:

• ChartMogul/Baremetrics: EUR 100-250/month. Quick setup (connect Stripe, done). Limited to billing metrics — no product analytics, no tenant-level health scores, no custom metrics.
• Custom dashboard: EUR 3,000-8,000 one-time + EUR 0-80/month infrastructure. Full control, product analytics integration, custom metrics, no ongoing SaaS fees. Breaks even vs. ChartMogul in 18-30 months, with significantly more capability.
• Recommendation: Use ProfitWell (free) for basic Stripe metrics from day one. Build a custom dashboard when you need product analytics, engagement scoring, or churn prediction — typically at 200+ paying customers.