Comment by kridsdale1
Comment by kridsdale1 6 days ago
The systems I’ve use pre-allocate users effectively randomly an arm by hashing their user id or equivalent.
Comment by kridsdale1 6 days ago
The systems I’ve use pre-allocate users effectively randomly an arm by hashing their user id or equivalent.
careful when doing that though! i've seen some big eyes when people assumed IDs to be uniform randomly distributed and suddenly their "test group" was 15% instead of the intended 1%. better generate a truely random value using your languages favorite crypto functions and be able to work with it without fear of busting production
If you mod by anything other than a power of two, it won't be. https://lemire.me/blog/2019/06/06/nearly-divisionless-random...
That article is mostly about speed. The following seems like the one thing that might be relevant:
> Naively, you could take the random integer and compute the remainder of the division by the size of the interval. It works because the remainder of the division by D is always smaller than D. Yet it introduces a statistical bias
That's all it says. Is the point here just that 2^31 % 17 is not zero, so 1,2,3 are potentially happening slightly more than 15,16? If so, this is not terribly important
> If so, this is not terribly important
It is not uniformly random, which is the whole point.
> That article is mostly about speed
The article is about how to actually achieve uniform random at high speed. Just doing mod is faster but does not satisfy the uniform random requirement.
additional to the other excellent comments they will become non-uniform once you start deleting records. that will break all hopes you might have had in modulo and percentages being reliable partitions because the "holes" in your ID space could be maximally bad for whatever usecase you thought up.
To make sure user id U doesn’t always end up in eg control group it’s useful to concatenate the id with experiment uuid.