The DAU/MAU ratio explained: the formula, what a good stickiness number is, a worked example on real-looking data and why a weekly product needs WAU/MAU.
By Sergey BruhPublished 8 min read
A free course for PMs and marketers: short lessons, real product data and exercises with instant feedback.
Start the free courseThe DAU/MAU ratio is average daily active users divided by monthly active users: the share of the month's users who show up on a typical day. If 1,000 people used your app this month and on an average day 200 of them opened it, DAU/MAU is 20%. It's the most common measure of stickiness, and it's only meaningful when your product is meant to be used daily. For a product people need once or twice a week, a low DAU/MAU is normal, and the honest number is WAU/MAU. Below: the formula, what counts as a good ratio, a worked example on a month of data from Halves (a fictional expense-splitting app) and the traps that make the ratio lie.
DAU, WAU and MAU are the numbers of distinct users who did a qualifying action (for example, opened the app) in a day, a week and a month. Stickiness divides a short window by a long one:
Two details decide whether the result is right:
The ratio also has a readable meaning. Multiply DAU/MAU by the number of days in the month and you get how many days a typical monthly user was active. A 20% ratio in a 30-day month means about 6 active days per user.
The ratio can't go below one day in the month (about 3% for a 30-day month) or above 100%. The figures that circulate in the industry go roughly like this:
Treat these as folklore, not standards. They mix products with different rhythms and, more often than not, different definitions of "active". The only fair benchmark is a product with the same natural usage rhythm, measured the same way, or your own ratio over time.
An investor tells the Halves team that good consumer apps have DAU/MAU around 50%. Halves's dashboard shows 17% for June. Here is the recount on 1–28 June (four full weeks, treated as the month).
The export has 140 users with any event in June. But 12 of them have no app opens at all: their only events were recurring bills that the server created automatically. They never touched the app, so:
MAU = 140 − 12 = 128
The daily counts add up to 611 (40 on rent-day Monday 1 June, 13 on the last Sunday, between 16 and 27 on the other days). The same 611 comes out when you add up every user's active days, which is a free check.
Average DAU = 611 ÷ 28 = 21.82
The dashboard was right. In days: 0.1705 × 28 = 4.77, so a typical June user opened Halves on about 5 days out of 28.
Nobody splits a dinner bill every day. Flatmates and couples share costs a few times a week or month, so the natural rhythm is weekly. WAU for each week of June (users with at least one active day that week) was 84, 83, 73 and 78:
And 71 of the 128 users (55.5%) were active in at least three of the four weeks. That's a habit, just not a daily one. The honest reply to the investor: DAU/MAU is 17.0%, it's the wrong ruler for bill splitting, and at our rhythm WAU/MAU is 62.1%, with the definition written next to it.
Trips at 30% look alarming until you remember what a trip is: one intense week, then maybe a settle-up day. A trip user active one week in four is doing exactly what the product is for. Trips are judged per trip (did the group log expenses to the end and settle up?), not per week.
Ask: how often does a satisfied user need the product? Measure at that interval. A daily ratio on a weekly product calls a healthy product a failure; a monthly ratio on a daily product hides a fading habit.
Suppose a dashboard counts MAU from any event (140 users, including the 12 server-only ones) but WAU from app opens. Its WAU/MAU would be 79.5 ÷ 140 = 56.8% instead of 62.1%. Counting automatic events as activity inflates MAU and deflates every ratio built on it. Write the metric definition once and use it for both parts.
A ratio over a mixed crowd moves when the crowd changes. Say July brings 60 extra trip users who behave exactly like June's trip users (WAU/MAU 30%), and everyone else stays the same:
The ratio falls by ten points while no segment changed at all. That's mix shift: report the ratio by segment, or at a fixed mix, before calling it a product problem. The lesson Volume, quality and ratios that lie walks through a full mix-adjusted example.
The ratio also rises when casual users leave. If the 14 "other" users disappear next month and nothing else changes, WAU/MAU becomes (79.5 − 3.5) ÷ (128 − 14) = 76 ÷ 114 = 66.7%. Better ratio, smaller product. Always show MAU next to the ratio.
A 31-day month has more room for active days than a 28-day one. Compare like with like: fixed 28-day or 30-day windows, or the same calendar month year over year.
Stickiness tells you how often this month's users come back within the month. It doesn't say whether new users stay for months; that's what retention by cohort is for. And neither MAU nor stickiness is a good company goal on its own: MAU is a volume metric: it would rise with more ad spend or a busy season even if the product didn't change at all. See north star metric examples for metrics that count value rather than visits, and what product analytics is for how these pieces fit.
No. DAU/MAU measures how often the month's users return within that month. Retention follows a cohort of new users over weeks or months and asks how many are still active. A product can have high stickiness among its regulars and poor retention of newcomers.
Either, as long as you keep it fixed. Rolling 30-day MAU gives a smooth daily series; calendar months are easier to explain. Don't mix the two in one chart.
Because four weeks fit in a month, WAU/MAU runs much higher than DAU/MAU: at Halves it's 62.1%. As with DAU/MAU, compare against your own history and against products with the same weekly rhythm.
Usually because MAU is growing faster: a partner promo that pays a sign-up bonus, or a seasonal peak, brings many light users who came for the reward or a one-off need. Split by acquisition channel or sign-up cohort: if each segment's ratio is stable, it's mix shift, not a product problem.
Compute DAU, WAU, MAU and stickiness yourself on the June file in the free lesson DAU, WAU, MAU and stickiness, part of the free course Product Analytics: From Data to Decisions.
