АБ марафон поток 2 - финал ⚔️

Буквально только что провел финальный стрим для ребят со 2 потока марафона АБ тестов.

Каждый запуск для меня - это как маленькая жизнь. Новые люди, ежедневный контакт, ответы на вопросы, проверка домашек.

Хочется чтобы каждый смог забрать с марафона как можно больше знаний и навыков.

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

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

Через 7 дней, 10 марта стартует 3 поток марафона АБ тестов, на него осталось буквально несколько мест. Если хочешь успеть, то пиши мне @borzilo_y

P.S. Сегодня последний день ранней цены, завтра цена вырастет на 5000р

5 реальных причин SRM с которыми я сталкивался на практике

Если не знаете что такое SRM,то читайте эти статьи

https://xn--r1a.website/y_borzilo/398
https://xn--r1a.website/y_borzilo/541
https://xn--r1a.website/y_borzilo/546

А теперь перейдем к практическому опыту

1. SRM из-за отличия в скорости загрузки страниц
Если у вас трекинг попадания пользователя происходит на фронте, т.е. в браузере и скорость загрузки контроля и теста будет сильно отличаться, то часть пользователей медленной страницы могут не дождаться её прогрузки и событие аб теста не успеет улететь в веб-аналитику.

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

2. SRM из-за ошибок в отчетности
Я делал отчет для контроля АБ тестов и тестировал его на "стерильных АБ тестах", где была очень маленькая доля пользователей < 0.001% которые попадали в 2 варианта АБ теста и это никак не аффектило на SRM.

Но потом оказалось, что есть небольшая доля АБ тестов, в которых 0,5% пользователей попадает в несколько вариантов АБ теста и в таких АБ тестах мы выявляли SRM.

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

Почти на всех АБ тестах доля тех кто попадал в 2 варианта эксперимента была очень маленькая и там это ни на что не влияло, а там где было около 0,5% пользователей попадающих в 2 варианта, такой расчет вызывал SRM

3. SRM из-за кук предыдущих экспериментов
В одной из платформ АБ тестов с которой я работал мы постоянно ловили дисбаланс выборок. В контроль всегда попадало больше пользователей чем в тест.

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

Т.е. он не проходил по новой процесс определения варианта в рамках нового АБ теста. Отсюда возникал дисбаланс и контрольная группа всегда получалась больше чем тестовая.

4. SRM из-за редиректов
Этот вариант перекликается с 1 вариантом. Существую схемы организации экспериментов когда пользователь приходит на страницу с экспериментом, сплитование происходит на стороне браузера после определения варианта к которому будет отнесен пользователь если выпал контроль, то продолжают загрузку текущей страницы, а если выпал тест, то пользователя с текущей страницы перенаправляют на другой url адрес.

Как правило редирект занимает какое-то время и тестовая страница грузится дольше чем контрольная и у части пользователей тестового варианта страница не успевает прогрузиться и не успевает улететь событие веб-аналитики в систему трекинга

5. SRM из-за сэмплирования
Системы веб-аналитики, да и некоторые СУБД имеют алгоритм сэмплирования. Это когда берется только часть данных и по ним оценивается реальное число.

Например, у вас по 50000 пользователей в каждом варианте, но включено сэмплирование и система берет 1000 из одного варианта, 800 из другого, по своим алгоритмам определяет "истинное" число.

Потом система вам говорит, что в одном варианте 50000 пользователей, а в другом 48000 пользователей. Вы получаете дисбаланс там где его нет, просто в силу того что в системе работает сэмплирование.

Напоследок напомню, что через 5 дней стартует марафон АБ тестов, где мы тоже будем учиться работать с SRM и другим особенностям АБ

Чем отличается АБ тест и пилотный эксперимент?

АБ тест
АБ тест проводится тогда когда у нас есть некоторый предмет, который мы хотим изменить и посмотреть как изменится эффект от него (метрики). Например есть страница на сайте с формой сбора контактов, сделали копию страницы и новую форму, запускаем АБ тест с 2 версиями страницы и сравниваем метрики по вариантам. Думаю тут всем все понятно.

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

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

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

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

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

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

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

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

Дисперсия - священная корова АБ тестов 🐮
Хочу начать небольшой цикл статей про дисперсию. Сегодня хочу дать интуитивное понимание, что это такое и почему она так важна в контексте АБ тестов.

Начнем с примера. Вот у нас есть интернет магазин где пользователи совершают покупки и мы решили провести АБ тест формы оформления заказа. Вариант А - длинная форма заказа, вариант Б- короткая форма заказа

В итоге собрали выборки пользователей по суммам их заказов

Вариант А: 500, 0, 700, 0, 1000, 0, 1200 - среднее 485,7
Вариант Б: 3000, 800, 200, 0, 500, 0, 0 - среднее 642,85

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

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

Но тут встают 2 проблемы
1. Мы не можем собрать всех потенциальных пользователей и оценить по ним метрику.
Т.к. это зачастую просто не реально, мы не можем дотянуться до всех.

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

Например
Вариант А: 300, 400, 3000, 0, 100, 600, 500 - среднее 700
Вариант Б: 0, 200, 900, 700, 2000, 0, 0 - среднее 542

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

1 - В силу того что мы случайно отбираем пользователей в группы и вот чисто в силу случая в одну выборку попало больше тех кто заплатил больше.
2 - Дисперсия. Это мера разброса(изменчивости) значений метрики.

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

Вариант А: 100, 100, 100, 100, 100, 100, 100 - среднее 100
Вариант Б: 200, 200, 200, 200, 200, 200, 200 - среднее 200

В данном случае у нас дисперсия будет равна 0. Т.е. нет никакой изменчивости по наблюдениям, они все одинаковы в рамках выборок и ГС.

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

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

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

Дорогие девушки! С праздником 8 марта. В этот день не думайте про АБ тесты и аналитику. Посвятите день отдыху и заботе о себе. SQL, python, дашборды никуда не денутся. С праздником💐💐💐

Стартанули сегодня 3 поток марафона АБ тестов

Будем решать кейс по поиску точки роста в интернет магазине.

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

Если кто-то из тех кто записывался потерялся, то напишите мне пожалуйста @borzilo_y

Напомню, что у нас есть уютный чат где обсуждается много интересных тем, вот из последнего

1. Догфудинг - исследования для бедных
2. АБ тесты не нужны - разгоняем холивар по высказыванию главы гроухака revolut
3. Хороший продукт - работает сразу, остальное скорее всего мишура
4. Пятерочко-дни как базис наблюдения для оффлайн экспериментов в магазинах

Присоединяйся и дай волю своему батхерту, если что-то из тем тебя задело https://xn--r1a.website/bor_chat

Стоит ли использовать пятерочки-дни в качестве единицы наблюдения в оффлайн экспериментах с магазинами?

Это пост-саммари. По результатам разбора вопроса экспертным советом нашего чата

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

- Отдельный клиент магазина. Мы не можем в одном магазине показать одному клиенту одну выкладку товара, а другому в этот же момент другую.

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

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

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

Ниже еще важные нюансы и предложения по этой ситуации

1. Нужно подбирать не просто пятерочка-дни, а пятерочка-"кластер_времени", когда подобранные на А/А при прогоне ~10к итерации будет контроль ошибки 1го рода на заданном уровне. И не факт, что это (как затея) сработает, сразу скажу!

Для прочих: основная идея пятерочка-дней в том, что работают, скажем, две разные смены, а значит эта точка не столько единый магазин, сколько две "разные" точки. В этом смысле у нас, с некоторыми оговорками, увеличиваются данные на тест за тот же период.
(с) Сергей Матросов

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

3. Я бы просто в регрессионную модель положил эти смены, дни недели и что там ещё вас смущает как ковариаты. Дёшево и сердито.
(c) Матвей Славенко

4. Пятерочка-дни мусор. Используй causal inference
(c) Анонимный источник из X5

5. Ссылка на пост Валеры Бабушкина

Чтобы я спрашивал у кандидата на собесе на продуктового аналитика?👔

Недавно мне задали такой вопрос. Решил написать про это свое мнение.

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


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

1. Системное понимание бизнеса
Меня всегда корежит когда меня зовут собеседоваться на позиции под названием "аналитик-разработчик". Какой я вам разработчик, может еще предложите алгоритмы выучить? Для меня продуктовая аналитика это про бизнес. Т.е. это такой "экономист" новой цифровой эпохи, а в место предприятия у него продукт.

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

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

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

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

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

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

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

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

3. Техничка sql, python
Сразу скажу, я сам не люблю эту секцию на собесах и часто её заваливаю, т.к. мне это в целом не интересно как аналитику, если бы я любил прогать, пошел бы в разрабы. Считаю если человек имеет реальный опыт работы аналитиком, то скорее всего sql писать он умеет.

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

А у вас какое мнение? Если согласны, пишите в комменты. если не согласны - тем более пишите в комменты😏

А расскажи как провести АБ тест?

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

У тебя есть проекты, по ним есть KPI. Твоя задача понять как из точки А прийти в точку Б. Для этого делаем исследования, пилим стратегию, делаем позиционирование продукту, оптимизируем конверсию, тестим рекламные кампании, собираем фидбек, анализируем метрики и вот в этом всем я жил 8 лет, пока не стал аналитиком)

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

Python блажь собеседований или реальная потребность бизнеса?

Давайте поговорим о том в каком объеме продуктовому аналитику надо знать питон и уметь прогать?

Расскажите как часто вы используете python и в каких кейсах.

На мой взгляд этот навык переоценен, в том плане что на собесе вас будут просить решать задачи на питоне, а потом может оказаться, что он вам будет нужен только раз в полгода и то на уровне крутить данные в pandas, а не прогать ООП с алгоритмами))

Приобрел книженцию. Читали уже?

Нашел в линкедыне

Решил выгрузить из головы список ошибок, которые можно допустить при анализе трафика.

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

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