4 June 2025 · Cohorts
Sampling versus hashing for cohorts
Product teams want to know whether last week’s installers still open the app. That question does not require a full user table. It does require you to choose a method and live with its bias.
Week six of Privacy-First Mobile Telemetry is where learners try to keep both sampling and hashing “for flexibility”. The payload doubles. The dashboard disagrees with itself. Faculty mark that as a fail even if both methods are individually sound.
Sampling
You keep a random fraction of sessions or of rotating session keys, then scale counts. It is honest about uncertainty. It breaks when traffic is spiky — promotions, celebrity mentions, regional holidays — unless you recompute the fraction. Several alumni noted this after the studio; we now ask for a seasonality note with the homework.
Sampling is usually the right default for high-volume consumer apps where you need directionally correct retention, not a courtroom-grade individual history.
Hashing
You hash an account id or a short-lived key into a bucket and store bucket-level counts. It can preserve cohort shape without exporting the id. It fails if the hash includes a stable device secret, because then you have reinvented a fingerprint. It also fails if buckets are so fine that a bucket is a person.
We use hashing more often for opt-in research exports and for authenticated products with a visible account. We do not hash advertising identifiers and call the result privacy-first.
Choose in writing
Your dictionary should say which method the activation cohort uses, why, and what question you will no longer answer. If growth later demands both, that is a new purpose — possibly a new consent state — not a silent plugin. See first-party events without fingerprints for the identity side of the same argument.
If you want this exercise marked against your production traffic, that is Guided Bench or Mentored Residency, not the blog. Write to the studio.