Engagement rate is the share of users who, in a given period, performed an action in the product that counts as valuable. In a SaaS product it is calculated as the number of unique active users divided by the number of everyone who had access to the product. The result depends on how “activity” is defined, so the definition has to be set before the first measurement.
What engagement rate is
The metric answers the question of what share of users actually use the product and what share merely have an account. The general formula is simple:
engagement rate = users who performed the action ÷ users who could have performed it × 100%
The numerator and denominator count people, not events. The correctness of the whole calculation depends on this rule, as the first example shows.
How engagement rate in GA4 differs from the metric in a product
Two different measures go under the same name. In Google Analytics 4, engagement rate is the share of engaged sessions. According to Google’s documentation, a session is engaged if it lasts longer than 10 seconds, contains a key event, or has at least 2 page or screen views. In GA4 the bounce rate is the inverse of this value.
This definition works for websites and marketing pages. In a SaaS product it says little, because a logged-in user almost always spends more than 10 seconds in the application. A product team needs its own definition, based on an action that gives the user value: an invoice issued, a ticket closed, a lesson completed. Why regular use matters so much in a subscription model is explained in the post on what SaaS is.
How to measure engagement in a SaaS product
- Share of active users: unique users who performed the chosen action in the period, divided by everyone with an active account.
- DAU/MAU: the average number of daily active users divided by the number of monthly active users. It shows for what part of the month the average user uses the product.
- Frequency of use: the number of sessions or days with activity per user per month.
- Feature usage: the share of active users who used a given feature. It is useful for judging whether a new feature has been noticed.
- Funnel steps: the share of users moving from one stage of a process to the next.
Time spent in the application is a misleading measure. In a work tool, a long session may mean the task is hard to complete.
Example 1: engagement with a new course
A SaaS service with online courses publishes a new course and checks how users engage with it. Data from the first month:
- 5,000 users viewed the course page,
- 2,500 started the course,
- 1,500 completed at least one lesson,
- 800 took part in the quiz.
A common mistake is to add up the events: 2,500 + 1,500 + 800 = 4,800 and divide by 5,000 views, which gives 96%. This result is false, because the same person who started the course, completed a lesson and took the quiz was counted three times.
The correct calculation counts people at each step separately:
| Step | Users | Share of those who viewed the course | Share of the previous step |
|---|---|---|---|
| Course view | 5,000 | 100% | |
| Course start | 2,500 | 50% | 50% |
| Completing at least one lesson | 1,500 | 30% | 60% |
| Taking the quiz | 800 | 16% | 53% |
If engagement is defined as completing at least one lesson, the course’s engagement rate is 1,500 ÷ 5,000 = 30%. The table also shows where to look for improvement: half of the people who saw the course did not start it at all, so the first issue is the course page, not the quiz.
Example 2: frequency of use and DAU/MAU
A SaaS application has 10,000 monthly active users (MAU). The number of logins over 30 days is distributed as follows:
- 2,000 users logged in once (20%),
- 3,000 users logged in 2 to 10 times (30%),
- 5,000 users logged in more than 10 times (50%).
An average cannot be calculated from ranges alone, so a value has to be assumed for each group. Assuming an average of 6 logins in the middle group and 12 in the most active group, the calculation looks like this:
(2,000 × 1 + 3,000 × 6 + 5,000 × 12) ÷ 10,000 = 80,000 ÷ 10,000 = 8 logins per user per month
The result depends on the assumptions made, especially in the open-ended “more than 10” group. An exact average comes only from the sum of all logins in the source data divided by MAU. The distribution itself says more than the average: one user in five logged in only once, and that is the group to start the analysis with.
The second measure of frequency is DAU/MAU. If the same application has an average of 2,300 daily active users, then DAU/MAU = 2,300 ÷ 10,000 = 23%. The average user therefore uses the application on about 7 days out of 30. Whether that is a lot depends on the product: a system for handling orders every day should have a much higher value than a billing tool used once a month.
What mistakes distort engagement rate
- Events instead of people. Adding up interactions inflates the result, as example 1 showed.
- Logging in as activity. Opening the application does not mean a task was completed. A better basis is the action the customer pays for.
- Changing the definition midway. A metric calculated differently in two quarters is not suitable for comparison.
- One number for all roles. An administrator and an end user use the product at a different pace. A metric calculated across both hides a decline in one of the groups.
- Comparing with someone else’s benchmark. A value from another product, calculated to a different definition, is not a reference point. The reference point is your own result from a month ago and a year ago.
A drop in engagement usually precedes a customer leaving. That is why engagement rate is analysed together with retention and churn, described in the post on user retention metrics, and with the satisfaction measures described in the post on NPS, CSAT and CES.
Measuring engagement in the Analytics and performance service
A number alone does not say why users stop using the product. In the Analytics and performance service we check whether measurement is complete, we combine the metrics with session recordings and conversion on the most important journeys, and the result is a list of changes ordered by implementation sequence. For session recordings we draw on the fact that Squares is a Hotjar partner.
Frequently asked questions
How do you calculate engagement rate?
The number of unique users who performed the chosen action in a given period is divided by the number of users who could have performed it, then multiplied by 100%. The numerator and denominator count people, not events. Example: 1,500 people completed a lesson out of 5,000 who viewed the course, so the metric is 30%.
What engagement rate is good in a SaaS product?
There is no single value. The result depends on how activity is defined and on the rhythm of work with the product: a system for handling orders every day should have a much higher DAU/MAU than a billing tool used once a month. The reference point is your own result from a month ago and a year ago, not a benchmark from another product.