A/B тесты. Чем полезны продуктовые эксперименты

Всем привет! Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которыми можно поговорить простым человеческим языком. Дорогие друзья, это последний эпизод седьмого сезона нашего подкаста. Для того, чтобы восьмой сезон понравился вам ещё больше, мы подготовили опрос. Ссылка на него лежит в описании к этому эпизоду. Вообще, нам, команде подкаста, очень нравится, когда вы, дорогие слушатели, нам пишете. Написать нам можно двумя способами. Либо на e-mail, Либо в Телеграме у нас есть специальный чатик для слушателей подкастов, там уже почти 1000 человек. Приходите, делитесь эмоциями, задавайте вопросы, там классно. И наконец, пожалуйста, поставьте нам 5 звезд или напишите комментарий в Apple. Для меня это очень важно. Сегодня будем говорить о АБ-тестировании. И вы, возможно, никогда о такой штуке не слышали. На самом деле, АБ-тестирование применяется в IT, в сервисах, в стартапах и в целом в современной жизни довольно часто. Что это такое, как корпорации ставят над нами эксперименты и почему это не так уж и плохо, мы узнаем в этом эпизоде. Это подкаст «Студия Либо-Либо», и мы его сделали вместе с сервисом онлайн-образования «Яндекс Практикум». Если вы давно слушаете этот подкаст, то вы могли задуматься о том, чтобы стать программистом. Программирование и IT— это огромная сфера, и для начинающих вообще непонятно, в чем разница между бэкэнд-разработкой, фронтэнд, веб-разработкой или, может быть, мобильной разработкой— iOS и Android. Если вы об этом задумываетесь, но не можете выбрать, чем же вам все-таки начать заниматься, то специально для вас есть курс Яндекс.Практикума. Он называется «Проф.Ориентация». Курс двухчасовой, бесплатный. Ссылка в описании к этому эпизоду.

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

Виталий, что такое аботестирование для людей, которые вообще ничего про это не слышали никогда? Для чего аботестирование применяется?

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

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

Тестировать можно всё, что угодно. Есть UI-ные эксперименты, есть эксперименты на ценах, когда мы, например, пытаемся менять цены. Есть эксперименты на операционной деятельности бизнеса, есть офлайн-эксперименты, онлайн-эксперименты. В общем, это достаточно не такой всеобъемлющий процесс. По факту очень много процессов и таких сложных завязанных на АБ-тестах, и они просто не могут без них быть, потому что это единственный способ оценить причинно-следственную связь. Все остальное— это пальцем в небо.

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

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

Можешь для того, чтобы было как-то более наглядно, привести примеры, все-таки, реальный, конкретный пример, гипотез, которые были вот в недавних твоих проектах, например?

Вот, давай возьмем большой ритейл.

Условная пятерочка, x5 или что-нибудь такое?

Ну, условная. Он работает в детском сегменте.

Хорошо.

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

Это на сайте где-то или в приложении?

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

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

Они не будут отличаться с точки зрения процесса проведения АБТеста, то есть эксперимента. То есть мы точно так же разделим аудиторию, что-то посчитаем, сделаем какой-то вывод и так далее. Они отличаются, наверное, на уровне самой обстоятельности идей. То есть до бесконечности кнопки красить невозможно, и, наверное, в зрелом продукте, который уже сформировавшийся, перекрашивая кнопки, навряд ли ты чего-то значимого добьешься. То есть, чем продукт моложе, тем больше можно хватать вот эти вот низко висящие плоды (low-hanging fruit) и тестировать очень базовые вещи, на основе которых мы можем что-то вырасти. Но, опять же-таки, в зависимости от типа бизнеса, то есть, если мы говорим о транзакционном бизнесе, в котором основная цель это продать, заработать, доставить и так далее, заниматься маленькими UI-ными изменениями на зрелом продукте, но, наверное, будет достаточно сложно потом это UI-ные изменения оцифровать в деньги. При всем при этом, например, может быть какой-нибудь Яндекс.Поиск, и, например, ребятки захотят перекрасить, я не знаю, цвет ссылок. в какой-то другой цвет. Но здесь уже будет зависеть нисколько от того, что мы тестируем, а чем мы измеряем. То есть, какую метрику мы возьмем, на основе которых мы дадим заключение о том, что цвет действительно на что-то влияет. Если мы цвет будем мерить средним чеком, например, в интернет-магазине, скорее всего, мы ничего не увидим. Но если мы сможем подобрать какую-то релевантную

метрику... Типа, как часто люди возвращаются, потому что этот цвет напоминает им цвет детства или еще что-нибудь такое?

Ну, например.

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

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

Мы всё время говорим А и Б. А реально обычно сравнят два варианта или больше?

В зависимости от. Часто продуктовые команды порываются делать много гипотез. Есть нашумевший кейс, когда Google в Gmail протестировали 40 оттенков ссылочек. 40 оттенков синего.

Типа какой цвет больше нравится пользователю?

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

Так, хорошо.

Какой ответ мы можем получить? Мы получаем ответ... Беременный, не беременный. Да, но усложняется этот ответ вероятностными ответами. У нас есть false positive, ложноположительное решение. Ложно-негативное решение и истинно-положительное решение. Что такое false positive rate, то есть ложно-положительное? Когда мы говорим, что девушка не беременна, а мы говорим, что она беременна. Что такое true positive? Когда девушка беременна, и мы получаем ответ, что она действительно беременна. И вот степень эффективности АБ-тестов мы замеряем как раз-таки при помощи false positive, то есть альфа или p-value. То есть вот это пресловутое p-value— это наш false positive.

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

Абсолютно правильно. И когда мы тестируем 40 вариантов, во что мы попадаем? Когда мы многократно сравниваем объект с объектом, то есть у нас 40 объектов, и мы хотим сравнить эти 40 объектов попарно. То есть мы что делаем? Мы вероятности перемножаем, правильно? И раз мы перенажаем вероятность, то у нас возрастает вероятность ложноположительного решения. То есть у нас выше вероятность того, что мы скажем, что разница есть там, где разницы нет. И поэтому мы должны эту ложноположительную вероятность всячески корректировать. Делая дополнительные коррекции, нам придётся увеличивать объём трафика.

То есть ещё больше экспериментов надо провести? еще больше людей нужно.

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

Это 40 умножить на 40 или это 40 в 40-й степени?

40 в 40-й степени. Прикольно.

То есть проверять лучше два варианта от греха подальше.

Лучше два. У нас есть разные подходы, как это делается. То есть чем больше продукт, тем гибче он может подходить к этой истории. Мы можем брать очень заниженную вероятность false positive rate, то есть ложную положительную вероятность, и тем самым нивелировать вот эти неприятные прецеденты. То есть, например, там, Авито, Яндекс, VK, Google, Netflix и так далее могут себе это позволить. Если вы маленький продукт, стартапчик, конечно же, вам в этой парадигме будет жить сложно, и лучше тестировать А и Б, и получить побольше тестов, чем ложное принятое решение в процессе эксперимента.

Я хочу сделать шаг назад и спросить тебя про деление пользователей на группы. Мы всех пользователей сервиса должны поделить на две группы или достаточно взять только какую-то часть пользователей?

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

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

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

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

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

если вы слушаете наш подкаст давно, то вы наверняка знаете, что когда я хочу разобраться в рекрутинге, в найме, в рынке труда, я зову Киру Кузьменко, потому что Кира— один из лучших IT-рекрутеров России. Так вот, Кира и студия Либо-Либо запускают новый подкаст о том, как устроиться на работу за рубежом. На конкретных примерах они разбираются, какие ошибки мы обычно допускаем и как их преодолеть. Первый кейс, первый эпизод— о project-менеджере, который пытается устроиться на работу в Финляндии. Очень классный подкаст. Называется Собес. Доступен на всех ведущих платформах. Ссылка в описании к этому эпизоду.

Можешь на примере объяснить? Вот у меня есть, например, вот мой сайт, я на нем хочу ввести типа черную тему и понять, нужна она людям или нет. Что мне нужно учесть для того, чтобы поделить пользователей на группы?

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

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

Да. И что мы хотим от системы сплитования? Первое, мы хотим, соответствуя правилам того, как мы указали в настройках разделения, чтобы эти настройки выполнялись по факту. Например, мы в настройках указали то, что мы хотим, чтобы наша аудитория делилась 50 на 50, да, то есть 50% в группу А, 50% в группу Б. Бывает так, что это правило не выполняется. Мы в настройках указали 50 на 50, по факту мы получаем там 60 на 40, то есть мы получаем какое-то смещение. Чем больше это смещение, тем это критичнее, потому что в данном случае инструмент не подконтролен нам. Вторая составляющая— это пересечение. Это когда у нас пользователи оказываются и в группе A, и в группе B, то есть мы их перемешиваем. Чревато это тем, что если я увидел и вариант A, и вариант B, мое поведение, очевидно, будет меняться.

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

Да, именно. Третья составляющая, которую мы тоже хотим отслеживать, это баланс по стратам. Что это такое? Страты, давай представим, что это какой-то сегмент. Допустим, я пользователь из Москвы, ты пользователь из Риги. Я хотел бы, чтобы если в моей группе пользователи из Москвы... в группе А пользователи из Москвы 30%, чтобы в группе Б пользователи из Москвы тоже было 30% плюс-минус какая-то погрешность, но не статзначимая.

Логично. Ну да, потому что иначе я буду Москву и Ригу, а не просто обычных, ну типа, а не просто людей.

Конечно. Тогда как бы если у меня дисбаланс в каком-то сегменте, этот дисбаланс будет объяснять изменения в метрике. То есть не моя гипотеза объясняет изменения в метрике, а это дисбаланс. Ну и последнее, что хотелось бы сказать, это false positive rate, вероятность ложноположительного решения. Если мы будем много раз сравнивать группу А с группой А и получать большое количество ложноположительных решений, в нашем случае, значит, система сплитования тоже не работает, потому что мы сравниваем два одинаковых объекта, А, и

результаты должны быть одинаковыми.

Да, они должны быть... Нет, они должны быть одинаковыми.

Плюс-минус.

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

Уже после начала эксперимента, ты имеешь в виду?

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

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

Чтобы понять, какой вариант лучше, тебе нужно собрать определенную выборку. Размер этой выборки определяется разными факторами, например, величиной лифта, то есть насколько сильно группа А отличается от группы Б. Чем больше вот это вот относительное изменение, то есть чем больше у тебя прирост, тем меньше тебе нужна трафика, чтобы этот прирост обнаружить. Но есть вторая составляющая. Помимо того, что у нас есть сигнал, вот эта вот относительная разница, это сигнал, который мы хотим замерить, то есть это наш прирост. у нас есть шум, это дисперсия, т.е. насколько сильно наше среднее будет отличаться от каждого значения в нашей выборке. Чем больше шума, т.е. дисперсия, тем больше нам требуется данных. Это второй фактор. Т.е. первый фактор— это размер изменения, который мы замечаем. Второй фактор— это насколько шумны наши данные. И вот на балансе между размером эффекта и шумом мы будем пытаться рассчитывать, сколько нам необходимо трафика. То есть есть такая штука, как дизайн эксперимента, то есть мы до того, как запускаем ABO-тест, пытаемся предрассчитать, то есть спрогнозировать, сколько нам необходимо наблюдений, чтобы с достаточным уровнем уверенности утверждать, что этот результат будет статистически значимым и так далее, и так далее, и так далее.

Про дисперсию мне стало понятно. Это про то, что если на 10 тысяч … только на 10 долларов, то нам маленького количества людей раз проверки хватит для того, чтобы уверенно сказать, что A лучше, чем B. А если они покупают примерно одинаково, то тогда, наверное, нужно больше экспериментов, чтобы уверенно сказать.

Да, да, да. То есть чем лучше или хуже перформит одна из групп, то есть, например, если мы сделали такую крутую гипотезу, то что пользователи стали в три раза больше, покупать, то нам нужно меньше времени на эксперимент. Но я опять усложню, но это надо усложнить. Не только самим временем определяется эксперимент. То есть у нас есть, например, метрика, да? Давай вот представим себе, что у метрики есть временное окно. Ну, то есть пользователь же зашел на наш сайт, например, на интернет-магазин. Он же не в секунду принимает решение о том, что он хочет купить. Он пришёл, посмотрел, положил в корзину, ушёл, сравнил с конкурентами, опять пришёл... Обсудил с женой. Обсудил с женой. И вот период от первого действия до закрытия этого действия, то есть первое действие я зашёл, второе действие я купил. Вот этот промежуток, это называется временное окно. И если у нашей метрики большое временное окно, например, от момента первого действия до момента закрытия действия проходит три недели, даже если мы собрали весь необходимый трафик за два дня, нам все равно нужно учитывать временное окно, потому что ты метрику заметишь только через какой-то промежуток времени. Это тоже важно учитывать, это тоже накладывает определенные отпечатки на качество эксперимента и так далее.

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

На самом деле, можно по-разному сделать. Ну, то есть, есть продукты, в которых условно в CMS-ке заложена какая-то логика АБ-тестирования. То есть, у нас есть Допустим, какой-то OfferLake, в котором хранятся какие-то изменения на продукте. Мы из CMS стучимся в OfferLake и там разбиваем пользователя и отрисовываем это изменение для пользователя. Может быть, какое-то внешнее решение со сплитованием, то есть у нас есть сайт, мы там ставим какой-нибудь конфликт, JS на сайт, он обращается к нашему сервису, говорит, вот этого пользователя отправь вот сюда. Дополнительно у нас есть какие-то фича-флаги, которые говорят, что если пользователь вот здесь, то отрисуем вот это. И таким образом у нас A/B-тест. Дополнительно в этой же системе мы, например, прописываем правила сплитования, то есть на кого мы это сплитуем, как сплитуем и так далее. Ну и, как правило, сейчас, наверное, многие стараются держать как внешний сервис. Соответственно, есть команды, которые делают эти решения внутри, то есть поддерживают их in-house. Есть команды, которые закупают решения у внешних вендоров.

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

Не должен заметить, но есть разные кейсы. Давай расскажу, в каких случаях пользователь может заметить, что он в АБ-тесте. Есть такой инструмент, например, Google Tag Manager.

Это штука, через которую все подключают аналитику и другие всякие штуки.

Да, аналитику, дополнительные пиксели. И, например, через Google Tag Manager, учитывая то, что мы можем поставить какой-то код какого-то сервиса, через который мы будем запускать АБТест. Внутри это у тебя набор определенных тегов, которые активируются по какому-то правилу. Пользователь зашел на любую страничку, активируя ему вот этот скрипт, который дальше обратится к какому-то сервису, который дальше отрисует что-то на сайте. То есть внутри Google Tag Manager есть тег, сам Google Tag Manager— это какой-то тег, у нас есть дом-дерево, то есть как-то это будет прогружаться асинхронно. пользователь может зайти на сайт, у него сначала прогрузится Google Tag Manager, потом прогрузится содержимое Google Tag Manager, и в итоге что может получиться? То, что пользователь сначала увидит одну страничку, а через секунду у него перерисуется какой-то контент, и он увидит другое содержимое. Вот в этом случае пользователь увидит то, что он в АБ-тесте.

Я с таким сталкивался. Сайт загружается, и там что-то меняется после загрузки. Это я как раз попал в АБ-тест.

Скорее всего, ты попал в АБ-тест, который запущен вот под такой логикой.

Ну, это просто плохо напрогано.

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

Потому что мы с помощью кук как раз определяем, мы ставим человеку куку, чтобы...

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

А если человек заходит с двух разных компьютеров, он увидит две разные версии сайта?

Если мы идентифицируем его по кукам, да.

А если он авторизуется на сайт, тогда мы уже как пользователи можем?

Да, тут, соответственно, он увидит один и тот же вариант.

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

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

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

Ой, это очень крутая штука.

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

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

Типа возвраты.—

Да, возвраты. Возвраты на какой-то промежуток времени. Мы можем считать просто возвраты, как вот вернулся или нет. А можно считать частоту, то есть сколько раз внутри какого-то временного промежутка пользователь послушал. Например, в месяц в среднем один пользователь слушает там три раза. У нас уже три метрики, которые в целом отцифруют эффективность твоего контента и заинтересованность им пользователей. На самом деле можно еще одну прикольную метрику придумать. Шеринговая история. Как много поделились этим подкастом, например. Тоже отличная метрика, потому что это органический рост твоей аудитории, что тебе тоже, безусловно, интересно. Но самое сложное в данном случае это создать алгоритм сплитования. То есть то, как мы будем разделять наших слушателей на группу А, например, которые будут слушать исходную версию подкаста, и группу Б, где мы будем давать более хардкорную информацию. Например, не будем разжевывать каждый термин, а будем прям вот по харду рассказывать, как все оно есть. Есть ситуации, как наша, например, когда мы разделить наших пользователей не можем. по разным обстоятельствам. И здесь могут работать так называемые квази-эксперименты, когда у нас нет честного деления. Это эксперименты на базе определенных алгоритмов с использованием машинного обучения. Например, что мы могли бы сделать? Вот у нас есть наш подкаст, он идёт постоянно одинаково с одним и тем же типом контента. У нас есть какой-то определённый примежуток времени. После какого-то другого примежутка времени мы взяли и начали записывать хардкорный подкаст.

То есть мы делим не людей, а делим время, в которое мы работаем на разные типы.

Да, но здесь что важно учесть, что если мы просто сравним два временных периода, например, период, если мы сравним сентябрь с октябрем, Так нельзя сделать.

Почему?

Потому что у нас есть разные внешние факторы. Что такое внешние факторы?

Сезонность, например.

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

То есть сравнить нужно с поправкой.

С небольшой коррекцией, да. Мы можем... взять нашу модельку, взять определенные фичи, на основе которых мы будем обучать эту модельку, я сейчас очень упрощаю, и мы можем сделать определенный предикт, условно, что было бы, если бы вот этого вот хардкорного подкаста не было, и сделать синтетический контроль, то есть синтетическую контрольную группу, и сравнить теперь предсказанную на исторических донорах синтетическую контрольную группу с фактической метрикой. И вот провести вот такой вот квази-эксперимент. Такие подходы часто используются тогда, когда у нас нет возможности разделить нашу аудиторию на группу А и группу Б соответственно. В такси-сервисах они используются, Uber много такое делает, Facebook вот. И вот таким образом мы можем провести соответствующий эксперимент на подкасте. Либо заставить Apple сделать функциональность по АБ-тестам.

Очень прикольно, что можно даже неделя после на группе провести АБ-тест. Я сейчас хочу просуммировать пока то, что мы обсудили, чтобы как-то подвести итог. Значит, АБТест— это способ проверить гипотезу о том, какой вариант нашего сайта или какого продукта, или вообще чего угодно, какой вариант лучше за счет того, что мы одной группе пользователей даем один вариант, другой группе пользователей— второй вариант, и сравниваем, какой вариант лучше по результату. Единственное, не делить пользователей на группы, а можно поделить время на группы и в одном месяце делать одно, в другом месяце другое и сравнивать эти месяцы с поправкой на то, как бы это все менялось в отсутствие эксперимента. Виталий, я хочу истории из ада, потому что, судя по тому, что ты рассказываешь, это очень большая и сложная система. По моему опыту как техдира, если есть большая и сложная система, то она 100% глючит хоть в какой-то момент времени. Как эти глюки могут выглядеть? Вспомни что-нибудь из своей практики, самое веселое.

Ну, давай расскажу. Один сервис, большой такой сервис, логистически сплетовались курьеры. У курьеров есть определенные признаки, то есть там провели сегментацию, есть, условно, новички-курьеры, средние курьеры и премиальные курьеры. Премиальные курьеры это чуваки, которые типа-то не опаздывают, давно работают, у них хорошие отзывы, ну, в общем, которым есть доверие и со стороны того, кто предоставляет услугу, и тех, кто получает услугу. Ребята гоняли АБТ-тесты, делали какие-то выводы, но потом начали замечать то, что как-то вот странно все происходит, то есть много АБТ-тестов, которые заканчиваются положительно, то есть альтернативный вариант, то есть гипотеза над контролем выигрывает, но потом ничего не наблюдаем. обратились к нам, мы начали выяснять, выяснили, что так получается, что в одной из групп всегда превалируют очень сильно премиальные курьеры. То есть в одной из групп премиальных курьеров как минимум на 60% больше всегда. Господи... И в итоге результат эксперимента объясняется просто тем, что премиальные курьеры получают по всем фронтам лучше. То есть они получают от пользователей лучше, от продукта лучше, скорость у них выше, качество выше и так далее. Это просто был косяк на уровне системы сплетования, и по факту все эксперименты, которые проводились в каком-то временном промежутке, были как бы сломаны. Да, можно накостылить. и там сбалансировать всю эту историю, но это костыль, и в данном случае просто надо все переписывать. Очень часто эксперименты ломаются именно на уровне сломанной системы сплитования, потому что просто подумали то, что это слишком просто, просто сделаем обычный рандомайзер, и все будет работать. На самом деле нет, и в итоге может быть крутой процесс продуктовый, но вот этот вот моментик, связанный со сплитом, Он сломанный, и в итоге все эксперименты проводятся соответствующим образом.

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

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

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

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

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

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

А, можно пересекать, не обязательно всех моих пользователей.

Да, мы можем пересекать, но при определенном условии.

Вау, вот в этот момент сплетование становится сложным.

Да. А, например, представь себе другую ситуацию. Представь себе то, что ты запустил АБТест, и у тебя два сервиса, которые обеспечивают твою гипотезу, они конфликтуют с друг другом. Такое ведь может быть чисто теоретически? Может быть. Тогда тебе нужно сделать что-то, чтобы у тебя пользователи просто не могли пересечься между двумя вот этими алгоритмами. Значит, тебе нужно создать слой. У тебя будет слой, например, поиска и слой ещё какой-нибудь. И в этом случае как бы у тебя... Внутри этого слоя у тебя эксперименты не пересекаются. И в этом слое ты можешь создавать конфликтующие по функциональности эксперименты, зная то, что пользователи не пересекутся.

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

Ой, слушай, не скажу, сколько в один момент времени. Ну, например, какой-нибудь... Большой продукт Яндекс, я думаю, в год может спокойно выпускать там полторы-две тысячи A/B-тестов.

Вау! Это примерно по три АБТ-теста в день.

Ну да.

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

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

Мы должны посмотреть сначала на нашу метрику. Насколько у нее большая дисперсия, насколько она шумная.

Если все открывают две страницы, дисперсия 0. Если все открывают разное количество страниц, дисперсия большая, да?

Ну, то есть да. условно, дисперсия, это насколько каждый пользователь, который открывает странички, отличается от среднего количества открытых страничек. Чем больше наш шум, то есть чем больше наша дисперсия, тем больше нам данных требуется, потому что очевидно, да, что слишком большой размах наших данных. Дальше есть наша ошибка первого рода. Это false positive rate.

Так, false positive, значит, я думаю, что типа черная тема классная, на самом деле она не классная.

Да, она не классная, да. Чем меньше мы хотим иметь ошибки первого рода, тем больше нам нужна трафика, то есть чем больше нам нужно наблюдений. И вот есть ошибка. А еще есть еще одна метрика вероятностная, которую тоже нужно важно учитывать. Это уже true positive, то есть вероятность обнаружить изменения там, где оно действительно есть. То есть условно, с какой вероятностью тест мне скажет, что я болею, когда я действительно болею? Как это измеряется? Чем выше величина нашего изменения, тем более вероятно мы это изменение обнаружим. Но вероятность обнаружения этого изменения будет зависеть как от дисперсии, так от количества наблюдений, так и от ошибки первого рода, то есть от false positive. И вот на вот этом балансе мы рассчитываем минимальный объем трафика, который нам необходим для того, чтобы замерить какую-то величину изменения. В случае с темной темой на сайте, какой мы ответ получим? То, что, условно, если мы сравниваем темную и светлую тему на сайте и видим какую-то разницу в метрике, например, 2%, какая вероятность того, что эти 2% окажутся статистически значимыми? То есть какая вероятность того, что мы истинно обнаружим вероятность изменения там, где это изменение действительно есть? Хотя у нас оно по факту есть.

А, чтобы эти 2% не оказались под случайностью.

Да.

Окей. Важно ли время, которое шел эксперимент, или достаточно просто нужного количества повторений?

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

Прикольно. И получается, эту галочку надо включать, эту функцию включать именно в эти месяцы.

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

Вот это круто. А как понять, когда завершать эксперимент?

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

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

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

Дисперсия больше.

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

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

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

Все, что ты пока объясняешь, это безумно сложная математика. У меня вообще чувство, что я вернулся опять в курс по статистике из университета. Есть ли на рынке решения, которые можно просто plug and play, типа подключил и поехал? Или это всегда нужно самим пробовать?

Есть на самом деле решения, которые ставятся, настраиваются и работают как внешний продукт. Например, Statsig. Это ребята, бывшие выходцы из Facebook, Airbnb и так далее, они сделали огромную платформу, которая и сплиты делает, и расчеты делает, такая вот SaaS-платформа по автоматизации экспериментов. А есть Optimizely, тоже делают готовую платформу. Visual Website Optimizer, VWO. Ребята из Индии тоже делают крутые решения. Google Optimize, то есть гугловский продукт, который входит в парадигму Google 360, Analytics 360.

энтерпрайз-решение.

Да.

На российском рынке сейчас появляются решения, то есть вот у нас есть своя система сплитования, разрабатывают еще несколько команд параллельно. Вот, поэтому решений много, рынок емкий, и каждый год появляются какие-то отдельные решения, то есть там есть, например, какие-то более специфичные, Unleash или Split.io, которые дают функциональность только сплита и фича флагов, то есть они не дают инструмент анализа, а просто дают решения, которые хорошо могут засплитесь. Вот наше решение как раз к EXPF Sigma, оно ближе к этим ребятам. Соответственно, есть такие инструменты. И дальше как бы у продуктов всегда есть выбор. Они либо идут в историю и делают собственные решения, либо идут на рынок и выбирают какой-то внешний продукт. Очевидно, что, не знаю, российские биг-тех-компании, мировые биг-тех-компании, они стараются держать инструменты внутри. Почему? Потому что, во-первых, у них объем огромный, это просто дорого. Во-вторых, секьюрность, так или иначе. В-третьих, собственное технологическое легаси это важно. То есть управляемость, масштабируемость и так далее. Это быстрее банально сделать внутри.

Виталий, я хочу уточнить, я правильно понял, что когда обычно говорят о статистическом анализе, о статистике, там есть какой-то набор готовых программ очень известных, типа язык программирования R, SPSS. Люди, которые проводят АБ-тесты в компаниях, они их используют или те коробки, о которых ты рассказал, они все это закрывают и дают тебе уже такой конечный продукт и результат?

Ну, в основном, это питон, на самом деле. То есть, если история идёт о ручном анализе, то это чаще всего делается на питончике, реже на R, и вот всякие там статистика, СПСС и так далее. То есть, я не встречаю, чтобы они сейчас использовались. Поэтому если это что-то внутри, то это питон. Если это внешнее решение, да, оно закрывает определенный кусок ручного анализа, но не исключает присутствие аналитика, который потом что-то дорассчитает, пересчитает.

Люди, которые работают с АБТ-тестами, это отдельная профессия с этими данными? Это отдельная профессия или это делают аналитики, например?

Вообще не отдельная профессия. По хорошему счёту, навык разбираться в АБТ-тестах – это один из hard skills, которые ждут от современного продуктового аналитика, либо data-сиентиста, если он в соответствующей специализации. Но заметен определённый тренд, что в компаниях, в командах выделяются отдельные команды, которые отвечают за развитие методологии экспериментов, либо за развитие платформы, которая позволяет автоматизировать эксперименты.

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

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

Я просто думаю о запуске своего стартапа. И есть вещи, которые я сам лучше сделаю. А есть вещи, которые, типа, аппендицит я себе вырезать не буду, даже если у меня есть хороший скальпель, потому что, ну, типа, так не делается. Лучше к хирургу пойти. Вот. А БТС-то они ближе куда?

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

кажется, что... Если ты любишь... если ты мазохист и любишь статистику.

Да-да. Ну, то есть нет, на самом деле, я бы, короче, делегировал. Ну, то есть я бы передал это на эксперта, и всё.

Отлично.

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

Да, мы EXPF. В рамках EXPF у нас есть и сервисные услуги, то есть мы продукты предоставляем, и консалтинг. Если мы говорим про консалтинг, то здесь всё просто, у нас цена исходит из часа. То есть у нас есть стоимость часа, он стоит 9500, и дальше, чем больше часов, тем, соответственно, сложнее проект, тем больше его стоимость. И там есть два варианта монетизации. Именно консалтинговый услуг – это проект, когда мы заранее предрасчитываем стоимость, Когда мы точно знаем образ результата и говорим клиенту стоимость, клиент в два раза ее платит. Предоплата, постоплата. А есть тендем, то есть time and materials, когда сколько часов на работу и сколько денег получили. Вот, то есть две модели, и если говорить о среднем чеке, Если средний чек, наверное, корректнее считать по году сотрудничества, то средний чек, сейчас он составляет примерно 5 миллионов 400 тысяч.

В год?

Да, одного клиента.

Полмиллиона в месяц всего, окей. Даже меньше чуть-чуть.

Это прям средний. Это именно консалтинговые услуги.

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

Да, да, да.

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

Если мы приходим к клиенту с внедрением нашего решения по системе сплитования, то от момента старта до момента первого теста пройдет две недели, и сам пилот займет месяц. Первый пилот. То есть мы за месяц просто проверим то, что это решение работает, и он уже на следующий месяц сможет полноценно запускать любое количество тестов. Это если мы внедряем свое решение. Если мы приходим, и клиент хочет развить решение in-house, то в данном случае процесс может занять от трех до шести месяцев. Почему такой лаг? Потому что мы должны изучить, погрузиться в инфру, погрузиться в сервисы, промоделировать разные штуки, подготовить документацию, описание, коннектиться с разработчиками их, объяснить разработчикам, что нужно сделать, потом провести авторские надзоры, далее, далее, далее. И здесь будет лаг, будет зависеть в том числе от вовлечения той стороны в этот проект. Но я думаю, ты сам это прекрасно понимаешь, занимаясь заказной разработкой.

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

Есть, мне кажется, три варианта, как это можно сделать. Можно купить много книжек по статистике, учить книжки по статистике и параллельно, вооружившись либо питоном, либо R на каких-то настоящих, либо ненастоящих данных, проверять те теоретические концепции, которые ты изучаешь. То есть брать теорию, накладывать ее на эмпирику. Второй вариант это пойти работать и в процессе трудовой деятельности уже накалываться на те шишки, которые будут приходить. Но здесь важно как бы, чтобы в компании, в которой Наш потенциальный аналитик работает. Была хорошая культура экспериментов. Ну и третий вариант это пойти учиться куда-то. То есть есть определенные... есть разные курсы. У нас есть свой интенсив, есть у Karpov.Courses интенсив, есть на DataCamp отдельные модули про АБТест, есть на Reforge курсы про АБТест и так далее. И вот можно выбрать какой-то из образовательных интенсивных курсов и так далее. Но это не отменяет вообще никоим образом практику. То есть в любом случае нужно либо пэд-проект, на котором ты будешь что-то закреплять, либо рабочий проект.

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

Есть такой колоритный персонаж. Он раньше работал в Майкрософте, отвечал там за команду X-Платформы. Это команда, которая занималась развитием платформы экспериментов в Майкрософте. Его зовут Рон Кохави. и у него есть книжка про эксперименты. Он там описывает процесс от самых азов до очень сложных историй про эксперименты. Она очень крутая, она является, наверное, крутым интердакшеном вообще про то, что такое АБТ-тесты и так далее. Это вот точно Мастрит. И мне очень нравится книжка Сара Бослаф, статистика для всех, Габеленко с крабом красным на обложке. Вот, и там она хорошо объясняет, не игнорируя какую-то академическую точность, но при всём при этом не уходя уж в слишком строгое обоснование каких-то вещей про основные фундаментальные статистические концепции. Вот параллельно читая про в целом АБТ-сты и параллельно изучая какие-то отдельные вещи, в которых в первой книге упоминается, но не раскрывается, можно в принципе составить себе такой неплохой кругозор.

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

Кайф.

Спасибо тебе большое, что выделил время.

Спасибо огромное, что позвал.

И мы его сделали вместе с сервисом онлайн-образования Яндекс Практикум. Над подкастом работали редакторка Маша Агличева, продюсерка Настя Медведева, звукорежиссерка Нина Мамотина. За джингл спасибо Алексею Зеленскому. Спасибо вам большое, дорогие слушатели.