Спасибо за вопрос! Происходит по-разному. Но в большинстве случаев в момент входа в эксперимент. Таким образом в эксперименте участвуют в том числе и новые пользователи.
А разметка заранее происходит в тех случаях, если нужно вручную «выравнивать» группы по метрике, чтобы устранить риск изначального смещения.
Поправку не используем. Это невозможно делать в случае огромного количества метрик и разрезов. Всегда что-нибудь да красится. Дефолтная alpha = 0.005, при желании можно понизить прямо на дашборде.
Привет! У нас часто бывает больше одной тестовой группы с разными вариантами. В таких случаях мы делаем попарное сравнение. Как правило, заводим также две контрольные группы, что иногда помогает валидировать случайные прокрасы.
Большое количество экспериментов порождает много быстро «отмирающего» кода, который живет лишь пока идет эксперимент. Это неизбежность. Поэтому разработчики вынуждены делать уборку: при итеративной разработке это уже сродни привычке.
На клиенте должны быть реализованы различные сценарии, включением и отключением которых занимается бэкенд (в нашем случае это микросервис). Мы умеем запускать и останавливать эксперимент без накатывания новой сборки.
мы всё-ещё храним небольшую группу пользователей, которые никогда не получали персональные рекомендации
Если использовать эту группу несколько раз в качестве контрольной, то начиная со второго аб-теста результаты могут сильно поехать из-за смещения, образованного эффектом «памяти» пользователей.
Что мешает считать дисперсию для метрика отношения, говорим что это биномиальное распределение/бернули, оценочная дисперсия p*(1-p)
Это не то же самое, что ratio-метрика в общем смысле.
Вы оценивали процент ошибок (например на синтетике или уже проведенном А/Б) первого/второго рода, при разных B, от B = N до B = const c разными значениеяси
Оценивали. Чем больше B, тем меньше ошибка. 200 — хороший компромисс между размером ошибки и объемом данных, которые нужно хранить.
Почему не стали использовать линеаризацию, она выглядит вычислительно проще и элегантнее
Наш метод — это абсолютно то же самое немного в другом ракурсе. Но при этом он сохраняет mean для выборки и не зависит от mean в контрольной группе, а выборочная дисперсия равна оценке по дельта-методу.
В теории возникает, на практике — нет. Во-первых, MDE не дает принимать преждевременные решения, если важные метрики не прокрасились. Во-вторых, когда у тебя в распоряжении много метрик и разрезов, легко отличить реальный эффект от false positive.
Вы верно сформулировали: опасные пересечения не допускаем, опасные допускаем.
Невозможно одновременно проводить много экспериментов, не допуская пересечений. Поэтому мы делим все экспы на подмножества (слои), в каждом из которых обеспечивается отсутствие пересечений: т. е. ни один пользователь не может попасть одновременно в два эксперимента из одного слоя. Подробное объяснение, как реализована эта логика, осталась за пределами статьи, но презентация Google наглядно объясняет идею.
Статистику по количеству экспериментов разглашать не могу.
1) В рамках эксперимента вы оцениваете сразу несколько метрик. Используете ли какие-то поправки для групповой проверки гипотез (бонферони и тп)?
В репорте можно менять порог для вероятности ошибки I рода (по дефолту у нас он довольно низок: 0.005). Это «ручной» аналог различных поправок. Вообще говоря, поправки на множественность гипотез в нашем случае плохо применимы: с учетом разрезов в каждом тесте мы проверяем десятки тысяч гипотез, многие из них коррелируют друг с другом.
2) В какой ситуации вы принимаете решение об остановке эксперимента? Только когда достигнут размер выборки необходимый для достижения нужной стат мощности?
Крутим до тех пор, пока MDE не сойдется до приемлемых значений по самым важным метрикам. Бывает, что MDE вообще не сходится до нужных значений за адекватный срок, в таком случае нужно перезапускать эксперимент на большей доле трафика.
3) Как вы формулируете нулевую / альтернативную гипотезы если нужно проверить что некоторая метрика не упала?
Так и формулируем: метрика M не должна упасть больше чем на X%. В течение эксперимента ждем прокраса на X%, либо отсутствие прокраса при MDE <= X%.
Отвечаю на вопросы:
1. Можно, cистема полностью для этого подходит.
2. Зависит от настроек в самом эксперименте. Но чтобы метрики собирались со всех платформ, необходимо делить пользователей на группы по хешу от id учетной записи, а не устройства.
3. В таком случае мы не собираем метрики со старых приложений. Это поведение также настраивается через конфиг.
Спасибо за вопрос! Происходит по-разному. Но в большинстве случаев в момент входа в эксперимент. Таким образом в эксперименте участвуют в том числе и новые пользователи.
А разметка заранее происходит в тех случаях, если нужно вручную «выравнивать» группы по метрике, чтобы устранить риск изначального смещения.
Один комментарий.
Если использовать эту группу несколько раз в качестве контрольной, то начиная со второго аб-теста результаты могут сильно поехать из-за смещения, образованного эффектом «памяти» пользователей.
Это не то же самое, что ratio-метрика в общем смысле.
Оценивали. Чем больше B, тем меньше ошибка. 200 — хороший компромисс между размером ошибки и объемом данных, которые нужно хранить.
Наш метод — это абсолютно то же самое немного в другом ракурсе. Но при этом он сохраняет mean для выборки и не зависит от mean в контрольной группе, а выборочная дисперсия равна оценке по дельта-методу.
К сожалению, в виду NDA не могу рассказывать в паблик о конкретных примерах успешных и неуспешных экспериментов.
Невозможно одновременно проводить много экспериментов, не допуская пересечений. Поэтому мы делим все экспы на подмножества (слои), в каждом из которых обеспечивается отсутствие пересечений: т. е. ни один пользователь не может попасть одновременно в два эксперимента из одного слоя. Подробное объяснение, как реализована эта логика, осталась за пределами статьи, но презентация Google наглядно объясняет идею.
Статистику по количеству экспериментов разглашать не могу.
В репорте можно менять порог для вероятности ошибки I рода (по дефолту у нас он довольно низок: 0.005). Это «ручной» аналог различных поправок. Вообще говоря, поправки на множественность гипотез в нашем случае плохо применимы: с учетом разрезов в каждом тесте мы проверяем десятки тысяч гипотез, многие из них коррелируют друг с другом.
Крутим до тех пор, пока MDE не сойдется до приемлемых значений по самым важным метрикам. Бывает, что MDE вообще не сходится до нужных значений за адекватный срок, в таком случае нужно перезапускать эксперимент на большей доле трафика.
Так и формулируем: метрика M не должна упасть больше чем на X%. В течение эксперимента ждем прокраса на X%, либо отсутствие прокраса при MDE <= X%.
Отвечаю на вопросы:
1. Можно, cистема полностью для этого подходит.
2. Зависит от настроек в самом эксперименте. Но чтобы метрики собирались со всех платформ, необходимо делить пользователей на группы по хешу от id учетной записи, а не устройства.
3. В таком случае мы не собираем метрики со старых приложений. Это поведение также настраивается через конфиг.