Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can assign multiarm bandit trials on a lazy per user basis.

So first time user touches feature A they are assigned to some trial arm T_A and then all subsequent interactions keep them in that trial arm until the trial finishes.



The systems I’ve use pre-allocate users effectively randomly an arm by hashing their user id or equivalent.


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.


How do you handle different users having different numbers of trials when calculating the "click through rate" described in the article?


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


The user ID is non uniform after hash and mod? How?


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.


If your number of AB testing combos cohorts is fewer then 100 then yeah this passes for being uniform


It doesn't, mathematically. It might be good enough for some cases, but it is not good enough for cases that actually require uniformity.


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.


Just make sure you do the hash right so you don’t end up with cursed user IDs like EverQuest.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: