--- title: "How to Build a Subscription Analytics Revenue Intelligence SaaS" author: "Nate Laquis" author_role: "Founder & CEO" date: "2026-05-25" category: "How to Build" tags: - subscription analytics - revenue intelligence - SaaS metrics - MRR tracking - churn analytics excerpt: "Baremetrics, ChartMogul, and ProfitWell proved the market. Here is how to build your own subscription analytics and revenue intelligence platform from billing ingestion to predictive churn scoring." reading_time: "14 min read" canonical_url: "https://kanopylabs.com/blog/how-to-build-a-subscription-analytics-revenue-intelligence-saas" --- # How to Build a Subscription Analytics Revenue Intelligence SaaS ## Why the Market Needs Better Subscription Analytics Every SaaS company tracks MRR in a spreadsheet until about $50K ARR. Then the spreadsheet breaks. Upgrades get miscounted, prorations throw off monthly totals, and nobody can agree on the churn number. That is the exact moment founders start searching for subscription analytics tooling, and it is the reason Baremetrics, ChartMogul, and ProfitWell (now owned by Paddle) built category-defining businesses. But here is the thing: most existing tools are either too simple or too rigid. Baremetrics gives you clean dashboards but limited segmentation. ChartMogul is powerful but expensive at scale. ProfitWell is free but now deeply tied to Paddle's ecosystem. If you are building a subscription analytics and revenue intelligence SaaS in 2026, you have a real opportunity to win on three fronts: deeper intelligence (predictive churn, expansion signals), broader integrations (not just Stripe), and better multi-tenant support for agencies and PE portfolio companies. We have helped teams build analytics platforms that process millions of subscription events daily. This guide covers the full architecture, from billing data ingestion to cohort analysis, forecasting models, and the alerting layer that turns data into action. Whether you are building this as a standalone product or embedding it inside your existing SaaS, the core patterns are the same. ![Subscription analytics dashboard showing MRR and churn metrics](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80) ## Core SaaS Metrics Your Engine Must Calculate Before writing a single line of code, you need to define the metrics your engine will compute. These are not negotiable. Every subscription analytics platform must get these right, because if your MRR calculation disagrees with the customer's billing system, you lose trust instantly. ### MRR and ARR Monthly Recurring Revenue is the foundation. It sounds simple (sum of all active subscription amounts, normalized to monthly), but the edge cases are brutal. You need to handle annual plans (divide by 12), quarterly plans (divide by 3), metered billing (use committed minimums or trailing average), free trials (exclude until conversion), and coupons (deduct discount amount). ARR is simply MRR times 12, but only include subscriptions with terms of 12 months or longer for a strict definition. ### MRR Movement Categories Raw MRR is useless without understanding how it changed. You need to decompose MRR movement into five categories every month: New MRR (first-time subscriptions), Expansion MRR (upgrades, add-ons, seat increases), Contraction MRR (downgrades, seat decreases, removed add-ons), Churned MRR (canceled subscriptions), and Reactivation MRR (previously churned customers returning). The formula is straightforward: Ending MRR = Starting MRR + New + Expansion + Reactivation - Contraction - Churn. ### Churn Rates You need both customer churn (logo churn) and revenue churn (MRR churn), because they tell different stories. A company losing 5% of customers monthly but only 2% of MRR is losing small accounts and retaining large ones. Calculate gross churn rate (churned MRR / starting MRR) and net revenue churn (churned + contraction - expansion / starting MRR). Negative net revenue churn means your expansion revenue exceeds losses, which is the gold standard for SaaS companies. ### Net Revenue Retention (NRR) NRR measures how much revenue you retain from existing customers over a period, including expansion. The formula: (Starting MRR + Expansion - Contraction - Churn) / Starting MRR. Top-performing SaaS companies hit 120%+ NRR. Your platform should benchmark customers against industry medians. ### LTV, CAC, and Payback Period Lifetime Value equals ARPU divided by gross churn rate (for a simple model) or use a discounted cash flow approach for more accuracy. Customer Acquisition Cost comes from marketing and sales spend divided by new customers acquired. LTV/CAC ratio should be above 3x for healthy unit economics. Payback period (CAC / monthly gross profit per customer) tells you how many months until a customer becomes profitable. These metrics require integrating data beyond billing, specifically marketing spend and sales pipeline data. ## Data Ingestion: Connecting to Billing Providers Your analytics platform is only as good as the data flowing into it. The ingestion layer is the hardest part to get right, and it is where most teams underestimate the complexity. You need to support multiple billing providers, handle webhook reliability, and normalize wildly different data models into a unified schema. ### Stripe Integration Stripe is your first integration, period. Over 70% of SaaS companies use Stripe for billing. You need to ingest these webhook events at minimum: **customer.subscription.created**, **customer.subscription.updated**, **customer.subscription.deleted**, **invoice.paid**, **invoice.payment_failed**, **charge.refunded**, and **customer.created**. For multi-tenant support (agencies connecting their clients' Stripe accounts), use Stripe Connect with OAuth to let users authorize access. Do not rely solely on webhooks for initial data. When a user first connects their Stripe account, you need to backfill historical data using the Stripe API. Paginate through all subscriptions, invoices, and customers. For a typical SaaS with 5,000 customers, this backfill takes 15 to 30 minutes depending on rate limits. Run it as a background job and show progress in the UI. ### Chargebee and Recurly Chargebee and Recurly have similar webhook architectures but different event schemas. Chargebee sends events like **subscription_created**, **subscription_renewed**, **subscription_changed**, and **subscription_cancelled**. Recurly uses **new_subscription_notification**, **updated_subscription_notification**, and **expired_subscription_notification** via push notifications or webhooks. Build an adapter pattern where each provider maps to a common internal event schema. ### Webhook Reliability Webhooks fail. Stripe retries for up to 72 hours, but you still need idempotency keys on every event to prevent double-counting. Store the event ID from each provider and check for duplicates before processing. Use a dead-letter queue for events that fail processing after multiple retries. Implement a daily reconciliation job that compares your computed MRR against the billing provider's subscription list to catch any missed events. For your [subscription billing implementation](/blog/how-to-implement-subscription-billing), consider building a unified event bus using Amazon SQS or Google Cloud Pub/Sub. Each incoming webhook gets normalized into your internal schema, published to the bus, and then consumed by multiple downstream services: the metrics engine, the alerting system, and the data warehouse. ![Revenue intelligence dashboard with cohort analysis and forecasting](https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&q=80) ## Building the Metrics Engine and MRR Calculation Pipeline The metrics engine is the core of your product. It takes raw billing events and computes every metric your customers need. Getting this right requires careful thinking about temporal accuracy, currency handling, and the order of operations. ### The Subscription Snapshot Approach The most reliable approach is to maintain a "subscription snapshot" for every day (or every month boundary). Each snapshot records the subscription ID, customer ID, plan, quantity, unit price, discount, and effective MRR contribution. When a billing event arrives, you update the current snapshot. To compute MRR for any given month, you look at the snapshot on the last day of that month. This approach is simpler than trying to replay events every time and makes historical corrections straightforward. ### Handling Upgrades, Downgrades, and Prorations Upgrades and downgrades are where most analytics tools get the numbers wrong. When a customer upgrades mid-cycle, Stripe issues a prorated invoice for the remainder of the current period and starts the new plan on the next cycle. Your MRR calculation should reflect the new plan amount immediately (MRR represents the forward-looking monthly rate), not the prorated invoice amount. Similarly, downgrades should update MRR to the new lower amount on the effective date, not when the invoice is generated. Build a clear separation between "invoice-level" metrics (actual cash collected) and "subscription-level" metrics (normalized recurring amounts). Your customers will want both views, and mixing them up creates confusion that erodes trust in your platform. ### Multi-Currency Support If your customers sell internationally, you need to normalize MRR to a single reporting currency. Use a consistent exchange rate source (European Central Bank publishes daily rates for free) and lock the rate at the time of subscription creation or renewal. Do not recalculate historical MRR with current exchange rates, because that creates phantom MRR movements that do not reflect real business changes. Store both the original currency amount and the normalized amount in your subscription snapshots. ### Technology Stack for the Engine For the metrics engine, you have two strong options. ClickHouse is purpose-built for analytical queries over large datasets. It handles time-series aggregations (sum MRR by month, segment, cohort) at sub-second speeds even with millions of rows. TimescaleDB is PostgreSQL with time-series extensions, which is a better fit if your team already knows Postgres and you want to avoid adding another database. Use dbt (data build tool) to define your metric calculations as SQL transformations. This makes your metric definitions version-controlled, testable, and auditable. Your dbt models should follow a layered approach: staging (raw events cleaned up), intermediate (subscription snapshots, MRR movements), and marts (final metric tables ready for the API). ## Cohort Analysis and Forecasting Models Cohort analysis and revenue forecasting are the features that differentiate a real revenue intelligence platform from a basic metrics dashboard. These are the features that make finance teams, not just product teams, pay for your tool. ### Retention Cohorts Group customers by their signup month and track what percentage remain active over time. Display this as a classic triangle chart where rows are cohorts and columns are months since signup. Color-code cells so users can instantly spot which cohorts retain better or worse. The real value comes from letting users filter cohorts by plan, acquisition channel, geography, or any custom attribute. A SaaS company might discover that customers acquired through content marketing retain 30% better than paid search customers, which completely changes their budget allocation. ### Revenue Cohorts Revenue cohorts work the same way but track MRR per cohort instead of customer count. This reveals expansion patterns: does MRR per cohort grow over time (strong product-market fit and upsell motion) or decay (value leakage)? Overlay revenue cohorts with retention cohorts to see whether surviving customers are spending more or less over time. ### Acquisition Cohorts and Segmentation Beyond time-based cohorts, build segmentation capabilities that let users create custom cohorts based on any combination of attributes: plan type, company size, industry, feature usage, and acquisition source. Each segment should have its own MRR, churn rate, NRR, and LTV calculations. This is where your product becomes genuinely actionable, because aggregate metrics hide the signal. A 5% monthly churn rate might be 1% for enterprise customers and 12% for self-serve customers, and each demands a completely different response. ### Forecasting Models Start with a simple approach: linear extrapolation of current MRR trends for a 3 to 12 month forecast. Apply the current net MRR growth rate forward and display confidence intervals based on historical variance. This is surprisingly useful and easy to implement. For more sophisticated forecasting, use Facebook Prophet (now just "Prophet") or build custom time-series models. Prophet handles seasonality, trend changes, and holidays automatically. Feed it your monthly MRR history and it produces forecasts with uncertainty intervals. For SaaS-specific forecasting, build a bottoms-up model: forecast new customer acquisition separately from expansion and churn, then combine. This lets you model scenarios like "what happens to ARR if we reduce churn by 1% and increase expansion by 2%?" If you are looking to build a more comprehensive [AI analytics dashboard guide](/blog/how-to-build-ai-analytics-dashboard), consider layering anomaly detection on top of your forecasts. Flag when actual MRR deviates from the forecast by more than two standard deviations so customers catch problems (or wins) early. ![SaaS metrics tracking board for subscription revenue optimization](https://images.unsplash.com/photo-1512758017271-d7b84c2113f1?w=800&q=80) ## Revenue Recognition, Health Scoring, and Alerting Revenue recognition, customer health scoring, and proactive alerting are the three features that push your product from a reporting tool into a revenue intelligence platform. These features justify 2 to 3x higher pricing because they deliver direct ROI. ### ASC 606 Revenue Recognition SaaS companies with annual or multi-year contracts must recognize revenue ratably over the service period, not when cash is collected. Your platform should automatically calculate recognized vs. deferred revenue for each contract. For a $12,000 annual contract paid upfront, you recognize $1,000 per month. Build a revenue waterfall report that shows how today's bookings translate into future recognized revenue. This is table stakes for any SaaS company raising venture capital or preparing for an audit, and finance teams will pay premium pricing for it. The tricky part is handling mid-term changes. When a customer upgrades mid-contract, you need to recalculate the remaining obligation and adjust the recognition schedule. Store the original contract terms, amendment history, and current recognition schedule for each subscription. If you want to go deep here, study the IFRS 15 and ASC 606 standards, specifically the five-step model for identifying performance obligations. ### Customer Health Scoring Health scores predict which customers are at risk of churning before they cancel. Build a composite score (typically 0 to 100) based on multiple signals: billing health (failed payments, past-due invoices), usage trends (declining logins, reduced API calls, fewer active seats), support interactions (increasing ticket volume, negative sentiment), and contract signals (approaching renewal, recent downgrade). Weight each signal based on your historical churn data. Customers who churned in the past, what did their signal patterns look like in the 30 to 90 days before cancellation? For [AI-powered churn reduction](/blog/ai-powered-customer-retention-churn), train a gradient-boosted model (XGBoost or LightGBM) on historical churn outcomes with these signals as features. The model learns non-obvious patterns, like customers who contact support exactly twice in the first month actually have higher retention than those who never contact support. Deploy the model to score customers weekly and surface the highest-risk accounts in a prioritized list. ### Alerting and Expansion Signals Build an alerting system that notifies customers about important changes in real time. Critical alerts include: MRR dropped more than a threshold percentage in a single day, a large account downgraded or initiated cancellation, payment failure rate spiked above normal levels, and churn rate exceeded the trailing average by more than two standard deviations. Expansion opportunity alerts are equally valuable: a customer's seat utilization exceeded 80% (they might need more seats), usage of a premium feature spiked (they might upgrade), or a customer just hit their plan limit. Deliver alerts through multiple channels: in-app notifications, email digests (daily or weekly), Slack/Teams integrations, and webhook callbacks for customers who want to trigger their own workflows. Let users configure alert thresholds and routing rules so they are not overwhelmed with noise. ## Architecture, Competitive Positioning, and Go-to-Market With the core product defined, let's talk about the full technical architecture and how to position your platform in a market that already has established players. ### Full Technical Architecture Your production stack should look something like this. API layer: Node.js with TypeScript (Fastify or Hono) or Python with FastAPI. Database: PostgreSQL for transactional data (customers, accounts, configurations), ClickHouse or TimescaleDB for analytical queries (metrics, time-series). Queue: Amazon SQS, Google Pub/Sub, or Redis Streams for webhook ingestion and async processing. Cache: Redis for frequently accessed dashboards and metric summaries. Transformation: dbt for metric calculations running on a schedule (every hour or triggered by new events). Frontend: Next.js with React, using Recharts or Tremor for data visualization. For multi-tenant architecture, every query must be scoped to the tenant's organization ID. Use row-level security in PostgreSQL and tenant-prefixed tables or materialized views in ClickHouse. Stripe Connect handles the multi-account linking: each customer authorizes your app to read their Stripe data via OAuth, and you store the access tokens securely (encrypted at rest, rotated on refresh). ### Reporting and Export Features Finance teams live in spreadsheets, so CSV and Excel exports are not optional. Build a report builder that lets users select metrics, date ranges, segments, and groupings, then export the results. Scheduled reports (email a PDF summary every Monday morning) are a premium feature that large customers love. For investor-ready reporting, generate clean PDF reports with MRR charts, cohort tables, and key metric summaries that founders can attach to board decks. ### Competitive Positioning The existing players leave real gaps you can exploit. Baremetrics is beautiful but shallow. It covers basic metrics and benchmarking but lacks advanced cohort analysis, forecasting, and health scoring. ChartMogul is the most complete but charges based on MRR tracked, which gets expensive fast for larger SaaS companies ($600/month at $10M ARR). ProfitWell (now Paddle Billing Metrics) is free but limited to Paddle/Stripe and has become an upsell vehicle for Paddle's billing product. Your positioning options: go deep on intelligence (health scoring, churn prediction, expansion signals) to justify premium pricing. Go broad on integrations (support Chargebee, Recurly, Zuora, custom billing systems) to win customers locked out of Stripe-only tools. Or go multi-tenant for the underserved PE and agency market (portfolio companies need consolidated analytics across dozens of SaaS businesses). The multi-tenant angle is particularly compelling because private equity firms managing 5 to 20 SaaS portfolio companies will pay $2,000 to $5,000 per month for a consolidated view across all their investments. ### Getting Started Start with Stripe-only integration, the five core metrics (MRR, churn, NRR, LTV, CAC), and basic cohort analysis. Ship this in 8 to 12 weeks with a team of two to three engineers. Then layer on forecasting, health scoring, and additional integrations based on customer feedback. The analytics engine is technically demanding, but the real moat is data quality. If your MRR numbers match exactly what customers see in Stripe, you have earned their trust. Everything else builds on that foundation. Building a subscription analytics platform is a serious engineering undertaking, but the market demand is proven and growing. If you want help designing the architecture, building the metrics engine, or shipping an MVP fast, [book a free strategy call](/get-started) and let's map out your roadmap together. --- *Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-a-subscription-analytics-revenue-intelligence-saas)*