Провальный A/B тест из-за ошибки в логике хэширования

Самый смешно запоротый A/B в моей практике Как-то раз в A/B тесте нашей модельки с альтернативным решением, заказчику (онлайн-магазину) понадобилось рассказать, зачем нужно брать хэши от айдишников пользователей перед делением на группы, потому что заказчик хотел просто брать четные айдишники в одну группу, а нечетные в другую. Рассказали, что не все вещи, кажущиеся равномерным распределением, правда им являются. Рассказали про то как многие смело разбивают клиентов на группы по последней цифре телефона и потом внезапно узнают, что группы перекошенные. И даже рассказали, что не все хэши одинаково хорошо перемешивают группы и какие предлагаем использовать. Дальше первую неделю A/B видим как стабильно ведем в тесте, радуемся, готовимся праздновать, но на очередном созвоне с заказчиком мимолетом ловим очень тревожную фразу. СТО заказчика решил поделиться своим ноу-хау:«хэш же нам нужен, чтобы результат был максимально непредсказуемым, так что я сделал не hash(id), а hash(id+email), чтобы еще лучше перемешивало группы» 🗿 Осторожно интересуюсь: а когда человек не залогинен, как это работает? СТО: тогда e-mail - пустая строка. Я: а сразу после логина? СТО: сразу после видим e-mail и уже не пустая. В общем, при логине с вероятностью 50% группа менялась, а логин был обязателен для оформления покупки… Кстати, времени у заказчика на еще один правильный А/В не было, так что как вы думаете, что было дальше, и чем закончился проект? :)