Which User Engagement Metrics Show Real Use?

The monthly dashboard says more people are active. The product team has also watched sign-ins rise. Yet customers still ask why their teams are not getting much from the product. That disagreement is familiar because opening an app is easy to count, while completing the job that brought someone there takes more thought to define. A useful engagement report should answer both questions: how many people reached the product, and how many did something worth returning for?

I would begin with the second question. Pick a recognizable action that represents progress for the user, then measure its reach and repetition among people who could reasonably take it. Keep visits and session measures nearby, but give them a supporting role. This choice costs some simplicity: a single headline number will no longer stand in for every kind of use. It gives the team a better basis for deciding whether to improve access, teach a feature, remove friction, or change the product itself.

Define “active” around a job the user came to do#

An active user is someone who met a chosen activity rule during a stated interval. Change the rule or the interval and the count changes. Google Analytics, for example, has its own definition of an active user based on engagement with a site or app; that platform count is useful for understanding reach, but it is not a universal definition of product value. Google explains how its active-user metric is populated. A product team can define a narrower count around an action that fits its service.

Imagine a reporting product in which an editor assembles a report and publishes it for colleagues. All numbers in this example are illustrative. Suppose 1,000 editors had access during a month, 600 opened the product, and 240 published at least one report. “Monthly users who opened the product” is 600; “monthly editors who published” is 240. Both counts are correct under their definitions. Only the latter tells us how many editors completed the particular job we chose to watch. The 240 are 24% of eligible editors, or 40% of editors who opened the product. Those percentages answer different questions, so the denominator belongs in the sentence whenever the result is shared.

The event should be specific enough to mean something. A generic click on “Publish” may include failed submissions; a successful publish event should mark the completed action. The event also needs an owner and a unit: are we counting unique editors, reports, or publishing attempts? If one editor publishes twelve reports, that is one publishing editor and twelve completed reports. Neither figure can replace the other. The first tells us reach; the second tells us volume. If reports can be published automatically, decide whether automation belongs in the same count before calling it editor engagement.

There is no perfect value event for every product. A publishing action may matter to an editor, while a reader may get value by viewing the finished report. I would keep separate definitions for those roles rather than forcing readers and editors into one “active” metric. The test is whether a person familiar with the user’s job can look at the event and say what the user accomplished. If the team cannot answer that question, changing a chart will not make the count more informative.

Use active users and engagement rate to locate the gap#

Reach measures still matter. Daily, weekly, and monthly active users show how many unique people qualified under the selected activity rule within each window. They help locate a change in participation, especially when the same rule and population are used from period to period. For the reporting product, I would show both editors who opened the product and editors who published a report. If openings grow while publishing editors stay flat, more people are arriving without completing the chosen job. That pattern suggests a question about what happens between opening and publishing; the counts alone cannot tell whether the obstacle is confusing setup, lack of data, or simply no report due that month.

Google Analytics engagement rate answers a different question. It is the share of sessions classified as engaged by Google’s criteria, which include session duration, a key event, or multiple page or screen views. It is a session measure, so a rise in engagement rate does not itself show that more distinct editors published reports. Google’s engagement-rate definition is useful when reading the platform dashboard, but the product decision still needs the relevant action and eligible population. I would use engagement rate to notice whether visits are becoming more involved, then look at completed work before describing that change as stronger adoption.

The difference is practical, not semantic. A person can spend time searching for a missing setting and qualify as engaged in a session measure. Another person can open a report, get the needed answer quickly, and leave. Depending on what each person came to do, the shorter visit may be the better product experience. Time and session measures become more helpful when paired with a named task, such as time from opening an editor to successfully publishing. Even then, a shorter interval could reflect an easier task rather than an improved interface. Read the count alongside the work being done.

Retention shows whether the same people return#

A monthly active-user line can rise while the people behind it keep changing. New editors may replace editors who stopped publishing, leaving the total apparently healthy. Retention gives that turnover a visible shape. Start with a group of people who completed a specified entry action in a specified period, then ask what share completed a specified return action later. Adobe’s retention guide describes that separation between the start event and return event, and shows the original group as the denominator for later periods. Adobe’s retention analysis documentation also distinguishes returning in an exact period from returning on or after a point in time.

For the illustrative reporting product, take the 240 editors who first published in one month. If 120 of those same editors publish in the next month, next-month publishing retention is 120 divided by 240, or 50%. If 90 publish in the following month, that period’s rate is 90 divided by the original 240, or 37.5%. The rate does not use that later month’s entire active population as its denominator. It follows the same starting people, which is precisely why it can reveal a loss hidden by new arrivals.

The return action should match the claim. Returning to the homepage measures a different kind of persistence from publishing another report. I would choose the latter if the question is whether editors keep doing reporting work. I would also choose a month rather than a day if the underlying job is monthly reporting. A daily retention chart for a monthly task makes ordinary usage look like abandonment. A daily cadence could be appropriate for a product whose intended job is daily; the interval should follow the job, not a dashboard default. Mixpanel’s discussion of retention makes the same practical point: the meaningful action and expected usage interval determine what a return means.

Compare entry groups when a product or its audience changes. One cohort may have joined before a new publishing flow; another may have joined after it. Showing their later return rates side by side is more informative than blending them into a single overall rate. The comparison still does not establish why the curves differ. The groups may also differ in role, acquisition channel, or reporting needs. I would use the difference to decide where to investigate, then check what actually changed for those editors. Mixpanel’s cohort example illustrates how behavior-defined groups can be compared over time, but the event that places people in a group must stay visible when interpreting the result.

Frequency and stickiness need the right cadence#

Once you know who returns, ask how often they complete the chosen action. Event frequency counts repeated actions within a declared period. In the reporting example, four successful publishes by one editor in a month could reflect four separate reporting jobs. Four attempts to publish the same report after an error would indicate a different experience. Count successful completions separately from attempts and failures. Amplitude’s discussion of feature-use frequency shows how repeated events can be examined by user; it does not make every repeated event a sign of value.

Stickiness compares participation in a short window with participation in a longer one. Google Analytics, for instance, reports daily active users divided by monthly active users and related daily, weekly, and monthly ratios. Google’s user-stickiness definition describes those windows. If the same activity rule produces 100 daily active users and 400 monthly active users, the illustrative DAU/MAU ratio is 25%. It means that the day’s qualifying users are a quarter of the month’s qualifying users. It does not mean that each monthly user was active on a quarter of the days.

I would use stickiness when frequent use is part of the intended experience. A collaboration tool used for daily coordination may benefit from a daily-to-monthly view. A monthly reporting workflow may not. Raising its DAU/MAU ratio by prompting people to open the product every morning could improve the ratio without improving reporting. For the reporting product, a more direct measure is whether eligible editors publish when their next report is due. The right window depends on when the user has reason to return.

Frequency also needs a distribution, not just an average. In an illustrative month, ten editors could publish ten reports each while ninety editors publish one each. That is 190 reports from 100 editors, an average of 1.9 reports per publishing editor. The average hides two very different patterns of use. Looking at how many editors published once, twice, or more often helps separate broad participation from concentration in a few heavy users. The same distinction becomes consequential when one person’s work makes an entire customer account appear active.

Feature adoption starts with who can use the feature#

Feature adoption asks whether eligible people actually use a specified capability. The numerator needs an event that shows use, and the denominator needs people who had the chance to use it. Amplitude describes feature adoption through unique users who perform a tracked feature event and the share of active users who do so. Its feature-adoption example follows that share over time. For a product team’s own decision, “active users” may still be too broad a denominator if only a subset has access or a relevant role.

Suppose the reporting product adds scheduled delivery, but only 200 of its 1,000 editors have permission to configure it. If 50 of those 200 configure a schedule, adoption among eligible editors is 25%. Dividing 50 by all 1,000 editors produces 5%, a different answer driven largely by access. Neither number says whether scheduled reports were delivered successfully or whether recipients used them. If the product question is whether scheduling saves editors a recurring task, I would follow configuration with successful delivery and later use. The first-use count says the feature was tried; continued successful use says more about whether it found a place in the workflow.

Keep exposure separate as well. Editors who saw an announcement, editors who could use the capability, and editors who used it are three distinct groups. A small use count among people who never had permission should not be blamed on the feature design. A small use count among eligible editors who repeatedly encounter the option raises a different question: perhaps the feature is hard to understand, perhaps the current manual workflow is adequate, or perhaps the need is rare. An adoption percentage identifies where to ask; it cannot choose the explanation by itself.

The cost of this precision is that access rules and roles must be kept up to date. That work is justified when a team might otherwise spend months changing a feature for people who could never use it. I would postpone an adoption target until the denominator is clear. A target built on an undefined population is easy to move by changing permissions, even if no user’s experience improves.

Read individual use beside account use#

For a product sold to organizations, individual users and customer accounts answer different questions. Imagine one customer account with twenty eligible editors. If only one editor publishes every report, that account is active, yet use is concentrated in one person. Another account may have ten editors each publish once. Counting active accounts treats these situations alike; counting publishing editors reveals the difference. Conversely, a single large account can supply many active users while most other accounts do nothing. I would show both levels when deciding whether adoption is spreading across customers and within each customer.

The distinction matters even more when discussing retention. An editor returning next month is a retained user under the chosen product definition. An organization continuing to pay is a continuing customer. One can occur without the other. Adobe’s retention method follows users who take selected actions; it does not convert their return into a measure of continuing payments. If a team needs to judge commercial retention, it must look at the paying customer population separately. Product use may help explain a change in that population, but it is not the same count.

Account aggregation is still useful. An organization may care that at least one report was delivered, regardless of which editor did the work. The better choice depends on the decision. For onboarding, I would look at how many invited editors complete their first publish. For account health, I would look at whether the account has recurring completed reports and whether work depends on one person. For a feature intended only for administrators, I would judge uptake among administrators, then consider whether the account receives the intended outcome. Each view keeps the actor and denominator attached to the claim.

Let disagreements between metrics guide the next decision#

Engagement metrics become useful when they disagree in a way that suggests a concrete next question. If opening editors rise while publishing editors and successful reports stay level, examine the path from opening to publishing and the share of editors who had a report to make. If first-time publishing rises but the same entry cohorts seldom publish again when the next report is due, look at whether the first report was useful and whether the next job ever arose. If scheduled-delivery adoption is high while manual publishing attempts also rise, check whether schedules are failing, duplicating work, or serving a different reporting need. These are interpretations to test against the actual product, not automatic conclusions from a chart.

I would keep a compact set of definitions beside the dashboard: the action that qualifies a user as active, the people eligible to take it, the observation window, the cohort entry and return actions, and whether the count is for people or accounts. Then I would show the few measures that answer the current decision. For the illustrative reporting product, that could mean eligible editors, editors who published, reports successfully published, next-month publishing retention for new publishers, and accounts with recurring completed reports. Add session engagement or DAU/MAU only when the question genuinely concerns visit quality or short-window recurrence.

The judgment is simple: user engagement is strongest when people complete the job they came for and return when that job arises again. Active-user counts, engagement rate, stickiness, frequency, and feature adoption each show part of that pattern. Their value comes from a stated action, population, and interval. Without those three, an improving number can describe more traffic, more retries, or a change in who was counted. With them, the same numbers can point to a decision a product team can actually make.