4 неочевидных способа зафейлить A/B тест
Как испортить A/B тест поглядыванием, отсутствием проверки на множественные тестирования или незафиксированными критериями принятия решения до запуска многие знают (а если не знаете, про это еще напишу). Но сегодня речь будет про другое. Статистика и знание теории экспериментирования важная вещь, но даже с идеальным знанием статистики и A/B тестов все еще нет гарантии, что A/B тест пройдет корректно.
Ниже тру стори из моей практики, как разнообразно зафейлить АБ тест не статистикой 👇
🟡Конверсия в эксперименте в одном из сегментов получилась больше 100%
Это мое любимое, писала про похожее чуть выше, но история не устаревает. На общей конверсии этого не было видно, однако результаты A/B получились странные. В разрезе по сегментам обнаружилось: в одном из них не отправлялись события начала воронки, и конверсия получилась выше 100%. Мы не знаем, сколько пользователей заходило в воронку, и было ли это равномерно между тестом и контролем, этот сегмент однозначно зафейлен. Далее я попробовала посчитать результаты A/B без этого сегмента, но это уже методологически неверно (получился серый тест, потому что эффекта нет или после удаления сегмента не хватило мощности?) и эксп пришлось перезапускать после починки логгирования.
Важное замечание: анализ по сегментам был уже в рамках исследования, что пошло не так с A/B тестом, а не для принятия решения на основании одного из сегментов (для этого надо было изначально закладывать в дизайне и делать поправку, что отдельная история).
🟡12% пользователей оказались одновременно в тесте и в контроле из-за бага при запуске A/B
Флаги аналитики протекли в конфиг, и сплитование поломалось. Со стороны мониторинга казалось, что все ок, группы были равны (формально), однако на этапе анализа результатов выяснилось, что часть пользователей из тестовой группы по флагам были и в тесте, и в контроле. В результате корректно просплитованных пользователей оказалось меньше чем ожидалось, эксп пришлось перезапускать. Примерная оценка потерь: с таким багом сплитования нужно на 30% больше трафика при том же MDE.
🟡Некоторые пользователи попали в тест, но воздействия не получили
Сплитование на этот раз было корректным, но на бэке стояли дополнительные условия выдачи фичи, и часть тестовой группы фичу просто не увидела. Это в итоге снова нарушило рандомизацию, просто исключить пользователей из анализа не получилось, тест пришлось перезапускать.
🟡Расхождение данных между источниками, которое случилось из-за теста
По событиям из одного источника в тестовой группе увидели стат значимое падение ключевой метрики. По другому источнику (данным из хранилища DWH) получился стат значимый рост, хотя обычно источники были коррелированы. Оказалось, что события терялись чаще именно из-за тестовой фичи. На этот раз был хеппи энд, так как по более надежным данным из хранилища удалось подвести итоги и тест был признан успешным 🎉
Я бы хотела сказать, что больше подобных случаев не было, к сожалению на этом список не заканчивается, а здесь приведены самые эпичные.
Что общего у этих историй? Ни одну из них не предотвратит знание поправок на множественное тестирование или разницы между тестами Стьюдента и Велча.
Однако со зрелой платформой и культурой экспериментов половина этих фейлов не случилась бы вообще или была отловлена еще при запуске: мониторинг и алерты количества событий, проверка что пользователи реально получают фичу, расчет денежных метрик по DWH, а не по событиям и это далеко не все.
Поэтому немного вечной классики про качество данных: сложные методы хороши, но только после того, как в простых тестах удается добиться максимальной корректности запусков и расчетов на платформе. На отсутствии перезапусков можно очень неплохо улучшить time-to-market, возможно даже лучше, чем внедрением diff-in-diff, CUPED и других модных методов.
В нашем случае все уже не так драматично, мы растем и в процессах и культуре АБ тестов, что уже позволило сократить количество историй выше. Кроме этого, меняем текущую платформу сплитования на более кастомизируемую и современную (угадайте, кто лидирует этот процесс 😎).
А что из неочевидных багов в АБ попадалось вам? Пишите в комментариях 👇
Как испортить A/B тест поглядыванием, отсутствием проверки на множественные тестирования или незафиксированными критериями принятия решения до запуска многие знают (а если не знаете, про это еще напишу). Но сегодня речь будет про другое. Статистика и знание теории экспериментирования важная вещь, но даже с идеальным знанием статистики и A/B тестов все еще нет гарантии, что A/B тест пройдет корректно.
Ниже тру стори из моей практики, как разнообразно зафейлить АБ тест не статистикой 👇
🟡Конверсия в эксперименте в одном из сегментов получилась больше 100%
Это мое любимое, писала про похожее чуть выше, но история не устаревает. На общей конверсии этого не было видно, однако результаты A/B получились странные. В разрезе по сегментам обнаружилось: в одном из них не отправлялись события начала воронки, и конверсия получилась выше 100%. Мы не знаем, сколько пользователей заходило в воронку, и было ли это равномерно между тестом и контролем, этот сегмент однозначно зафейлен. Далее я попробовала посчитать результаты A/B без этого сегмента, но это уже методологически неверно (получился серый тест, потому что эффекта нет или после удаления сегмента не хватило мощности?) и эксп пришлось перезапускать после починки логгирования.
Важное замечание: анализ по сегментам был уже в рамках исследования, что пошло не так с A/B тестом, а не для принятия решения на основании одного из сегментов (для этого надо было изначально закладывать в дизайне и делать поправку, что отдельная история).
🟡12% пользователей оказались одновременно в тесте и в контроле из-за бага при запуске A/B
Флаги аналитики протекли в конфиг, и сплитование поломалось. Со стороны мониторинга казалось, что все ок, группы были равны (формально), однако на этапе анализа результатов выяснилось, что часть пользователей из тестовой группы по флагам были и в тесте, и в контроле. В результате корректно просплитованных пользователей оказалось меньше чем ожидалось, эксп пришлось перезапускать. Примерная оценка потерь: с таким багом сплитования нужно на 30% больше трафика при том же MDE.
🟡Некоторые пользователи попали в тест, но воздействия не получили
Сплитование на этот раз было корректным, но на бэке стояли дополнительные условия выдачи фичи, и часть тестовой группы фичу просто не увидела. Это в итоге снова нарушило рандомизацию, просто исключить пользователей из анализа не получилось, тест пришлось перезапускать.
🟡Расхождение данных между источниками, которое случилось из-за теста
По событиям из одного источника в тестовой группе увидели стат значимое падение ключевой метрики. По другому источнику (данным из хранилища DWH) получился стат значимый рост, хотя обычно источники были коррелированы. Оказалось, что события терялись чаще именно из-за тестовой фичи. На этот раз был хеппи энд, так как по более надежным данным из хранилища удалось подвести итоги и тест был признан успешным 🎉
Я бы хотела сказать, что больше подобных случаев не было, к сожалению на этом список не заканчивается, а здесь приведены самые эпичные.
Что общего у этих историй? Ни одну из них не предотвратит знание поправок на множественное тестирование или разницы между тестами Стьюдента и Велча.
Однако со зрелой платформой и культурой экспериментов половина этих фейлов не случилась бы вообще или была отловлена еще при запуске: мониторинг и алерты количества событий, проверка что пользователи реально получают фичу, расчет денежных метрик по DWH, а не по событиям и это далеко не все.
Поэтому немного вечной классики про качество данных: сложные методы хороши, но только после того, как в простых тестах удается добиться максимальной корректности запусков и расчетов на платформе. На отсутствии перезапусков можно очень неплохо улучшить time-to-market, возможно даже лучше, чем внедрением diff-in-diff, CUPED и других модных методов.
В нашем случае все уже не так драматично, мы растем и в процессах и культуре АБ тестов, что уже позволило сократить количество историй выше. Кроме этого, меняем текущую платформу сплитования на более кастомизируемую и современную (угадайте, кто лидирует этот процесс 😎).
А что из неочевидных багов в АБ попадалось вам? Пишите в комментариях 👇