What is hash-based assignment?

The obvious way to assign users to variants is to decide once and write it down. Hash-based assignment does the opposite: it computes the answer from the user's identifier every time it is needed. Hash the identifier together with the experiment id, take the result modulo 100, and map that number onto the allocation ranges. The same inputs always produce the same output, so no state is stored and none can go stale.

That statelessness is worth more than it first appears. A web front end, a mobile client, a recommendation service and a nightly analytics job can each compute a user's variant independently, with no shared database and no network call, and they will agree. There is no assignment table to keep consistent, no read on the critical path, and no cache invalidation problem. For a platform running hundreds of concurrent experiments this is the difference between a viable design and one that adds a database lookup to every request.

The hash function needs specific properties and cryptographic strength is not among them. What matters is uniformity — buckets equally likely — and good avalanche behaviour, meaning a single-bit change in the input scrambles the output. Sequential user ids are the test case: a weak hash can leave neighbouring ids in neighbouring buckets, which correlates assignment with signup date and therefore with tenure. MurmurHash3 is the usual choice; MD5 works and is slower for no benefit here.

The input has three parts and each earns its place. The unit identifier must be stable — a user id where available, a first-party cookie otherwise. The experiment id makes assignments independent across concurrent tests, which is the property most commonly lost by omitting it. And a salt or layer identifier lets a platform re-randomise deliberately, so that a long-running series of experiments does not keep exposing the same users to the same arm.

The one operational hazard is that changing any part of the input reassigns everybody. Rotating the salt, renaming an experiment, or altering how the identifier is derived all move users between arms mid-flight, which is exactly the failure that produces a sample ratio mismatch. These inputs should be treated as immutable for the life of an experiment, and the platform should refuse to change them on a running test rather than trusting anyone to remember.

A platform team compares two hash functions for assignment quality on 500,000 sequential integer user ids, then simulates the effect of rotating the salt while an experiment is running.

Hash B is the instructive failure because its headline check passes perfectly. A modulo of a sequential id gives exactly uniform bucket counts — better than MurmurHash's honest randomness — while placing everyone who signed up in the same hour into a handful of adjacent buckets. Any experiment whose allocation boundaries fall between those buckets is then comparing cohorts rather than random samples, and the SRM check will not notice because the totals are even. That is why avalanche behaviour matters more than uniformity here. The salt rotation row is the operational lesson: it is a legitimate and useful capability between experiments, and inside a running one it silently rebuilds both arms from different people. The platform should make it structurally impossible rather than documented as inadvisable.