Малоизвестные грабли A/B тестирования и роль контрольных экспериментовТестирование, A/B-тестирование
Работал в разработке в Sun Microsystems, где делал Java; в Intel, где опять делал Java (проект Apache Harmony, части которого впоследствии были включены в платформу Android); в поиске Яндекса, где оценивал качество поиска, в том числе и пользовательскими экспериментами; занимался маркетингом в JetBrains и аналитикой данных во ВК.
С середины 2015 года Роман изменил род деятельности и занимается тренингами по презентациям для IT'шников и подготовкой докладов на технологических конференциях. За это время успел поработать более чем с двумя тысячами спикеров. Накопленный опыт никуда не девается, и поделиться им хочется.
Многие считают, что провести A/B эксперимент просто, тем более, что уже есть инструменты, которые позволяют автоматизировать этот процесс. При этом почти никто не задумывается о допущениях, на которых основана работа этих инструментов. По-настоящему случайное распределение пользователей, независимость измеряемых событий — либо всё это кажется само собой разумеющимся, либо об этом вовсе не задумываются.
Между тем систему проведения экспериментов на пользователях очень легко сломать, поставив её в неподходящие условия, и потом принимать по результатам экспериментов решения, не отличающиеся от случайных. В докладе мы рассмотрим несколько примеров из мировой индустрии и из практики Яндекса. Если вы делаете у себя A/B тестирование, то хотя бы одна из этих проблем у вас почти гарантированно есть.
Как одно из средств мониторинга здоровья системы экспериментов предлагается проведение постоянного A/A эксперимента, то есть такого, у которого контрольная и экспериментальная группы пользователей видят одно и то же. Есть довольно много классов проблем, которые можно выявить с помощью этого мониторинга. Единственно, делать его довольно накладно, если у вас мало пользователей, но и на этот случай есть пара лайфхаков, которые мы тоже рассмотрим.