Учёт данных о прошлом поведении пользователя в метриках A/B-тестирования

Если вам случалось проводить эксперименты, то вам знакома такая проблема, что не хватает пользователей и эксперимент не даёт значимого результата. Роман Поборчий и его коллега Никита Поваров на фестивале РИТ++ 2018 рассказали об алгоритме, который решает эту проблему. Мы опубликовали расшифровку доклада. Получилось всё очень просто — немножко арифметики, пара элементарных формул.

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

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

Исход эксперимента зависит:

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

Когда я своим знакомым, даже из IT, но не имеющим отношения к А/В-тестированию и к экспериментам, рассказываю про это, они спрашивают, а что тут вообще может быть сложного? Запустил одной группе одно, другой другое, кто лучше — тот пошёл в продакшен — круто!

Я понял, люди думают, что это устроено так:

Допустим, это магазин и чеки. Людям кажется, что у нас есть А и В, и сразу понятно, кто из них лучше — что тут думать? Какая может быть сложность и наука?

Поговорим, почему это не так.

Сейчас покажу другую картинку. Представим, у нас есть такая клиентка:

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

Скорее всего, у нас есть другая клиентка, у которой похуже с деньгами.

Если она придёт к нам за покупками, оставит в версиях А и В тоже чуть по-разному (в А меньше).

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

Поэтому, естественно, картина получается, скорее, такая:

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

Из истории важно: мы не знаем, какая тут шкала по размеру чека — может быть, даже логарифмическая. Но вот у нас есть несколько очень богатых клиентов и их совсем мало (как и должно быть). Поэтому они могут очень неравномерно распределиться между сторонами эксперимента.

Это очень обидный эффект, с которым мы начали бороться с помощью стратификации.

Объясню термин с помощью недоумения от художника:

Если серьезно, то техника такая: мы пытаемся найти параметры, которые не зависят от качества нашего сервиса, но влияют на поведение пользователей, и смотрим распределение пользователей по этим параметрам.

Среди параметров может быть день попадания в эксперимент. Если эксперимент идёт неделю, то пользователь может впервые прийти в понедельник, вторник или в любой другой день, а может впервые прийти в последний день — в субботу. Оказывается, что это важно: люди, которые приходят в субботу, в среднем ведут себя не так, как люди, которые зашли в эксперимент в понедельник. Можно посмотреть, одинаково ли раскиданы по сторонам эксперимента люди, которые в первый раз пришли в понедельник, вторник и т.д. Если нет, то можно перевзвесить. Если выясняется, что те, кто пришли в субботу, в сторону А попали в 2 раза больше, чем в сторону В, то можно в итоговой метрике это перевзвешивать. Когда параметров много, то какой-то из них раскидается обязательно неравномерно даже на большом числе пользователей.

Есть такой параметр, как час попадания в эксперимент. Поведение тех, кто приходит ночью, отличается от поведения пользователей, которые приходят днем.

Браузер — тоже классный параметр: люди, которые пришли из Chrome, совсем не такие как те, которые пришли из Internet Explorer. Тоже надо смотреть на распределение.

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

С одной стороны, то, чем мы занимаемся это предельный случай стратификации.

А с другой стороны, хотелось бы измерять не большой черный столбик, поскольку он у каждого свой, а разницу между А и В, чтобы понять — как отличается пользователь от себя нормального? Эти «хвостики» могут быть вверх и вниз, более нормально распределены и не так сильно разбросаны.

Больше всего пользователь похож на себя в прошлом. Вокруг этого вся методика и строится. Она очень простая.

Пусть M_user — это метрика, которую мы считаем для каждого пользователя в эксперименте. Мы вычитаем данные из прошлого того же самого пользователя M_user_past, если они есть. Это и есть наша новая метрика, которую мы собираемся использовать в качестве основной:

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

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

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

Есть основополагающая статья 2013 года от нескольких авторов из Bing (Alex Deng, Ya Xu, Ron Kohavi, Toby Walker), в которой эта техника впервые описана. С тех пор прошло несколько лет, но для многих этот приём всё ещё новость.

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

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

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

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

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

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

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

Когда вы проводите эксперименты, обычно есть отсечка по уровню значимости (т.е. по вероятности допустить ошибку первого рода). Большинство работает с 95%, кто-то с 99%, а то и с 99,9%. Допустим, мы выбрали 95%. Все книги и статьи говорят — проведите хотя бы один А/А тест перед тем, как что-то делать, чтобы убедиться, что всё не сломано. А/А тест — это когда мы показываем одно и то же обеим группам: и контрольной, и экспериментальной. И вот мы провели этот тест. Какой у него должен быть результат со значимостью 95%?

На самом деле в 95% случаев А/А тест скажет, что разницы нет, а в 5% скажет, что разница есть. То есть он имеет вероятностную природу — это как кот Шрёдингера, который непонятно, жив или нет. Он может сказать и так, и так. Если вы провели А/А тест, и он вам с одной попытки сказал, что разница есть, это ещё не трагедия, а повод попробовать перезапустить его и посмотреть. Но в маленьком проценте случаев (здесь 5%) тест имеет право ошибаться. Ничего страшного в этом нет. Плохо, когда он совсем никогда не говорит. Если разница на тесте никогда не показывается, то А/А тест и на нормальных экспериментах тоже всегда будет говорить, что разницы нет. Так жизнь устроена, так работают статистические тесты. Эксперимент должен быть откалиброван на А/А тестах. Но вот беда — как проверить с одного запуска, что распределение у нас именно такое? Правильный ответ: никак.

Есть техника, которую я призываю всех использовать. Она тоже бесплатная и никак не вредит вашему пользователю.

Мы провели один А/А тест. В данном случае разноцветные геометрические фигуры — это пользователи, одни из которых попали в группу А, другие в группу А’. Данные мы записали себе в сторонку, после этого над пользователями уже никак не издеваемся.

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

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

Призываю вас делать это и смотреть, куда сходятся эксперименты. Если люди об этом не задумываются, метрики ломаются. Например, метрика не соответствует критерию. Или наоборот, эти данные для этого критерия использовать нельзя, поэтому тест выдаёт не тот результат. Таких косяков бывает много, только часть метрик может нормально отрабатываться. Самое ужасное, что я видел — это десятки процентов. Должно быть 5%, а получается 20%. Это значит, что из всех экспериментов 20% выдают просто случайный результат — мы же этого не хотим.

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

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

Конечно, если мы магазин и пытаемся без регистрации ничего не продавать, то моментально разоримся. Если мы поиск и пробуем просить людей залогиниться, чтобы им давать поискать, то они все уйдут к тем, кто не просит. В общем, со всех сторон обложили — трудно!

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

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

Допустим, у нас есть юзеры Вася, Лена и Петя, для которых мы считаем метрику, и всё нормально. Но потом приходит Алёна в первый раз и сразу попадает в эксперимент. Мы ничего про неё не знаем, прошлых данных у неё нет — что ей писать в метрику?

Если мы напишем ей 12, то вся метрика сместится в сторону Алёны, и это будет плохо. Вообще в принципе плохо писать полное значение новых юзеров в метрику, это обязательно все перекосячит.

В этом месте предлагается усреднять данные всех остальных пользователей и сравнивать Алёну со средним пользователем за прошлый период эксперимента:

Удобно, что всё работает. Что бы мы не делали, как бы не усредняли, оно работает!

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

Все результаты среднего будут разные, но в любом случае этот метод хорошо работает.

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

Что с этим делать? Рассмотрим на примере поиска Яндекса. В поиске иногда интересно смотреть на параметр количество кликов на запрос: пользователь задал поисковый запрос, ему выдались результаты, и он на какие-то из них кликнул, а на какие-то нет. Это бывает важно.

Понятно, как это считается — в контрольной группе все клики делятся на все запросы:

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

А с этим что делать? Обратите внимание, что большинство таких метрик — это частное (что-то от всех пользователей делится на что-то от всех пользователей). Техника, которая предлагается, выглядит примерно так: берем контрольную группу и по ней считаем соотношение C/Q. Это будет некая константа, посчитанная по контрольной группе. Мы хотим сделать метрику, которая по смыслу выражает то же самое, но рассчитанную для каждого пользователя.

Возьмем запросы каждого юзера, которые он совершил, и перемножим на полученное контрольное соотношение:

Это число показывает сколько бы накликал юзер, если бы он сделал столько запросов, сколько сделал, кликая при этом как средний юзер в контрольной группе. Если мы это просуммируем по всем юзерам из контрольной группы, то сумма всех Q-user из контрольной группы — это Q. Оно сократится и останется только C.

Сравним то, сколько бы юзер накликал, с тем, сколько он реально накликал, и назовем эту разницу нашей новой метрикой:

Мы уже выяснили, что если просуммировать по всем юзерам из контроля, то в правом слагаемом останется C. При этом в левом слагаемом при суммировании всех юзеров из контроля тоже останется C. То есть для контрольной группы эта метрика тождественно уходит всегда в ноль. Это мега-супер удобно, потому что мы сравниваем не два параметра с какими-то дисперсиями, а какой-то параметр с дисперсиями с нулем. Соответственно, мир сразу становится легче и всё гораздо удобнее, потому что сравнивать с нулём проще, чем сравнивать с объектом с доверительным интервалом.

M-user — это уже некое число, которое считается для пользователя и примерно выражает по смыслу количество кликов на запрос, при этом для пользователя мы можем посчитать эту метрику и за предыдущий период тоже.

А теперь поговорим про объём, потому что иногда мы проводим эксперименты подлиннее, а иногда покороче: «Не хватило, давайте продлим ещё на недельку». Это не всегда хорошо, потому что мы хотим, чтобы пользователи были подвержены эксперименту как можно меньше — вдруг мы что-то плохое сделаем для них. Если плохо, то мы хотим быстрее откатить, а если хорошо, то все равно выкатится в продакшен. Поэтому чем короче эксперимент, тем лучше.

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

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

У интернет-сервисов есть две модели монетизации:

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

Например, у компании Head Hunter обе модели монетизации:

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

Рассмотрим одну из нормальных метрик лояльности sessions per user. На самом деле здесь не сессии, а дни недели, когда пользователь засветился на нашем сервисе. Это не очень чувствительный параметр, есть лучше, просто он очень удобно отмечается крестиками в таблице, поэтому я на этом примере буду рассказывать.

Мы видим, что у нас есть активные пользователи (Маша, Вася, Петя) и есть менее активные, например, Лида, которая в среду к нам пришла и всё. Допустим, нам этих данных не хватило и мы хотим подержать эксперимент подольше, ещё одну неделю.

Что у нас происходит? Маша по-прежнему очень активна, Вася и Петя примерно в своём темпе работают, Наташа куда-то слилась, Володя, наоборот, активизировался, Лида опять пришла в среду ровно один раз. Но кроме этого за эту неделю к нам пришли ещё несколько людей — Антон (может быть, он был в отпуске и теперь активизировался) и Аня. Причем Аня — нормальный юзер, у неё есть аккаунт на нашем сервисе, она каждый раз заходит через процедуру восстановления пароля, но всё-таки заходит.

За первую неделю у нас были какие-то люди и у них было от 6 до 1 посещений. За вторую неделю мы вроде бы собрали больше данных, но при этом разброс этих данных тоже увеличился — от 13 до 1, и они все тоже разные.

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

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

Повторюсь, не все метрики так себя ведут, некоторые действительно держатся нормально, у них дисперсия не так растет. Но некоторые подвержены этой проблеме. Надо помнить, что дисперсия может расти вместе с объёмом данных.

Я часто рассказываю эту арифметику, тривиальные вещи, и люди говорят: «Вы что? Уже давно все в несколько слоев эксперименты накладывают, каждый пользователь участвует одновременно в нескольких экспериментах! Почему мы об этом не говорим, давайте какие-то современные техники!»

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

Но давайте вспомним, что у нас тут 21 век и немного поговорим про современные технологии.

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

В принципе ничто нам не мешает взять прошлые данные, графики годовой динамики и годовой сезонности — мы же можем посмотреть, как каждая неделя и каждый период в году отражается, может быть, где-то наложить спад и подъём. Можно взять график каких-то геополитических событий, праздников, даже прогноз погоды. Это не шутка, потому что прогноз погоды — это важная вещь. Зуб даю, что любой общероссийский крупный интернет-сервис (Яндекс, Mail, Авито) очень хорошо по трафику видит, когда в Москве дождь, а когда солнечно. Трафик больше, когда дождь, и реально это очень хорошо видно.

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

На эту тему есть статья, где люди примерно так сделали. Эту статью можно по-разному интерпретировать. Моя интерпретация такова, что мы получаем немножко выгоды по сравнению с простым использованием прошлых данных. 5% означает, что если раньше из 100 экспериментов 20 были результативны, а теперь их 21. Но, с другой стороны, там, где раньше была простая арифметика, теперь поселяется непонятное машинно-обученное нечто, которое надо периодически переобучать, повторять, собирать для неё сложные данные. При этом сервисы иногда отваливаются и что-то недодают. В общем, я бы не стал это делать.

Если применять технику учёта данных о прошлом поведении пользователя:

A/B тестирование проводится, когда продукт уже создан и у него есть пользователи. А о том, как создавать продукты, востребованные рынком, поговорим на Product Fest 9 декабря в Москве. Билеты уже в продаже, до повышения цен осталось три дня.

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