Product Usage Analytics: Metrics, Setup and Dashboards

Product usage analytics is the practice of measuring how people actually use your software after they sign up, then using that evidence to decide what to build, fix and tell customers. For a SaaS team the work comes down to three jobs: pick a small set of metrics, collect the data cleanly, and put the results in front of the people who need them, whether that’s your own team or your customers. This guide covers all three, and we’ll be upfront about where our own product, dashrendr, fits.

dashrendrPut product usage metrics to workBuild customisable dashboards from connected data or your REST API, then use them internally, embed them in your product, or email reports.Try the playground

TL;DR

• Product usage analytics answers who is active, who is getting value, who is at risk, and which features earn their keep.
• Start with a handful of metrics: active users, activation funnel, retention, feature adoption and power-user behaviour. Skip the 40-metric wall.
• Write a tracking plan before you write tracking code, and give it an owner. Most bad usage data starts here.
• A dashboard needs one goal and few metrics. Then schedule it, so the numbers reach people without anyone logging in.
• dashrendr is an analytics platform for SaaS teams. Plans start at $6/month, with a 14-day free trial and no credit card required.

Table of Contents

• What product usage analytics actually is
• Product usage metrics worth tracking
• How to collect usage data you can trust
• What a usage dashboard should show
• Getting the numbers to people automatically
• Build, buy or stitch together?
• Our perspective: usage analytics is a delivery problem
• Building usage dashboards with dashrendr
• A four-week plan to get started
• FAQ
• Sources

What product usage analytics actually is

The definition is simple. Pipedrive’s engineering team describes it as analysing product data to understand how customers use a product, what they do and why. Atlassian frames product analytics in a similar way: you record user actions as events, aggregate them, and use the results to improve the product.

What separates it from other analytics is the question being asked. Marketing analytics asks where visitors came from and which channel converted. Business intelligence asks about the company as a whole: revenue, costs, pipeline. Product usage analytics starts after the signup and asks what the person did next. Did they finish setup? Did they come back in week two? Did they ever touch the feature you spent a quarter building?

Stripe’s overview of usage analytics makes the same point: the aim is to move beyond simple traffic counting and understand which behaviours drive retention or churn. Page views tell you someone arrived. Usage data tells you whether they stayed for a reason.

The decisions it should feed

If a metric never changes a decision, stop reporting it. Good usage analytics feeds decisions like these:

• What to build next. Atlassian notes that event data can show which features need work and which matter most, which helps you prioritise changes.
• Where onboarding leaks. If 60% of new accounts never connect their first data source, that’s a bigger problem than any missing feature.
• Who needs a call. An account whose weekly activity has stopped is a churn risk before it’s a cancellation.
• Whether a change worked. Atlassian also recommends running hypothesis-led experiments and deciding afterwards whether the change succeeded. That only works if you wrote the hypothesis down first.

One caution before the metrics. Numbers don’t explain themselves. Aha! points out that a drop in conversion might signal friction rather than lost interest. Pipedrive’s article also warns that usage data alone is not enough on its own: combine it with financial data and customer feedback. Treat the dashboard as the thing that tells you where to look, then go and talk to people.

Product usage metrics worth tracking

Pipedrive’s list of questions is a good skeleton: how many active users you have, what drives retention, which setup or activation steps lose people, and how power users differ from everyone else. Here is how we’d turn that into a working set for a typical SaaS product.

Metric	Question it answers	How to define it
Active accounts (weekly or monthly)	Is anyone actually using this?	Count accounts, not just users, that performed one meaningful action in the period
Activation rate	Do new signups reach first value?	Share of new accounts completing your 2 to 4 key setup steps within a set window
Funnel drop-off	Where do people stall?	Step-by-step conversion through setup or a core workflow
Retention	Do they come back?	Share of a signup cohort still active in week 1, 4, 8 and 12
Feature adoption	Which features earn their keep?	Share of active accounts using a feature at least once in the period
Power-user behaviour	What do your best customers do differently?	Compare the top slice of accounts with the rest, feature by feature
Usage vs. entitlement	Who is outgrowing or underusing their plan?	Consumption against plan limits, per account

Define “active” before anything else

The single most expensive mistake in usage analytics is a vague definition of an active user. Logging in is not usage. Opening the app and closing it is not usage. Pick the action that signals the customer got value (created a report, sent an invoice, ran a query) and count only that. Write it down. Every dashboard you build afterwards inherits that definition, so get it right once.

Metrics for accounts, not just individuals

In B2B SaaS the buyer is a company. One enthusiastic user inside an otherwise dormant account doesn’t make that account healthy, and ten occasional users can be a perfectly healthy account. Track at both levels: the individual for product decisions, the account for customer success and renewals.

How to collect usage data you can trust

Bad data is worse than no data, because people act on it. The fix is boring and mostly done before anyone writes code.

1. Write a tracking plan. Datalyze’s playbook describes it as a source of truth that documents every event and property you plan to collect before code is written, which helps prevent corrupted data. Segment’s documentation adds that a tracking plan works as a technical spec you can validate incoming events against.
2. Name an owner. Someone has to say no to the fifth variant of “button_clicked”. Without an owner, event names drift within a quarter.
3. Track important events on the server. Datalyze recommends server-side tracking to minimise data loss, since browser tracking can be blocked or dropped. Billing events, account creation and completed core actions belong on the server.
4. Validate continuously. The same playbook suggests automated alerts, QA for every new event, and consistency checks against your database. A simple alert when an event’s volume falls to zero catches most breakages.
5. Join it with other systems. Stripe notes that usage analytics delivers the most value when connected with CRM, billing and support data. A usage dip means something different for a customer with an open support ticket than for one who is on holiday.

A tiny tracking plan to copy

For a reporting product, a first plan might hold only six events: account_created, data_source_connected, first_report_created, report_viewed, report_shared and export_downloaded. Each gets an owner, a trigger, the properties it carries (account ID, user ID, plan) and a note on where it fires. Six well-defined events beat sixty sloppy ones.

Privacy and access control

Usage data describes real people, so decide early who can see what. Keep personal identifiers out of events unless you need them, collect only what a decision requires, and make sure each customer can only ever see their own data when you show it back to them. Check the privacy rules that apply where your customers are (in Australia, that starts with the Privacy Act and the Australian Privacy Principles), and talk to a privacy lawyer before you finalise a policy. Internally, give dashboards to the roles that need them: support doesn’t need the revenue view, and finance doesn’t need user-level event streams.

What a usage dashboard should show

Most usage dashboards fail by showing everything. Brights’ guide to SaaS reporting puts it well: a useful dashboard has a clear goal, a small set of metrics that directly support it, and context that explains whether a change is expected. Datalyze adds a storytelling structure: open with a question, order the reports so each leads to the next, and land on an answer.

In practice, you’ll want two or three distinct dashboards.

An internal product health dashboard

This one is for your team, and the question is “is the product working for people?” Put activation rate and weekly active accounts at the top, retention cohorts in the middle, and feature adoption below. Add a plain-language note beside any metric that moves for a known reason, such as a launch or a holiday week.

A customer success dashboard

The question here is “who needs attention?” List accounts by recent activity, usage against plan limits, and the key features each one has or hasn’t adopted. This is where the account-level view earns its place.

A customer-facing usage dashboard

Your customers also want to see how they use your product. An admin wants to know which of their team members are active, how much of their allowance they’ve used, and what results the product delivered. Showing this back to them makes the value visible at renewal time, without a slide deck. We cover which numbers to put in front of customers in our post on five metrics every SaaS founder should expose, and the broader pattern in our guide to customer-facing analytics.

Getting the numbers to people automatically

A dashboard nobody opens doesn’t help anyone. The usual fix is to push the numbers out: a weekly KPI snapshot in the inbox of the team, a monthly usage summary for each customer’s account owner.

A reporting routine that holds up looks like this:

• Weekly, internal: five to seven headline metrics with week-on-week change, sent Monday morning before planning.
• Monthly, internal: retention cohorts and feature adoption, for product reviews.
• Monthly, customer-facing: a branded usage summary for each account, sent to the admin.

Keep the format identical each time, so readers learn where to look. If the report changes shape every week, nobody builds the habit. For a closer look at how we handle this, see our automated reporting use case.

Build, buy or stitch together?

There are three realistic routes to a usage dashboard, and each suits a different team.

Route	Where it works	Where it hurts
Chart library in your own code	You want total control and have developer time to spare	You build layouts, multi-tenancy, exports and scheduling yourself, and then maintain them
Enterprise BI tools such as Metabase or Looker	You have analysts and a company-wide reporting need	Our own comparison puts the cost of the bigger tools at $1,000+/month, and setup takes real effort
A dashboard layer like dashrendr	You want branded, embedded or emailed dashboards quickly, at a small-team price	It’s built for SaaS teams and product dashboards, not for standalone BI for individuals

That’s our view, and we’re obviously not neutral. The honest summary: if you’re a two-person team, a chart library may be fine for a month. When customers start asking for exports, per-customer views and a scheduled email, the build cost grows quickly.

Our perspective: usage analytics is a delivery problem

We talk to a lot of SaaS founders and developers, and the pattern is consistent. They already have the data, sitting in PostgreSQL, a BigQuery dataset or a Google Sheet. What they don’t have is a pleasant way to turn it into something a product manager, a support lead or a customer can read.

So that’s the layer we built. dashrendr is an analytics platform for SaaS teams: you connect your data sources or push your own data through the REST API, build dashboards in a drag-and-drop editor, and put them where they’re needed. That might be embedded in your product, on your team’s screens, or in a scheduled email.

Our opinion, for what it’s worth: don’t start with the tool. Start with the six events, the one definition of “active”, and the one question each dashboard answers. Once those exist, the dashboard itself takes an afternoon. If you skip them, no tool will rescue you, ours included.

We’d also push back on the idea that usage analytics is a luxury for later. A weekly email with five numbers, started in month one, gives you a baseline that’s very hard to reconstruct afterwards.

— Paloma

Building usage dashboards with dashrendr

If you want to put this into practice, here’s what dashrendr does for the job:

• Connects to your data. Google Analytics, BigQuery, PostgreSQL, MySQL, MongoDB, Google Sheets, or your own data via the REST API. See data integrations.
• Builds visually. The drag-and-drop builder needs no code, and there are pre-built templates to start from.
• Embeds in your product. Customers see their own data, with multi-tenant security and full brand customisation. There’s also a white-label portal.
• Serves your internal team. Use dashboards for operations and support or to track your own KPIs.
• Sends on a schedule. Daily, weekly or monthly email reports through automated reports, with PDF, CSV and PNG export.

The product analytics use case shows how to display usage back to your customers.

Plans start at $6/month (Hobby), then Starter at $15/month, Grow at $39/month and Premium at $99/month. Extra team members are $3/month each. Every plan starts with a 14-day free trial, and no credit card is required. There’s no free plan, just the trial. Full details are on the pricing page.

Not sure which plan fits? Start the trial, connect one data source, and build the weekly KPI snapshot first. It’s the smallest piece that proves the idea.

A four-week plan to get started

1. Week 1: decide. Agree on the definition of “active”, choose five to seven metrics, and write the tracking plan with an owner.
2. Week 2: collect. Implement the events, with the important ones on the server. Set an alert for any event that drops to zero.
3. Week 3: display. Build the internal health dashboard. Keep one goal and few metrics, and add context notes.
4. Week 4: distribute. Schedule the weekly email, then design the customer-facing view and decide what each account can see.

After a month, review what the team actually used. Cut anything nobody looked at.

FAQ

What is the difference between product analytics and product usage analytics?

In everyday use the terms overlap. Product analytics is the wider discipline of analysing how users engage with a product. Product usage analytics puts the focus on what customers do after signup: adoption, engagement, retention and account health. For B2B SaaS, the account-level view is the important addition.

How many metrics should a product usage dashboard have?

Fewer than you think. Aim for one goal per dashboard and a small set of metrics that support it, with context to explain changes. If a metric doesn’t change a decision, remove it. Five to seven headline numbers is a sensible ceiling for a weekly snapshot.

Can I track SaaS product usage without a dedicated analytics engineer?

Yes, if you keep the scope small. Write a short tracking plan, send key events from your server into a database or through an API, and use a visual dashboard builder on top. The risky parts are event naming and validation, not the charts, so give the plan an owner.

Should customers see their own usage data?

Often yes. A usage dashboard inside your product helps admins see activity and value, and it makes renewal conversations easier. The requirement is strict separation: each customer must only see their own data. Decide which metrics are suitable to share before you build.

Sources

• Product usage analytics at Pipedrive
• Usage Analytics for Businesses Explained | Stripe
• Product analytics | Atlassian
• A Complete Guide to Product Analytics For Product Managers | Aha!
• The Analytics Playbook for Founders and PMs | Datalyze
• Create a Tracking Plan | Segment Docs
• Data Analytics & Reporting in SaaS Products | Brights
• Australian Privacy Principles | OAIC

Recommended

• Show users how they are using your product
• Feature Adoption Metrics: What to Track and How
• Self-Serve Analytics: How-To Guide for SaaS
• 5 Metrics SaaS Founders Must Show Customers