Product analytics for SaaS means instrumenting the specific in-product actions that predict whether a user sticks, then measuring two numbers above all others: activation (the share of signups who reach first real value) and retention (the share who keep coming back week after week). Get those two right and almost every other metric — conversion, expansion, revenue — follows. Most teams instead drown in dashboards of pageviews and signups that look healthy while the product quietly leaks users.
This guide covers how to define activation for your product, which events to track (and which to skip), how to read a retention curve, and the small tooling choices that keep analytics honest. It's the measurement layer underneath everything in the SaaS UX and Growth pillar.
Key takeaways
- Activation is the single most important early metric. Define it as a concrete first-value moment ("created first booking", "invited first teammate"), not "signed up" or "logged in twice."
- Track events, not pages. A SaaS funnel is made of actions (create, invite, publish, pay), so instrument those — pageviews barely correlate with retention.
- Retention curves tell you if you have a product, not just a launch. A curve that flattens means real value; one that drops to zero means you're refilling a leaky bucket.
- A handful of events beats a hundred. Start with 8–15 well-named events tied to value; you can always add more, but you can't retroactively clean up a messy taxonomy.
- Instrument early, even on a tiny app. Retrofitting analytics after launch loses you the comparison data you most need.
What is activation, and how do I define it for my product?
Activation is the moment a new user first experiences the core value your product promises. It is not account creation, and it is not a second login — those are necessary steps, but they don't mean anyone got value. The job is to name the one action (or short sequence) that reliably separates users who stay from users who churn.
The definition is product-specific. For a clinic SaaS like Callidus — a React, TypeScript, and Firebase app I built solo over roughly ten weeks — activation isn't "clinic owner signed up." It's closer to "created the first patient record and booked the first appointment," because a clinic that has put real data into the system has crossed from evaluating to using. For BookBed, a Flutter and Firebase property-management app that runs from one codebase across six OS platforms (iOS, Android, web, macOS, Linux, Windows), the equivalent moment is connecting a calendar so bidirectional iCal sync starts pulling real reservations in — that's when the product stops being a demo and starts saving the owner time.
A simple way to find your activation event: look at users who became long-term customers, then look at what they all did in their first session or week that one-time visitors didn't. That shared action is your activation candidate. Then sanity-check it — does reaching it actually correlate with sticking around? If yes, you have your North Star input. This pairs directly with onboarding flows that activate users: onboarding is the path, activation is the destination.
Which events should I track (and which should I ignore)?
Track actions that represent intent or value. Ignore noise. A good starting taxonomy for most B2B SaaS is 8–15 events covering four buckets:
- Acquisition / setup:
signup_completed,workspace_created,teammate_invited. - Core value actions: the verbs your product is built around —
booking_created,patient_added,invoice_sent,report_published. These are the ones that matter most. - Habit signals:
returned_day_2,feature_x_used, anything that shows repeat engagement. - Monetization:
trial_started,plan_upgraded,payment_succeeded.
Name events as object_action in past tense and keep casing consistent. Attach a small, deliberate set of properties (plan tier, tenant id, source) rather than dumping everything — over-propertied events become impossible to query cleanly later.
What to skip: raw pageviews as a primary metric, generic clicks, and "engagement" scores you can't trace back to an action. Pageviews tell you traffic moved; they almost never tell you value happened. If you instrument only one category well, make it the core value actions — those feed both activation and retention.
One caution for multi-tenant products: always carry a tenant identifier on events so you can segment per-customer, but treat analytics payloads as you would any user data — minimize what you send and respect consent. The same boundary discipline that governs your per-tenant data isolation applies to what leaves the app toward your analytics tool.
How do I read a retention curve?
A retention curve plots the percentage of a signup cohort still active N days or weeks after they joined. You group users by the week they signed up (the cohort), then track what fraction return in week 1, week 2, week 3, and so on. The shape tells you almost everything.
There are three shapes worth recognizing:
- Drops to zero: retention falls and keeps falling toward nothing. You don't have product-market fit yet — every dollar of acquisition leaks straight out.
- Declines then flattens (the "smile" plateau): retention drops in the first weeks, then levels off at a stable floor — say it settles around some non-trivial percentage and holds. That flat tail is the signal that a real segment found durable value. Your job becomes widening that segment.
- Flattens then rises: the rare, strong case where the cohort's later weeks tick back up because activated users expand usage. This is what expansion revenue looks like in a chart.
Always read retention by cohort, not as one blended average — a blended "active users" line hides the fact that new signups can mask churning old ones. And separate activated from non-activated users: activated cohorts almost always retain dramatically better, which is the empirical proof that your activation definition is the right lever to pull.
What's the difference between vanity metrics and actionable metrics?
A vanity metric goes up and to the right no matter what you do and doesn't change a decision. Total registered users only ever climbs. Cumulative signups, total pageviews, raw downloads — all flattering, all useless for steering. The test: if a number moved, would you do anything differently? If not, it's vanity.
Actionable metrics are ratios and rates tied to behavior over a window: activation rate (activated ÷ signups), week-4 retention, free-to-paid conversion, feature adoption among active users. These can go down, which is exactly what makes them useful — a falling activation rate after a release tells you the release hurt, and you can roll back or fix.
The practical move is to put one input metric (activation rate) and one output metric (retention or revenue retention) at the top of every dashboard, and demote everything else. When those two are healthy and growing together, growth compounds; when acquisition is up but activation is flat, you're spending to fill a bucket with a hole in it — and that hole is usually onboarding or pricing, which is why activation work and a pricing page that converts so often move the same retention number.
What tools should a small SaaS use, and when should I add them?
The right answer depends on stage, but the principle is constant: instrument before you think you need to. Retrofitting analytics after a launch costs you the baseline cohorts you'd compare against.
For a solo build or early MVP, you have three realistic tiers:
- Roll your own events table: write activation and core-value events to your own database (a Firestore collection, a Supabase table) and query them with SQL or a lightweight dashboard. Cheap, fully owned, no third-party data sharing — good for a Pizzeria Bestek-style app on React and Supabase where Supabase Realtime and the existing schema already sit right there. The cost is you build the charting yourself.
- A dedicated product-analytics tool (the PostHog / Mixpanel / Amplitude class): you get funnels, cohorts, and retention curves out of the box. Worth adding the moment you have enough users that eyeballing the database stops working.
- Session replay / qualitative tools: add only after the quantitative layer points you at a specific broken step — replay tells you why a funnel stage leaks once your events tell you where.
Whatever you choose, define your event taxonomy first, on paper, and keep it small. A clean 12-event schema you actually understand beats an auto-captured firehose every time. And tie analytics events to the same value moments your billing cares about — when billing and payments and product analytics agree on what "value delivered" means, your activation, retention, and revenue numbers finally describe the same reality.
FAQ
Is activation rate or retention rate more important?
They measure different stages, so you need both, but they're sequential. Activation rate tells you whether new users reach first value; retention tells you whether activated users stay. Fix activation first — there's no point optimizing retention for users who never got value, because they were never going to come back anyway.
How many events should I track when starting out?
Start with roughly 8–15, covering signup/setup, your core value actions, repeat-engagement signals, and monetization. A small, well-named set you understand is far more useful than hundreds of auto-captured events you can't query cleanly. You can always add events; cleaning up a messy taxonomy after the fact is much harder.
Can I do product analytics without a paid tool?
Yes, especially early. Writing activation and core-value events to your own database (a Firestore collection or a Supabase table) and querying them with SQL covers the essentials at zero extra cost and keeps all data in-house. Move to a dedicated analytics tool once manual querying stops scaling or you need funnels and cohort charts without building them yourself.