I know this might come across as a nitpick, but A/B testing and similar techniques aren't at all about what users choose. They are about constructing a statisti

I know this might come across as a nitpick, but A/B testing and similar techniques aren't at all about what users choose. They are about constructing a statistically correct test between two alternatives measured in some predetermined way (eg. transactions/users but equally well consenting users/total users) with the least amount of bias. The bit about minimizing bias means that you couldn't possibly give users the A/B variants to choose from but instead must assert the best you can that no user is exposed to different variants of the same experiment. You would typically do this by giving the client a cookie with a random seed which you can then hash with a secret and the id of the experiment to get a randomly distributed but sticky/consistent variant assignment that doesn't scale client storage with the number of experiments. Where things get more interesting is how to change behavior when a user logs into a new device. Do you switch to the users set of variant assignments or keep the experience on this device consistent? This being said, yeah, I'm pretty sure this is the result of optimization on "what fraction of users give consent" while keeping an eye on uninstall rate as a health metric. Source: Redesigned/rewrote A/B testing (and general optimization) framework for large e-commerce company many years ago.