Power Users Return for a Specific Job

A product dashboard has a tempting answer to the question “Who are our power users?”: sort people by sessions and take the top row. The names are easy to find. The harder question is whether those people are repeatedly getting the job done that the product exists to help them do. Someone can open an app every morning because a workflow is valuable, because a task is confusing, or because a reminder keeps pulling them back to an unfinished task. Session count cannot tell those stories apart.

For a product team, a power user is best treated as a person who repeatedly completes a meaningful workflow within a relevant period, among people who had a real opportunity to use that workflow. That is a working definition, not a universal industry cutoff. It makes the label useful: the team can say which action matters, why the period fits the job, and whose behavior is being compared. The definition also prevents a quiet change in meaning when a chart goes from individual people to customer accounts.

The practical call is to start with the work, then choose the activity measure. If a report is meant to be produced every week, a person who produces it on four successive weeks may be a stronger power user than someone who checks the dashboard daily but never finishes one. The first person demonstrates repeat use of the intended workflow; the second demonstrates attention to the product. Those are different observations, and each can be useful for a different decision.

Start with the job a user comes back to finish#

Imagine a reporting product used by analysts, managers, and account administrators. An analyst builds a report; a manager reads its findings; an administrator manages access. If the team calls all three people power users whenever they log in often, the label says little about what makes the product valuable. The administrator might visit on many days during setup and rarely afterward. The analyst might do substantial work once a week. The manager might use a finished report without ever touching the report builder.

Before choosing a threshold, name the workflow and the person eligible to perform it. For report creation, the population might be analysts with access to the builder, and the meaningful action might be publishing a report. For report consumption, the population and action would be different. It is reasonable to keep both views, but they should have separate names. Otherwise a rise in “power users” could reflect a new mix of roles instead of a change in how any role uses the product.

The action needs to represent enough progress to matter. A page view, login, or opened editor may be an entry point to a workflow, but none shows that the work was completed. A published report is a better candidate if publishing is the intended outcome. In another product, the meaningful point might be sending an invoice or completing a lesson. The precise event is a product judgment, and it should be stated plainly enough that a reader can challenge it. If the event merely records that someone arrived, the power-user label will overstate what the data shows.

This choice has a cost. A completion event will usually include fewer people than a broad activity event, and some legitimate work may not be captured if the workflow ends outside the product. That is preferable to pretending every visit has equal meaning. Where the completion is outside the product, say so and use a narrower claim: these people repeatedly reached the last recorded step. The missing outcome would need to be observed before calling the behavior successful completion.

Frequency matters only after “active” has a meaning#

Google Analytics describes user stickiness through ratios of daily, weekly, and monthly active users: DAU/MAU, DAU/WAU, and WAU/MAU. Its daily, weekly, and monthly counts use the last 24 hours, seven days, and 30 days respectively. The ratios compare activity across those windows; they do not specify which product action should count as meaningful activity. Google’s user stickiness guide makes the time comparison clear. A product team still has to decide whether “active” means any visit or a defined workflow event.

Suppose an illustrative reporting product has 1,000 eligible analysts active at least once in a 30-day window and 200 active in the last 24 hours. Its DAU/MAU ratio is 200/1,000, or 20%. Now suppose only 80 of those 200 daily users publish or revise a report. The 20% ratio tells us about the defined active-user counts; it does not tell us that 200 people completed report work that day. If the team silently swaps “opened product” for “published report,” it has changed the question while keeping the same chart label.

Daily use is also the wrong default for a job that naturally happens weekly or monthly. A person who prepares a report every Friday can be consistent without appearing in a daily active count on Monday. Conversely, a daily visitor may be checking whether someone else has finished a report. Choose the interval from the expected rhythm of the job: a week for a weekly task, a month for a monthly close, or a shorter period when the work itself recurs more often. If the rhythm is unknown, examine the spacing of meaningful events before choosing a “frequent” cutoff. The cost of waiting for that information is a slower label; the benefit is that the label will describe the work rather than an arbitrary calendar habit.

Nor should the highest stickiness ratio automatically become a target. A high ratio can indicate frequent engagement under the configured definition, as Google explains, but frequency alone cannot establish user value or why someone returned. For the reporting product, the better question is whether people repeatedly reach the report outcome at the cadence their role calls for. A daily ratio can remain useful as context, while the power-user definition lives closer to the workflow.

Make the power-user rule reproducible#

A behavioral cohort is a group selected by recorded actions within a time window. Amplitude’s documentation gives event rules such as completing checkout twice in the previous week and notes that cohorts based on those rules can be used in charts. Amplitude’s behavioral cohort guide supports that mechanics. A power-user cohort can use the same form: eligible people who perform a specified meaningful event a specified number of times in a specified period.

For the imagined reporting product, one candidate rule might be: an analyst with builder access who publishes at least one report in each of four consecutive weeks. Another might be: an analyst who publishes a report in two of the last four weeks and revises an earlier report at least once. These are illustrative rules, not recommended benchmarks. The first rewards regular production; the second recognizes an iterative job. Which rule is better depends on how this product is meant to be used. If report publishing is rare but revision is central, the first rule would exclude many people who may be doing substantial work.

Write the rule in ordinary language next to the chart. Include the event, the eligibility condition, the time window, and how repeated activity is counted. “Four reports in four weeks” is not the same as “a report in each of four weeks”: someone can publish four reports on one day and then never return. Decide whether repeated work across separate periods matters. If it does, make that requirement explicit. Also decide what happens when a person joins halfway through the window. A new analyst who has only been eligible for one week should not be treated as a four-week failure.

The event and time rule are part of the definition, so changing either changes cohort membership. That is a feature when the definition improves, but it creates a comparison problem. If last quarter’s cohort used any report opening and this quarter’s uses publishing, a lower count is not by itself a decline in power use. It may be the expected result of a stricter rule. Keep the earlier rule and period visible whenever a revised chart is discussed. A team can then compare behavior under one stable definition before drawing a trend from the numbers.

A return is useful when it is a return to the right action#

One completed action can signal initial success; repeated completion shows that the person came back to the job. Retention analysis makes that distinction concrete. In Amplitude, a retention chart starts from a specified event, checks for a specified return event, and measures the interval between them. The selected return event determines what counts as retained in that chart. Amplitude’s retention analysis guide describes those choices.

For the reporting example, starting with a first published report and looking for another published report in a later week answers a more focused question than starting with sign-up and looking for any later visit. The latter can still answer whether people return to the product. It cannot say they returned to create reports. If the team wants to understand sustained reporting work, it should use a return event that matches that work. If the team wants to understand reading or sharing reports, it should define a separate return event for that behavior.

The interval changes the interpretation too. A report published again the next day may reflect one project stretched over two days. A report published in a later reporting cycle may indicate that the product fits a recurring job. Neither is intrinsically better; the decision depends on what recurrence means for this product. An analyst whose job is to publish one monthly report should not be judged against a seven-day return rule. If the team cannot yet describe the normal cycle, it should avoid a confident “power user” claim and first learn when the job recurs.

Even a well-chosen return event has limits. The chart records actions, not the usefulness of the finished report. It cannot reveal whether the analyst was pleased with the process or whether the manager acted on the result. The defensible statement is specific: these eligible analysts published again within the chosen interval. A stronger claim about the value of their work needs information beyond this action log.

In a shared account, count people and accounts separately#

The person who does the work is not always the unit the business wants to understand. Amplitude’s account-level reporting groups activity by an account or other declared entity, while its default reports describe individual users. Its documentation gives cases where different people in one group complete different steps of a workflow. Amplitude’s account-level reporting guide explains this distinction. A customer account can therefore look active even when no single person performs every step.

Return to the imagined reporting product. One analyst builds a report, a manager reads it, and an administrator changes permissions. At the account level, the customer has touched several parts of the workflow. At the individual level, each person has a different pattern. If the team is deciding whom to invite into a report-builder study, it should find the analysts who repeatedly build reports. If it is deciding which customer accounts use reporting across roles, it should examine accounts and the distribution of work inside them. Calling the whole account a “power user” hides who actually uses the feature.

An illustrative account with ten active members and one repeated report publisher is not equivalent to an account with ten active members and five repeated publishers. Both may satisfy an account-level condition of “at least one publisher,” yet the breadth of use differs. That difference could matter when deciding whether to improve the builder for a specialist or make reporting easier for more members. The counts alone do not settle that product choice, but they tell the team which question to ask next.

Choose the unit before computing a rate. “Twenty power users among 100 eligible people” and “twenty power accounts among 100 eligible accounts” both equal 20%, but they describe different populations. Mixing a person numerator with an account denominator gives a number with no clear interpretation. For products with shared work, it is often useful to keep both views side by side and name each one: repeated publishers, and accounts with repeated publishing activity.

Compare power users without mistaking selection for an effect#

Once a rule is stable, comparison can reveal what is distinctive about the group. Amplitude’s cohort comparison can show overlap, user properties, retention, average events, and active counts for defined cohorts or an active-user baseline. Amplitude’s cohort comparison guide describes these views. They let a team ask, for example, whether repeated report publishers also return for later work more often than other eligible analysts under the same observation period.

The comparison needs a fair population. If one group consists of analysts with builder access and the other includes managers who cannot publish, a difference in publishing says little about product behavior. Likewise, a cohort of people who joined six months ago has had more chances to return than a cohort of people who joined last week. Keep eligibility, role, and time opportunity visible. Compare like workflows over like periods before treating the gap as useful product information.

Selection remains even after those choices. People who repeatedly publish reports may differ from occasional publishers in workload, responsibility, or reasons for using the product. If they later return more often, that does not establish that publishing caused the return. The safer reading is that the behaviors occur together among the defined groups. That observation can guide a closer look at the workflow, but it should not be turned into a promise that forcing another person to publish will make them a power user.

Consider an illustrative cohort comparison: 60 of 100 eligible repeat publishers publish again in the following month, while 90 of 300 other eligible analysts do so. The observed rates are 60% and 30%, with denominators stated. This would be a useful difference to discuss. It would not prove a product mechanism, and it would not show whether the repeat publishers created better reports. Before making a product change, the team would need to understand what made the work recur, where occasional publishers stopped, and whether the same report task was available to both groups.

Use the label to make a product decision#

The power-user label earns its place when it changes an action. If repeated report publishers struggle at the final publishing step, improving that step may help the people already doing the core job. If occasional publishers complete one report and then have no recurring assignment, a campaign pushing them to publish every week may be poorly aimed. The right response depends on the work available to them, not on a desire to lift a cohort count.

One useful decision is whom to learn from. People who repeatedly complete the workflow can describe which parts they rely on and what still costs them effort. People who tried once and did not return can describe a different path. The event data selects relevant groups; it does not supply their reasons. A team should keep the questions separate: what the recorded actions show, and what the people doing the work say those actions meant.

Another decision is what to improve for new users. A stable power-user cohort can show the sequence of recorded actions associated with repeated work. That sequence is a candidate path to make clearer, not a script every new user must follow. If a step is performed only by administrators, putting it into an analyst’s onboarding would confuse roles. If a recurring action is performed because the existing workflow is cumbersome, copying the pattern would preserve the burden. The team needs to know the job behind the clicks before promoting a frequent pattern into a product design.

The most useful working definition is therefore modest and specific: eligible people who repeatedly complete the product’s chosen job within its natural cycle. Keep the event, interval, and unit of analysis visible whenever the number is reported. Use visit frequency to understand how often people appear, cohort rules to identify repeated behavior, and return events to see whether the job recurs. Then judge the next product move by the work people are trying to finish. A power-user count is a way to locate that work; it is not a substitute for understanding its value.