Your site-wide p75 LCP improved over the last quarter, but when you split the same data by device class, p75 LCP got worse for mobile and worse for desktop. As the person who owns performance reporting for the organisation, how do you explain that, and how would you set reporting up so leadership is not misled by it again?

## What is happening This is mix shift — the performance version of Simpson's paradox. An aggregate percentile is computed over one pooled set of samples drawn from several populations with different distributions. Its value depends on two independent things: how fast each population is, and what share of the samples each contributes. Change the shares and the aggregate moves, even with every population's own distribution held fixed. Make it concrete. Suppose mobile visits are slow and desktop visits are fast, and last quarter the split was 70/30 mobile-heavy. This quarter a desktop-oriented campaign, a seasonal swing, or a native app absorbing your most engaged mobile users moves the split to 50/50. Mobile got slower. Desktop got slower. But a much larger share of the pooled samples now comes from the fast population, and the pooled p75 — which just reads off a rank in the merged sorted list — lands at a better value. The arithmetic is correct and the conclusion "the site got faster" is false. Other mix shifts that produce the same effect: a slow country's traffic drops after you stop advertising there; a heavy page template loses traffic to a light one after a navigation change; bot or synthetic traffic is filtered out and it happened to sit in one tail; you launch in a market with excellent connectivity. The common structure is always a change in *who is measured*, not in *what they experienced*. ## Why you cannot fix it with arithmetic The first thing people reach for is recombining the segment numbers — average the mobile and desktop p75s, or take a traffic-weighted average. Both are wrong, because **percentiles are not additive**. There is no operation on two percentile values that yields the percentile of the combined population; the merged rank depends on the full shape of both distributions, not on one point from each. A traffic-weighted average of percentiles is especially seductive because it looks statistically responsible, and it can be off by a lot when the two distributions differ in shape. The only correct way to get an aggregate percentile is to compute it from the underlying observations — the raw samples, or a distribution representation such as a histogram that can be merged before the percentile is taken. That constraint has a real architectural consequence: if your pipeline stores per-segment summary percentiles and throws away the distribution, you have permanently lost the ability to roll data up, slice it a new way, or answer a question you did not anticipate. Store distributions, derive percentiles at read time. ## Setting the reporting up so this cannot mislead **Segment by default, with shares visible.** The primary view should be per-device-class p75 with each segment's share of traffic next to it, not a single blended number. When a headline moves, the first question — "did the mix change?" — is then answerable in the same glance instead of requiring an investigation. **Choose few, stable, owned segments.** Device class is nearly always the right first cut, because it is where the largest and most persistent performance gap sits. Add region and page template if they carry real ownership. Resist proliferation: fifty segments means every dashboard has something red, nobody is accountable for anything, and the small ones are pure noise anyway. The test for a segment is whether a named team would act on its regression. **Report a mix-normalised comparison for period-over-period claims.** When the question is "did our work make things faster?", hold the mix fixed — compare each segment against itself, or recompute the current period's blend using last period's traffic weights, and label it clearly as what it is. Keep the true blended number too, because that is the one the outside world assesses you on; just never present the two as if they answer the same question. **Alert on segments, not on the headline.** A blended metric can mask a serious regression in a minority population indefinitely. Alerting per segment catches it, and it also stops teams from being paged for a marketing campaign that changed the traffic mix. **Say what the number means every time you publish it.** "p75 LCP across all page views in the window, mobile 62% of traffic (was 71%)" costs one line and pre-empts the wrong inference. Most misreadings of aggregate performance numbers come from a missing denominator rather than a wrong figure. ## The organisational point The deeper issue is that any single headline number becomes a target, and targets get met by whatever means are available — including means that have nothing to do with engineering. A team optimising a blended metric can improve it by shipping a faster site, or by the traffic mix drifting favourably, and the dashboard cannot tell the two apart. Making the mix visible is what keeps the metric honest; making segments the unit of accountability is what makes it actionable. The blended figure is worth keeping for exactly one purpose — it is the bar you are assessed against externally — and it should never be the number a team is asked to move.