Growth Accounting

For years a product's health got reported as one line: 30,000 monthly active users (MAU). Thirty thousand last month, thirty thousand this month, so the slide says flat and the meeting moves on. Nothing appears to have happened.

In reality close to ten thousand people may have moved in and out. Four thousand arrived for the first time, 900 came back after a gap, and 4,900 left during the same weeks, and the totals happened to cancel. A product in that state and a product that's flat at 1,000 new against 1,000 lost are not in the same situation. The first is pouring water hard into a bucket with a hole in it; the second is quietly parked. The fix is opposite in each case, and the total hides which one you're in.

The same trouble shows up when the number does move. A report of 30,000 rising to 33,000 means something completely different depending on whether those 3,000 came from doubling ad spend while churn held steady, or from cutting churn in half. Growth accounting exists to pull those movements back out from behind the total. The name borrows from bookkeeping, where a change in the balance is never recorded as a single figure but as the entries that came in and the entries that went out.

Sort every user in a period into four buckets that don't overlap, then compare consecutive periods bucket by bucket. There are five steps.

1. Pick a period. Weekly suits products people open daily; monthly suits work tools with a longer rhythm. Once chosen, don't change it — a different unit can't be compared to earlier months.
2. Define active in one sentence. Is signing in enough, or does someone have to create something? Pagedeck counts anyone who edited a document that month. A loose bar undercounts churn and delays the moment a problem becomes visible.
3. Place each user in one bucket by looking at this period, the previous one, and everything before. Active in both periods is retained. Active for the first time is new. Absent last period but active sometime earlier and back now is resurrected. Active last period and gone now is churned.
4. Add and subtract. This period's active count is retained + new + resurrected, and the change from last period is new + resurrected − churned. With 25,100 retained, 4,000 new, and 900 resurrected, the month lands at 30,000; subtract 4,900 churned and the net change is zero.
5. Put several periods side by side as bars, with new and resurrected above the axis and churn below, so both sides are visible at once. A single month can't tell you whether it was unusual — six months is the minimum worth looking at.

None of this works without a record. If event tracking isn't in place, step 2 is where you stop, and there's no way to reconstruct last quarter's events after the fact.

It fits best where users can come and go freely. In one-and-done services, or in contracts where churn can only happen on a renewal date, the four buckets don't divide anything meaningful. In a product people can drop and pick up again, the resurrected bucket gets large enough to read on its own — and once it passes 20 percent of all arrivals, waking dormant users is usually cheaper than acquiring new ones.

There are three limits. First, it counts people, not usage. Whether 5,000 or 300 of those 25,100 retained users show up daily is invisible here. Second, it doesn't say why anyone left. That 4,900 churned is a fact; price, a competitor, or a broken feature is a separate investigation. Third, changing the definition of active shakes every historical number at once, which means a well-intentioned cleanup of the tracking code can erase your ability to compare this quarter to last.

So the method narrows down where to look rather than answering on its own. Once the churn side is confirmed as the problem, the next cut is by cohort, and then a growth experiment touches that specific spot. Accounting gets you as far as the address.

"Net change was zero last month, but split it out and new users were an all-time high."

Growth stalled because of churn, not because acquisition slowed.

"Resurrected share has climbed three months running — looks like the dormant-user email is working."

The path for bringing lapsed users back is actually functioning.

"Let's open this quarter with the accounting table instead of the summary."

Start the discussion from the buckets rather than the total.

At Pagedeck, Mia builds this table at the start of every month. One month active users went from 30,000 to 31,000, which looked unremarkable. Split out, new users had jumped from 4,000 to 5,600 while churn rose from 4,900 to 5,500. The ads Ravi ran that month did lift arrivals, but the people arriving weren't lasting a month.

The conversation shifted away from whether to spend more or less on ads and toward what new users do in their first week. Theo cut the same data by signup source and found that only half of ad-sourced users created a document in week one. The table didn't say the ads were bad; it said to look at the churn side.

The most common mistake is deciding the net number is enough. What anyone really wants to know is whether users went up or down, so it's a natural place to land. But net is the output of four buckets, and identical outputs come from completely different states. Zero from 4,900 new against 4,900 churned and zero from 200 against 200 call for different work — fix the product in the first case, bring people in during the second. Watch only the net and you can repeat the same report for six months without changing anything, because the number never tells you which of the two rooms you're standing in.

Reading the buckets as a report card causes its own damage. The moment a large churn bucket means the product team failed and a small new bucket means marketing failed, pressure appears to loosen the definition of active. Count a sign-in as active and churn appears to shrink. The table then stops catching anything, and the fact that people are leaving surfaces only when revenue bends.