Defining "active"

In the script, each definition is one test on the per-hour record of an account: any is "at least one event", push is "at least one PushEvent", open is "at least one issue or pull request opened". An account is active on a day under a definition if the test passes in either sampled hour of that UTC day. The three tests are one line each, and that line is the whole product decision. "Any event" includes starring someone else's repository and commenting on a thread; "pushed code" is closer to the work; "opened an issue or PR" is the narrowest, the moment an account asks the project for something or offers it something.

None of the three is the right one. The right one depends on the question. A capacity planner wants "any event" because servers do not care about intent. A team asking "is our product being used for its purpose" wants the narrow verb, and has to accept a number one ninth the size. Reporting the wide number to answer the narrow question is the most common quiet lie in product analytics, and it is rarely told on purpose.

Two reasons, both worth saying out loud whenever the number is quoted. First, the sample: only accounts whose id is divisible by 20, so about one account in twenty, kept deterministically so the same accounts are followed through every hour. Second, the clock: two hours out of 24, every day. An account that works from 09:00 to 17:00 Central European time and never touches GitHub at 03:00 or 15:00 UTC does not exist in this dataset. 79,555 is "accounts in the sample seen in the sampled hours during March 2024", and the build-along prints it with that sentence attached. Part 3 is about what the two-hour clock does to every count on the page.

The 98 dropped accounts are the ones whose login ends in [bot]. Automation that does not label itself stays in the sample, exactly as in session 2's hour, where the busiest account had no suffix at all. Session 5 goes looking for it in the right tail of the days-active histogram.

MAU here is the number of accounts active on at least one of the 28 days, so it is one count for the whole window. DAU is a count per day, 28 of them, and the page reports the average. WAU is a count per calendar week (the window starts on a Monday, so the four weeks are Monday to Sunday), and the page reports the average of the four. A single account can therefore be in MAU once, in WAU up to four times and in DAU up to 28 times. DAU/MAU asks: of the people who showed up at all this month, what share shows up on a typical day. DAU/WAU asks the same over a week, and comes out around three times larger because a week is a smaller net.

Li Jin and Andrew Chen put the objection precisely in their power-user curve essay: DAU/MAU "is a single number and so blurs this variance". They meant the variance between users who come once and users who come daily. Tonight's data adds a second blur: the ratio also hides which verb was used to count anyone at all. Session 5 unpacks the first blur with the L28 histogram, on these same accounts.

It is tempting to read 6.4 versus 6.6 versus 5.0 as "engagement is about the same however you define it", and that reading is exactly backwards. When the definition narrows from any event to pushing code, both numerator and denominator shrink, and they shrank in almost the same proportion, so the ratio held. The narrowest verb has the lowest ratio, 5.0 percent, which is at least in the expected direction: opening issues and pull requests is a rarer daily habit than pushing. But a ratio that sits between 5 and 7 percent for three populations that differ ninefold is telling you it is a poor instrument for this question, not that the question has one answer.

A working rule: never report a ratio without the two counts that made it, on the same line. "DAU/MAU 6.6 percent (3,218 of 48,946, pushed code, sampled hours)" cannot be misread. "Stickiness 6.6 percent" can be misread in a dozen ways, and will be.

The clock. Two hours of 24 is the extreme case, chosen because 56 files can be streamed on a laptop while 672 cannot. But even complete data has a clock problem: a "day" is a UTC day here, and an account in Sydney whose working afternoon is 03:00 to 07:00 UTC has its Tuesday counted as Wednesday. Choose the day boundary and write it down; the same person can be a one-day user or a two-day user depending on it.

The verb. Session 1 found 234 PushEvents in a single hour that carried zero commits: a branch moved, a force push, a ref updated with nothing new in it. The push test tonight is "at least one PushEvent", so every one of those 234 makes its account "pushed code" active for the day. A stricter verb, "pushed at least one commit", needs the payload's commit count, which the sampler kept as a per-event count but not per commit. The definition you can compute is bounded by what you chose to keep.

The gap. An event that never arrived looks identical to an action that never happened. In this sample the gap is 22 hours a day and it is known. In a product it is a client that dropped events on a bad connection, and it is not known unless someone counts arrivals against expectations, which is what the session 1 validator's "not in the plan" tray was for.

The two-hour clock undercounts everything, but not evenly. MAU is hurt least: an account needs to be seen in just one of 56 sampled hours across the month to make it in. DAU is hurt most: an account has to land in one of two specific hours on that specific day. So the DAU/MAU ratio is biased low by construction, and by an unknown amount, because the true distribution of activity across hours for these accounts is not in the data. That is why the page reports 6.4 percent without ever calling it GitHub's stickiness, and why session 5's days-active histogram will lean left partly for a reason that has nothing to do with the users.

A fair question is whether any of this is worth computing. Yes, for the comparison: all three definitions were sampled by the same clock, so the ninefold gap between them is real even though each absolute number is low. Relative claims survive a shared bias; absolute claims do not.