Growth Analytics

For a long time a team that stopped growing had no way to point at the reason. The only numbers on the wall were totals. Eight thousand two hundred signups this month, a hundred and forty million won in revenue, thirty thousand active users. Those three lines say where the company stands, but they say nothing about what to fix. Signups can land exactly where they landed last month because paid traffic doubled while search traffic was cut in half. Active users can sit at thirty thousand while the thirty thousand faces behind that number turn over completely every month. A total covers everything happening underneath it.

So the monthly growth meeting always went the same way. Grace would ask why the quarter came in flat. Ravi would say the ad budget was too small. Theo would say the signup screen was too slow. Sofia would say a competitor cut prices. All three sound plausible and none of them come with evidence. The decision drifts toward whoever argued hardest that day, and a quarter later nobody can tell whether it was the right one. The next meeting produces the same three answers. When three answers survive a whole quarter, the team ends up doing a little of each, which makes it even harder to tell what worked.

Growth analytics exists to put numbers in that seat, and it does two things. The first is splitting totals apart. Break those 8,200 signups out by the path people arrived through, by the week they signed up, by what they did in their first session, and "we didn't grow" turns into "paid signups went up, but more than half of them disappear in week two." The first sentence keeps a meeting going. The second one decides what to work on. The second job is separating a real effect from a coincidence. A number going up in the week the signup screen changed is not proof the change did it. A holiday may have fallen in the same week, or the product may have been mentioned somewhere with an audience. Filling the gap between "it went up" and "it went up because of this" belongs here too. Put both jobs together and a vague statement about stalled growth narrows to one or two places anyone can actually reach.

The terms under growth analytics fall into two groups. One holds the methods that split a total apart until a cause has a location (analysis). The other holds the gauges that compress a whole situation into a single number you can call healthy or not (metrics).

Analysis splits into four methods, and what separates them is what gets cut. One cuts a headline metric, one cuts the change in user count, one cuts the number of days people showed up, and one hunts for the behavior that divides the people who stay from the people who leave.

1. North star decomposition — taking the one metric a team has agreed to lead with and writing it out as multiplication and addition. If Pagedeck leads with weekly active editors, that number equals active teams times members per team times the share of those members who edited something. Written out that way, "raise the metric" splits into three different jobs: bring in more teams, get more people inside each team using the product, or turn viewers into editors. Plug the current values in and the cheapest lever usually stands out on its own. Growing team count by ten percent and lifting the edit share by ten percent rarely cost anything like the same amount.
2. Growth accounting — writing this month's change in active users as four separate buckets: new, resurrected, churned, and retained. Thirty thousand last month and thirty thousand this month looks like nothing happened. Open it up and you may find 4,000 new users and 900 returning ones coming in while 4,900 walked out. The net is still zero, but that company is in a completely different position from one with 1,000 new and 1,000 churned, and the work is different too. The first needs the hole patched. The second needs more water.
3. Power user curve — a distribution built by sorting users by how many days out of the month they showed up. The horizontal axis runs from one day to thirty, and the height at each point is how many people used the product that many days. Most products draw a slide: tall on the left, falling to the right. When the far right edge rises again, there is a distinct group living in the product nearly every day. That shape is invisible in a single line reading thirty thousand active users. Thirty thousand people who each drop by once or twice a month and thirty thousand that include 5,000 daily regulars lead to very different quarters. The first group empties out within a month of a competitor showing up; the second group pulls other teams inside their own companies in.
4. Magic number — finding the threshold where doing some action a certain number of times right after signup changes how many people are still around later. If people who created three or more documents in their first week are still there two months on at 60 percent, while people who created two or fewer sit at 18 percent, the threshold is three. Once that number exists, what to ask new users to do stops being a matter of opinion. The welcome emails, the buttons on the first screen, and the order of the help articles all line up behind it.

Metrics is the group that compresses all of that into one value, and it currently holds one term. Quick ratio divides what you gained by what you lost: new plus resurrected users over churned users. A one means you replaced exactly what walked out, and anything above one is net growth. In the example above, 4,900 divided by 4,900 is exactly 1.0, which is standing still. Early SaaS companies often talk about four as a healthy figure. The reason this number earns its place is that it separates two companies a growth rate alone would put side by side. Both may be growing ten percent a month, but if one runs a quick ratio of 5 and the other 1.2, the second one has to acquire more people every month just to hold its current pace. Acquisition almost always gets more expensive over time, so nobody holds that position for long.

The two groups work in sequence. A metric raises the flag and analysis goes looking for where the flag came from. A quick ratio sliding from 3.1 to 0.9 tells you something broke, not what. Growth accounting says whether churn rose or new signups fell; cutting that result by acquisition path says which group of arrivals is leaking. Once the location is fixed, a growth experiment pokes at it once, and reading what came back is this field's job again.

All four methods rest on the same precondition: what people clicked has to have been written down. You cannot find a magic number in a product that never records document creation, and you cannot cut signups by path if the path was never stored on the account. That is why instrumentation has to be designed months ahead of the analysis that needs it. There is no way to reconstruct last quarter's records once last quarter is over. Deciding what you want to know comes first, and the records get designed backward from that question. If there are five questions to answer this quarter, the events worth instrumenting follow from those five.

"Net is zero this month, but the accounting says the problem is churn, not new signups."

The same zero points at retention work rather than acquisition work.

"Send me signups broken out by channel. Paid swamps everything when it's aggregated."

One large line item is hiding the movement in all the others, so split it.

"The number went up, but I can't write this one down as a win. Three releases shipped that week."

Too many candidate causes to assign the change to any one of them.

Pagedeck's monthly growth meeting usually opens with Mia putting one screen up. Under a line saying active users went from 30,000 to 30,200, there are three more lines: 4,000 new, 900 returning, 4,700 churned. Grace reads the top line, but the conversation attaches to the ones below it. When it comes out that 2,600 of those 4,700 had signed up less than a month earlier, the meeting stops being about ad budget and becomes about the first month.

Ravi then lays acquisition path over the top. Of the 4,000 new users, the 1,800 who came from ads are down to 12 percent a month later, while the 1,100 who came from search hold at 41 percent. Nobody jumps to killing the ads. First they look at why ad traffic leaves so fast, and whether what the ad promises lines up with what the first screen shows. What this step produces is not an answer but two or three candidates worth checking. The meeting's output is that list, not a conclusion. Mia writes one line per candidate describing what would settle it, and next month's meeting opens with those lines.

The easiest assumption to make is that collecting enough data makes analysis happen on its own. Instrument every screen, build twenty dashboards, and the answer will surface eventually. It works the other way around. Records piled up without a question attached lose track of what each field even meant, and the same metric name starts returning different values on different dashboards. At that point meetings stop discussing numbers and start arguing about which number is correct, so the tooling built for analysis is what blocks it. Decide what you want to know first, then design the records backward from there.

Reading two numbers that moved together as cause and effect is just as common. Once you see that people who create three documents in week one stick around, "make them create three documents" follows naturally. But those three documents may be a symptom rather than a cause. If the people who arrived with real work to do are the ones creating documents and also the ones staying, pushing three documents onto someone with no work to do changes nothing. Skip that distinction and a team spends a quarter adding prompts that drive three-document completion from 40 percent to 70 percent, then finds two-month retention sitting exactly where it was. Turning a symptom into a cause takes a separate step: show the prompt to one group, withhold it from another, and compare. What analysis hands you is always a candidate, and promoting a candidate to a cause is the next stage's job.