The power-user curve from real rows

The construction has two steps and no statistics. First, per account, collect the set of UTC days on which it was seen; the size of that set is its score, 1 to 28. Second, count how many accounts landed on each score. That gives a list of 28 counts, and the histogram is that list drawn as bars. For the sample under "any event" the first count is 53,046 and the last is 62: 53,046 accounts seen on exactly one day, 62 seen on all 28.

Grouping into bands is a presentation choice, and the one on the figure (1, 2-3, 4-7, 8-14, 15-21, 22-28) is the one the script prints. Bands make the shape readable across the room; the 28-bar version is what you inspect at your desk. Keep both. The band shares under "any event" are 66.7, 24.0, 7.5, 1.6, 0.2 and 0.1 percent, and they sum to the MAU of 79,555 because every active account is in exactly one band.

Session 3's three definitions of active each produce their own L28, and the shape moves with the definition. Under "pushed code" (MAU 48,946) the bands read 64.2, 26.0, 8.0, 1.5, 0.1 and 0.2 percent, with 57 accounts on all 28 days. Under "opened an issue or pull request" (MAU 8,993) they read 77.5, 18.3, 3.7 and 0.4 percent for the first four bands, then almost nothing: 1 account on all 28 days, 4 on 22 or more. The rarer the behaviour, the further left the curve leans. Publish the definition with the curve, every time, because the curve is unreadable without it.

Jin and Chen's post says Facebook "would have a very right-leaning smile, with 60%+ of its MAUs coming back daily". That is their description, not a number anyone outside Facebook has checked, so hold it as a claim about what a social product can look like, not as a benchmark to hit.

Rank by days and you measure breadth of presence: how many of the 28 days an account showed up. Rank by events and you measure volume: how much it did. They point the same way here (33.5 percent of account-days with the top tenth; 30.1 percent of events with the top hundredth) but they are different questions, and a product team should choose the one that matches what it sells. A daily habit product cares about days. A tool billed on usage cares about events.

Concentration is also a warning about denominators. When a tenth of accounts hold a third of the account-days, any per-account average is being pulled toward that tenth, and the median (1 day) is the number that describes the typical account. Session 2 met the same shape inside one hour, where the top 1 percent of actors produced 38.7 percent of the events. It is the normal shape of a public event stream, and the reason the median is printed next to every mean.

"The top 10 percent" is a slice of a ranking, not a list of named people you can act on. The cut point moves every month as the population changes, and an account that was in the top tenth in March may drop out in April without changing its own behaviour at all, simply because others moved. Segments that a team acts on (a mailing list, a feature flag) need a fixed rule in absolute terms, such as "seen on 8 or more days", so that membership is stable and comparable across months. Ranked shares are for describing the shape; absolute thresholds are for building lists.

Automation looks like devotion. A scheduled job runs every day, so it lands on day 28 of the L28 and sits at the very top of the curve. The 62 accounts seen on all 28 days are exactly where a scheduled job lands, and the crude check cannot say how many of them are scripts with ordinary logins. Under "pushed code" the same tail reads 92 accounts on 22 or more days, 11 of them bot-like; under "opened an issue or pull request" it is 4 accounts, 1 bot-like. The narrower the definition, the fewer machines survive it, which is one more argument for choosing "active" as a behaviour that requires a person.

Sampling looks like disengagement. The other direction is just as important. A real daily user who works from 06:00 to 14:00 UTC touches neither sampled hour and scores zero days in the month; a user who overlaps one sampled hour on some days scores a handful. Two hours of 24 is 1/12 of the day, and the curve is left-leaning partly because of that. Part of the shape is real (most public GitHub accounts are occasional) and part is the instrument, and the rows cannot tell you the split. Say both when you present it.

Do not silently drop the 17. Print them, with their day counts and event counts, and read the list. A name check is a hypothesis generator; the confirmation comes from behaviour: an account that acts at the same minute every day, only ever pushes, and never opens, stars or comments is behaving like a schedule. Keep the rule you settle on in code next to the [bot] suffix filter, so that the next person sees both filters and the reasoning, and report the curve with and without the flagged accounts. When the two curves disagree materially, the automation share is a finding, not a footnote.

In a product you run, the same problem appears as internal accounts, QA users, monitoring probes and integrations, and it appears first in the right tail, because that is where anything that never sleeps ends up.