Собрал большой список вопросов(около 90) для диагностики процесса АБ тестов в командах. Пройдя по нему можно найти точки улучшения своих АБ тестов.

P.S. Это не чек-лист, а именно список вопросов для диагностики, интерпретация - это отдельный квест, который должен выполнять специалист, который в этом понимает

Когда пытаешься разобраться почему данные в отчётах расходятся

#хиханьки

Эффекты первичности и новизны в АБ тестах

Начнем с примеров, чтобы понять, что это такое.

Эффект первичности
Возьмем банковское приложение. Хотим протестировать гипотезу о том, что если перенести кнопку оплаты в новое место на экране, то это уменьшит время, которое нужно пользователю, чтобы провести платеж.

Провели АБ тест в течении недели и увидели, что время в тестовой группе выросло, а мы ожидали что пользователи быстрее будут проводить платеж.

Что произошло?
Аудитория приложения - текущие клиенты банка. Оплата - это регулярная операция. У пользователя уже выстроился некоторый паттерн решения этой задачи завязанный на текущий интерфейс приложения.

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

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


Эффект новизны
Возьмем снова банковское приложение. К примеру мы запустили новый баннер с рекламой кэшбека и хотим сравнить его эффективность с предыдущим баннером рекламирующим кэшбек.

Провели АБ тест в течении недели, увидели что кликабельность нового баннера выше. Тут может быть подвох.

Возможно пользователи попавшие в тестовую группу кликают на новый баннер не потому что там реально классное предложение, а потому что это просто что-то новенькое и им любопытно.

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

Как распознать эти эффекты?
Для начала скажем, что эти эффекты в основном возникают когда вы проводите АБ на аудитории старых пользователей или текущих клиентах, т.е. тех у кого уже есть какой-то опыт работы с вашим продуктом.

Если пользователи новые то и контрольный и тестовый вариант будут давать новый опыт пользователям, в обоих группах.

Один из способов понять есть ли эти эффекты это взглянуть на динамику целевого показателя построенного по дням без накопительного итога.

Если перенести на наши примеры, то в случае эффекта первичности мы все же должны будем увидеть тренд на сокращение времени на оплату от дня ко дню, т.к. пользователи учатся новому паттерну.

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

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

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

Привет! Какую бы тему вы хотели чтобы я осветил в канале?

Кто-нибудь попробовал воспользоваться этой штукой?

Удалось извлечь пользу?

Как понять, что пора делать АБ тесты и понять, что это даст ценность для бизнеса?

Недавно я попросил подписчиков написать вопросы на которые они хотели бы получить ответ от меня. Один из участников сообщества задал вопрос:

Как из пальца высосать обоснование необходимости использования АБ-тестирования, если очень хочется их проводить, но ресурса нет и не предвидится?

Ну а если серьёзно, то как понять, что настал тот час, когда уже пора начинать проводить АБ-тесты и что это даст реальный value

Мне эти вопросы показались интересными поэтому давайте поговорим про это.

Ценность АБ тестов для бизнеса
Давайте начнем с примера. Вот мы добавили в продукт или куда-то еще новый функционал или выкатили новый оффер. Как он может повлиять на бизнес и нужные нам метрики?

1. Никак не повлиять, все останется как и без новой фичи
2. Улучшить бизнес результат и метрики
3. Ухудшить бизнес результат и метрики

Вариант 1 и 2 по сути не несут никаких рисков, т.к. мы либо ничего не меняем, либо работаем в плюс. Но также есть и 3 вариант, что мы можем получить ухудшение от нововведения и загнать бизнес в минус.

На мой взгляд основная ценность от АБ теста для бизнеса, то что мы можем выявлять негативные изменения и отказываться от них.

Вы можете возразить, но ведь и без АБ теста можно понять стало лучше или хуже. Отчасти это правда, но зачастую нет.

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

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

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

Вам шашечки или ехать?
В компаниях я встречаю 2 подхода. Одни команды "делают проекты" другие "растят метрики".

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

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

Другой вариант когда команда "растит метрики". У них есть какие-то планы по деньгам, ключевым метрикам. Соответственно у них 2 задачи делать такие изменения которые будут растить метрики и не делать изменения, которые будут ухудшать метрики. Вот эти ребята на мой взгляд очень заинтересованы в АБ тестах, т.к. они хорошо снижают риск того что они ухудшат свои метрики и как следствие не выполнят свои планы.

Как получить обоснование на АБ тесты?
На мой взгляд лучшее обоснование - это хорошенько обосраться, т.е. сильно уронить метрики, которые важны для бизнеса, чтобы всё это дошло до ТОПов компании, тогда все вспотеют и будут искать способы этого не допустить в будущем и придут к идеи, что нам нужны АБ тесты.

В чате обсуждается "вопрос тысячелетия", с которым сталкивается любой АБ тестер.

Можно или нет использовать t test для выборок с не нормальным распределением? Узнай правду первым. Присоединяйся к чату https://t.me/bor_chat

Как отличить новичка от опытного аналитика?

Опытный аналитик, как и человек с опытом в любой области совершил много ошибок, а новичок знает только правильный путь (а может и его не знает). Поэтому я бы заготовил несколько типовых кейсов с ошибками и попросил бы отыскать ошибки и объяснить почему это ошибка.

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

Другой способ - это взять несколько сложных мемов из моего канала и попросить объяснить в чем там прикол 😁

Когда захожу на маркетплейсы, то всегда думаю о том что скорее всего какой-то ml алгоритм построил выдачу с оптимизацией на максимизацию прибыли, поэтому скролю и ищу какие-то интересные варианты товаров, которые не выгодны маркетплейсу, но выгодны мне.

А зачем вам эта аналитика? Может лучше что-то другое?

Наглядно про ошибку первого рода

На графике изображена симуляция АА теста по дням проведения и расчет p-value.

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

На графике видно, что АА тест идет 30 дней. Логика: каждый день в эксперимент добавляются новые наблюдения и считается суммарня конверсия на каждый день, а на график выводится p-value посчитанное на каждый день. В 8 и 9 день мы видим, что p-value < 0,05.

Но мы знаем, что это искусственная генерация АА теста и никаких отличий в ГС из которой берутся выборки нет и мы не должны получать стат значимые отличия, но как видите мы их получили в 8 и 9 день - это и есть ошибки первого рода.

Поэтому так важно "не подглядывать" и только 1 раз принимать решение при классическом сэтапе экспериментов, т.к. если бы вы проверили на 8 или 9 день АБ тест в котором нет никакой разницы, то могли бы посчитать, что она есть и получить ошибку, а вот на 30 день её нет.

Проблема в том что случайность нам не подвластна и мы не знаем в какой именно из дней может возникнуть ложноположительный результат, он мог быть и в 30.

Поэтому строгое соблюдение регламента проведения АБ тестов помогает удерживать ложноположительные результаты в пределах альфы, в рамках нашего скоупа экспериментов.

В коментах к посту задали вопрос:

Что думаешь на счет того, чтобы смотреть динамику p-value по дням? Чтобы как раз не попадать в случайный прокрас

1. А сколько именно дней после сбора наблюдений надо смотреть динамику p-value? 3 дня или 7 или 10? Какой-то внятной стат теории под этим подходом я не знаю. (Если кто-то знает поделитесь плиз)

Вот на скрине методом недолгого перебора нашел комбинацию устойчивого p-value < 0,05 в течении 6 дней в конце симуляции АА теста. Так что наличие плато может быть тоже случайностью.

2. Это увеличивает вероятность ошибки первого рода, т.к. по сути мы пытаемся несколько раз принять решение

3. С учетом того, что мы хотим проводить много АБ тестов, то это может тормозить нашу очередь АБ тестов, а значит замедляет time to market продукта


А у вас какое мнение на счет "смотреть на выход в плато p-value < альфа в течении скольки-то дней"?