Все знают, что А/Б-тестирование – двигатель развития проектов, инструмент для повышения конверсии, роста продаж и вообще ключ от всех дверей. Но это в идеальном мире, а в жизни, если вам скажут, что А/Б-тест – это легко и просто, не верьте, потому что одно некорректное исследование может привести вас в лабиринт из одинаково плохих вариантов или направить по ложному пути, в конце которого ждет неизбежный откат обновлений. Как следствие – впустую потраченные время и ресурсы.
***
Узнать больше о секретах успешного маркетинга можно на нашем канале в Telegram — Secretmarketingua
***
Мы тоже через это прошли, проводили эксперименты без учета статистической значимости, пренебрегали автоматизацией, радовались росту показателей в период предновогодних акций и были разочарованы, когда оказывалось, что это не сам эксперимент успешный, а время его проведения удачное.
Теперь мы сделали выводы и готовы рассказать и показать на собственном примере, какие ошибки могут возникнуть при А/Б-тестировании и как их избежать.
Ошибка 1. Не нужно смотреть на Луну через микроскоп
Во-первых, необходимо правильно выбрать метрики, которые затронет эксперимент. Вы изначально должны понимать, какую цель преследуете. Для бизнеса наиболее интересна прибыль, но в отдельно взятых случаях считают то, на что сам эксперимент нацелен, в частности, конверсию в оплату, ретеншн (удержание) пользователей, конверсию в регистрацию в сервисе, длину сессии и многое другое.
В нашем продукте, как и во многих других, LTV (lifetime value) – это ключевая метрика при тестировании гипотез. LTV – это деньги, которые нам приносит один пользователь, эта метрика учитывает все:
- Будущие покупки пользователя как качественный прогноз;
- Продление существующей подписки в перспективе;
- Стоимость трафика;
- Виральность – сколько пользователь принесет нам других, органических, а значит, бесплатных клиентов, и какой доход они принесут.
Это сложная и, в значительной степени, прогнозная метрика, поэтому для ее расчета нужно потрудиться. В отдельных случаях нет уверенности в ее правильном расчете, поэтому нужно отслеживать влияющие показатели.
В нашем случае это:
- Покупки в течение недели;
- Прогнозные значения покупок;
- Конверсия в регистрацию;
- Удержание (retention) после регистрации.
Например, у нас в самом начале работы была гипотеза, что уменьшив цену нашего продукта, мы повысим удержание клиентов и увеличим конверсию в оплату. Так и произошло, и мы приняли результат эксперимента за успешный. Однако затем мы посмотрели на LTV и поняли, что на самом деле теряем деньги – клиенты в среднем хуже докупают подписку. На третий месяц проведения эксперимента основной костяк платежеспособной аудитории не изменился. В число новых покупателей вошли пользователи, которые откладывали приобретение подписки на потом. Их привлекло снижение цены, но как раз из-за удешевления продукта они принесли меньше прибыли. Прирост retention не компенсировал уменьшение выручки через виральность и увеличение количества потенциальных покупателей. В итоге после применения условий эксперимента для всех пользователей на основании данных первой недели, пришлось откатить эксперимент.
В некоторых случаях мы смотрим на промежуточные метрики с целью принять или отклонить эксперимент, не доходя до итогового LTV. То есть мы знаем, как составные элементы влияют на LTV, и следим, например, только за конверсию в оплату. Такой подход экономит время и силы и применяется, если мы верим, что принцип при прочих равных (если остальные факторы не меняются) соблюдается. Например, не приходится ждать данные по конверсии в продление годовой подписки, если ты уверен, что она не меняется.
Ошибка 2. Вчера не равно сегодня
По возможности проводите тестирование параллельно. В большинстве сфер присутствует сезонность, неоднородность трафика и шоки, которые могут сильно исказить результаты. Если сначала провести клиентов по одному сценарию, а потом по другому, могут возникнуть неточности.
Это классический пример, мы, к счастью, такую ошибку не допускали. Эксперимент запускается не в А/Б, а последовательно, то есть метрики эксперимента сравниваются с метриками прошлого периода. В итоге эксперимент показывает существенный рост. Его расширяют на всех пользователей, но метрики больше не растут, как ожидалось, а возможно, даже падают. Почему же так получается? Потому что обстоятельства в периоды теста отличались.
Известный факт: сервисы, нацеленные на туристов, получают большую выручку в туристический сезон. Сервисы, как наш, предназначены для помощи родителям школьников, меньше зарабатывают в летние каникулы. Так получается, что не в сезон мы зарабатываем примерно на 20% меньше с одного пользователя, а также существенно снижаем трафик.
Новый год является периодом повсеместных акций, в частности, у конкурентов. Поэтому последовательный тест групп может показать не то, что эксперимент удачен, а то, что период для группы с экспериментом был более благоприятным и значительно завысил результаты.
В некоторых случаях могут быть менее очевидные причины некорректности результата эксперимента. Например, отдел маркетинга нашел очень мотивированный канал и приводит пользователей, которые приносят большую прибыль, что в итоге сильно влияет на расчеты. Или же была опубликована статья, в которой уделялось внимание отдельным функциям приложения, что привело к тому, что вновь пришедшие пользователи стали интересоваться именно этими возможностями, и начали покупать иначе.
Можно внимательно следить за всеми факторами, однако высок риск что-то не учесть или о чем-то забыть. В итоге корректно сделать поправки технически достаточно тяжело. Поэтому проще и эффективней проводить тесты параллельно. Однако нельзя забывать о различных шоках. То, что хорошо показывает себя в период акций, может иметь не такой эффект в обычной ситуации.
Более агрессивный показ экранов оплаты является ярким примером тому: больше пользователей узнают про базовую цену и охотнее покупают акционный товар, однако вне акции такие экраны раздражают аудиторию, снижают покупки и ретеншн, как следствие, органический трафик и покупки в будущем. То есть эксперимент не дает прироста.
Все, что работает на одних пользователях, не всегда работает на других.
Ошибка 3. Не всегда 2+2=4
Не забывайте про совместные эффекты – эксперименты могут влиять друг на друга. Например, экспериментируя с пуш рассылками, мотивирующим пользователя к оплате, мы можем отправлять четыре варианта, и каждый из них по отдельности будет выгоднее, чем базовый вариант. Мы можем принять их все, но на практике это окажется невыгодным для нас.
У нас есть два эксперимента, которые мы проверяем. Результаты по LTV представлены в таблице, где A – это базовые варианты, а B – вариант после эксперимента:
| A1 | B1 | A2 | B2 | |
| LTV | 180 | 220 | 150 | 250 |
Исходя из этой таблицы можно сделать вывод, что оба эксперимента очень даже успешны и оба следует принять, однако это не совсем так. Если мы посмотрим все пересечения экспериментов, то окажется, что вариант с принятием обоих экспериментов не лучший, так как они негативно влияют друг на друга.
| A2 | B2 | |
| A1 | 100 | 200 |
| B1 | 260 | 240 |
Более того, возможна ситуация, когда неудачный эксперимент взаимодействует с удачным таким образом, что в итоге мы откатываем оба. Результаты такого случая показаны в таблицах. Судя по первой, оба эксперимента нужно откатывать так как они дают отрицательный результат.
| A1 | B1 | A2 | B2 | |
| LTV | 220 | 180 | 210 | 190 |
Однако, если мы посмотрим, как эти эксперименты взаимодействуют между собой, то поймем, что откатить оба эксперимента значит потерять потенциальную прибыль. Лучший вариант – принять только 1 эксперимент и это потенциально увеличило бы прибыль на 44%.
| A2 | B2 | |
| A1 | 180 | 240 |
| B1 | 260 | 120 |
Решением может быть сохранение свободной от всех экспериментов группы пользователей или простой анализ экспериментов как перед их запуском, с оценкой перспектив и возможностей их взаимного влияния, так и уже при получении результатов. В этом может помочь постоянный мониторинг ключевых метрик. Снижение показателей – повод пристальнее присмотреться к экспериментам. Также может помочь мониторинг всех экспериментов, которые есть в продукте, для проверки, в том числе, совместных эффектов.
Ошибка 4. Мы вырастили продукт на 200%, но это не точно
Кажется, что это лежит на поверхности, но не забывайте про статистическую значимость: большая выручка или значение метрик не означает, что вариант действительно лучше. Нужно проверять статистические значимости всех изменений, исходя из них планировать длительность всех экспериментов, потому что бывает, что проверяя что-то на небольшом проекте, в нашем случае, на небольшой локали (стране), нужно очень долго ждать результат, особенно если это лежит глубоко в воронке приложения.
В этом случае простой критерий Стьюдента или Фишера и доверительные интервалы для базовых показателей позволят лучше понимать, что происходит в сервисе, что метрики действительно растут, и обезопасит от принятия решений, мотивированных ложными данными.
Кейс
До того, как мы сами начали следовать этим простым правилам и отслеживали статистику только в подозрительных ситуациях, мы вынесли одну из ключевых функций – прослушать звук вокруг ребенка – на главный экран.
В итоге в первые дни LTV показал рост +20%, но по прошествии времени экспериментов варианты сравнялись по этому показателю. При этом статистические тесты с самого начала опровергали гипотезу о разнице в группах.
Отслеживание статистических показателей позволяет проверять гипотезы о том, какие посылы работают, и получать результаты в адекватный промежуток времени, а не принимать решение по велению души. Для ускорения экспериментов в этом случае необходимо применять методы уменьшения дисперсии для экспериментов, но это отдельная важная и сложная тема.
Ошибка 5. Человеку свойственно ошибаться
Если А/Б-тестирование поставлено на поток и не автоматизировано, то в процессе проведения тестов есть множество простых и рутинных задач. Однако цена ошибки – это качество принятых гипотез. Механическая ошибка в группе А и Б меняет результаты на противоположные.
Когда мы только начинали ставить А/Б-тестирование на поток, метрики по всем текущим экспериментам считались ручками 1 раз в неделю на SQL перед специальным собранием. Однажды этот подход дал жесткий сбой, мы тестировали локализацию приложения в Бразилии. По рекомендации локальных маркетологов мы сменили картинки на рекламных скриншотах так, чтобы пользователю было проще ассоциировать себя с людьми на картинке. Этот эксперимент шел успешно на протяжении 3 недель и только на 4-й что-то пошло не так. На 4-й неделе, “данные пересеклись”, и мы начали разбираться. Оказалось, что эксперимент не имел положительного эффекта: мы впустую потратили 3 недели.
Другой кейс – ошибки на более раннем этапе – при биении на А/Б-тест. В прошлом году мы недосмотрели и поставили 2 одновременных эксперимента на одну и ту же группу пользователей. Выглядело это так: тестировали новые картинки на онбординге, а получили рост продаж лицензий. Фантастика! Начали разбираться, оказалось, что эксперимент с картинками полностью совпал с другим, нацеленным на оплату. Пришлось делать перетест обоих экспериментов. В итоге картинки не оказали никакого влияния, а эксперимент с оплатой остался в приложении.
Необходимо постоянно мониторить метрики и статистическую значимость. Если сегодня мы выигрываем, то это не значит, что это не случайно, даже если статистические критерии говорят об этом. 99% значимости эффекта от эксперимента – это достаточно точная гарантия валидных результатов. Однако если метрика LTV пересекается несколько раз, то это повод задуматься над тем, что текущее значение – это статистический выброс. Идеальная картина эксперимента: это когда данные с первого дня показывают стабильную разницу, которая не меняется во времени, а доверительные тесты только сужаются.
В итоге автоматизация всех рутинных процессов позволит избежать большинства обидных ошибок и больше внимания уделять качеству проработки нетипичных кейсов и развитию качества аналитики. Это в итоге позволит ускорить проведение тестов, улучшить качество гипотез и больше доверять результатам.
Ошибка 6. Всегда нужно иметь какую-то тактику и желательно ее придерживаться
И последнее, но не по значимости, – это заранее планировать эксперименты, четко представлять цели. Возьмите себе за правило при постановке ТЗ на эксперимент задавать себе такие вопросы: Какие метрики вырастут? Какие есть риски? При этом учитывайте недополученную прибыль от позднего принятия эксперимента, потенциальный шанс снизить текущие метрики и расход ресурсов.
В идеальном мире мы заранее знаем, сколько будет длиться эксперимент, какой эффект мы будем считать успешным (изменение ключевых метрик), когда мы будем отключать эксперимент и в каком случае. При отсутствии детального проектирования экспериментов запросто можно не получить какого-то конкретного результата. В итоге приходится досчитывать метрики, и тут оказывается, что не всегда это возможно, и приходится пересчитывать все. Иногда для этого требуются различные дополнения в самом приложении, и получается, что мы очень сильно затягиваем процесс принятия гипотез, тормозим развитие продукта.
Кейс
Недавно мы проверяли новый формат оплаты на небольшой локали, с учетом пожеланий интернет-маркетологов сделать кнопку входа в меню более яркой и детальной. В итоге оказалось, что для этого требуется много времени. Мы долго раскачивались, в приложении появились достаточно крупные изменения интерфейса, так что потребовалось заново запускать весь эксперимент, заново его менять, исходя из нового меню.
Другой пример: мы решили добавить эксперимент с подключением второго родителя (отправляется реферальная ссылка, при установке приложения пользователь подключается сразу же и минует этап подключения детей). Мы сделали это подключение в двух местах – при регистрации и из меню приложения, однако реферальная ссылка была одинаковой для обоих мест. Соответственно, возникли проблемы с определением, где именно подключается больше людей. По итогу было сложно понять, эффективны оба экрана или только один, какая конверсия из отправки ссылки в подключение второго родителя на них, и, как следствие, какой из экранов нужно улучшать в первую очередь.
***
Узнать больше о секретах успешного маркетинга можно на нашем канале в Telegram — Secretmarketingua
***
Заключение
Эксперименты – драйвер роста, и от их правильного применения зависит то, в какую сторону будет двигаться продукт. Выдвинуть гипотезы – лишь первый шаг в улучшении продукта. Не забывайте, что рост 200% приходит только с гипотезами на ценности пользователей, а не от изменения положения кнопки покупки.