You have a SaaS product with signups coming in and a dashboard full of numbers that all look fine. Before you add another chart, write one sentence that names the first thing a new user does when the product has worked for them. That sentence is your activation event, and everything below builds on it.
Product analytics for a SaaS means instrumenting the in-product actions that predict whether a user stays, then watching two numbers above the rest: activation, the share of signups who reach first real value, and retention, the share who keep coming back. This guide covers how to define activation, which events to track, how to read a retention curve and how small teams can start without a large tooling budget. It sits underneath the SaaS UX and growth pillar.
What is activation in SaaS product analytics?
Activation is the point where a new user first gets the core value your product promises. It is not account creation and it is not a second login, since both can happen without anyone getting value.
The definition is specific to each product, so don't copy one. Two labelled examples, both proposals of mine rather than reported results:
- For Callidus, a React and Firebase clinic SaaS with scheduling and patient records, I'd test "created the first patient record and booked the first appointment" as the activation candidate. A clinic that has put real data in has moved from evaluating to using.
- For BookBed, a Flutter and Firebase property-management app with bidirectional iCal sync, I'd test "connected a calendar so real reservations start syncing". That's the moment the product stops being a demo.
To find your own, compare users who became long-term customers with users who left. Look for an action that the first group completed early and the second group mostly didn't. Then check whether reaching it really goes with staying, because a correlation you never tested is a guess. This is the same exercise as designing an onboarding flow that activates users: onboarding is the path and activation is the destination.
Is there a benchmark for a good activation rate?
There is one widely cited early signal, and it comes from retention, not activation rate. Amplitude's 7% retention rule, drawn from its 2025 Product Benchmark Report of more than 2,600 companies, says that when at least 7% of a cohort returns on day seven, the product is in the top 25% for activation performance. The same article reports that 69% of top day-seven performers were also top three-month performers.
Two cautions, both my reading. The figure is a cross-product benchmark, so a B2B tool with a weekly usage rhythm may not fit a day-seven measure. And a benchmark is a sanity check, not a target to optimize in isolation. Compare your own cohorts over time first.
How do you turn an activation sentence into a number?
Pick a time window, count the signups in a cohort, and count how many of them fired the activation event inside that window. The window is your decision, so write it down and keep it fixed.
Consider a hypothetical product, not a real one. If 200 people sign up in a week and 50 of them create a first record within seven days, the activation rate for that cohort is 25%. Next week you compare the new cohort against that figure, not against the all-time average. If the rate drops after a release, you have a dated suspect to investigate.
Some practical rules that keep the number honest:
- Count people, not events. Mixpanel's docs state that retention counts users, not event totals, and the same thinking applies to activation.
- Change the definition rarely. Each change breaks comparison with earlier cohorts, so record the date when you do it.
- Segment by plan or source once you have enough volume, because one blended rate can hide a channel that never activates.
- Review the number on a fixed rhythm, such as weekly, so a dip is noticed while the release that caused it is still fresh.
Which events should a SaaS track first?
Track the actions that show intent or value, and start with a short list. Anything you can't tie to a decision is noise. Four buckets cover most B2B products:
| Bucket | Example events | Why it matters |
|---|---|---|
| Setup | signup_completed, workspace_created, teammate_invited | Shows who finished the first steps |
| Core value | booking_created, patient_added, invoice_sent | Feeds both activation and retention |
| Habit | feature_used, a return visit on a later day | Shows repeat engagement |
| Monetization | trial_started, plan_upgraded, payment_succeeded | Connects behaviour to revenue |
PostHog's event documentation recommends an [object][verb] naming format, with examples such as project created and invite sent. Add a convention of your own on top and apply it everywhere, because a taxonomy with three spellings of the same action is painful to query later. PostHog also advises including more properties than you might need at first. My own preference is deliberate properties such as plan tier, tenant identifier and source, but the point is to decide, not to drift.
PostHog offers autocapture for pageviews and common interactions, yet its docs say custom events for critical actions such as signups are still needed for reliability. That matches the advice above: instrument the core value actions by hand.
For a multi-tenant product, carry a tenant identifier on events so you can segment per customer. Treat analytics payloads as user data: send only what you need and respect consent. The discipline that governs per-tenant data isolation applies to what leaves your app as well.
How do you read a SaaS retention curve?
Group users into cohorts by signup period, then track what share returns in each following period. The shape of the curve tells you whether you have a product that holds people, and cohorts keep new signups from masking churn.
The Mixpanel retention documentation describes a retention behavior as doing one event and later coming back to do another, and notes that retention counts users, not event totals. The PostHog retention docs define retention as how many users return during subsequent periods and offer first-time, first-ever and recurring variants. Pick one definition and keep it fixed, or your curves won't be comparable.
Three shapes are worth recognizing. These are interpretations drawn from common practice, not quotes from either vendor:
- Falls toward zero. Users leave and keep leaving. The product hasn't yet found a segment it holds.
- Falls, then flattens. A stable floor suggests a segment found lasting value. Your job is to widen that segment.
- Flattens, then rises. Later weeks tick up, which can happen when activated users expand their usage.
Always read retention per cohort, and split activated from non-activated users. If the activated group holds much better, that supports your activation definition, though it doesn't prove cause.
Which metrics are vanity and which are actionable?
A vanity metric rises no matter what you do and doesn't change a decision. Cumulative signups and total pageviews only ever climb. The test is simple: if the number moved, would you act differently?
Actionable metrics are rates tied to behavior over a window: activation rate (activated users divided by signups), week-four retention, free-to-paid conversion, and feature adoption among active users. They can fall, which is why they're useful. A drop in activation rate after a release is a signal to investigate.
Put one input metric (activation rate) and one output metric (retention or revenue retention) at the top of the dashboard and demote the rest. When acquisition rises and activation stays flat, the usual suspects are onboarding and pricing, which is why activation work often travels with a pricing page that converts.
What mistakes make retention data misleading?
Most of them come from measuring inconsistently rather than from choosing the wrong tool.
- Blending cohorts. A single "active users" line lets new signups hide churn among older ones. Read each cohort separately.
- Counting the wrong thing. Retention that counts page loads will look healthy even when nobody performs a core action. Anchor the return event to a value action.
- Moving the goalposts. Switching between first-time, first-ever and recurring retention in the same report makes curves incomparable. Keep one setting.
- Reading a small cohort as a trend. A cohort of a few dozen users swings widely from week to week. Wait for enough volume before you act on a dip.
None of these needs a paid tool to avoid. They need a written definition and the discipline to use it.
Which analytics tools suit a small SaaS?
Start with your own events table if you're small, and move to a dedicated product-analytics tool when querying the database by hand stops scaling. Add session replay only after your events show you which step leaks.
| Option | Good fit | Trade-off |
|---|---|---|
| Your own events table (a Firestore collection or Supabase table) | Solo builds and early MVPs, such as a React and Supabase app like Pizzeria Bestek | You build the charts yourself; data stays in-house |
| A dedicated tool such as PostHog, Mixpanel or Amplitude | Once you need funnels, cohorts and retention curves without building them | Another vendor holding user data |
| Session replay | After the numbers point to a specific broken step | Explains why a step leaks; doesn't find it |
Whichever you pick, draft the event list on paper first and keep it small. A clean list you understand beats a firehose. Then align the events with the moments your billing and payments system cares about, so activation, retention and revenue describe the same reality.
Write your activation sentence now, then list the five events that would prove a user reached it. If you can't name them, that's your first instrumentation task.