Population reports

Every other report in megamaster answers "how do I play this?" Population answers "how does this lot play it?" — whether "this lot" means a behavioural type, a list of opponents you named yourself, or the wider field. That's what turns a deviation from your solver baseline into a decision about whether to keep deviating.

Two ways to say who you mean

By how they play. Describe a type — VPIP, PFR and WWSF ranges, plus a minimum hand count so a 12-hand sample can't join — and megamaster resolves which players in your database match it. "Loose-passive regs I've seen at least 200 hands of" is a group of this kind.

By name, as a saved list. The short stackers. The guys you respect. The three regs you keep running into on Tuesdays. Filter until the list looks right, then freeze it under a name and come back to it whenever you like.

The difference isn't cosmetic. A threshold filter is a query: its membership drifts every time you import hands and somebody's VPIP crosses a boundary. A saved list is a judgement, and it should only change when you change your mind. Storing a judgement as a query would quietly re-decide it under you, which is why the two are separate rather than one feature with a save button.

They're also exclusive, not combinable — pick a saved list and the sliders are ignored. Intersecting them would give you a set that's neither, re-cut by the stats every time you looked at it.

Your aliases come with you

If you've aliased a player's accounts together — the same opponent under three screen names across two sites — putting any one of those accounts in a list brings the rest with it. You added a person, not a login, and the reports treat them as one player with one full sample rather than three thin ones.

The list still shows exactly what you added; the expansion happens when a report runs. Where the two differ you'll see both numbers — "6 players you picked, covering 9 accounts" — because a silent multiplier on your sample size is precisely the kind of thing you should be told about rather than left to infer.

Then walk the same tree you walk for yourself

Once a group is resolved, the explorer is the same decision-node explorer as the Lines tab, with the same notation and the same drill-down — only the subject has changed from you to the group. Whatever you learned to read on your own stats reads identically here.

What to use it for

The honest use is as a third column beside your own frequency and the solver's. A gap between you and the solve is a question, not an answer; the population number is often what settles it. Betting a size the solve likes 40% of the time is a different decision when the field folds to it 71% than when they fold 52%.

What it is not is something to drill. There is no trainer on this tab on purpose — you don't want to build reflexes around how a group of opponents plays, you want to build them around how you should respond to it. See the Lines map for the part that's about your own play.

Two pools, one instrument

There are two populations you can point this at, and they answer different questions.

Your pool is computed over your own database — the opponents you actually played. Its built-in limit is that you only see how they played against tables you were sitting at, and only the hands your export recorded. Real sample of a real field, not a complete one.

The baseline pool is a downloaded aggregate package covering far more hands than any one player's database holds, sliced by site, stake and year. It renders through the same explorer as your own pool, so the two read as one instrument pointed at two populations rather than two different reports.

Why a second pool is worth having

Because a GTO-only comparison can get the direction of the advice wrong, not just its size.

Take the delayed cbet: essentially every pool overfolds against it. A student whose bet-facing range looks "too weak versus GTO" may be correctly built versus the population they actually play. Told only that they deviate from the solve, they'd fix something that wasn't broken and lose money doing it. The columns side by side — you, your pool, the baseline pool, the solve — is what makes that visible.

What's in a baseline package, and what isn't

Postflop counts and frequencies per node, preflop frequencies per position, context and action, and a small set of anonymized example hands — enough to check what a filter is actually matching, because a frequency you can't spot-check is a number you have to take on faith.

The examples are real hand texts with the boards, actions and any shown cards intact. What's removed is identity: screen names are replaced by position labels, table names generalized, presence and chat lines stripped. They're capped at 40 per cohort and pot type per segment, and the build runs a hard audit against the known-names list before a package is finalized — if any screen name survives sanitizing, the build fails and the package doesn't get made rather than shipping and being apologized for later.

So: no screen names or identities anywhere, rather than no hands at all. Worth stating precisely, because "no hands" would be the more comfortable claim and it wouldn't be true.

Thin samples are floored twice. At build time, any node under the k-floor (50 by default) is dropped from the package entirely — those samples aren't in the file you download. At read time, nodes under a second floor (20 by default) are hidden as well, and the count is re-checked whenever you slice by texture, since slicing is what turns a healthy sample into a thin one.

Packages are built by running the app's own pipeline — the same adapters, the same node-fact builder, the same texture module — over a mined archive, so the baseline's keys are identical to yours by construction rather than by a mapping that could drift.

You don't have to take the sample's composition on trust either: the census page is an interactive breakdown of that corpus by site, stake, format and month. A baseline is only as relevant as the games it came from, so it's worth checking your stakes are actually in there before you lean on it.

Regs, fish, and unknown

Every aggregate carries a cohort dimension, and the explorer shows Regs by default — folding fish decisions into the read is exactly the noise the dimension exists to remove. A player counts as a fish at VPIP of 35 or more, or a VPIP-PFR gap of 18 or more; anyone under 30 observed hands is unknown, as is everyone on sites that anonymize names at the export (GGPoker), where there's no stable player to accumulate a read against in the first place.

Switch cohorts deliberately rather than by default. "How does the field play this?" and "how do the regs play this?" are different questions, and the second is usually the one you want when deciding whether your own deviation is a leak or an adaptation.