DAU, WAU, MAU and stickiness

DAU, WAU and MAU count distinct users who did the qualifying action in a day, a week and a month. For Halves the qualifying action is opening the app (app_opened), so a person counts once per period however many times they opened it.

The trap is the export. As Totals, unique users and counting traps showed, an account that appears only through server-created rows hasn't been active. Halves's June user file has 140 rows, one per user mentioned anywhere in June's data, but 12 have server_only = true and zero active days in every week.

So MAU for 1–28 June is 140 − 12 = 128, not 140. Rows in a file are "accounts the data mentions"; MAU is "people who did the qualifying action".

Two more details belong in the definition. The month here is 1–28 June, four whole weeks, which makes weekly and monthly numbers line up. And the qualifying action must be the same for DAU, WAU and MAU, or any ratio between them compares two different things.

Stickiness is the share of the month's users who show up on a typical day:

DAU/MAU = average DAU ÷ MAU

DAU moves a lot day to day: 40 on Monday 1 June, when flats log the rent, and 13 on Sunday the 28th. So the formula uses the average DAU over the month, not one day's value.

There are two routes to that average, and they must agree:

• add up the dau column for the 28 days and divide by 28;
• add up every user's active days in the user file and divide by 28.

Both totals are 611, because every active user-day is one unit of some day's DAU. Average DAU = 611 ÷ 28 = 21.82. Stickiness = 21.82 ÷ 128 = 0.1705 ≈ 17.0%.

Two routes to one number is a free check on your arithmetic and on the data. If they disagree, either a day is missing from one file or the two files use different definitions of "active". Find out which before you quote the ratio.

DAU/MAU of 17% is easy to misread as "17% of our users open the app every day". That's not what it measures.

The ratio compares an average day with the whole month. On a typical June day about 21.8 of the month's 128 users opened Halves. Those 21.8 can be different people each day. In a product where everyone comes about once a week, every user can be perfectly loyal and DAU/MAU still sits near 1 in 7, about 14%.

So the ratio says how concentrated the usage is in time, not how many people are daily users. To learn the second, you'd count people active on at least, say, 20 of 28 days, a different metric.

The same caution applies to WAU/MAU. 62% means that a typical week has 62% of the month's users, not that 62% come every week. For "who comes back week after week", count it directly, for example the share of MAU active in at least 3 of the 4 weeks.

When you quote any of these ratios, name it and its period, so nobody turns an average into a headcount.

A product's natural usage rhythm is how often a satisfied user needs it. Nobody splits a dinner bill every day; flats log rent, couples add the week's shopping, groups settle up. Halves is a weekly product, so its stickiness should be read weekly too.

WAU/MAU = average WAU ÷ MAU

WAU for a week is the number of users with at least one active day in that week. From the June user file:

• week 1: 84, week 2: 83, week 3: 73, week 4: 78;
• average WAU = (84 + 83 + 73 + 78) ÷ 4 = 318 ÷ 4 = 79.5;
• WAU/MAU = 79.5 ÷ 128 = 0.6211 ≈ 62.1%.

The same month that looked weak at 17% daily looks healthy at 62% weekly. The users didn't change; the ruler did.

A common slip is to add up the four weekly WAUs and divide by MAU, which gives 248%: a person active in all four weeks is counted four times. Average the weeks first, then divide.

When a benchmark comes from daily products such as messengers or games, it doesn't compare with a weekly product. Quote the ratio that matches your rhythm, with its name.

A ratio of averages can't tell you whether the same people come back. 62% WAU/MAU could mean most users come most weeks, or a churning crowd where each week brings different people. To see a habit, count it per person.

For each of June's 128 active users, count the weeks with at least one active day (weeks with days_w above 0). Then group:

• 3 or 4 of 4 weeks: 71 users, 71 ÷ 128 ≈ 55.5% of MAU;
• only 1 week: 40 users, about 31.3%;
• 2 weeks: the remaining 17.

More than half of the month's users came in at least three of the four weeks. That's a weekly habit, and a stronger reply to a worried investor than any single ratio.

The one-week group needs a second look before anyone calls it a problem. Many of those users are in trip groups, which by design are used hard for one week. Splitting regulars by group type separates "used as designed" from "tried once and left".

Write the threshold into the definition ("active in at least 3 of 4 weeks"), because 2 of 4 would give a different number.

Split June's WAU/MAU by group type and three rhythms appear:

• couples: 87.5%, almost everyone every week;
• flats: 74%, most weeks;
• trips: 30%, about one week in four.

Trips at 30% look like a problem only if you judge them by a weekly ruler. A trip is one intense week of shared costs, then a settle-up day. A trip user active one week in four is doing exactly what the product is for.

So segments are judged at their rhythm. For trips, a fitting measure is per trip: the share of trips where the group logs expenses to the end and settles up. Pushing trip users with weekly reminders after the trip has ended would treat the design as a defect and risks annoying them into muting Halves before the next trip.

This is the mix problem from the previous lesson in a new form. One ratio for everyone blends three rhythms, and a summer with more trips would pull the overall WAU/MAU down while every segment stays healthy. Report the ratio by segment whenever the segments live on different clocks.

A product's natural usage rhythm, how often a satisfied user needs it, decides which activity measure means anything. Measure at that interval and a ratio tells you something; measure at the wrong one and a healthy product looks like a failure.

• A team chat app is needed every working day: DAU/MAU fits.
• Halves for couples and flatmates follows weekly shopping and monthly rent: WAU/MAU fits.
• Halves for trip groups is needed once per trip: measure per trip, for example the share of trips where the group logs expenses to the end and settles up.
• An app for yearly tax returns is needed once a year: measure the share of last year's filers who file again.

A daily ratio would call the last three failures, although each is doing its job.

How to find the rhythm: look at the data, not at benchmarks. Plot the gaps between a user's active days, or the share of users active in each week, and see where usage clusters. If gaps bunch at about seven days, the product is weekly; a spike and then a year of silence means yearly. Then pick that period, name it on every chart and keep it stable.

A ratio is meaningful only if numerator and denominator count the same kind of thing. For activity ratios that means the same qualifying action.

Suppose a dashboard takes MAU from any event, so the 12 server-only users join it, but takes WAU from app_opened:

• average WAU stays 79.5;
• MAU becomes 140 instead of 128;
• WAU/MAU = 79.5 ÷ 140 ≈ 56.8%, against 62.1% with one definition.

The ratio drops for a reason unrelated to users: 12 people whose bills ran on schedule count as monthly users who "didn't come back" weekly. Flip the mismatch, WAU from any event and MAU from app opens, and the ratio can even pass 100%.

The fix is boring and essential: define "active" once, with its qualifying action and exclusions, and build DAU, WAU and MAU from it.

How it fits together: count distinct people by one definition, read the ratio at the product's own rhythm and by segment, and count habits per person. Next, Case: a north star for Halves uses all of this to choose the number Halves steers by.