{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-20T06:02:36.306Z"},"content":[{"type":"documentation","id":"c62a0f06-9936-42a4-b5f3-cbbd402217c1","slug":"segment-ranking-sample-size-artifact","title":"Why the Top and Bottom Segments in Your Report Are Both the Smallest Ones (2026)","url":"https://www.koji.so/docs/segment-ranking-sample-size-artifact","summary":"Observed segment averages carry noise inversely proportional to sample size, so sorting on them preferentially selects small segments at both extremes. A simulation of 40 segments with identical true means and average size 49 puts segments averaging size 16 in the top four. This is distinct from multiple comparisons because no test is run, and it survives a correct statistical model. Fixes: balanced sample sizes at design time, intervals instead of point rankings.","content":"Sort your segments by satisfaction score and look at the top three. Then look at their sample sizes. In most research readouts, the segments at the top of the ranking and the segments at the bottom of the ranking are the same kind of segment: the small ones.\n\nThis is not a bias you can correct by being careful. It is arithmetic. **Ranking segments by their observed averages is, in part, ranking them by how few people answered** - and the smaller your segments, the more of the ranking is sample size rather than signal.\n\n## The answer, stated first\n\nAn observed segment average is the true value plus noise, and the size of the noise depends on n. Small segments have noisy averages, so they land far from the middle in both directions. When you sort and take the top of the list, you are selecting on that noise, and the selection preferentially picks exactly the segments whose noise is largest.\n\nThe consequence: **your best-performing segment is disproportionately likely to be one of your smallest, and it is likely to be closer to average next quarter** - not because anything changed, but because it was never actually at the top.\n\nThe same is true of the bottom of the ranking. The worst segment is also disproportionately small. Teams notice this less often because a bad number prompts investigation rather than celebration, but it is the identical effect with the sign flipped.\n\n## The demonstration that settles it\n\nHere is the cleanest way to see that this is arithmetic and not bad luck. Build a set of segments in which **every segment has exactly the same true score**, vary only their sizes, and rank them.\n\nSimulating 40 segments that all share a true mean of 4.10 on a 1-5 scale, with a within-segment standard deviation of 1.2 and sizes ranging from 6 to 200 (average size 49), then repeatedly ranking them by observed mean:\n\n- Average size of the **top four** segments by observed mean: **16**\n- Average size of all segments: **49**\n\nThe top of the leaderboard is populated by segments about a third the typical size, in a world where no segment is better than any other. Every \"insight\" in that ranking is an artefact of the denominator. Re-run it with a different random seed and the names change; the pattern does not.\n\n### The published version, with real populations\n\nGelman and Price demonstrated the same effect on U.S. county disease rates, in a paper whose title is the conclusion: all maps of parameter estimates are misleading. Working with a model constructed so that county parameters were \"distributed randomly, with no spatial correlation\" - that is, with no real geographic pattern at all to find - they report that when counties with very high observed rates are highlighted on a map, \"almost all of the highlighted counties are low-population counties.\"\n\nTheir quantification is the number worth remembering. In their cancer-rate model the average county population is 80,000. The expected average population of the counties that get highlighted as the top 10 per cent is **16,000** when highlighting is based on raw observed rates. One fifth the typical size, selected out of a population with no real spatial structure whatsoever.\n\nThis is why maps of disease rates by county reliably light up the sparsely populated interior of the United States, and why the same counties often appear on maps of the *lowest* rates. It is also, precisely, why your segment leaderboard looks the way it does.\n\n## Why this is not the multiple comparisons problem\n\nThe resemblance is close enough to cause confusion, so it is worth separating them carefully.\n\nThe [multiple comparisons problem](/docs/multiple-comparisons-problem) is about **testing**: run twenty significance tests at a 5 per cent threshold and you expect one false positive. The fix is a correction to the threshold, or control of the false discovery rate.\n\nThis is different in three ways that matter:\n\n1. **There is no test.** You sorted a column. No p-value was computed, no threshold was crossed, and no correction has anywhere to attach.\n2. **It survives a correct model.** Gelman and Price are explicit that they count a pattern as an artefact \"if it occurs even when inferences are based on the correct statistical model\". Getting the statistics right does not remove it.\n3. **The direction is predictable.** A multiple comparisons false positive could be any segment. This one specifically favours the small ones, every time.\n\nYou can apply every multiplicity correction in the literature and still hand your executive team a ranking whose top is selected on sample size. The two problems compound; neither is the other's fix.\n\nIt is also distinct from [regression to the mean](/docs/regression-to-the-mean-research), which is the same statistical fact observed across time - you pick an extreme at one point and it moves back at the next. Here there is no second measurement. The ranking is wrong the first time you look at it.\n\n## Where this shows up in product and research work\n\n- **Segment leaderboards in dashboards.** Any table sorted by a rate with a variable denominator.\n- **Top requested feature by segment.** Small segments produce extreme request percentages.\n- **Account-level health scores.** The accounts flagged as healthiest and least healthy are both disproportionately the ones with the fewest logged interactions.\n- **Win rates by source.** A channel with 6 opportunities shows a 67 per cent win rate and goes into the board deck.\n- **NPS by cohort.** NPS is unusually vulnerable because it discards the middle and differences two proportions, which inflates the variance relative to a mean.\n- **Experiment results sliced after the fact.** The subgroup with the biggest lift is usually the smallest subgroup.\n- **Vendor or competitor comparisons built on review counts.** The highest-rated product on a review site is frequently the one with nine reviews.\n\nThe common structure is a rate or an average, a denominator that varies across rows, and a sort.\n\n## What to do instead\n\n### 1. Never sort on a raw estimate alone\n\nSorting is the operation that does the damage. If the table must be sorted, sort on a credibility-weighted estimate rather than the raw one - see [credibility weighting for small segment estimates](/docs/credibility-weighting-small-segment-estimates) for the blend. This does not make the ranking correct, but it removes the crude version of the artefact.\n\n### 2. Understand that shrinking has its own bias, in the opposite direction\n\nThis is the part that catches people who have already learned lesson one. Gelman and Price continue: in their model, the expected average population of the highlighted counties is 16,000 under raw ranking but **190,000 under posterior-mean ranking** - against a true average of 80,000. Shrinkage does not land you on the truth. It overshoots, and the top of a shrunk ranking becomes disproportionately populated by your *largest* segments, because those are the ones whose estimates were allowed to stay extreme.\n\nIn my 40-segment simulation the same reversal appears in milder form: ranking by the shrunk estimate lifts the average size of the top four from 16 to 39, against a true average of 49 - much better, and still not neutral.\n\nSo there is no point estimate you can rank that is free of the effect. That result deserves its own article, and it has one: [when shrinkage hides the one segment that actually changed](/docs/exchangeability-assumption-shrinkage-research).\n\n### 3. Show the uncertainty, and let it do the work\n\nPut a confidence interval on every segment and display it. A ranking in which the top eight intervals all overlap communicates the truth immediately, and non-technical stakeholders read it correctly without being taught anything. This is the single highest-value change most teams can make to a segment report.\n\n### 4. Rank on the probability of being extreme, not on the estimate\n\nIf you genuinely need a shortlist, compute for each segment the posterior probability that its true value exceeds some threshold you care about, and rank on that. It is still not fully neutral with respect to sample size, but it is honest about what it is claiming, and it forces you to name the threshold - which is usually a productive argument.\n\n### 5. Equalise n at design time\n\nThe cleanest fix happens before any data exist. If you know which segments you intend to compare, recruit to comparable sample sizes rather than taking whatever the population mix delivers. A deliberately balanced design makes the whole problem mostly disappear, because the artefact is driven by *variation* in n across rows. When every row has the same denominator, sorting is fair.\n\nThis used to be impractical. Filling a quota of 40 interviews in six segments meant six recruitment pushes, six scheduling cycles, and a month. With an AI-moderated platform like Koji it is a quota setting, because no segment costs more moderator time than any other.\n\n## How Koji makes the balanced design affordable\n\nThe reason segment sizes vary so wildly in most research is not that anyone wanted them to. It is that traditional research fills whatever slots it can get, and the segments that are hard to reach stay small forever - so those segments are permanently the noisiest rows in the table and permanently the ones topping and bottoming the leaderboard.\n\nKoji attacks this at the root. Because interviews are AI-moderated and asynchronous, there is no moderator calendar to fill and no per-interview marginal cost in analyst time. Running 40 conversations in your smallest segment costs roughly the same effort as running 40 in your largest, which means **balanced n is a design choice rather than a budget negotiation**. That single change removes most of the artefact described in this article, because the artefact lives entirely in the variation of sample sizes across rows.\n\nKoji's structured questions make the segment definitions clean at the point of collection. Using single_choice or multiple_choice questions as screeners assigns each respondent to a segment during the conversation itself, so you are not reconstructing segments later from mismatched CRM fields. A scale question gives you the per-respondent numeric values needed to compute a real confidence interval per segment rather than a bare mean, ranking questions expose priority differences that a single average hides, and yes_no questions give clean incidence rates with a known denominator.\n\nKoji's real-time reporting also lets you see the size imbalance while the study is still open. If enterprise has 9 responses and mid-market has 84, you can push more interviews into enterprise that week instead of discovering the problem in analysis, when the only remaining options are a caveat or a cutoff.\n\nAnd when a segment does look genuinely different, the open_ended responses and the AI's automatic follow-up questions give you the mechanism. A ranking tells you which row is highest. The transcripts tell you whether there is a reason - and a real reason, articulated by the people in that segment, is far better evidence that a difference is real than its position in a sorted table.\n\n## Frequently asked questions\n\n### Does this mean segment analysis is useless?\n\nNo. It means sorted tables of raw averages are a bad interface for segment analysis. The underlying differences can be perfectly real and worth acting on. What you cannot do is read the ordering off a leaderboard and treat the top row as the finding. Use intervals, use credibility weighting, and prefer balanced designs.\n\n### My top segment has 40 responses, not 6. Am I safe?\n\nSafer, but the question is relative, not absolute. What matters is how the sizes vary across the rows you are comparing. Forty is small if the other segments have 4,000 and large if they have 25. If every segment is around 40, sorting is close to fair.\n\n### Is this the same as Simpson's paradox?\n\nNo. Simpson's paradox is about a relationship reversing when you aggregate or disaggregate across a confounder - a composition effect, treated in [mix shift](/docs/mix-shift-rate-composition-decomposition). The effect here needs no confounder at all and appears when segments are identical in every respect except size.\n\n### Would a bigger overall sample fix it?\n\nOnly if the extra sample is distributed so that the segment sizes become more equal. Doubling every segment reduces the noise but leaves the *relative* pattern intact, so small segments still occupy the extremes. Doubling only the small segments fixes it properly.\n\n### How do I explain this to a stakeholder who wants a ranked list?\n\nShow them the ranking with intervals attached, and point out how many of the intervals overlap. Then show the sample sizes next to the ranks. In practice the sample-size column does more persuasive work than any explanation of variance, because the pattern is visible immediately once someone looks for it.\n\n### Does this affect qualitative research too?\n\nYes, in a looser form. If you run six interviews in one segment and thirty in another, the six-person segment will produce both your most extreme-sounding quotes and your most unrepresentative themes, simply because a small sample has a wider spread of possible compositions. Koji makes this easy to avoid by lowering the cost of bringing the thin segment up to parity.\n\n## Related Resources\n\n- [Structured questions guide](/docs/structured-questions-guide) - the six question types and when to use each\n- [Credibility weighting for small segment estimates](/docs/credibility-weighting-small-segment-estimates) - the blend that partly fixes this\n- [When shrinkage hides the one segment that actually changed](/docs/exchangeability-assumption-shrinkage-research) - why the fix has its own bias\n- [The multiple comparisons problem](/docs/multiple-comparisons-problem) - the related but separate testing problem\n- [Regression to the mean](/docs/regression-to-the-mean-research) - the same fact observed over time\n- [Mix shift and composition effects](/docs/mix-shift-rate-composition-decomposition) - when segment composition drives the total\n","category":"Analysis & Synthesis","lastModified":"2026-09-19T03:23:58.661465+00:00","metaTitle":"Why Segment Rankings Are Confounded With Sample Size","metaDescription":"Sorting segments by average score partly sorts them by sample size. Why your best and worst segments are both small, and what to report instead.","keywords":["why segment rankings are misleading","segment leaderboard bias","small sample segment ranking","sorting by average bias","segment analysis mistakes","sample size artifact","noisy segment scores"],"aiSummary":"Observed segment averages carry noise inversely proportional to sample size, so sorting on them preferentially selects small segments at both extremes. A simulation of 40 segments with identical true means and average size 49 puts segments averaging size 16 in the top four. This is distinct from multiple comparisons because no test is run, and it survives a correct statistical model. Fixes: balanced sample sizes at design time, intervals instead of point rankings.","aiPrerequisites":["Familiarity with segment reporting","Basic understanding of sampling variability"],"aiLearningOutcomes":["Recognise when a ranking is confounded with sample size","Distinguish this artefact from the multiple comparisons problem","Design balanced segment samples that avoid it","Present segment results without a misleading leaderboard"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}