Ошибки в дизайне A/B тестов, которые я думала, что никогда не совершу
Запуская свои первые эксперименты, я считала, что все эти «три / пять / семь самых популярных ляпов», о которых читала в статьях и слушала на конференциях — уж точно не про меня. Тем более в дизайне теста помогал большой красивый шаблон исследований, принятый в компании.
Но на практике ждали подводные камни. Давайте поговорим, что может случиться, если вы немного налажаете в дизайне или недоработаете заполнение своего шаблона. И как все это исправлять.
Хотела нанести пользу новым пользователям, но они вели себя естественно не так, как задумано
Основной инструмент продаж в Skyeng — бесплатное вводное занятие по видео с преподавателем-методистом. Мы проводим уроки на своей платформе, и бывает, что ученик пытается подключиться к звонку, но у него не захватывается микрофон или камера.
Это может произойти по десяткам причин — от банального мисклика по уведомлению в браузере (как на этой картинке) до совсем экзотических случаев: например, как-то раз человек пробовал заниматься из Tesla, а там свое ПО, которое мы не поддерживаем.
Если быстро устранить проблему не получается, происходит технический срыв вводного урока:
- у ученика остается негатив,
- у преподавателя срывается занятие,
- школа лишается конверсии в оплату здесь и сейчас (это основная метрика нашего отдела), компенсирует выход на урок преподавателю и запускает процесс по переносу занятия.
Страдают все. Поэтому в прошлом году мы затеяли кучу проектов по снижению технических срывов. Каждую идею тестировали: бизнес хотел понимать, работает ли фича и отобьются ли затраты на ее поддержку.
Одно из решений, которое надо было запустить в тест — квест проверки оборудования. В оригинале это был вижет, вот его основные экраны.
Идея простая: не ждать момента выхода на урок, а предложить ученику проверить камеру и микрофон заранее — когда он оставил заявку на обучение. Если что-то пойдет не так, сформируем тикет в техподдержку, и у ребят будет несколько часов, чтобы решить проблему.
Когда делила пользователей на тест и контроль, ожидала, что в тестовой группе люди будут кликать на виджет и пройдут квест. Что может пойти не так?
В контрольной группе («А») все шло своим чередом — люди оставляли заявку и шли по своим делам. Но после теста мы увидели, что процент технических срывов в группах «А» и «В» был схож до сотой доли процента. Хм, это все в тестовой все группе проходили квест, но он не помогал, или никто не заходил внутрь? Мы не знали — не было логирования.
Два этапа слились в один, и оказалось, что мы не можем их разделить. Пришлось перезапускать тест и логировать ключевой этап «зашли в квест». Мы узнали, что в него заходили около 10% пользователей. Значимого роста метрики не случилось: квест канул в лету, саму проверку оборудования в итоге встроили в онбординг при глобальном редизайне. А я теперь проверяю на старте, будут ли у меня данные обо всех ключевых этапах воронки.
Не спрашивала себя «А раскатить-то сможем?». Или история про звонок, который и правда очень важен для нас
Помимо технических проблем, иногда ученик просто не появляется на том самом бесплатном вводном уроке — потому что проспал, вылетело из головы, что-то перенеслось и так далее.
Поэтому перед каждым занятием методисту нужно найти ученика, который готов к созвону: для этого система выдает ему несколько контактов, и преподаватель их обзванивает. Это «отъедает» 12–15% времени, которое человек может потратить на что-то более полезное или приятное.
Кажется, хорошая возможность для автоматизации — пусть звонит робот. Но нужен А/В тест: ведь часть людей, услышав робота, может кинуть трубку. Возможность что-то просадить — очевидна. Мы запустили тест и поначалу все шло на удивление хорошо, но… Нас подвел перфекционизм.
В ряде сценариев роботу нужно было переводить звонки на человека-оператора: например, если ученик хотел отменить урок, оператор должен был внести изменения в CRM. А иногда роботу просто попадались разговорчивые собеседники — система не была рассчитана на серьезное распознавание речи и поддержку диалогов, тут тоже нужно было подключать человека.
Мы хотели сделать опыт пользователя максимально бесшовным.
Поэтому решили переключать такие звонки сразу на входящую линию телефонии. Даже если вопрос не был срочным. Методисты в тех же случаях говорили: «Вам перезвонят через 3–5 минут, чтобы переназначить урок». И у операторов был запас времени, чтобы распределять нагрузку и успевать помочь всем.
Договориться с роботом операторы не могли, и он создавал пики с несколькими срочными звонками в минуту. Схема оказалась немасштабируемой.
В пиковые моменты ситуация напоминала классическую игру) За фото спасибо «Википедии» и ее контрибьютору perepelin30.
Мы вернулись к схеме, которую используют методисты, — если человек четко озвучивал запрос на перенос, робот отвечал «Мы перезвоним». Сразу на операторов стали переводиться только потенциально срочные вопросы. После этих изменений пришлось запускать тест заново, так как изменение могло повлиять на ключевые метрики. А мы теперь перед каждым экспериментом задаем вопрос: «Ок, если все пойдет хорошо, раскатить-то это сможем?»
Запускала тест, проверяла, что все идет нормально, шла разгребать кучу текущих задач
В Skyeng есть очень классная и растущая часть аудитории — это дети, которые учат с нами математику и английский. Но мы не можем проводить вводный урок для ребенка, если не присутствует его родитель. Прямо юридически не можем. Поэтому, если ребенок подключается один, происходит срыв урока. Дальше вы знаете: негатив, перезапись и прочее.
Родителей всегда предупреждали об этом устно, при звонке, на котором согласовывали время занятия. Но от звонка до урока проходило время и, конечно, не все помнили об этой договоренности.
Тогда пришло решение: давайте отправлять смс-напоминание. Примерно такой текст уходил родителю ближе ко времени вводного занятия.
Рост числа вводных уроков без срывов не значит роста конверсии в оплату. Нужно прикинуть ROI. Для этого проведем эксперимент:
- рандомно поделим все заявки по детскому направлению на две группы,
- родителям в первой группе не отправим ничего — у них обычный флоу,
- родителям в другой группе отправим два смс-напоминания: за 24 и за 1–2 часа до начала урока.
Стартовали тест, сделали проверку в первый день — и пошли разгребать текучку.
Через пару недель заглядываю в дашборд —, а там кроме тестовой и контрольной группы есть еще какие-то пользователи.
Если мы хотели делить 50 на 50, то красный график явно говорит — что-то пошло не так.
Оказалось, виной всему банальный баг: что-то не то с событиями, смс по триггерам уходили не всем. Баг починили, но тест пришлось перезапускать заново: в итоге, даже если у вас есть правильный дизайн теста, со всеми заполненными шаблонами и так далее — это не значит, что тест пройдет гладко. И заглядывать в него стоит как можно чаще.
p.s. Я очень надеюсь, что этот текст поможет кому-то совершить меньше ошибок в своих тестах. Скорее всего у вас будут или уже есть свои забавные кейсы: будет круто, если вы когда-нибудь тоже ими поделитесь!
p.p.s. Пост основан на докладе в ростовском ИТ-комьюнити RnDTech — если вы живете где-то на юге страны, присоединяйтесь, ребята делают отличный движ.
