Придумал поговорку: Покажи мне свой data quality и я скажу какой у тебя data driven 😁

АА тесты какие и когда применять ⚒

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

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

❇️ 1. Реальные АА тесты в проде на живых пользователях
Такие АА тесты позволяют проверить полностью весть setup эксперимента. Под setupом эксперимента я имею в виду, сплитовалку, инфраструктуру, трекинг, реализацию самих вариантов, метрики, стат критерий.

Технические проблемы могут приводить к тому, что ваши выборки будут неоднородны и разбалансированы и как следствие метрики будут прокрашиваться чаще чем в 5% случаев. Либо вы можете использовать неподходящий стат критерий для метрик и тогда тоже будете получать завышенный FPR.

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

Например если 5 из 10 АА тестов прокрасились, то скорее всего где-то проблема. Если 1 из 10 то может это случайность. В идеале нам нужны 1000 АА тестов, но делать их в проде долго. Дальше мы рассмотрим другой вариант.

❇️ 2. Симуляции АА тестов на основе данных реального АА теста
Мы запустили АА тест, собрали данные. Теперь мы можем взять каждую из выборок и насемплировать из них подвыборки и сравнить их между собой с помощью стат теста, например 1000 симуляций АА тестов.

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

❇️ 3. Искусственные АА тесты сплитовалки
Сплитовалка сервис, который присваивает варианты АБ тестов. Как правило у сплитовалок есть api, куда отправляют запрос, а в ответ получаю вариант экспа.

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

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


❇️ 4. Симуляция АА тестов на исторических данных для валидации метрик и стат тестов
Здесь идея в том, что мы берем некоторые реальные исторические данные, на которых считаем наши метрики. При помощи python у себя на компе генерим из этих данных выборки, загоняем нашу метрику в стат тест и оцениваем на 1000-10000 симуляций АА тестов, выдерживает ли связка метрика - стат критерий долю ложно-положительных прокрасов на уровне альфа.


❇️ 5. Модельные симуляции АА тестов
Иногда в результате реальных АА и АБ тестов вы можете получить какие-то неожиданные результаты или какое-то непонятное для вас распределение метрик.

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

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

#ab

Вчера говорят Google Big Query и Looker studio заблочили в РФ. Успели пересесть на что-то или как справляетесь?

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

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

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

#хиханьки

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно или нет использовать t test для выборок с не нормальным распределением? Узнай правду первым. Присоединяйся к чату https://xn--r1a.website/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 < альфа в течении скольки-то дней"?