Всем еще раз привет! На связи с вами Артем Солоухин. Я представляю команду surge pricing, подразделение эффективности и маркетплейса «Ситимобил». Сегодня мы с вами немного поговорим про switchback эксперименты и про сетевые эффекты. Начнем с небольшого интро в том, чем занимается наша команда, чтобы стало понятно, почему нас волнует то, о чем мы сегодня поговорим.  Далее немного обсудим сетевой эффект, поговорим про switchback, решает ли он проблему сетевого эффекта и насколько. Подведем какие-то итоги. Итак, погнали. 

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

Но если более глобально, то в surge pricing мы боремся за то, чтобы сделать пассажиров и водителей более счастливыми, или как минимум, сделать так, чтобы сервис такси, как уже подметил, мог представлять услуги такси. Одной из ключевых проблем, которую мы решаем, является wild goosechase. Это такое состояние, когда мы заставляем водителя ехать далеко, а пассажиров ждать долго.  

Большая часть времени водителя в такой ситуации приходится на путь к пассажирам и доход может оказаться ниже по сравнению с работой в обычное время. Так агрегатор рискует лишиться водителей и пассажиров. Если же у вас возникает вопрос о том, почему здесь такой странный термин, wild goose chase, то здесь есть две причины его использования. Первое – это применение термина Кастильо, одного из авторов фундаментальных трудов о динамическом ценообразовании такси. А вторая, по сути, исходная – это то, что в разговорном английском языке wild goose chaseотносится к таким длительным расточительным, в конечном счете тщетным преследованиям недостижимой цели. 

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

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

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

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

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

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

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

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

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

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

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

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

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

Также важно подбирать для вот этого switchback эксперимента гиперпараметры. Какие здесь есть гиперпараметры. Мы уже немного затронули. Первый из гиперпараметров – это площадь. Можно хоть на весь город, хоть на всю страну поставить группу А или группу Б, а можно лишь на один район или и того меньше. Здесь нужно исходить из того, как себя ведут ваши метрики, какая их природа. 

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

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

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

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

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

Если пользователи делают заказ примерно в одно время, в одной географической площади, условно, на 100 метров друг от друга отдалены, в таком случае наверняка они будут претендовать на одну и ту же водительскую базу и как-то друг на друга влиять. Если задать некоторую функцию, попробовать численно выразить такой сетевой эффект по классическому А/В эксперименту, switchback, я не буду раскрывать конкретику, тем более здесь у нас наши любимые друзья из Яндекс.Такси, в общем, если это сделать, то сетевой эффект, посчитанный по классическому А/В тестированию где-то в  три раза выше, чем по switchback. 

Это кажется довольно вкусно. К тому же если там еще сходятся А/А тесты, все понятно по результатам экспериментов, то кажется, что вполне хорошая механика. 

Но у нее есть некоторые проблемы. Мы уже затрагивали вопрос подбора гиперпараметров в виде площади и времени. Здесь есть такой важный момент. На самом деле сетевой эффект не полностью исключается в switchback. Он сохраняется на границах переключения моделей. Представьте, что у вас есть модель, которая с 18 часов до 18.59 минут раскрасила город в группу А, у которой динамическое ценообразование отключено и цены очень дешевые. В таком случае за вот этот час всех водителей разобрали, потому что все очень дешево, хорошо для пассажиров. К 18.59.59 свободных водителей в городе нет. Тут наступает 19 часов. Город раскрашивается в группу В, в которой динамический коэффициент включен. Мы сталкиваемся с первой ситуацией. Водителей вообще нет. Даже если кто-то попробует заказать, то он не получит назначение машины. Второй момент. Вы будете вынуждены как-то балансировать. Там же работает алгоритм балансирования. Соответственно, там могут повышаться цены и так далее. Соответственно, тоже некоторым образом влиять на поведение пользователей. 

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

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

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

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

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

Вы делите свой город таким образом, чтобы у вас в группе А1 и группе А2 накопилось примерно по 25% наблюдений, в группе накопилось 50%. Таким образом, в конце эксперимента вы можете сравнить группу А1 с группой А2, понять, сходится ли там та метрика, которую вы хотите проверить в эксперименте. Если там все сходится, если никаких вопросов нет, тогда вы можете доверять результату сравнения конкатенированного набора данных  А1 и А2 с В. switchback и вообще, любой эксперимент, который бы вы ни проводили, со сплитованием по хешу от id, чему угодно, вы можете получить такую ситуацию, что в одну из групп залетит какая-то аномалия. В одной из групп окажутся те пользователи, которые ведут себя немного иначе, нежели чем пользователи в другой группе. Заведомо ваш эксперимент будет обречен либо на успех, либо на провал. Здесь как повезет. Может быть, скос будет в ту сторону, в которую нужно, может быть нет. Черт знает. Лучше проверить. 

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

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

Четвертое. Нужно осторожно очищать данные после проведения эксперимента. Если вы очищаете всякие выбросы, наблюдения на границе переключения сплитов, если на границе площади очищаете наблюдения, то важно сделать так, чтобы у вас не осталось 10% от того набора наблюдений, который был изначально. Здесь нужна какая-то мера. Возможно, если у вас не сходится А/А тест, то стоит его подержать подольше, а не применять кучу очисток. Или подобрать другой город, или посмотреть на то, а все ли у вас хорошо технически в эксперименте. Возможно, у вас где-то есть техническая проблема, какая-то ошибка, что иногда бывает. 

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

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

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

Полезные ссылочки

1. Switchback-эксперименты в Ситимобил: Часть 1. Зачем это нужно

2. Testing for arbitrary interference on experimentation platforms

3. Случайность над случайностью или в поисках "Социального эффекта"

4. Switchback Tests and Randomized Experimentation Under Network Effects at DoorDash

5. Switchback-тестирование. Как бороться с социальными эффектами в A/B-тестах

6. Ваш алгоритм прибыл