18 February 2026
Sampling mobile events without lying
Client-side sampling is a reasonable way to keep a phone cool. It becomes a lie when the live tile uses census language.
A 10% sample of session starts can still support real-time app KPI tracking if three things are true. The sample is random at the grain you care about. The denominator is the sampled world, not the imagined full population, unless you publish an expansion method. The tile title says sampled.
What we see instead: a crash-free percentage computed on sampled sessions, then placed beside a fully counted trial-start tile, then discussed as if both were the same kind of number. Guardrails may be late and sampled. Heroes usually should not be. If they must be, the lag window and the sample rate belong in the same sentence.
Device bias matters. A sample that drops older OS versions because those clients fail the new telemetry SDK is not a 10% sample of the product. It is a sample of the clients that still speak the new dialect. Write that down before a director treats a dip as a quality win.
In the Event Freshness Desk we practise a dull label: “crash-free, 10% client sample, watermark 40 minutes.” Dull labels prevent exciting mistakes.