# North star, activation and retention metrics for SaaS

Canonical URL: https://www.martechdevs.com/blog/saas-activation-metrics

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2025-05-13

Last updated: 2026-10-01

A useful SaaS metric system connects three questions: are customers receiving the value the product promises, are new customers reaching that value, and do they keep returning for it? Use a north star metric to focus the team on recurring customer value, an activation metric to measure an early qualifying outcome and retention metrics to check whether that outcome lasts. Define the population, counting unit, event and time window before choosing targets.

Signup volume can rise while fewer customers reach a useful result. An onboarding checklist can reach 100% completion because you made every step compulsory. Daily active users can grow because people repeatedly reopen the app to resolve an error.

The number is doing what you told it to do. The harder question is whether the definition represents progress for the customer and the business.

This guide uses an illustrative reporting SaaS to build a connected set of metrics, test an activation hypothesis and turn the definitions into something every dashboard can calculate consistently.

## Give each metric a specific job

The **north star metric** expresses a recurring form of customer value that matters to your product strategy. It helps teams align their work around an outcome they can influence.

An **activation metric** measures whether an eligible new customer reaches a defined early outcome within a specified period. It gives onboarding and acquisition teams a nearer-term signal to investigate and improve.

A **retention metric** measures continued or repeated use, or continuation of the commercial relationship, for a defined starting cohort. Product-use retention, customer renewal and revenue retention answer different questions. Keep their names and definitions distinct.

A **KPI** is any important performance indicator used to manage the business or a team. The north star can be a KPI; many other KPIs remain necessary. Cash collection, service reliability, support burden and acquisition cost do not become unimportant because you chose a product-value metric.

Amplitude's [north star checklist](https://amplitude.com/books/north-star/the-north-star-checklist) ties the metric to customer value, strategy, measurability and actionability. Treat the connection to business success as something to investigate in your product, rather than a guarantee conferred by the label.

## Begin with the customer outcome you can observe

For a reporting SaaS, the customer might want a reliable view of performance before a recurring team meeting. A login is weak evidence of that outcome. A successfully generated report that a person actually views is closer, although it still does not prove the report improved a decision.

A candidate north star could be **weekly reporting workspaces**: distinct eligible workspaces in which a human member views at least one successfully generated, non-empty report based on a supported live data source during the calendar week.

That definition has several deliberate choices:

- It counts workspaces because the example product delivers shared value to teams.
- It requires a usable report, so empty previews and failed generation jobs do not qualify.
- It requires a human view, so unattended background generation alone does not count.
- It counts each workspace once per week, so one heavy user cannot inflate the number indefinitely.
- It uses a weekly cadence because the example use case is recurring weekly reporting.

These are assumptions for the example, not a universal SaaS definition. A solo writing tool may need a person-level measure. A payroll product may deliver value on a monthly or fortnightly cycle. An API product may deliver value entirely through automated use, making a human-view requirement inappropriate.

Use customer conversations and observed workflows to assess whether the proposed action represents value. The guide to [identifying key customer journeys](https://www.martechdevs.com/blog/identify-key-customer-journeys) provides a way to connect that qualitative evidence to the instrumented journey.

## Choose a cadence that matches the job

Do not select daily activity simply because the analytics tool makes it easy to display. A customer who successfully completes a monthly task may have no reason to return tomorrow.

Inspect the intervals between meaningful actions among repeat users, then compare them with the workflow customers describe. Amplitude's [usage-interval documentation](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret-usage) measures the distribution of users' median intervals for selected events. It includes users who perform those events on at least two different days.

That inclusion rule matters: the chart describes repeat users in its eligible set. It does not explain everyone who signed up and never reached a second day of use. Use it to investigate cadence alongside cohort retention and customer research.

If the product supports both weekly operators and occasional auditors, inspect those use cases separately. A blended interval can be a poor description of either group. Keep the top-level metric understandable, with segments that explain meaningful differences.

## Build an activation hypothesis from the path to value

For the reporting example, a candidate activation event is the first qualifying report view within seven days of workspace creation. Connecting a data source is a necessary setup step, but it may not be sufficient evidence of value.

Describe the hypothesis explicitly: “Workspaces that reach a usable report during their first week are more likely to return for reporting in a later week. Reducing the obstacles to that first report may improve later use.”

The first sentence is an association to examine. The second is a causal claim to test through a product change. Keep them separate.

Start with a short list of plausible milestones drawn from the customer journey. For each, assess whether it is observable early, understandable to the team, feasible to influence and available to the intended customer population.

Reject definitions that merely restate the future outcome. “Active in week five” cannot be an early activation signal for week-five retention. Avoid selecting a complicated combination of dozens of events solely because it fits one historical dataset.

The [tracking-plan template](https://www.martechdevs.com/blog/tracking-plan) helps specify the success event and distinguish it from attempts, failures and delivery retries.

## Test the signal with non-overlapping observation windows

Choose a new-workspace cohort with enough completed observation time. In this example, measure activation from creation up to, but excluding, seven days later. Measure later qualifying use from 28 days after creation up to, but excluding, day 35.

Freeze the early activation flag at the end of its window. A report viewed on day ten does not retroactively turn the workspace into a first-week activation success.

Suppose an illustrative cohort contains 200 eligible workspaces with complete data through day 35:

- 80 activate in the first seven days; 60 of those show qualifying use in days 28 to 34.
- 120 do not activate in the first seven days; 36 of those show qualifying use in days 28 to 34.
- First-week activation is 80 / 200, or **40%**.
- Later use among early activators is 60 / 80, or **75%**.
- Later use among the others is 36 / 120, or **30%**.
- Later use across the whole starting cohort is 96 / 200, or **48%**.

The 45 percentage-point gap makes first-week activation worth investigating. It does not establish that forcing every workspace through that action will raise later use by 45 points.

Customer intent, company size, prior experience or access to the right data source may affect both early success and later use. Compare meaningful segments and check a later cohort before treating the association as stable. Keep subgroup counts visible so a striking percentage from a handful of accounts does not dominate the decision.

Also report the exceptions. Twenty early activators did not return in the later window, while 36 other workspaces did. Speak to examples from both groups. They may reveal a different use case, a delayed setup path or a success definition that needs refinement.

## Make retention semantics explicit

“Day-30 retention” can mean several things: activity on a particular day, activity in a surrounding week, or a return on that day or later within the observable period. Those definitions will not generally produce the same result.

Amplitude's [retention documentation](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret) distinguishes Return On, Return On or After and custom windows. Choose the version that answers your question and record the relevant time settings. A tool's default is not your business definition.

For the worked example, the outcome is **qualifying workspace use in the interval from day 28 inclusive to day 35 exclusive**. It is neither paid renewal nor use exactly 30 days after signup.

Only include fully observed cohorts in the simple comparison above. A workspace created ten days ago has not had an opportunity to reach day 28. Counting it as a retention failure would make recent cohorts look artificially weak. Show incomplete periods as pending, with the observation cutoff clearly stated.

Keep cancelled or deleted accounts in the original cohort where they legitimately belonged, subject to your data-retention requirements. Removing unsuccessful customers from the denominator makes retention appear stronger without changing the customer experience.

## Test a change that helps customers reach value

Once the signal looks useful, investigate the obstacle. Perhaps customers cannot identify the right permission scope for their data connector. A guided validation step could help them complete setup and reach a report.

Randomly assign eligible new workspaces to the existing flow or the proposed flow, using a unit that prevents members of the same collaboration environment from receiving conflicting experiences. If one commercial account controls several workspaces, account-level assignment may be more appropriate.

Microsoft Research's [pre-experiment guidance](https://www.microsoft.com/en-us/research/articles/patterns-of-trustworthy-experimentation-pre-experiment-stage/) explains why collaboration effects, identity stability and enterprise constraints influence the unit of randomisation. Match the analysis to the actual assignment unit.

Before launch, choose the primary outcome, the smallest effect worth acting on, the required sample and observation period, and the reliability and cost measures that must not worsen unacceptably. Use first-week activation as an early diagnostic if later use is the outcome the decision depends on.

An illustrative completed experiment might have 500 independently assigned workspaces in each arm:

- Existing flow: 200 activate and 150 show qualifying use in days 28 to 34.
- Proposed flow: 240 activate and 165 show qualifying use in days 28 to 34.
- Activation rises from **40% to 48%**, an eight percentage-point difference.
- Later use rises from **30% to 33%**, a three percentage-point difference.

The later-use estimate is encouraging but imprecise. A simple fixed-horizon normal approximation for the difference between two independent proportions gives an approximate 95% interval of **−2.8 to +8.8 percentage points**. That range includes a decline as well as a useful improvement.

The calculation is `0.03 ± 1.96 × sqrt((0.33 × 0.67 / 500) + (0.30 × 0.70 / 500))`, using the standard [two-proportion interval method](https://online.stat.psu.edu/stat200/Lesson09). It assumes independent units and a preplanned fixed-horizon analysis; clustered assignment, repeated peeking or multiple primary comparisons require appropriate treatment.

Do not promise the commercial effect from the activation movement alone. Check experiment data quality, the planned decision rule and the costs of the change. Decide whether the evidence supports rollout, further investigation or a better-designed follow-up test. Avoid extending the experiment repeatedly until a preferred result appears.

## Use a small metric tree to explain movement

The north star should lead to questions teams can answer. For weekly reporting workspaces, separate newly qualifying workspaces, continuing workspaces and returning workspaces after a lapse.

These groups need explicit, mutually exclusive definitions. One approach is to classify a workspace by whether this is its first qualifying week, whether it also qualified in the previous week, or whether it qualified earlier but skipped the previous week. Their counts then sum to the weekly total.

Use diagnostics underneath: connector success, time to first qualifying report, report failures and support requests during setup. These help explain a change in the outcome without each becoming a company-wide target.

![SaaS metric tree connecting customer value to activation, retention and measured product changes](https://www.martechdevs.com/assets/blog/saas-activation-metrics.svg)

An increasing total can hide worsening retention if acquisition is growing quickly. Show cohort results alongside the north star. Conversely, a stable total can hide an improving product if fewer eligible customers entered the funnel.

For time to value, report the completion rate with the distribution. “Median time to first report is ten minutes” can describe only the successful minority while most workspaces never complete it. State who the median includes and show the proportion of the full eligible cohort completing by relevant time thresholds.

## Add guardrails against gaming and hidden cost

Ask how a team could improve the chosen number while making the product worse. This is a practical review exercise, not an accusation.

If report generation counts, a background job could create more reports nobody uses. If invitations count, onboarding could force users to invite people who have no reason to join. If sessions count, a broken workflow could produce repeated visits.

For the reporting example, useful checks could include generation failures, data freshness, support requests, customer-reported usefulness and the compute cost per qualifying workspace. Track commercial outcomes separately, including paid conversion and renewal where relevant.

Do not add a new metric for every possible concern. Select the checks that could realistically reverse your decision. Define what movement would trigger investigation and who will respond.

## Write the metric once in a shared specification

Different tools can implement the same business definition only when its edge cases are explicit. Keep a versioned specification linked to the event contract and the model that calculates it.

Here is a copyable definition for the example activation rate:

```yaml
metric_id: workspace_activation_7d_v1
name: First-week workspace activation rate
owner: Product analytics owner
unit: Workspace
cohort_entry: Workspace creation timestamp
population: New production workspaces in the weekly-reporting use case
exclusions: Employee, test, demo and migration-created workspaces

qualifying_outcome:
  event: Human Report Viewed
  requirements:
    - Report generation succeeded
    - Report is non-empty
    - Report uses a supported live data source
    - Viewer is a human member of the workspace

activation_window:
  start: Creation timestamp, inclusive
  end: Creation timestamp plus 7 days, exclusive
  time_basis: Elapsed UTC time

numerator: Distinct eligible workspaces with a qualifying outcome
denominator: All eligible workspaces in fully observed cohorts
deduplication: Count each workspace once
minimum_observation: Full 7-day window plus documented ingestion allowance
late_data: Restate affected cohorts and retain the refresh timestamp

validation_outcome:
  name: Qualifying use in days 28 to 34
  start: Creation timestamp plus 28 days, inclusive
  end: Creation timestamp plus 35 days, exclusive
  minimum_observation: Full 35-day window plus ingestion allowance

refresh: Daily after upstream completeness checks
known_limit: A report view is a proxy for customer value
```

The seven-day and 35-day windows are example choices. Replace them when your product's use cycle or sales motion requires different windows. Set the ingestion allowance from observed delivery behaviour and document how corrected data changes previously reported cohorts.

Build a few controlled examples that every implementation must match: a qualifying action just before the deadline, one exactly at the excluded boundary, two repeated actions, an employee workspace and an account with no action. If the dashboard and warehouse disagree, these cases help locate the definition that differs.

Give an AI assistant the metric ID, version, relevant model and freshness information when asking it to analyse performance. The [AI-ready marketing data guide](https://www.martechdevs.com/blog/ai-ready-marketing-data) explains the broader context layer. A language model cannot resolve an undefined denominator by phrasing the answer confidently.

## Metric review checklist

- [ ] The customer outcome and intended use case are clear.
- [ ] The north star measures an observable proxy for recurring value.
- [ ] The counting unit matches how the customer receives that value.
- [ ] The cadence reflects the job customers need to complete.
- [ ] Activation has a defined population, deadline and qualifying event.
- [ ] The later validation outcome uses a separate observation window.
- [ ] Incomplete cohorts are distinguished from unsuccessful customers.
- [ ] Rates are shown with counts and meaningful segments.
- [ ] Observational associations are distinguished from experiment effects.
- [ ] Experiment assignment and analysis use compatible units.
- [ ] Financial, reliability and cost checks can expose harmful optimisation.
- [ ] Every tool uses the same versioned definition and controlled examples.

Start by reviewing one recent, fully observed cohort against this checklist. It will usually make the next measurement task concrete: fix an event, clarify eligibility, separate a use case or investigate a customer obstacle. If the definitions are agreed but the tools disagree, our [product analytics implementation work](https://www.martechdevs.com/product-analytics) can connect them to a consistent, testable model.

## Frequently asked questions

### What is a north star metric?

It is a shared product metric intended to represent recurring customer value and focus the team's improvement work. Choose an observable definition connected to your strategy, then investigate how it relates to retention and business results. Keep financial and operational KPIs alongside it.

### How is a north star metric different from an activation metric?

The north star describes recurring value across the relevant customer base. Activation describes an early qualifying outcome for a new-customer cohort within a deadline. The same type of action can contribute to both, but their populations, windows and business questions differ.

### What is a good activation rate for SaaS?

A percentage is only comparable when eligibility, event meaning, observation window and customer use case are comparable. Establish a trustworthy baseline for your product, investigate meaningful segments and test improvements against later outcomes. A borrowed benchmark cannot tell you whether your own activation definition represents value.

### Does a strong correlation with retention prove the activation event causes it?

No. Customer intent, experience and other factors can influence both behaviours. Use the relationship to form a hypothesis, inspect exceptions and test a change that helps customers reach the outcome. Measure the later result using a design appropriate to the product.

### Can we change our north star metric later?

Yes, when the strategy or evidence justifies it. Record the reason, preserve the previous definition and show how the new one differs. Where possible, calculate both over an overlap period. Do not silently rewrite the definition to make a target easier to meet.

## Sources

1. Amplitude, [The North Star checklist and statement exercise](https://amplitude.com/books/north-star/the-north-star-checklist), accessed 1 October 2026.

2. Amplitude, [Interpret your Retention Analysis chart: Usage interval](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret-usage), documentation accessed 1 October 2026.

3. Amplitude, [Interpret your retention analysis](https://amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-interpret), documentation accessed 1 October 2026.

4. Microsoft Research, [Patterns of Trustworthy Experimentation: Pre-Experiment Stage](https://www.microsoft.com/en-us/research/articles/patterns-of-trustworthy-experimentation-pre-experiment-stage/), 2020.

5. Penn State, [Inference for Two Samples, STAT 200](https://online.stat.psu.edu/stat200/Lesson09), course reference checked 1 October 2026.