DAU/WAU/MAU: how many were alive

The word that appears in L.'s journal 214 times

"The case stays open until you learn the language it is written in. Let's start with the word DAU." — QUERY

DAU (daily active users) — how many unique users were active during a day. WAU — during a week, MAU — during a month.

But DAU is not sitting in the black box as a ready number. It is the result of a six-step chain, and it is worth walking that chain by hand once — after that it runs automatically, in your head.

The chain: log → number

1. Take the event log — all of it, for all time.
2. Filter the period: keep rows whose timestamp falls inside the day in question.
3. Filter the activity event: keep only rows whose event counts as "activity" under our definition.
4. Keep the user_id column: time, sessions and properties are no longer needed.
5. Drop duplicates: one user = one record, no matter how many rows they left.
6. Count what is left. That is DAU.

Let us walk the March 14 log fragment from the previous lesson, taking app_open as activity:

step 1: 9 log rows
step 2: all 9 — a single day
step 3: keep only app_open → 4 rows (4412 morning, 7781, 4412 afternoon, 9003)
step 4: user_id → 4412, 7781, 4412, 9003
step 5: drop the duplicate 4412 → 4412, 7781, 9003
step 6: DAU = 3

Look at step 5. Cat 4412 opened the app twice — morning and afternoon. He enters DAU once. That is exactly why DAU is neither the number of app launches nor the number of sessions.

For the same reason WAU is not the sum of seven DAUs. A cat who visits daily contributes 7 to the DAU sum and 1 to WAU:

        Mo Tu We Th Fr Sa Su
Barsik:  ●  ●  ●  ●  ●  ●  ●
Musya:   ●  ○  ●  ○  ●  ○  ●
Ryzhik:  ●  ●  ○  ○  ○  ●  ●
DAU:     3  2  2  1  2  2  3   → DAU sum = 15
                               → WAU = 3 (only three unique cats)

The DAU/WAU ratio is a metric in its own right: it shows what share of the weekly audience the product sees on an average day. The closer to one, the more often people come back.

"Active" is a construct, not a fact

Step 3 of the chain hides the main decision: which event counts as activity. The log has no "active: yes/no" column. It only has events, and someone must decide which of them mean life.

Take one Kotomarket day — March 14 — and compute DAU three times under three definitions. Same data, same chain; only step 3 changes:

The three numbers differ by almost fivefold. And here is the claim worth rereading: all three are correct — provided one was chosen and written down. These are not three attempts to guess the "real" DAU. They are three different metrics, each with its own meaning:

• app_open measures reach: how many people opened the product at all. Useful for judging traffic and push performance;
• product_view measures engagement: the person did not just open it, they started looking. Closer to genuine interest;
• add_to_cart measures purchase intent. The strictest definition and the smallest number.

L. argues with the team three times in the journal: "A person who opened a push and closed it instantly is not active. They are annoyed. If we book annoyance as activity, we are lying to our own face." The team kept app_open — because competitors counted it that way and comparability was wanted. That is an argument too; what matters is that the decision was made deliberately and written down.

A classic mistake is comparing two products' DAU without asking about definitions. "They have a million DAU, we have two hundred thousand" means nothing if their activity means "opened" and ours means "did something". That is comparing cats to dogs by leg count: formally consistent, meaningless.

The abbreviation does not define the window

The second decision hides in step 2 — the period. The word "week" has at least two meanings, and they produce different numbers.

A calendar window. A week is Monday–Sunday. A month runs from the first to the last day. Such a window is easy to compare ("week 11 versus week 10") and easy to explain, but it jumps around: a week with a holiday behaves differently, February is three days shorter than March.

A rolling window. "The last 7 days including today" and "the last 30 days". Every single day has such a window — you can plot a rolling WAU by day and it will be smooth: each new day adds one day and drops one.

calendar WAU:   [Mo Tu We Th Fr Sa Su][Mo Tu We Th Fr Sa Su]
                 one number per week    the next number

rolling 7d WAU: [Mo ... Su] → [Tu ... Mo] → [We ... Tu] → ...
                 a new number EVERY day

Both are legitimate. Trouble starts when they get mixed up — and they constantly do, because both are called "WAU".

The phrase "WAU for the week" defines nothing. The abbreviation states the length of the window and says nothing about its boundaries. Ask: a calendar week, or the last 7 days?

The classic disaster: the "Pult" dashboard shows a rolling 30d MAU line while the investor deck shows last month's calendar MAU. The numbers disagree, and half a day is spent hunting a "bug" that does not exist.

There is a third detail that breaks comparisons — the timezone. If one report cuts days by UTC and another by Moscow time, the day boundary shifts by three hours: evening orders land on different days. On daily numbers that is noise; on hourly charts it produces phantom "midnight dips".

A definition must never change silently

January. Kotomarket computes average DAU for the month from app_open — it comes out at 10,000.

February. A new analyst decides that "opened and closed" is not activity and switches the computation to product_view. Average DAU for the month falls to 7,500.

On the "Pult" dashboard it looks like this:

January  ████████████████████  10,000
February ███████████████        7,500   −25%

Management sees a quarter of the audience vanish and declares a fire. The cause is hunted for a week: a release? ads? competitors? seasonality?

The cause is methodology. The product did not change at all. Step 3 of the chain did.

This is not a hypothetical: half of the "mysterious dips" in L.'s journal are built on it. Hence a rule stronger than any dashboard:

Change the definition — recompute the history. The new definition is applied to ALL past days so the line on the chart compares like with like. And at the switch point the chart gets a vertical marker labelled "activity definition changed".

If history cannot be recomputed (the past data simply is not there), the new metric is shown as a separate line and never passed off as a continuation of the old one.

A classic mistake is silently "improving" the computation and telling no one, because the new definition is objectively better. Even when it truly is better, an unannounced switch turns the chart into a lie: a chart promises comparability, and there is none.

L.'s entry #9: "Three times a year we hunted the cause of a drop that never happened. Every time it was a colleague who had improved something in the query. Now we have a rule: any change to a metric goes into the change log and gets a marker on the chart."