Retention reports show whether users who performed one event came back and performed another event later. Use them to understand repeat usage after activation, onboarding, or feature discovery.


Create a retention report

  1. Open Analytics.
  2. Choose a project and board.
  3. Select New chart.
  4. Choose Retention as the report type.
  5. Select the initial event.
  6. Select the returning event.
  7. Choose the date range.
  8. Save the chart to your board.

Choose the initial event

The initial event defines the starting cohort. Examples include signed up, completed onboarding, viewed a tour, used a feature, or started a trial.


Choose the returning event

The returning event defines what counts as retained behavior. It can be the same event or a different event. For example, you can measure users who signed up and later returned to use a key feature.


Filter retention data

Use filters when you only want to analyze a specific audience or behavior. You can filter by event properties or user properties such as plan, country, campaign, role, or device.


Add a breakdown

Breakdowns let you compare retention across groups. Use them to answer questions like whether retention differs by plan, signup source, feature used, or region.


Read the table

Retention can be displayed as percentages or raw counts. Percentages help compare cohorts of different sizes. Raw counts help you understand absolute volume.

Example: return usage after activation

Choose an initial event that represents first value, such as a configured project_created action, and a returning event that represents useful repeat behavior, such as a configured project_updated action. These are example event names; create and validate the matching actions in your own installation.

  1. Verify both events and their user identities in Live Events.
  2. Select the initial and returning events in a Retention report in the same Analytics project.
  3. Use a date range that contains the starting activity and allows enough time for the return behavior you want to study.
  4. Read both the percentage and the underlying cohort size. A change based on a handful of users deserves a different interpretation from the same change across a large cohort.
  5. Compare cohorts using a relevant property only after confirming that property is present and consistently populated.

Do not interpret a recent cohort as having failed to return before its observation period has elapsed. Also check identity changes, tracking changes and environment mixing before attributing a retention change to the product. Keep the event definitions consistent when comparing releases or onboarding changes.

Was this helpful?