SaaS

Misc

Notes from
- Meaningful metrics: How data sharpened the focus of product teams
- Open Source does not win by being cheaper
Resources
- SaaS Growth Metrics
- What Is Monthly Recurring Revenue (MRR) and How Can It Help You Understand Business Health?
Open-Source solutions are great when a transparency problem is present
- SaaS tools need to process sensitive client data such as IP addresses, names, session recordings, etc., and in a world of increasing data regulations (e.g., GDPR and CCPA), it can be daunting for third parties to store that data.
- Example: PostHog
  - Options
    - Self-host an analytics solution yourself
    - Hire PostHog as a third party to do it, but with transparency into how that data is stored and how possibly migrating to self-hosted in the future would work.
  - Many companies will still opt for a hosted model, but they do so now with assurances of how the software works—line by line—and the process of migrating to a self-hosted model in the future if necessary. It’s not that open-source companies win by preventing the need for a third party; they win by allowing for the open audit of how it works.
Open Source can lean on the community to develop connections and extensions
- While the core product is typically maintained by a central engineering team, integrations or plugins are often built by community developers and then occasionally merged into the main branch.
- Conversely, closed-source solutions struggle with this because they rely on their engineering team. By tapping the community for feedback and help, open-source projects can also accelerate past closed-source solutions
Larger companies aren’t worried about going out of business because a piece of software is too expensive. They might be price-conscious in terms of negotiating a contract in context of their budget, but most SaaS software is just a line item at the end of the day.
- What matters more is that the solution is (a) a good solution, (b) around for the long haul, and (c) easy to manage. And, unfortunately, deploying an open-source solution can be tricky to manage.
- Most open-source solutions aren’t replacing a top-three line item, and therefore price isn’t the north star deciding factor.
MongoDB eventually switched to a special SSPL license to add specific restrictions on Cloud Providers from distributing a service without contributing to the project, which isn’t OSI approved, but is open-source practically).
- But why make this point? Well, splitting the hair between profit and usage is important to measuring long-term success. If a project gets great adoption but cannot drive revenue, it will die.

Metrics

Monthly Recurring Revenue (MRR)
\[ \mbox{MRR} = \mbox{Number of Active Accounts} \times \mbox{ARPA} \]
- The normalized, predictable revenue that is generated from active accounts on subscription-based payment plans on a monthly basis.
- \(\mbox{ARPA}\): Average Revenue per (Active) Account
- Each metric must be scaled to a per month basis:
  - Quarterly Contract → Divide by 3
  - Semi-Annual → Divide by 6
  - Annual → Divide by 12
- One-Time payments are not recurring and should not be included in the MRR calculation.
Net New Monthly Recurring Revenue (Net New MRR)
\[ \mbox{Net New MRR} = \mbox{New MRR} + \mbox{New MRR Expansion} + \mbox{Reactivation MRR} − \mbox{MRR Churn} \]
- An adjusted MRR that is inclusive of both gains and losses
- \(\mbox{New MRR}\): Incremental MRR from New Customers Acquisitions
- \(\mbox{New MRR Expansion}\): Additional MRR from Existing Customers (e.g. Upgrades, Upselling, Cross-Selling)
  
  \[ \mbox{Number of Customers Who Upgraded} \times \mbox{Difference in Monthly Subscription Fees Before and After Upgrade} \]
- \(\mbox{MRR Churn}\): Lost MRR from Cancellations or Downgrades
  
  \[ \mbox{Number of Customers Churned} \times \mbox{Average Monthly Subscription Fee per Customer} \]

User Segmentation

Diagram of users based on their activity on the language learning software, “duolingo.”
- See article for an example of a user journey
Activity States
- New users: learners who are experiencing Duolingo for the first time ever
- Current users: learners active today, who were also active in the past week
- Reactivated users: learners active today, who were also active in the past month (but not the past week)
- Resurrected users: learners active today, who were last active >30 days ago
- At-risk Weekly Active Users (WAU): learners who have been active within the past week, but not today
- At-risk Monthly Active Users (MAU): learners who were active within the past month, but not the past week
- Dormant Users: learners who have been inactive for at least 30 days
Rates
- Retention Rates
  - New User Retention Rate (NURR): The proportion of day 1 learners who return on day 2. This day 2 transition puts these learners into another “active” state (Current User)
- Deactivation Rates: e.g. WAU or MAU loss rate
- Activation Rates: e.g. Reactivation or Resurrection rate
Process
- Classify all users (past or present) into an activity state each day
- Collect data: monitor rates of transition between states.
  - These transition probabilities are monitored as retention rates, activation rates, and deactivation rates
- Use transition probabilities to create Markov model for simulations
Identify new metrics, through simulations of the Markov model, that - when optimized - are likely to increase a North Star or Primary metric.
- Example
  - Simulation is for 3yrs into the future
  - “Lever” is the parameter being increased
    - In the sim, it’s increased 2% month-over-month
  - Daily Active Users (DAU) is the North Star metric that is being opitimized (i.e. increased)
  - Interpretation: Increasing Current User Retention Rate (CURR) increases DAU by 75% over the next 3yrs
- Formulas at time, t
  - DAUt = ReactivatedUsert + NewUsert + ResurrectedUsert + CurrentUsert
  - WAUt = ReactivatedUsert + NewUsert + ResurrectedUsert + CurrentUsert + AtRiskWAUt
  - MAUt = ReactivatedUsert + NewUsert + ResurrectedUsert + CurrentUsert + AtRiskWAUt + AtRiskMAUt
  - ReactivatedUsert = ReactivationRatet * AtRiskMAUt-1
  - ResurrectedUsert = ResurrectionRatet * DormantUserst-1
  - CurrentUsert = (NewUsert-1 * NURRt) + (ReactivatedUsert-1 * RURRt) + (ResurrectedUsert-1 * SURRt) + (CurrentUsert-1 * CURRt) + (AtRiskWAUt-1 * WAURRt)
  - DormantUsert = (DormantUsert-1 * DormantRRt) + (AtRiskMAUt-1 * MAULossRatet)
  - AtRiskMAUt = (AtRiskMAUt-1 * ARMAURRt) + (AtRiskWAUt-1 * WAULossRatet)
  - AtRiskWAUt = (AtRiskWAUt-1 * ARWAURRt) + (CurrentUsert-1 * (1-CURRt)) + (ReactivatedUsert-1 * (1-RURRt)) + (NewUsert-1 * (1-NURRt)) + (ResurrectedUsert-1 * (1-SURRt))
Perform A/B tests to see whether 1) the selected metric can be moved and 2) whether moving it actually moves the north star/primary metric