Чтобы приложение стало действительно «народным» цифровым продуктом, его необходимо постоянно совершенствовать в соответствии с пожеланиями пользователя. Но как?
Узнать больше о болях и предпочтениях целевой аудитории помогают A/B-тесты — с помощью этого метода анализируют реакцию на нововведения разработчики самых разных платформ, и онлайн-кинотеатры не исключение. Александр Труфанов, руководитель направления продуктовой аналитики онлайн-кинотеатра KION, рассказывает, как строятся гипотезы для таких тестирований, какой результат считается успешным и почему без A/B-тестов развитие продукта невозможно.
Что это за инструмент?
A/B-тестирование или сплит-тестирование — это эффективный метод проверки различных продуктовых гипотез. В рамках такого теста разработчики выделяют из числа всех пользователей платформы две рандомно отобранные небольшие группы — эти люди становятся группой A и группой B соответственно.
Одной контрольной группе всё оставят как было, а другой продемонстрируют нововведения, которые планируется реализовать на сайте или в приложении. Это может быть новый дизайн кнопок, новая версия главной страницы, новая механика плеера или что угодно ещё. Затем аналитики «замеряют» реакции двух групп и делают вывод, в каком случае показатели лучше — с новым функционалом или без него.
Например, если выяснится, что группа, увидевшая обновление, чаще заходит в онлайн-кинотеатр и досматривает фильмы и сериалы до конца, чем это делает контрольная группа, значит, изменения пойдут платформе на пользу. Если же у тех, кто столкнулся с новым функционалом, показатели посещений и просмотров падают, такую фичу не стоит реализовывать.
Можно ли доверять результатам?
Стоит отметить, что люди в группы для тестов набираются максимально похожие, в среднем их характеристики примерно одинаковы. Для этого нередко испытуемые подбираются разработчиками рандомно. Сходство пользователей группы A с пользователями группы B — залог объективных результатов исследования.
Конечно, можно было бы сделать нововведения доступными сразу всем пользователям на платформе и уже потом проанализировать, насколько улучшились показатели. Но, во-первых, есть много других факторов, влияющих на результат, и время — один из таких факторов. Объём потребления контента в праздники и в будние дни разный, также существуют сезонные скачки и спады интереса. Чтобы исключить из уравнения влияние времени, внедрённые изменения и исходная версия тестируются одновременно.
Во-вторых, на частоту посещения онлайн-кинотеатра может банально повлиять громкая премьера нового сериала. Чтобы исключить вероятность повышенного интереса к платформе, связанного с новыми сериалами и фильмами, разработчикам пришлось бы выпускать обновления лишь тогда, когда на сервисе не выходит новый контент. В случае с активно развивающейся платформой, на которой новое кино появляется постоянно, это невозможно.
В-третьих, выкатить обновление сразу на всю платформу — это большой труд. Реализация таких масштабных изменений требует ресурсов команды, времени, бюджета, сил и готовности оперативно приходить на помощь многочисленным пользователям, если у них возникнут вопросы, связанные с новыми фичами.
Таким образом, A/B-тесты — оптимальный способ исследования реакции аудитории на новые фичи. В идеале при помощи сплит-тестов стоит проверять целесообразность любых нововведений. Иногда даже незначительные изменения могут сделать продукт гораздо привлекательнее для пользователей или, наоборот, разрушить позитивный опыт взаимодействия с платформой.
Тестирование фичи на небольшой аудитории помогает убедиться в том, что ей стоит посвящать ресурсы компании, на ней стоит фокусировать команду, в неё стоит инвестировать средства. Без тестов есть риск, что разработчики потратят время и силы на бесполезную функцию или даже функцию, снижающую показатели эффективности платформы, хотя они могли бы сконцентрироваться на чём-то полезном и нужном. Очевидно, внедрение обновлений без предварительных тестов может грозить компании убытками.
Как генерировать новые гипотезы?
Любой тест начинается с гипотезы — какого-то утверждения, доказать или опровергнуть которое предстоит в результате исследования. Гипотеза — это сформулированное ожидание от фичи. Ответ на вопрос «Какого эффекта мы добьёмся, если реализуем это нововведение?».
Многие гипотезы могут подсказать вам сами пользователи: их комментарии в магазинах приложений или соцсетях компании станут вдохновением для изменений на платформе. Иногда, если аудитория делится мнением неохотно, компании делают рассылку по своим клиентам и прямо просят рассказать, что им хотелось бы улучшить.
Суммируя, для генерации гипотезы нужно:
- Анализировать поведение пользователей на платформе (метрики: CR, CTR, TVTU — total view time на юзера и пр.);
- Анализировать обратную связь от пользователей (комментарии, обращения в поддержку, фокус-группы и любые виды коммуникации);
- Анализировать опыт конкурентов и зарубежных коллег по цеху;
- Масштабировать собственные удачные идеи (иногда гипотеза рождается в процессе реализации другого кейса или проведения небольшой локальной/ситуативной кампании).
А что после гипотезы?
Когда гипотеза будет сформулирована, важно определиться с метриками. Чем вы будете измерять эффективность своей фичи? Просмотрами, количеством проведённого на платформе времени, количеством кликов или чем-то другим?
Помните, что результаты вашего исследования должны быть измеримы, и сразу подумайте о том, на какие показатели будете смотреть. На этом же этапе решите для себя, какую разницу в результатах групп A и B вы будете считать важной, а какую можно будет отнести к статистической погрешности.
После этого останется обдумать детали эксперимента: сколько человек будет в тестируемых группах, когда и насколько долго вы будете проводить тест и так далее.
Что считать успешным тестом?
Конечно, разработчикам хочется, чтобы каждая их гипотеза выигрывала в тестах, но так получается не всегда. Важно понимать, что успешность теста оценивается правильностью его проведения, а не тем, что он показал статистически значимую разницу подходов.
Если тест проведён с соблюдением всех необходимых требований, то отрицательный результат — это тоже результат, потому что понимание, что фича не работает, сэкономило компании массу времени и других ресурсов на реализацию того, что не сработало бы.
Если же тест проведён неверно или фича просто плохо реализована, то нововведение может провалиться в тесте, хотя гипотеза верна. Например, если вы покажете пользователю плохо свёрстанную страницу с трейлером фильма вместо привычной статичной картинки, вы можете зарегистрировать падение интереса.
Но связано оно будет с тем, что страница сама по себе имеет отталкивающий вид, а не с тем, что пользователь предпочитает статичные картинки видеороликам. Чтобы тест прошёл успешно и дал объективные результаты, важно внимательно следить и за качеством реализации тестовых фич.
Но самое главное — не бояться экспериментировать и поощрять в команде здравый авантюризм, ведь нередки кейсы, когда подтверждается самая парадоксальная гипотеза.
Комментарии