Как часто вы оставляете подробные отзывы на приложения и сервисы, в деталях описывая, на что разработчикам нужно обратить внимание и в какую сторону стоит менять продукт? Как правило, подробную обратную связь люди дают редко и неохотно, гораздо чаще они молчат о своих пожеланиях, а с неудобствами просто мирятся, пока не кончится терпение. К счастью, у разработчиков есть способ узнать о неозвученных желаниях пользователей и определить вектор развития продукта. Этот способ — A/B-тестирование. Александр Труфанов, руководитель направления продуктовой аналитики онлайн-кинотеатра KION, объясняет, как этот инструмент служит для платформы языком общения со зрителями.
Что такое A/B-тестирование?
Успех технологичного продукта напрямую зависит от его способности постоянно эволюционировать. Нововведения (или, как их называют сами разработчики, «новые фичи») неизбежны, но не всегда можно предугадать, как на те или иные изменения отреагируют пользователи платформы. Возможно, фича сделает сервис еще удобнее и функциональнее, а значит, привлечет на платформу новых зрителей, но возможно, что обновление «не зайдет», и тогда онлайн-кинотеатр потеряет зрителей, просмотры и прибыль. Собственно, для проверки, будет ли пользоваться изменение успехом, и существуют A/B-, или сплит-тесты. Это относительно простой и быстрый способ проверить любую гипотезу разработчиков и узнать, как и насколько успешно с нововведением взаимодействуют пользователи. С коммуникационной точки зрения мы говорим о сборе обратной связи, что делает A/B-тестирование средством общения между платформой и конечным пользователем.
A/B-тестирование может применяться для проверки гипотез любого масштаба. Например, разработчик решил изменить дизайн маленькой кнопки: перекрасить ее в другой цвет и вместо слова «Старт» написать на ней «Смотреть». Или команда захотела полностью поменять дизайн всей главной страницы сайта и вместо статичной картинки добавить на нее интерактивные видеоэлементы. И в том, и в другом случае проверить, насколько это хорошие идеи, поможет A/B-тест.
Разработчики выберут среди пользователей две группы — A и B. Одним (группе A, также часто называемой «контрольная группа») все оставят как было, а другим (группе B, «тестовой группе») покажут обновленную версию. Спустя время нужно будет проанализировать, какая разница появилась в поведении пользователей из двух этих групп, в их взаимодействии с платформой. Упрощая: если окажется, что группа B проводит в онлайн-кинотеатре больше времени, чаще смотрит контент и чаще досматривает его до конца, значит, обновление, показанное группе B в тестовом режиме, пойдет всему сервису на пользу, и эту фичу стоит сделать доступной для всех зрителей. Если обновление касалось больше «начинки» платформы, а не дизайна, то при анализе результатов теста учитываются и технические характеристики: изменилась ли у группы B скорость загрузки контента, повлияла ли тестируемая фича на битрейт и так далее.
Насколько объективны такие тесты?
Как правило, люди в группы A и B набираются рандомно, соответственно, в среднем они плюс-минус одинаковы. Да, в ряде случаев разработчики могут вручную определять, кто будет участвовать в тестировании в целом, но при этом между членами двух отдельных групп не должно быть большой разницы, чтобы результаты были максимально объективными.
Цель эксперимента — сравнить реакции пользователей, которые не отличаются друг от друга ничем, кроме того, что одним новая фича доступна, а другие о ее существовании пока даже не знают. Важно, чтобы в среднем люди в группах A и B не сильно различались предпочтениями по контенту, стажем пользования сервисом и так далее. Рандомная выборка как раз помогает подобрать максимально усредненные и уравненные между собой группы.
Многие могут задуматься, почему бы просто не выкатить обновление на всех пользователей платформы и не сравнить показатели после обновления и до него. Но представьте ситуацию: мы делаем нововведение доступным для всех на неделю, сравниваем показатели этой и предыдущей недели и по результатам обнаруживаем прирост зрителей и повышение среднего времени просмотра контента. Казалось бы, гипотеза доказана — фича понравилась, людей стало больше, они стали смотреть контент чаще. Но что, если на той же неделе вышел новый сезон популярного сериала или на улице шел ливень каждый день? Повышение интереса к платформе и просмотру сериалов дома вполне может быть связано с громкой премьерой, а не с изменениями самого сервиса. Или другой пример: предыдущая неделя может выпасть на праздничные дни, а новая — на будние, а это тоже может отразиться на взаимоотношениях пользователей с онлайн-кинотеатром, на частоте просмотров и даже количестве новых регистраций.
Для объективной оценки ценности фичи нужно проводить тестирование между двумя разными группами людей, причем отслеживать реакции двух этих групп нужно параллельно, в один и тот же период, чтобы исключить влияние на результаты посторонних событий — праздников, премьер на платформе или даже светских новостей, связанных с актерами и режиссерами сериалов, представленных в библиотеке онлайн-кинотеатра.
Кто проводит A/B-тестирование?
В KION за A/B-тесты отвечают продакт-менеджер и аналитик. Они формулируют гипотезы, определяют важные метрики и решают, сколько пользователей должно участвовать в исследовании, чтобы изменение было статистически значимым.
В целом же тесты могут проводить маркетологи, которые хотят определить наиболее эффективные инструменты и способы коммуникации с пользователями. Рассылая, к примеру, двум группам пользователей разные пуш-уведомления и замеряя эффективность таких напоминаний, они тоже проводят A/B-тест.
Также в A/B-тестах почти всегда задействованы продуктовые дизайнеры, разрабатывающие новые визуальные решения — от целых страниц до отдельных кнопок — и меняющие интерфейс платформы.
Кроме того, конечно, в таких тестах часто участвуют разработчики, их руками реализуются многие новые фичи, касающийся технического наполнения сервиса.
Что нужно для A/B-тестирования?
Идея
Именно идея нововведения первична в A/B тестировании. Будь это идея редизайна плеера, идея новой фичи или идея изменения уже существующего функционала платформы, именно с этого «А давайте сделаем…» начинаются все A/B-тесты. Если вы верите, что ваша идея поможет сервису, улучшит пользовательский опыт и важные для вашей компании показатели (в нашем случае — количество зрителей, частоту и продолжительность просмотров контента, так далее), то идея вполне заслуживает того, чтобы стать тестируемой гипотезой.
Гипотеза
Гипотеза — это сформулированное утверждение формата «Если мы сделаем X, то в работе платформы произойдут позитивные изменения Y». В роли Y может выступать рост числа регистраций, рост количества просматриваемых подряд фильмов или эпизодов сериалов, увеличение времени нахождения пользователя на платформе и так далее. Формулируя гипотезу, вы определяете, какого эффекта ожидаете от нововведения, что и как, по-вашему, должно поменяться.
Метрики
Чтобы тестирование прошло эффективно, важно еще на старте продумать, как вы будете оценивать и анализировать результат. Для этого нужно определить, на какие метрики вы будете обращать внимание. Можно идти и в обратном направлении: сначала понять, какие метрики нужно нарастить, а потом уже выдвигать гипотезу, которая, по идее, должна способствовать такому росту.
Кроме того, чтобы определить метрики, важно еще и понять, какое изменение вы будете считать важным. Всегда существует статистическая погрешность, особенно, когда дело касается двух рандомно набранных групп пользователей.
А сколько людей понадобится для тестирования? Это тоже важный параметр. Стоит ли сравнивать поведение на платформе двух групп из 3–5 человек, или такое исследование будет нерепрезентативно? А точно ли стоит вовлекать в тест 5 000 пользователей? Когда все ответы будут на руках, можно смело приступать к исследованию.
Читать далее:
Мощная вспышка изверглась на Солнце: она уже повлияла на Землю
Средневековую крепость случайно обнаружили в лесу: находка удивила ученых
Ученые нашли новое генетическое заболевание у детей: как оно проявляется