Всем привет! Меня зовут Артём Дронов, я работаю в команде A/B-платформы Trisigma в Авито. Мы занимаемся поддержкой A/B-платформы и инфраструктуры метрик Авито, а также помогаем интегрировать наш продукт другим компаниям.
В этой статье я расскажу, что такое slicing, чем он может быть полезен, а чем — опасен, на примерах тех кейсов, которые были у нас в Авито. Рассмотрим, как можно использовать разрез в рамках своих экспериментов и получать максимум инсайтов из данных.
Статья будет полезна менеджерам продукта, аналитикам и любым специалистам, принимающим решения по А/В-экспериментами, а также разработчикам аналитических решений на данных.
Содержание:
Работа с данными и сегментами
Для начала разберемся: что же такое slicing?
Slicing — это способ анализа данных, при котором большой массив информации делят на различные блоки и рассматривают их по отдельности. Такой подход помогает увидеть закономерности и зависимости внутри данных, лучше понять их структуру и сделать более точные выводы. Компании используют этот метод, чтобы изучать показатели на детальном уровне и оценивать эффективность своих процессов (а заодно определять ключевые показатели эффективности).
Slicing обычно упоминается в контексте BI, когда вы можете:
взять данные;
разрезать их по нужным сегментам;
посмотреть метрики в той или иной категории и в тех или иных значениях;
сделать различные выводы о том, всё ли в порядке с метриками вашего бизнеса;
использовать эти выводы, чтобы найти проблемы в продукте или точки роста.
M42 как пример BI-инструмента
В качестве такого BI-инструмента можно посмотреть на М42 — это часть Trisigma, предназначенная для визуализации метрик заведенных в платформе. Подробнее об этом рассказывали в нашем видео:
В экспериментах, в общем говоря, легко сделать нечто подобное. Мы можем на основе любой метрики — например, метрики просмотра объявлений в Авито — увидеть, как её поделили на разные сегменты:
Правда, когда так делают в экспериментах, чаще говорят о slicing & dicing, подразумевая некие манипуляции, направленные на поиск причин признания эксперимента успешным.
Возникает вопрос: сам по себе slicing — это хорошо или плохо? Когда мы берем эксперимент, делим данные на множество разрезов и начинаем их анализировать, насколько это оправданно? Компании, которые так делают, глубже понимают результаты или находят удобные цифры и выдают их за реальные выводы эксперимента?
Об этом дальше ↓
Проблемы работы с большим числом наблюдений
Обычно платформенные решения на рынке считают примерно 50-100 различных комбинаций метрик и разрезов в рамках анализа экспериментов. В Авито их в несколько десятков и даже сотен раз больше.
На скриншоте — эксперимент, который проводился в Авито:
С точки зрения SRM (Sample Ratio Mismatch, также называемого «здоровье эксперимента»), он корректен. Сейчас при выбранных аналитиком порогах видно 234 прокраса — это на 2-3 порядка больше, чем обычно предлагают стандартные решения. И это только значимые изменения, при том что уровень значимости вполне строгий — не 0,5, а 0,01.
Такое количество метрик считают осознанно, чтобы контролировать сразу множество метрик и учитывать большое количество показателей.
Разберем на примере, что же всё это значит.
Допустим, мы хотим в нашем рубрикаторе переставить две категории местами. Категории — это Авто, Недвижимость, Работа, Услуги и так далее.
С точки зрения разработчиков экспериментов, задача довольно простая: нужно взять список с порядком категорий и переместить одну константу выше. На это уйдёт минут пять, остальное время займут тесты.
Но давайте разберем этот эксперимент с точки зрения анализа.
Когда вы крупная компания, ваша главная страница в некотором смысле распределяет трафик на все остальные блоки. И подобные изменения могут сильно повлиять на компанию по разным причинам. Например, если мы сдвинем категорию вправо, значит, какая-то другая категория уедет влево, и просмотры, заходы пользователей перераспределятся туда. Соответственно, изменится трафик. А раз изменится трафик, может измениться выручка и другие продуктовые метрики. Это значит, что команда, которую подвинули, может внезапно начать терять в показателях без каких-либо изменений со своей стороны.
Соответственно, нам необходимо внимательно смотреть на воронку в рамках этих категорий. И не факт, что под анализ попадут только эти две категории. Возможно, что при изменении комбинаций по-другому возникнет ситуация, когда пользователи, которые раньше сомневались, в какую категорию зайти, сразу попадут в нужную. И, возможно, когда мы поменяем эти две категории местами, трафик с третьей категории тоже перетечёт в другую.
Что ещё может пойти не так?
Мы можем повлиять на производительность сайта. Например, если визуальные компоненты отрисовываются по следующему принципу: сначала центр, потом края, чтобы пользователь быстрее видел итоговую картинку, — может случиться так, что компонент, который переехал в центр, стал тяжелее и теперь требует больше времени на отрисовку. В результате приложение грузится дольше, а пользователь может не дождаться загрузки и, решив, что что-то не работает, просто уйти искать нужное в другом месте.
Кроме того, важно помнить, что метрики обычно находятся в некотором смысле в верхней части страницы, а пользователь видит ещё множество компонентов внизу — рекламу, баннеры и так далее. Поменяв один компонент, мы можем изменить поведение пользователей: как часто они скроллят вниз в поисках нужного. А значит, за день может измениться огромное количество метрик, связанных, например, с персональными рекомендациями или рекламой.
Вроде всё понятно: много чего можно задеть, это очевидно. Но у этого подхода есть свои естественные минусы — и давайте о них тоже поговорим.
Первая проблема — это проблема анализа эксперимента. Чтобы её понять, рассмотрим простую ситуацию. Допустим, в рамках эксперимента мы анализируем некоторое количество комбинаций метрик и сегментов. Все наши метрики корректны и удовлетворяют заданным статистическим требованиям на А/A-тестах.
Теперь хотим решить задачу: у нас есть N комбинаций метрика + сегмент в рамках эксперимента с заданной ошибкой первого рода alpha. Чему равно математическое ожидание числа значимых изменений при отсутствии эффекта, то есть в А/А-тесте?
Ответ достаточно простой: оно вычисляется благодаря аддитивности математического ожидания и равно N * alpha. Например, если считаем 10 тысяч метрик при альфе 0,01, то даже в А/A-тесте получим в среднем 100 задетектированных изменений. К сожалению, мы не можем так же легко посчитать дисперсию, для этого нужны более сложные расчёты. Нужно учитывать, насколько метрики связаны друг с другом, и строить совместное распределение. Групповая вероятность ошибки первого рода (FWER) в подобной постановке стремится к единице.
Итак, мы видим порядка ста изменений. В такой ситуации можно придумать обоснование для любых изменений, то есть возникнет проблема с интерпретацией результатов.
Давайте подумаем, откуда возникает столько метрик в эксперименте. Допустим, нам нужно добавить в эксперимент метрики, которые мы хотим проанализировать. Разумеется, по одной метрике добавлять мы не будем — эту задачу нужно автоматизировать. Для этого чаще всего используют пресеты.
Пресет — это комбинация блоков метрик, связанных с определённой частью продукта, с набором разрезов, которые считаются в рамках эксперимента. Другими словами, берём пачку метрик и пачку разрезов, делаем декартово произведение и, добавляя одну несчастную комбинацию в виде пресета, мы фактически включаем в эксперимент несколько тысяч различных вычислений.
Если нужно посмотреть, что произошло с воронкой покупателей, просто добавляете пресет, который отвечает за покупательскую воронку, и смотрите на огромное количество показателей.
Допустим, мы осознаем, что эксперимент заденет другую команду. Тогда нужно сесть и понять, например, что объявления, по которым совершается доставка, могут просесть по разным причинам: может быть, они окажутся выше или ниже в выдаче после эксперимента. В таком случае можно проконтролировать ситуацию с доставкой, поговорить с коллегами. И добавить к анализу релевантные метрики в эксперимент. А можно пойти другим путём — просто добавить пресет доставки, и пусть команда доставки разберётся, всё ли у них там хорошо или нет. Так в эксперимент добавляются ещё пару тысяч наблюдений.
Итак, пресеты:
добавляются в эксперимент в один клик;
помогают, если не знаете, какую метрику выбрать, — можно взять готовый пресет команды;
позволяют смотреть дополнительные результаты даже тогда, когда они не нужны для текущего решения, — пригодится для будущих идей.
У этой истории есть очевидный плюс — это быстро и удобно.
Даже если мы понимаем, что эти данные никак не повлияют на принятие решения, в перспективе при анализе A/B-теста их можно использовать для инсайтов будущих экспериментов.
Но есть и подвох. Если посмотреть, как разрезы используются в разбивках по командам, то, по нашим данным, можно увидеть интересную особенность: то, как используется разрез, сильно зависит от того, чем конкретная команда занимается. Это своего рода обратная сторона той самой системы пресетов, которая у нас есть.
Это значит, что мы добавили метрики доставки, чтобы убедиться, что с ними всё в порядке, но сами разрезы доставки нас на самом деле не интересуют. Команде доставки важно, как меняется доставка в разбивке по, например, курьерским службам. А если наша задача — оценить метрики доставки на верхнем уровне, то это не нужно. В итоге мы считаем довольно большое количество данных, которые для нашей команды в эксперименте неактуальны. И в конечном счёте может получиться так, что пуши на доставку повлияли на контакты в недвижимости (нет).
Проблемы масштабирования экспериментов
Когда мы говорим о метриках, есть ещё вторая сторона — сторона платформы. У неё обратная задача: она должна всю нагрузку, которую вы создали, посчитать и помочь вам сделать выводы. Эта нагрузка на платформу, с точки зрения расчёта, будет зависеть от двух факторов:
Первый — это аудитория продукта. Чем больше пользователей, тем больше данных нужно переработать для того, чтобы получить результат.
Второй — это размер бизнеса. Чем больше становится бизнес, тем больше различных команд, отвечающих за более мелкие блоки, тем больше экспериментов проводится и тем больше параметров хочется контролировать. Если раньше контролировали, например, доставку, то теперь можете контролировать разные службы доставки. Получается, что количество данных стало ещё больше.
Рост данных — это большая проблема. Важно учитывать, что развитие компании и культуры экспериментирования в ней закономерно увеличивает число проводимых экспериментов. В таком случае возможны несколько путей:
расширить вычислительные мощности с целью формировать отчет к возросшему числу экспериментов в то же время или даже быстрее;
оставаться в пределах привычных нагрузок, но учитывать, что время формирования отчета при таком исходе вырастет, а значит, пользователи будут дольше ожидать результаты;
искать варианты оптимизации пайплайна расчетов.
Каждый из способов имеет место быть, но в разумных пределах.
Для тех, кто хочет узнать подробнее о том, как мы решаем технические трудности, есть наша отдельная статья на Habr.
Итак, мы поняли, что, с одной стороны, смотреть на множество разрезов в эксперименте — удобно и полезно, а с другой — это порождает множество сложностей. Давайте обсудим, как можно совмещать лучшие практики обеих сторон.
Как подойти к анализу таких экспериментов
С чего начать
Когда мы говорим про анализ эксперимента, прежде чем смотреть, сколько там метрик и какие из них прокрасились, нужно проверить базовые индикаторы корректности эксперимента, которые показывают, имеет ли смысл вообще его рассматривать. Индикаторы эксперимента обычно включают:
исправность логирования данных;
проверку здоровья эксперимента (Sample Ratio Mismatch), которая показывает, что пользователи поделились ожидаемо относительно дизайна эксперимента;
корректность expose — специальной разметки, обозначающей момент первого реального взаимодействия пользователя с тестируемым элементом;
иные маркеры качества, которые релевантны вашему эксперименту.
Это обязательные критерии — про них нужно говорить в любом случае, независимо от того, сколько метрик мы считаем в эксперименте.
Метрик много, но не все они равнозначны
Несмотря на то, что в отчете по эксперименту могут быть десятки тысяч показателей, важно анализировать те показатели, которые были выбраны в качестве целей в вашем эксперименте.
Со стороны платформы мы не заставляем пользователей указывать эти метрики и аплифты. Сначала в Авито сделали систему, которая позволяла посчитать практически всё, а потом стали прорабатывать инструменты формализации гипотезы прямо на платформе — и начали чётко прописывать конкретные цели для каждого теста.
Так появился раздел ключевых метрик, в рамках которого аналитики формулируют ожидания по целевым метрикам, прокси-метрикам и контр-метрикам. На основе этих метрик рассчитывается минимально детектируемый эффект, если говорить об экспериментах в парадигме Fixed Horizon. И именно по этим метрикам в первую очередь анализируется, насколько зелёным был ваш эксперимент.
Если у вас система, где считается очень много данных, и вы хотите формализовать культуру принятия решений, наш небольшой совет такой: не форсируйте добавление метрик. Иначе большинство из них будут из разряда «поднять выручку» и не принесут никакой пользы.
По опыту нашей команды, пользователи сами приходят к выводу: результаты проще интерпретировать, когда в эксперименте явно указано, с чем вы хотите работать. В итоге наши пользователи сейчас практически во всех экспериментах сами указывают эти показатели и смотрят результаты по ключевым метрикам.
Соответственно, вы можете использовать эти данные, чтобы оценить, насколько успешны ваши эксперименты. Можно посчитать статистику по команде, определить долю экспериментов, которые идут в соответствии с целями, и провести анализ того, насколько процесс принятия решений в компании или конкретно в вашей команде эффективен и полезен.
Работа с воронкой метрик
В Авито есть важная метрика — DTB. Это одна из ключевых метрик в компании, которая, грубо говоря, показывает, сколько сделок было совершено на платформе. Аналитики часто отслеживают критичные изменения в этой метрике, чтобы не навредить коллегам из других команд.
Одна из частых задач рядового аналитика выглядит так: есть отчёт по эксперименту, в котором посчитано около 50 различных разрезов, а эти разрезы ещё измерялись на разных видах мобильных устройств. В итоге для этой метрики мы имеем порядка 200 различных наблюдений для разных категорий.
И вот аналитик сталкивается с наблюдением: есть метрика и категория, где обнаружены статистически значимые изменения с pvalue 3*10⁻⁴. Возникает вопрос: как это изменение интерпретировать? С одной стороны, посчитано огромное количество данных, и прокрас может быть обусловлен множественной проверкой гипотез, а с другой — есть значимые изменения ключевой метрики. Разобраться, что с этим делать, может быть довольно непростой задачей.
Один из эффективных способов — смотреть выше по воронке. То есть анализировать прокси-метрики вашей ключевой метрики. Например, если мы говорим про DTB, прокси могут быть: доставка, звонки, тексты в сообщениях и так далее. DTB — композитная метрика, которая включает разные действия, приводящие к контакту. Вы можете раскладывать её на компоненты и смотреть, что выступает драйверами роста или падения в эксперименте. На основании этого можно понять, действительно ли наблюдаемое изменение статистически значимо или это один из ложных прокрасов, которые появляются из-за множественной проверки гипотез.
Пример реального A/B-теста:
В данном случае изменение оказалось действительно значимым. Аналитики раскручивали воронку дальше, выясняли причину просадки. Если бы мы просто посмотрели на метрику по сегментам, то, скорее всего, списали бы это на ложный прокрас. Но детальный анализ через воронку благодаря большому количеству наблюдений в отчёте позволяет оперативно выявить причину и понять, в какую сторону двигаться, почему что-то могло пойти не так.
Как находить нужное среди данных
Что касается управления отчётом, задача платформы, как и у любого хорошего дашборда, — дать возможность посмотреть на данные, с которыми вы работаете, под нужным углом и сделать это максимально просто и удобно. В отчёте есть много разных компонентов, я выделил самые важные. Более детально вы можете посмотреть, какие фильтры используем мы.
Помимо того, что мы даём возможность фильтровать только по нужным метрикам и разрезам, мы также отображаем количество прокрашенных, то есть статистически значимых изменений в эксперименте и его ожидаемое значение на основании логики, о которой мы упоминали выше.
Интересный момент, который вызывает дискуссии и вопросы о манипуляциях как внутри компании, так и вне её, — это возможность изменять ошибку первого рода прямо в отчёте эксперимента. Но здесь цель не в том, чтобы сделать любую серую метрику зелёной.
Дело в том, что аналитики, разбирая большой отчёт, после анализа ключевых метрик сталкиваются со множеством дополнительных данных и должны принимать решение по ним. В таких случаях аналитики «закручивают альфу», то есть выставляют значение, например, 10⁻⁵-10⁻⁶, и смотрят, что становится значимым в рамках всей воронки пользователей. После таких фильтров мы можем увидеть различные прокрасы.
В данном случае одна из таких метрик — количество пользователей, сделавших контакты с рекомендацией, — прокрасилась на 43 сигмы.
Списать такое изменение на случайность и на ошибку первого рода достаточно сложно, если у вас приемлемое количество данных и метрика корректно считается. И нет оснований предполагать, что там какой-нибудь выброс зашёл, залетел и сместил вам всё распределение. В данном случае это ещё юзерная (число уникальных пользователей с контактом с u2i рекомендаций) метрика, которая по своей природе достаточно робастна.
Если попытаться формализовать этот подход, самая лучшая аналогия здесь — поправка на FWER (family-wise error rate), то есть поправка Бонферрони. Она работает так: аналитик сначала выбирает много метрик, ставит очень маленькую альфу, потом берёт метрик поменьше и ставит альфу побольше. В некотором смысле это искусственная поправка на множественное сравнение и проверку гипотез — способ ручной тренировки с данными.
Есть, конечно, и коробочные поправка для тех кто не хочет заниматься перебором альфы. Она состоит из двух коррекций под капотом: комбинация alpha spending function для минимизации эффекта регулярного анализа отчета + FDR для учета множественной проверки гипотез.
Процессы принятия решения
И, конечно, не стоит забывать про процессные элементы. Без них принятие решений по А/В-тестам бывает довольно сложным.
Из хорошо показавших себя практик на опыте работы с платформой Авито очень популярна история с командной приёмкой А/В-тестов. Это концепция, при которой аналитики юнита собираются и анализируют А/В-тесты своих команд. Это даёт возможность взглянуть на эксперимент нейтральными глазами. Понятно, что мы как пользователи, которые проводят эксперимент, сильно мотивированы, чтобы он был зелёным, а коллеги-аналитики относятся к этому более беспристрастно и могут объективно оценить успешность теста.
Кроме того, платформы помогают пользователям с уведомлениями: показывают, что кто-то запустил эксперимент, где была задета метрика, которая была выбрана пользователем как важная и по которой он запросил уведомление. Где-то пользователи сами прикручивают алерты, где-то это делает система автоматически. Можно мониторить изменения метрик в завершённых тестах, например, отслеживать, что раскатался тест и в нём прокрашены ключевые метрики.
Также можно разрабатывать UI-решения, которые помогают с добавлением метрик в эксперименте и управлением ими. Если вам интересно, как с точки зрения UX и UI платформа помогает пользователям упрощать анализ АБ-тестов, пишите в комментариях — мы сделаем отдельную статью об этом.
Основные выводы
Хотя иметь возможность быстро увидеть данные по разным сегментам участников эксперимента крайне удобно, она приводит и к ряду сложностей. Мы рекомендуем придерживаться следующих простых, но эффективных правил при подобном анализе:
акцент на ключевых метриках. Независимо от выбранной методологии, важно делать акцент на ключевых метриках. Это сильно уменьшает волатильность в принятии решений и сокращает возможности для манипуляций.
анализ через воронку метрики. Эффективный способ оценить истинность прокраса — смотреть на воронку этой метрики. Можно анализировать данные выше и ниже по воронке в зависимости от того, что именно вы исследуете. Подтверждение по всей воронке — хороший аргумент в пользу того, что прокрас не случайный.
контроль дополнительных метрик и FPR. После анализа ключевых метрик можно проверить дополнительные метрики, собранные в эксперименте. Здесь важно быть аккуратным с отчётом и помнить про работу с FPR, ошибкой первого рода.
Если делать общий вывод, стоит ли считать много данных в отчёте по эксперименту, то мое мнение — да, если есть такая возможность. Это сложно вычислительно, но для крупного бизнеса часто необходимо, а маленькому помогает быстро находить инсайты без лишнего аналитического труда.
Спасибо вам за уделенное статье время. Пишите в комментариях вопросы, мысли и идеи!
Почитать подробнее о платформе Trisigma можно здесь, а если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.