Engagement you can defend

The definition. Count the accounts active on each day, average that across the month, and divide by the accounts active at least once in the month. On our GitHub sample, with "active" meaning any event at all, average DAU is 5,110.6, MAU is 79,555, and the ratio is 6.4 percent. The weekly version, DAU/WAU, is 18.6 percent. Both are real, both come from the same accounts, and neither says what a typical account looks like.

Why a ratio blurs. Jin and Chen's point is arithmetic, not opinion. The ratio is a mean, and a mean of a mixed population hides the mix. Product A in the sketch could reach the same ratio as product B by having many people show up a few days each; product B gets there with a small group that shows up every day and a crowd that barely does. One of those products has a habit inside it and the other does not, and that is the first thing a product leader needs to know.

What to ask instead. "How many days in the month were people active, and how is that distributed?" That question has a chart, the histogram in Part 2, and the chart cannot be summarised by one number without losing the shape.

DAU/MAU assumes a product that could plausibly be used daily. Many products cannot be: an expense tool is opened at month end, a tax product once a year, a code-review tool on working days. For those, a daily ratio reads as failure no matter how healthy the product is, and the honest choice is a period that matches the natural frequency: weekly actives over monthly actives, or monthly actives over quarterly. The build-along asks you to pick that period on purpose, in writing, so that nobody later compares a weekly product to a daily one and calls it a decline.

One seam to note. Whether those actives are still here in six months is retention, and it has its own course: Customer retention with Phoebe. Tonight stays inside the month.

The x axis is days active in the period, 1 to 30 for a month, 1 to 28 here because we watched four full weeks. The y axis is the share of monthly actives at each count. Every bar together adds to MAU, so the curve contains DAU/MAU and more: the ratio is roughly the average bar position divided by the period length, and the curve is the whole distribution the ratio was averaged from.

The smile. Jin and Chen's ideal is a right-leaning smile: a meaningful bar at the far right, meaning a group that shows up almost every day. They write that Facebook "would have a very right-leaning smile, with 60%+ of its MAUs coming back daily". That is their claim about a company they did not work for at the time and it is not verifiable from outside, so treat it as an illustration of the shape, never as a benchmark to be measured against.

Our curve leans left. 66.7 percent of the sampled accounts were seen on exactly one day in 28; 24.0 percent on two or three; 7.5 on four to seven; and everything beyond 8 days is under 2 percent combined. There is no second bump. Two explanations are true at once, and the next card separates them.

The real part. Most public GitHub accounts are occasional. Someone stars a repository, opens one issue, pushes one fix to a fork, and is not seen again that month. Session 2 of the analyst track found the same thing inside a single hour: 52.1 percent of actors had exactly one event. A left-leaning curve is what a broad, mostly casual user base looks like, and there is nothing wrong with it as long as nobody presents it as a smile.

The sampling part. We watched two hours a day, 03:00 and 15:00 UTC, and only accounts whose id divides by 20. An engineer who pushes code every working day from 09:00 to 17:00 in San Francisco is invisible at both of our hours and lands in the 1-day bar or not at all. So the true GitHub curve has more weight to the right than this one, and by an amount we cannot compute from this sample. That sentence is the caveat that makes the chart defensible: it says what the number is, how it was made, and which direction it is biased.

The habit worth copying: every engagement chart carries its sampling and its definition in the footnote. If yours came from the full event stream, say so. If it came from a client library that some users block, say which direction that pushes it.

A left-leaning curve means the days are concentrated in few hands. In the sample, the top 10 percent of accounts hold 33.5 percent of all account-days, and the top 1 percent by event count hold 30.1 percent of all sampled events. Those two numbers are the same story as the histogram from a different angle: a small group does a disproportionate share, and the ratio would have hidden that too. Analyst session 5 builds this curve from the rows and shows where automation hides in its right tail, which is where Part 3 goes next.

Any event. Starring a repository, commenting, pushing, anything at all: MAU 79,555, DAU/MAU 6.4 percent. This is the widest possible definition and the one most dashboards default to, because it is the easiest to compute and the largest number.

Pushed code. Only accounts that pushed at least once in a sampled hour: MAU 48,946, DAU/MAU 6.6 percent. Far narrower, and notice the ratio barely moved. The stickiness of the people who push is about the same as the stickiness of everyone; what changed is how many people there are.

Opened an issue or pull request. Accounts that did the thing that starts collaboration: MAU 8,993, DAU/MAU 5.0 percent. A fraction of the first number. If GitHub's product review quoted "monthly actives" without the sentence underneath, three honest analysts could bring three numbers between 8,993 and 79,555 and each would be right.

The lesson is not that the small number is correct. It is that the definition is the metric. Pick the action that means a user got value, write it down, and quote nothing that is not built on it.

The test. Could the team raise this number next quarter without a single user getting more value? If yes, it is vanity. "Any event" fails the test: a notification campaign that brings people back to glance at a page raises it, so does a bot, so does a new client that fires an event on open. "Opened an issue or PR" mostly passes: it takes a human intention, it is hard to automate without it showing, and it is rare enough that a real change is visible.

Vanity is not useless. The wide number tells you about reach; it just cannot tell you about value, and the failure mode is quoting one when you mean the other. A defensible review shows both, labelled, and never lets the wide one stand alone.

The engagement sample drops the 98 accounts whose login ends in [bot], because GitHub labels those. It cannot drop the rest. Among the 105 accounts seen on 22 or more days, a crude name check (does the login contain bot, -ci, ci-, sync, deploy, commenter or assistant) flags 17. The check is deliberately crude and the page says so: it will miss automation with an ordinary name and it will flag a human called "deploy-dave". The point is not the 17. It is that the far right of a power-user curve, the bar a growth team most wants to see, is exactly where scheduled software looks like a devoted person, and any right-tail celebration needs a bot pass first. Session 2 of the analyst track met the same problem inside one hour, where the single busiest login, with 25,458 events, had no [bot] suffix at all.