Представьте ситуацию. Приходит Product Owner и говорит: «Давайте сделаем новый дизайн страницы сайта». Аналитик берётся за задачу — проводит A/B-тест. Такая же задача случается в соседней команде, в сопоставимом по сложности продукте, — но если в первом случае тест занимал пару часов, то во втором ждать приходится несколько дней. Чем больше команд и аналитиков, тем выше риск разрозненности. 

Унификация процессов помогает минимизировать этот риск, только как к ней лучше подступиться? Подготовить чеклисты, шаблоны, документацию, скрипты..? В нашем случае понадобилось всё это, плюс самодельный инструмент, который автоматизирует статистический анализ результатов A/B-тестов

Под катом пошагово описываем, как мы унифицировали процессы в нашем A/B-тестировании, и что получили на выходе.

Привет! На связи Николай и Марк, продуктовые аналитики Сравни. Сегодня расскажем, как мы делали внутренние инструменты для упрощения процесса проведения A/B-тестов. Надеемся, статья будет полезна продуктовым аналитикам, знающим основы статистики и Python, а также менеджерам, которых интересуют вопросы выстраивания процессов вокруг аналитики. 

Но прежде чем перейти к описанию наших инструментов, немного контекста: зачем нам вообще потребовалось унифицировать процессы A/B-тестирования?

Проблемы A/B-тестирования

У нас в Сравни есть система A/B-тестирования: свои A/B-тесты крутятся в 13 продуктах. За сами тесты, их корректность и результаты отвечают аналитики — это порядка 40 специалистов.

В процессах всегда найдется, что улучшить. Год назад мы выделили ряд проблем, связанных с нашим A/B-тестированием:

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

2. Не было общего фреймворка для работы с A/B-тестами после сбора данных: какие критерии использовать статистически, на что обращать внимание, как правильно делать выводы и интерпретировать полученные результаты. У всех аналитиков в компании был разный уровень погружения в A/B-тестирование, статистику и так далее; поэтому корректность A/B-тестов могла быть завязана на человеческий фактор и не было уверенности в достоверности каждого выбранного теста.

3. На проведение A/B-теста уходило значительное количество времени; не было общей автоматизированной выгрузки или скрипта по анализу результатов. Различные скрипты, статистические тесты и функции писались под определённые задачи, без общей системы.

4. У бизнеса не всегда было понимание сроков анализа – везде было по-разному (уровень погружения в статистику, Python и прочее у специалистов в разных командах отличается, к тому же имеет значение специфика самого теста). У кого-то анализ теста занимал один час, а у кого-то — два дня. 

5. Не было общей структуры документации, где хранились бы результаты A/B-тестов. Одна продуктовая команда могла хранить их у себя, другая – вообще не вести документацию, но скидывать результаты в корпоративном мессенджере. И если коллеги хотели посмотреть, какие тесты крутились в соседнем смежном продукте, удобной возможности это сделать не было. 

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

1. Зафиксировать стандартный процесс для A/B-тестирования для всех продуктов, чтобы каждый аналитик в компании проводил тест единообразно — по одной инструкции, единому чеклисту. 

2. Сделать исчерпывающую документацию и свод правил по тому, как корректно провести A/B-тест и не ошибиться. 

3. Создать единый скрипт, который позволит быстро собирать нужные данные и графики для большинства кейсов. Конечно, мы не можем покрыть вообще все виды A/B-тестов ввиду их многообразия и уровня сложности, но будем стремиться, чтобы наш инструмент позволил бы охватить большую часть тестов.

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

Инструкция для проведения A/B-тестов и шаблон для оформления результатов 

Мы создали чеклист в Confluence, который помогает пошагово и корректно провести A/B-тест, а затем оформить результаты. 

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

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

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

Рассмотрим детальнее структуру шаблона и этапы его заполнения.

Шаг 1. Оформление гипотезы

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

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

Шаг 2. Планирование эксперимента

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

Разумеется, могут возникнуть вопросы, что именно выбрать, почему здесь то, а здесь это, что вообще такое «мощность». Поэтому для каждого пункта мы создали вложенную документацию. Например, пункт номер два – планирование эксперимента. Здесь доступна отдельная документация, в которой описаны все термины и большая часть подводных камней, которые могут встретиться при планировании эксперимента, с уточнениями, почему и как стоит выбирать те или иные параметры. В детальном описании разъяснена большая часть необходимой теории, а также приведены ссылки на релевантные статьи из внешних источников

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

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

Итак, мы определили гипотезу, описали её. Вторым пунктом — определили свою выборку, заполнили табличку. Затем, когда мы уже знаем время запуска теста, что там будет изменено, какие будут параметры и так далее, то создаём эксперимент в админке и ждём, когда разработка внесет это изменение. Когда это происходит, заходим в шаблон, переходим к пункту проведения эксперимента и здесь указываем id вашего эксперимента из админки, период проведения и ссылку на задачу разработки. 

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

Шаг 3. Получение данных для анализа результатов с помощью специального инструмента

Мы создали инструмент, который позволяет производить анализ результатов и получить нужные данные и графики. Как вы помните, в А/B-тесте самое важное — статистические критерии, и наш инструмент считает эти критерии. Также там есть вторичные вещи типа lift, MDE, срезов и так далее, по которым вы сможете проверить, точно ли не ошиблись, действительно ли есть статистически значимое изменение. 

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

Подробности о сути инструмента и принципах его работы мы расскажем чуть ниже.

Шаг 4. Анализ результатов

Здесь тоже доступна подробная документация с указаниями, на что следует смотреть. Есть ссылки на внешние ресурсы, где можно почитать теорию, и описаны наиболее очевидные подводные камни, чтобы мы могли себя перепроверить и не ошибиться. Точно так же, когда мы приходим к анализу результатов, мы заполняем в своём шаблоне блок «Анализ результатов». Тут самое важное — это, безусловно, табличка с нашей целевой метрикой: какой она была в варианте А, какой в варианте B, как изменилась и значимо ли это изменение. То же самое – про вторичную метрику. 

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

И если коллега из бизнеса решит посмотреть результаты A/B-теста, проведенного аналитиком, первое, что он увидит — это гипотеза: период проведения эксперимента, внесённые изменения, варианты дизайна. После этого — вывод: что поменялось, как поменялось, какие будущие гипотезы сформулированы на основе этих результатов. 

Обычно бизнесу для быстрой проверки достаточно гипотезы и вывода, в том числе, при возвращении в какие-то старые тесты. Всё, что ниже — табличка с планированием, различные задачи и идентификаторы, графики, — это уже для коллег-аналитиков или нас самих (тех, кто делает A/B-тест), чтобы мы могли к этим результатам вернуться и посмотреть, что поменялось и как вели себя метрики, переиспользовать скрипты и прочее.

Давайте резюмируем, какой у нас получается процесс. Допустим, Product Owner поставил задачу, сформулировал гипотезу, и аналитику нужно провести A/B-тест. Что мы делаем? Копируем шаблон и начинаем его поэтапно заполнять по чеклисту совместно с проведением эксперимента и анализом его результатов. Если возникают вопросы, смотрим дополнительную детальную документацию. 

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

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

Инструмент автоматизированной выгрузки и анализа результатов

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

Ноутбук состоит из двух частей. Главная часть — непосредственно ядро для A/B-тестера, которое отвечает за расчет статистических критериев в различных срезах данных входного датасета. Про него поговорим позже. Вторая часть призвана облегчить еще одну задачу для аналитиков: когда хочется быстро написать запрос (или даже собрать его в виджетах) и получить данные. Части в целом независимы друг от друга. A/B-тестер может работать и без виджетов, просто на вход ему нужно подать датафрейм, имеющий специальную структуру. 

Генерация запросов через виджеты

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

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

Посмотрите на виджеты, посвящённые созданию подключения к базе данных. Здесь часть полей уже выставлены по умолчанию, а некоторые надо дозаполнить. Предлагается указать имя пользователя, пароль (или его отсутствие), расставить датабазу, схему и свою роль.

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

Не углубляясь в детали: в конце процесса аналитик получает Python-строку, в которой содержится финальный SQL-запрос. Но как говорилось ранее, всё это необязательно, если аналитик уже имеет готовый запрос на руках — в таком случае этап формирования запроса можно пропустить.

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

И есть функция save_query_to_sf. Она сохраняет запрос в специальную таблицу, доступ к которой должен быть у всех ролей и на select, и на insert. Нам будет предоставлен id записи, который можно себе сохранить, чтобы потом из этой таблицы выбрать свой запрос, а также id эксперимента.

Сама таблица выглядит так: в ней есть столбцы id, timestamp лога, имя пользователя и наша роль, которые берутся из наших логина-пароля к Snowflake; id эксперимента и, собственно, сам запрос, который хранится строкой в Snowflake. 

Всегда можно вернуться сюда, выбрать свой запрос и повторить эксперимент. Стоит уточнить: в целом не предполагается, что этой таблицей будут часто пользоваться. Это скорее логи, которые делаются на всякий случай. Например, если нам требуется провести некий A/B-тест, а мы уже делали похожий два месяца назад, можно просто по id прошлого эксперимента или по учетной записи найти и посмотреть, какие скрипты мы выбирали ранее, и использовать их при необходимости.

A/B-тестер

Рассмотрим теперь важную особенность нашего ноутбука — A/B-тестер. Это класс, написанный в основном на Polars. В ней скорость работы с датафреймами выше, чем в Pandas, за счет чего достигается быстродействие A/B-тестера.

Что A/B-тестер умеет: он может брать условно произвольный датафрейм и итеративно (рекурсивно) проходить по его срезам и замерять метрики, применять к ним определённые критерии. Сами критерии находятся снаружи, A/B-тестер просто принимает их на вход в качестве аргумента. 

Как выглядит критерий? Это функция, которая должна принимать на вход первыми двумя аргументами два сэмпла (и если нужно, дополнительные аргументы) и возвращать некий словарик с выходными данными. Условно говоря, для t-теста (теста Стьюдента) она вернет основную метрику p-value. 

За счёт этого библиотека статистических критериев легко расширяется: можно просто написать свою функцию-оценщика, подходящую для этого API, и поместить её в A/B-тестер как аргумент. Сам A/B-тестер нарезает датафрейм и отправляет сэмплы в оценщик. Оценщик возвращает ему результаты, и A/B-тестер строит графики, выводит данные — в общем, помогает нам сделать выводы. 

Рассмотрим синтетический пример использования нашего A/B-тестера. Сгенерируем датафрейм размером десять тысяч строк. В целом датафрейм должен удовлетворять нескольким критериям: у него должен быть столбец с датой либо какой-то ещё континуальной величиной, которая позволит нам итерироваться во времени и смотреть прогресс эксперимента. Желательно иметь поле CLIENT_ID, потому что чаще всего мы смотрим именно в разрезе клиента. 

Также обязательно должен быть столбец AB_VARIANT, чтобы было что с чем сравнивать. И неограниченное число столбцов, которые отображали бы какие-то наши срезы (в примере мы хотим посмотреть Mobile/Desktop), а также неограниченное число метрик, которые мы хотим замерить. Единственное требование к последним — все подобные столбцы должны начинаться с названия MTR (от слова metric), чтобы под капотом A/B-тестер разобрал, что есть метрика, а что — колонка среза. 

Итак, мы сгенерировали три варианта. Замерять будем MTR_CR_ test. Для нулевой и второй ветки это просто нормальное распределение со средним 1 и дисперсией 0,5, а для первой ветки это также нормальное распределение, только со средним — 1,1. Сгенерированный датафрейм передаём на вход A/B-тестеру. 

Далее мы конфигурируем наш A/B-тестер независимо от статистических критериев. Например, если хотим посмотреть не только общие результаты A/B-теста, но и отдельно увидеть их в разрезе Device type — мобильных устройств и десктопа, нужно кликнуть DEVICE_TYPE. Дальше указываем, какой столбец является континуальным; в нашем примере это дата. Затем выбираем, какой именно тест проводим. Так как в нашем примере три ветки, выберем abn. В целом же аа сравнивает контрольную с контрольной, ab сравнивает контрольную с тестовой, abn сравнивает контрольную со всеми тестовыми, и mvt сравнивает всё со всем.

Есть ещё кумулятивный параметр: если мы хотим видеть кумулятивную динамику во времени в виде графиков, следует выбрать true. Вообще всегда выбираем true, иначе A/B-тестер просто выведет нам датафрейм, в котором будут результаты на последний день теста, а мы хотим видеть развитие. 

И наконец выбираем, что является контрольным вариантом, а что тестовым. В нашем примере 0 — контрольный, 1 — тестовый. Это используется в случае, когда у нас больше двух вариантов тестов, но мы хотим провести именно ab, сравнить конкретные два варианта. 

Дальше выбираем нужную метрику; в нашем случае это MTR_CR_test. Тут же ещё есть поле gb_cols. Что оно значит? Зачастую, чтобы посмотреть финальные значения метрики, мы должны сгруппировать её в контексте клиента, чтобы Сlient ID был уникальный. И прежде чем проводить собственно статистический тест, нужна предагрегация. Поэтому выбираем, чтобы метрика MTR_CR группировалась в рамках одного Сlient ID, пусть агрегат будет mean — «среднее значение». 

Дальше идёт пока что не статистический критерий, но служебная, вспомогательная штука, которая покажет, как распределились уникальные Сlient ID — увидим, как мы поделили трафик и как в агрегированном виде выглядит метрика. Мы делили поровну, то есть 33% на 33% на 33%, и на скрине видно, что всё действительно так и разбилось. Это кумулятивный график, то есть идет накопительный эффект от начала эксперимента до конца. Видно, что трафик действительно поделился практически поровну. 

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

Это был общий график, но поскольку мы заказывали ещё срезы по десктопу и мобильным девайсам, A/B-тестер предоставит графики в срезах. Чем больше уникальных значений будет в DEVICE_TYPE, тем больше графиков будет слева направо в ряд. Только не стоит вводить слишком много уникальных значений: если у вас окажется 15 графиков в ряд, ноутбук может заглючить, не говоря о том, что на это в принципе сложно смотреть.

Следующий раздел — расчёт MDE и lift. Если у нас есть какие-то параметры, они будут отображены в виджетах, чтобы мы могли их выбрать. Но обычно можно использовать значения, выставленные по умолчанию. Выставляем значения для нашего примера, запускаем ячейку и получаем два графика. 

У сетки графиков будет столько строк, сколько у нас попарных сравнений тестов. Мы сравниваем abn, поэтому сравнивается нулевой с первым и нулевой со вторым. Видно, что у нулевого с первым lift и MDE под конец практически равны. Это заставляет сомневаться в статистической значимости результата, но пока вроде бы lift чуть пониже. Со вторым видно, что lift значительно ниже. Значит, в дальнейшем мы уже в чём-то сможем быть уверены. И поскольку мы заказывали не только общие графики, но ещё и в срезах, то можем посмотреть отдельные метрики MDE и lift и в десктопе, и на мобильных устройствах. 

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

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

Если даже после теста Стьюдента вы не уверены в результатах, можно проверить их с помощью бутстреп-теста. Он тоже имеет два параметра: количество итераций и количество подвыборок. Что делает бутстреп: он берет рандомные подвыборки из сэмплов и считает какой-то их агрегат, например, среднее. Делает так столько раз, сколько мы выбрали, и формирует новые случайные величины, которые потом сравнивает. Параметром frac (сокращенное от fraction) можно выбрать относительную долю этих подвыборок. Например, единица означает, что будет подвыбран полный сэмпл. Можно указать 0,5, чтобы подвыборки были меньше. 

В нашем примере по среднему значению различий между подвыборками первая ветка практически стабильно обыгрывает нулевую. Это правильно, потому что у неё в распределении средняя величина больше. А вот то, что нулевая и вторая действительно равны, — не совсем очевидно, так как все генерировалось рандомно, а длину датафрейма мы задали всего 10 тысяч. 

Бутстреп считается долго и дорого. Что касается скорости, тут для датасета из 10 тысяч строк и 10 тысяч подвыборок такой же длины всё будет посчитано за 30 секунд, причем не только общий тест, но еще и в срезах.

Если провести нагрузочное тестирование с теми же параметрами, что и в рассмотренном нами примере, только с датафреймом длиной 10 миллионов, все вспомогательные данные, сама метрика, MDE и lift – посчитаются практически мгновенно. Бутстреп-тест для 10 миллионов строк и 1000 подвыборок считается примерно 5 минут; всё остальное выполняется фактически моментально.

Бывает так, что какая-то ветка начинается позже другой. Допустим, в понедельник у нас есть информация только по нулевой ветке, а по первой нет, и в этот день мы не можем сравнить эти две ветки. A/B-тестер это отслеживает — и предупреждает, если возникают подобные ситуации. В таком случае нужно просто следовать инструкциям в предупреждающих сообщениях; обычно достаточно сдвинуть временной диапазон исследования.

Больше никаких A/B-тестов на целый день

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

Практически все аналитики в компании (из числа тех, кто проводит A/B-тесты) сейчас пользуются чеклистом и инструкцией. Вопросов по процессу стало ощутимо меньше: многим коллегам инструкция помогла разобраться с необходимой теорией A/B-тестов.

Более конкретные данные мы получили по использованию инструмента автоматизации:

• Порядка 2/3 аналитиков, проводящих A/B-тесты, пользуются скриптом

• С началом его применения доля аналитиков, анализирующих A/B-тесты по несколько часов, сократилась с 50% до 16%

• Доля аналитиков, тратящих на анализ A/B-тестов целый рабочий день, сократилась с 16% до 0%

• С внедрением инструмента большая часть аналитиков анализирует A/B-тесты от 30 минут до 2 часов

Помимо очевидных преимуществ, с нашим нынешним фреймворком связан и ряд сложностей, над решением которых мы сейчас работаем. Одна из главных — это удобство пользователя. Аналитик видит весь код (кого-то это может смутить и запутать); ему нужно самому собирать окружение, чтобы запустить у себя Python-ноутбук; устанавливать все необходимые библиотеки. 

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

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

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

Возможно, о чём-то из упомянутого (или обо всём сразу) расскажем в одной из наших будущих статей. А пока — будем рады вашим реакциям и вопросам в комментариях!