Which SaaS metrics to track in the dashboard: a basic set for analyzing product and revenue
1. What a SaaS dashboard shows and why it matters
A SaaS dashboard is more than just a screen full of numbers. A proper dashboard shows registrations, logins, payments, plan type, subscription status, action history, and, if your analytics are solid, the user journey through the product. Put those pieces together and you get a clear picture: who came in, what they tried, where they got stuck, and why they left.
For a SaaS team, this dashboard is almost like a control panel. It shows how the product is performing in real time: whether registrations are growing, whether activation has dropped, whether the payment cycle has shifted, or whether cancellations are increasing. If the dashboard is put together badly, you can feel great about “new users” for a long time, even though half of them never reached the first meaningful action.
There is also a more down-to-earth benefit. The dashboard is a convenient way to check whether plans are working, where payments break, which features are barely used, and who brings in the most money. If you also have website support after launch nearby, it becomes much easier to keep the dashboard in good shape after release instead of fixing it only after users complain every day.
One important principle: the dashboard is not there for pretty charts. It exists so you can answer three questions in 10 minutes — is the product alive, is the money coming in, and are users staying? Everything else comes second.
2. User activity: registrations, logins, feature usage
Start with the basics. How many people registered per day, week, or month. How many of them logged in at least once. How many came back on day two and day three. These numbers, without any extra philosophy, show whether the top of the funnel is working.
Registration alone proves nothing. If 300 people registered in a week but only 60 entered the product, there is already a leak somewhere. Sometimes the reason is simple: the email never arrived. Sometimes it is more complex: the user did not understand why they needed this SaaS. So you should not just look at the number of registrations, but also at the share of users who completed the first meaningful action.
This is where the question comes up: which SaaS dashboard metrics should you track if you want to understand activity specifically, not vague interest? The short answer: active users over 1, 7, and 30 days, login frequency, depth of usage, and launches of key workflows. For a B2B service, that might be creating the first project, uploading a file, inviting a teammate, or running a report. For another product, the activation point will be different. There is no universal button.
Logins themselves are useful too, but only to a point. If a user opens the product 20 times a day and does nothing, that is not success. It is more likely a sign that they are looking for a feature they cannot find. In SaaS, one extra click often costs more than it seems.
To avoid guessing, it is worth defining 3–5 key workflows and measuring not only whether they were used, but also how often they repeat. A user who created a project once is not yet an active user. A user who created a project, set up an integration, and came back after 7 days is already showing behavior you can use to forecast revenue.
3. The funnel from registration to payment
The funnel is there to show the path from interest to money. It usually looks like this: registration, activation, trial period, first payment, repeat payment. At each step, some users drop off, and that is normal. What is not normal is when those losses are not measured.
First, look at how many people move from registration to their first meaningful action. Then see how many of them start a trial. After that, check how many pay once the trial ends. If there is a trial but only a tiny fraction complete it, the problem is not sales — it is the first experience. The user did not see value within 1–2 minutes. Sometimes they just needed a clearer nudge.
Bottlenecks often hide in unexpected places. For example, the payment form opens, but people drop off when entering card details. Or the trial ends before the user reaches the feature they actually need. Or activation is too hard: they have to fill in 6 fields, connect 2 integrations, and only then can they see any result. For SaaS, that is a direct path to losing part of your traffic.
It helps to track conversion between each step, not just the final payment rate. That way you can see exactly where the funnel is breaking. If registration looks fine but activation is weak, improve onboarding. If activation is strong but payment falls apart, look at pricing, the paywall, and the checkout itself. If you need a technical check of the payment flow, how to fix a 500 error on a website can be useful, because one failure at a critical moment cuts conversion more than any bad banner ever could.
Repeat payment deserves separate tracking. The first payment does not make a customer loyal. The second one shows that the product has become part of their workflow. That is a very different level of value.
4. Revenue and payment discipline
Once activity is clear, it is time to look at money. The standard core set here is MRR, ARR, average revenue per customer, payment conversion, overdue payments, subscription cancellations, and refunds. If SaaS is growing but revenue is flat, growth is coming from the wrong place or the traffic is too cheap.
MRR is useful for the monthly picture. ARR helps you look at annual dynamics and avoid panicking over one weak month. Average revenue per customer shows how well the product sells higher-tier plans or extra seats. If the average check drops while registrations grow, you should check whether a new wave of “free” users came in from a weak channel.
Overdue payments and cancellations should be tracked closely, not buried at the bottom of a report. One missed payment is not just lost revenue; it is also a risk that the user leaves without any fight. For a subscription model, payment discipline matters: did the auto-charge go through or not, was there a retry, how many users restored payment. Here, the winner is often the one who notices and reminds users about the problem faster and more accurately.
Refunds are a separate story. One refund may be noise, but a series of refunds signals a gap between expectation and value. If people ask for their money back after the first week, the promise on the landing page and the in-product experience have drifted apart. That is a direct signal for the product and marketing teams.
In some SaaS products, it is also useful to track discounts: they may lift payments at the start, but later they reduce revenue quality. If discounts become the norm, average revenue per customer stops being a healthy metric. You can see that quickly in the report if you look not only at totals but also at plan structure.
5. Retention and churn
Retention shows whether users stayed after their first contact with the product. Churn, on the other hand, shows who the SaaS lost. The simplest metrics here are churn and retention. Simple, but honest.
Churn can be measured by users, by accounts, and by revenue. For B2B, this is especially important because losing one customer with a large contract hurts more than ten small cancellations. Retention is usually easiest to review by week and by month. If the curve drops sharply in the first 7 days, the problem is almost always onboarding or the first workflow.
Repeat payments are a good practical marker of retention. A user may be active in the interface but still not renew. That happens when the value was one-off. Or when, in month two, they no longer understand what they are paying for. At that point, SaaS is already losing revenue, even though everything looks fine on the surface.
Cohort analysis helps reveal retention without self-deception. You should compare users who came in during the same period, not everyone mixed together. Otherwise January traffic gets blended with July traffic, and the conclusions will look nice but be useless. If one cohort has higher 30-day retention than another, look for the reason in the acquisition channel, the first experience, or the customer type.
Retention is rarely fixed with one button. Usually it takes 2–3 small changes: faster first value, clearer navigation, fewer unnecessary steps, and more precise reminders. But those are exactly the changes that create impact over 3–6 months, not just in a single report.
6. Behavior by segment
One overall SaaS number often lies. Users from different plans behave differently, and that is normal. That is why segmentation is almost always necessary: plans, acquisition channels, user roles, company size, geography.
For example, the free plan may generate lots of registrations and very little money. A paid plan may do the opposite — fewer registrations, but more MRR. If you look only at averages, you can get the strategy wrong. A channel with cheap traffic sometimes brings in users who barely convert to payment. A channel with expensive traffic may produce fewer registrations but higher LTV. Those are exactly the differences you need to see.
Breaking things down by role is useful in team-based SaaS products. An admin, a manager, and an operator almost never use the product in the same way. The admin checks settings, the manager checks reporting, and the operator handles daily tasks. If one segment uses the product heavily while another barely does, the in-account funnel is already skewed.
Geography matters too, even though people do not always think about it right away. Different time zones mean different activity peaks. Payment discipline and login frequency can also vary. Sometimes one segment is enough to reveal the issue. Sometimes you need the full set.
To avoid building reports manually, it helps to think through the structure in advance. If the project has already grown in integrations and access logic, a site analytics and monitoring platform · can be useful — not as a flashy example, but as a reminder that segments are best built into the system from the start.
7. Support, errors, and technical health
Product analytics does not live separately from engineering. If errors rise in the dashboard, payments drop, or support requests pile up, activity metrics are no longer easy to interpret. A user may not “churn” in an obvious way, but they may start using the service less and less well.
You should at least track 4 signals: number of support requests, types of requests, errors in key workflows, and payment delays. If tickets spike around one feature, that feature probably has a broken interface or logic. If requests keep coming for the same reason, the problem is systemic, not random.
Technical failures are especially dangerous on payment day, renewal day, or trial end. Users will forgive a small rough edge in a report. They are far less forgiving when the payment itself fails. One failed payment can trigger churn that is hard to win back later. That is why the dashboard needs not only a product layer, but also a technical monitoring layer.
It is useful to link errors to segments. If a failure affected only one plan or one country, there is no need to fix the whole SaaS blindly. If one user role sees the error more often than others, that is also a clue. Sometimes the problem sits in permissions, sometimes in a specific integration.
When technical health declines, retention and revenue metrics may worsen with a delay of several days. That is bad news. But it is visible in advance if you do not dismiss support and errors as “non-product” issues.
8. How to build a minimal dashboard set for SaaS
The minimum for proper control is 4 screens. First: a product dashboard with registrations, active users, logins, key workflows, and activation. Second: a financial dashboard with MRR, ARR, average check, payments, overdue balances, and refunds. Third: a retention report with churn, retention, and cohorts. Fourth: a segment report by plan, channel, role, and company size.
Each screen should have no more than 6–8 core metrics. Otherwise people stop looking at the dashboard and start asking the analyst, “So what matters here?” In SaaS, that is an expensive question, because extra noise in a report slows decisions down instead of speeding them up.
A good dashboard answers a question in 30 seconds. A bad one makes you scroll through 12 charts and then still go to chat. If the team is already being guided through design, analytics, and technical structure, it is worth comparing that setup with how website security is organized: a SaaS dashboard stores money, behavior, and personal data, so it should not be open to random eyes.
Another practical point: do not mix product and financial metrics on one screen without a clear logic. When “daily logins” and “annual revenue” sit next to each other, the brain grabs the loudest number and loses the context. It is better to have 4 dashboards than one overloaded one. This is not a matter of taste. It is a matter of manageability.
And the final step is agreeing on who checks each screen and how often. Product — daily or every other day. Financial — at least once a week. Retention — by cohorts once a month. Segments — whenever traffic or pricing changes noticeably. If you do not do that, even good metrics turn into an archive.
