Интернет-маркетинг

6 ошибок А/Б-тестирования, или как жирные гипотезы сливаются в трубу из-за плохой аналитики

Автор: Борис Голдобин22.06.2020

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

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

Теперь мы сделали выводы и готовы рассказать и показать на собственном примере, какие ошибки могут возникнуть при А/Б-тестировании и как их избежать. 

Ошибка 1. Не нужно смотреть на Луну через микроскоп

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

В нашем продукте, как и во многих других, LTV (lifetime value) – это ключевая метрика при тестировании гипотез. LTV – это деньги, которые нам приносит один пользователь, эта метрика учитывает все: 

  • Будущие покупки пользователя как качественный прогноз;
  • Продление существующей подписки в перспективе;
  • Стоимость трафика;
  • Виральность – сколько пользователь принесет нам других, органических, а значит, бесплатных клиентов, и какой доход они принесут.

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

В нашем случае это:

  • Покупки в течение недели;
  • Прогнозные значения покупок;
  • Конверсия в регистрацию;
  • Удержание (retention) после регистрации.

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

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

Ошибка 2. Вчера не равно сегодня

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

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

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

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

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

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

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


Все, что работает на одних пользователях, не всегда работает на других. 

Зачастую то, что было  успешно внедрено России, успешно и в других странах. Однако мы недавно тестировали триальный период пользования сервисом (3 дня) в нескольких странах. В России, что называется, не зашло. Выбрали еще пять стран – в трех не вызвало интереса, а в США  реакция оказалась положительной, получился хороший процент списания и рост продаж вдвое.


Ошибка 3. Не всегда 2+2=4

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

У нас есть два эксперимента, которые мы проверяем. Результаты по LTV представлены в таблице, где A – это базовые варианты, а B – вариант после эксперимента:

A1B1A2B2
LTV180220150250

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

A2B2
A1100200
B1260240

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

A1B1A2B2
LTV220180210190

Однако, если мы посмотрим, как эти эксперименты взаимодействуют между собой, то поймем, что откатить оба эксперимента значит потерять потенциальную прибыль. Лучший вариант – принять только 1 эксперимент и это потенциально увеличило бы прибыль на 44%.

A2B2
A1180240
B1260120

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

Ошибка 4. Мы вырастили продукт на 200%, но это не точно

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

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

Кейс

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

В итоге в первые дни LTV показал рост +20%, но по прошествии времени экспериментов варианты сравнялись по этому показателю. При этом статистические тесты с самого начала опровергали гипотезу о разнице в группах. 

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

Ошибка 5. Человеку свойственно ошибаться

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

Когда мы только начинали ставить А/Б-тестирование на поток, метрики  по всем текущим экспериментам считались ручками 1 раз в неделю на SQL перед специальным собранием. Однажды этот подход дал жесткий сбой, мы тестировали локализацию приложения в Бразилии. По рекомендации локальных маркетологов мы сменили  картинки на рекламных скриншотах так, чтобы пользователю было проще ассоциировать себя с людьми на картинке. Этот эксперимент шел успешно на протяжении 3 недель и только на 4-й что-то пошло не так.  На 4-й неделе, “данные пересеклись”, и мы начали разбираться. Оказалось, что эксперимент не имел положительного эффекта: мы впустую потратили 3 недели. 

Другой кейс – ошибки на более раннем этапе – при биении на А/Б-тест. В прошлом году мы недосмотрели и поставили 2 одновременных эксперимента на одну и ту же группу пользователей. Выглядело это так: тестировали новые картинки на онбординге, а получили рост продаж лицензий. Фантастика! Начали разбираться, оказалось, что эксперимент с картинками полностью совпал с другим, нацеленным на оплату. Пришлось делать перетест обоих экспериментов. В итоге картинки не оказали никакого влияния, а эксперимент с оплатой остался в приложении.

Необходимо постоянно мониторить метрики и статистическую значимость. Если сегодня мы выигрываем, то это не значит, что это не случайно, даже если статистические критерии говорят об этом. 99% значимости эффекта от эксперимента – это достаточно точная гарантия валидных результатов. Однако если метрика LTV  пересекается несколько раз, то это повод задуматься над тем, что текущее значение – это статистический выброс. Идеальная картина эксперимента: это когда данные с первого дня показывают стабильную разницу, которая не меняется во времени, а доверительные тесты только сужаются.

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

Ошибка 6. Всегда нужно иметь какую-то тактику и желательно ее придерживаться

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

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

Кейс

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

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

Заключение

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

Реакция на статью
поделюсь
100%
интересно
0%
полезно
0%
не уверен
0%
скучно
0%
где автор?
0%
Борис Голдобин
Аналитик службы клиентского сервиса и коммерческих методов «Где мои дети». Профессиональный математик, победитель чемпионатов по клиентской аналитике, участник научных конференций. Специалист в использовании word-embeddings для машинной генерации признаков из транзакционных данных. Интересы: машинное обучение и теории вероятности. Борис работает с «большими данными», анализирует поведение пользователей в продукте по цифровому следу. Наладил и автоматизировал систему аналитики A/B-тестирования продуктовых гипотез в компании, благодаря чему возросла прибыль и улучшилось юзабилити продукта. В своей работе использует методы машинного обучения, в частности retentioneering.
Комментарии
Оставить отзыв

You must log in to post a comment