В предыдущих статьях статья 1, статья 2, статья 3 мы рассмотрели основные подводные камни автоматизации и анализу АБ тестов, привели подробный обзор статей по этой теме, а так же рассмотрели типичные задачи аналитика данных. В контексте АБ-тестов одним из ключевых аспектов является механизм разделения на группы, который в терминологии специалистов часто называется сплитовалкой.

Может показаться, что задача элементарная - сгенерировать случайное целое число каждому пользователю с вероятностью 1/n, где n - число групп в АБ тесте. Но на практике, особенно для высоконагруженных сервисов, таких как Ozon, возникает множество архитектурных и платформенных сложностей. В данной статье мы сконцентрируемся на основных принципах деления на группы, принятых в индустрии.

В первой части статьи на Habr мы рассмотрели классические подходы к оценке изменений метрики при условии ее стационарности. В этом контексте статистические критерии, применяемые в A/B тестировании, оказались весьма эффективными.

Однако, если существует стабильный тренд, например, среднемесячная аудитория увеличивается из года в год, оценка разницы средних за два смежных периода времени может быть некорректной. В таком случае среднее значение предыдущего периода всегда будет отличаться от среднего постпериода, и это часто может быть не связано с исследуемым функционалом.

Одна из причин — тренд не всегда зависит от действий компании и часто является следствием внешних условий. Например, рост аудитории может быть связан с увеличением благосостояния населения, масштабированием бизнеса или сезонными факторами.

Таким образом, наличие или отсутствие тренда является важным аспектом анализа данных. Рассмотрим несколько успешных и неудачных подходов, которые можно применять для решения этой задачи.

В прошлой статье мы рассматривали неочевидные проблемы АБ тестирования и как можно с ними справляться [ссылка]. Но часто бывает так, что при внедрении новой функциональности АБ тестирование провести нельзя. Например, это типично для маркетинговых кампаний нацеленных на массовую аудиторию. В данной ситуации существует вероятность того, что пользователи контрольной группы, которым недоступна рекламируемая функциональность, начнут массово перерегистрироваться. Также возможен сценарий, при котором возникнет значительное количество негативных отзывов из-за воспринимаемой дискриминации. Но задача оценки таких нововведений одна из наиболее частых, которые приходится решать аналитикам. Если метрики только улучшаются, то это обычно легко объяснить хорошей работой, а если метрика ухудшилась, то сразу появляется задача на аналитика. В этой заметке мы рассмотрим первую часть задачи - а действительно ли метрика упала и если да, то имеет ли смысл разбираться дальше?

Задача оценки нововведений в онлайн и мобильных приложениях возникает повсеместно. Один из наиболее надёжных и популярных способов решения этой задачи - двойной слепой рандомизированный эксперимент, также известный как АБ-тест.

На тему АБ-тестирования доступны как статьи на Хабре, так и целые книги (неполный список литературы в конце). В основе АБ-теста лежит следующая идея - случайно разделить пользователей на две или более группы, в одной из которых исследуемая функциональность выключена, а в других - включена. Затем можно сравнить метрики и сделать выводы.