Продуктовые истории. Как на самом деле проводят A/B-тесты? Анализ и решение
Продолжаем рассказа про A/B. В первой части поговорили про дизайн и проведение, сегодня разберёмся с тем, как оно всё анализируется и как принимаются решения. Поехали!
Подведение итогов
А вот тут самая интересная для аналитика часть — разобраться где как что отработало и почему. За скобками оставлю математику и статистику, про это и так сказано в куче других статей, а мы продолжим говорить про нюансы и «как оно на самом деле». Ситуации, когда тестовая группа с запасом лучше контроля, причём во всех разрезах — это скорее исключение. Да и те иногда имеют нюансы, которые нужно учитывать. Сразу пример из практики — некоторое время назад мы прикрутили функциональность отложенной оплаты. Когда деньги за забронированный отель (напомню, что я работаю в сервисе бронирования, все остальные примеры в этом же контексте) списывались не сразу, а ближе к заезду. Для клиента никаких минусов — есть время подумать, не нужно морозить сумму на карте, можно несколько отелей забронить… Для нас тоже минимальная нагрузка, так как деньги снимаем с юзера до момента, когда нужно финально подтвердить/оплатить бронь у партнёра. Соответсвенно, тест выигрывает у контроля и по заказам, и по деньгами и по всему остальному с большим отрывом. Ура, всё хорошо? Да, но засада как раз в этом самом отсутствии обязательств. В тесте вместе с повышенным числом заказом скакнуло вверх и число отмен. Также среди броней, который позже отменялись, был намного более высокий средний чек — как будто некоторые юзеры изначально бронили то, что даже не планировали выкупать (у нас возникло подозрение, что это сценарий «мне нужно показать бронь для оформления визы»). Не учли бы это на этапе анализа — поверили бы, что дополнительные мильоны этим гениальным решением заработали! Прирост после очистки от шума всё равно оставался, значимый, но более скромный. Кстати, именно этот тест мы еще дополнительно пересчитали через несколько месяцев — чтобы получить уже чистое число броней, после того, как все желающие либо отменили бронь, либо прожили её (и значимый прирост всё ещё сохранялся).
И это простой тест, где все метрики в зеленой зоне. Обычно приходится иметь дело с чем-то вроде «конверсии в заказ подросли, но по денежным метрикам непонятно», «на первом этапе воронки плюс, а дальше без разницы», «сценарий, который улучшали, дал значимый прирост метрик, но в целом число заказов не изменилось (произошло перераспределение заказов)». И вот тут-то аналитику и приходится применять весь потенциал своего мозга, помноженный на знание продукта и из сырых данных вытаскивать реальную картину происходящего. Тут и очистка данных от выбросов (большая часть покупок наших клиентов в районе 10-20 тысяч рублей, но есть и толстые котики, которые своими заказами в дубайские оллинклюзивы шатают финансовые метрики во все стороны), и исключение случайного трафика, и даже попытки разобраться, как же всё таки отработала новая фича, если логи на неё не повесили.
Пример посложнее — после теста, который поменял ранжирование выдачи, увидели плюс в конверсиях и деньгах, но незначимый. Гипотеза не подтвердилась, тест серый? Как бы не так! Дело в том, что поисковая выдача (на который был A/B -тест) — самый крупный, но не единственный сценарий для заказа. Есть ещё карта, всякие разные подборки, лендинги, в конце-концов, отель напрямую можно найти и забронировать… И если смотреть прицельно на тех, кто заказывал с выдачи, то все метрики в зеленой зоне, то есть выдача стала работать лучше. Просто эти результаты частично размешались с другими сценариями, а частично их каннибализировали — в этом тесте заказов с карты стало, меньше (зачем ее листать, если нужный отель и так наверху).
Пример на грани курьёзного (и хороший вопрос для собеседования) — а может быть так, что конверсия в следующий шаг воронки упала, но для нас это хорошо? Да! В одном из тестов проверяли гипотезу, что пользователи случайно попадают со страницы отеля на форму оплаты, что как минимум часть из них путает значение кнопки «посмотреть» около описания номера. В тесте заменили это название на «забронировать», как результат — переходы на форму оплаты упали (что пугало бы нас в любом другом тесте), а вот сами заказы, наоборот, выросли.
Закончу небольшим лайфхаком для подведения тестов. Интуитивно кажется, что чем больше у нас данных (трафика) в тесте, тем лучше — больше мощность теста и легче заметить изменения. Это действительно так, если с ростом трафика его качество остается неизменным. А вот если дополнительные пользователи просто добавляют шум в данные, то это становится проблемой. Наверное видели такой сценарий в разных тревел-продуктах — ищешь билет на самолет, а у тебя в соседней вкладке открываются отели (которые ты вообще не спрашивал). Формально такой юзер запустил отельный поиск и попал в A/B тест. Фактически этот сегмент конвертится даже в просмотр карточки отеля на порядок хуже, чем те, кто осознанно пошли искать себе жилье. Заказов там вообще гомеопатическое количество. При этом таких паразитных открытий может быть очень много, но они все просто разбавляют вам конверсии — в «чистом» сегменте CR в заказ порядка 3%, а среди дополнительных — 0.05%. Убери их, и чувствительность теста вырастает, хотя трафика стало на пару десятков процентов меньше!
Принятие решения
Ну вот провели мы тест, посчитали результаты. Хорошо, если значимость получили там где ожидали, и остальные метрики не уронили, тогда можно выкатывать на всех и записывать себе успех. А если нет? «Серые» тесты случаются чаще, чем хотелось бы. В лучшем случае есть позитивные изменения в метриках на грани значимости (тоже, кстати, типовой вопрос с собеседования — «метрика выросла, но p-value 0.067. Тест неуспешный, раскатывать нельзя?»). И как тогда быть?
Самое главное, A/B-тест — это один из инструментов принятия решения. Лучший с точки зрения цифр, даже несмотря на его недостатки и ограничения. Но отсутствие значимости в нём еще не значит, что мы обязаны оставить контрольную версию. Итоговое решение за продакт менеджером, который может принять его и по другим факторам. В примере выше, когда метрики вроде бы пошли в нужную сторону, но не прокрасились, можно либо попробовать продлить тест и дожать до значимости, либо уже понять, что значимости этой ждать долго, и раскатить победившую версию. С высокой вероятностью продукт будет улучшен, просто цифрами подтвердить это убедительно в этом случае не получится.
Какие ещё факторы могут помочь принять решение?
Бизнесовые. Это для случаев, когда выручка/GMV выросли, а конверсии просели (например каким-то образом увеличили траты действующих клиентов, но отпугнули новых). Для агрессивного роста, когда хотим занимать долю рынка, такой тест не будет рекомендован к раскатке. Если сфокусированы на финансовой эффективности — будет.
“Очень надо”. Особая разновидность бизнесовых факторов, про неё уже говорили в первой части. Некоторые фичи катим вообще без тестов, а некоторые катим даже несмотря на красные результаты. Просто принимаем необходимость доработки и полировки всех тех спорных моментов, которые вылезли на анализе. Типовой пример — новый дизайн, стало красивее, но непонятнее, метрики проседают. Тут важно отделить новизны от реально спорных решений, вот как например упомянутое выше называние кнопки для перехода на оплату.
Размер эффекта. Иногда положительные, но слишком скромные аплифты — это повод не раскатить фичу, а, наоборот, взять на доработку. Из свежих примеров — пытались подтянуть отображение отелей в списке к тому, что юзер видит на карте (они у нас на одном экране). В теории становится в разы удобнее — двигаешь карту, и в списке остаются только отельчики, которые на карте, ожидали хорошего роста конверсий (ведь упрощается выбор), но эффект был околонулевой, а конверсия в карточку отеля даже упала. Поскольку ожидания были ого-го, оставили всё как есть и отправили идею на доработку, благо этап анализа подсказал нам идеи для улучшения.
Технические. Тест может не показать явного прироста, но фича, которую проверяли, позволяет нам дальше развиваться. Собственно, всякие технические A/B, где мы меняем какую-нибудь базу данных, но не меняем логику продукта ровно так себя и должны вести. И, если в таком техническом тесте случается жесткий минус (у нас так было недавно) — это повод пойти и под микроскопом проверить, все места, куда изменение логики пролезть могло. Мы в своём примере нашли, в неявном виде замена одной базы данных на другую на пару порядков сократила число отелей, которые мы адекватно сортировали на поисковой выдаче. Случайно провели ухудшающий A/B-тест, получается :).
Вайб и здравый смысл. В каких-то тестах вообще по метрикам не получается составить картину изменений — метрики дернулись незначимо, да ещё и в разные стороны. Вот тут уже продакт принимает решение исходя из чуйки, косвенных факторов и измышлений «Делает ли тестируемая фича хорошо? Может ли кому-то сильно вредить?». Например, унификация дизайна веб-версии приложения и полноценной апки может не повлиять никак на метрики, но просто упростить дальнейшую разработку — раскатываем. Отрисовка открытой карты с отелями не на заданной точке с фиксированным масштабом, а хитрым алгоритмом в редких случаях превращает карту в нечитаемое месиво; редко, но некрасиво, да и алгоритм дает дополнительную(маленьку, но всё же) задержку загрузки — не раскатываем.
На этом буду рассказывать свой рассказ про то, как оно «на самом деле» в A/B-тестах. Два поста вышло, а всё равно кажется, что только самую малость рассказал. Ну ничего, зато есть будет о чём рассказывать в следующих постах!