Продуктовая разработка в «Ауре»: гипотезы, side-by-side и эксперименты

В этой статье расскажем о процессе продуктовой разработки в «Ауре» и детально рассмотрим улучшение переключения ленты постов.

С чего все начинается — формирование гипотез

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

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

Есть продукт, который уже вышел на рынок, у которого уже есть первые пользователи и который уже решает определенную их задачу. Как его улучшать и что такое улучшение?

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

При этом причинно-следственную связь изменений в продукте и изменений на метриках можно отследить только в честных экспериментах — об этом детально ниже.

Про метрики стоит написать отдельную статью, но, если кратко, то всегда есть базовые метрики — они могут быть отложенными и долго прокрашиваться в экспериментах (например, MAU, retention 30 и так далее), поэтому часто есть набор второстепенных метрик, которые связаны с главными метриками, но которые быстро прокрашиваются в экспериментах («прокрашиваются» — обладают достаточной чувствительностью, чтобы показывать статистически значимые отличия за разумный период эксперимента).

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

Откуда брать такие гипотезы? Мы выделяем следующие методы формирования гипотез:

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

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

  • трек постоянно формируемых гипотез для улучшения ранжирования ленты (ML).
  • трек гипотез по новому функционалу.
  • трек гипотез по улучшению текущего функционала.

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

Пример формирования гипотезы и ее быстрая валидация

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

При этом пользователю на текущий момент доступно 6 типов лент постов:

  • Все посты — посты, которые ранжируются алгоритмом на основе поведения пользователя.
  • Подписки — посты от людей, на которых пользователь подписался.
  • Сообщества — посты из сообществ, в которых участвует пользовтель.
  • Горячее — топ-30 обсуждаемых постов за вчера.
  • Рядом — посты, которые были сделаны в 5 км от текущего положения пользователя.
  • Анонимные — посты от анонимных пользователей.

На ПК это выглядит достаточно прозрачно в виде бокового меню:

Выбор типа ленты на ПК

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

Выбор типа ленты на мобильных

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

Идентификация проблемы — в поддержку часто приходят вопросы о том, как можно посмотреть посты только от тех, на кого ты подписан или посты только из своих сообществ.

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

Быстрая валидация — провели исследование на текущей базе пользователей, спрашивали пул вопросов, связанных с выбором типа ленты.

Результат — 37% пользователей не знают о том, что можно переключать типы лент на мобильных устройствах.

Решение — пробуем изменить выбор лент, сделать его понятным и по-возможности в 1 клик, за счет чего хотим увеличить базовые метрики продукта.

Side-by-Side

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

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

Появляется задача — понять на раннем этапе еще до разработки, будет ли этот вариант хорошим или нет. Конечно можно сделать много вариантов и запустить на все честные эксперименты (под экспериментами мы понимаем A/B разного вида), но это обычно очень дорого и долго — потому что каждый вариант нужно будет реализовать, сверстать и так далее.

Поэтому для увеличения итогового успеха и уменьшения стоимости и времени разработки, мы используем промежуточный вариант — Side-by-Side. Как это работает?

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

Классический Side-by-Side предполагает, что вы показываете 2 варианта и просите выбрать один из них. Но мы часто просим выбрать один из многих вариантов.

Для Side-by-Side мы используем 2 базы — база наших пользователей (любой пользователь может создать пост с опросом, мы тоже этим пользуемся) и сервис «Я.Толока» (более универсальный вариант).

«Я.Толока» — хороший инструмент для выполнения многих задач, в том числе для проведения Side-by-Side. Если коротко, то это сервис, где живет много исполнителей, которые готовы за определенную плату выполнить разные задания. Как правило эти задания связаны с разметкой данных, модерацией, классификацией изображений и т.д. Стоимость назначает заказчик и она начинается от 1 цента за 1 задание.

Например, вы можете создать проект в «Я.Толоке», в котором покажете несколько вариантов своего интерфейса, опишете проблему и попросите пользователей выбрать наиболее подходящий для них вариант.

Немного цифр — обычно Side-by-Side на 1000 пользователей в «Я.Толоке» мы проводим за $15 (около 1100 руб по текущему курсу) и получаем все ответы в среднем за 30 минут. На наш взгляд, это достаточно дешево и очень быстро для такого вида исследований.

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

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

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

  • Обязательно просить аргументировать свой выбор и фильтровать в результатах ответы, в которых аргументация состоит просто из номера ответа без подробных объяснений.
  • Добавлять в задание специальные «ловушки» от ботов и недобросовестных исполнителей, например, один из вариантов, на котором написано «Не выбирайте этот вариант, это проверка». Дальше фильтровать из результатов тех, кто его выберет и таких исполнителей блокировать во всех последующих проектах в своем аккаунте.
  • Использовать встроенные в «Я.Толоку» системы защиты, например, быстрые ответы и капчу.
  • При настройке задания указывать фильтры на нужную аудиторию — там их много, например, по языку, устройству, уровню образования и так далее.

Пример Side-by-Side

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

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

После этого запустили Side-by-Side на наших пользователях и в «Я.Толоке».

Особенности:

  • Важно следить за смещением аудитории и проверять распределение по ключевым признакам пользователей, ответивших на Side-by-Side в «Я.Толоке», и вашей ЦА. Самое банальное — например, у вас сервис для аудитории студентов, а в «Я.Толоке» вам ответили только люди пожилого возраста, или наоборот, и по любому другому значимому признаку.
  • Важно следить за тем, чтобы разница ответов между вариантами не была случайной, т.е. разница была статистически значимой.

Общие результаты:

Распределение % людей, которые проголосовали за каждый вариант

Решение: запускаем честный эксперимент с вариантами 2 и 4.

Эксперименты

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

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

Про корректную подготовку и проведение написано достаточно много. Одно из важных условий — пользователи должны быть разбиты на независимые группы (бакеты) случайным образом.

Как этого достичь? Для этого мы используем id пользователя, к которому добавляем «соль», а потом хешируем получившееся значение одной из цифровых хеш-функций. Далее считаем остаток от деления на 100 и получаем значение от 0 до 99, по которому принимаем решение, в какую группу эксперимента попадает пользователь. При этом 1 пользователь всегда попадает только в 1 группу определенного эксперимента, заданного «солью».

Зачем нужна «соль»? «Соль» — это уникальный набор символов для одного эксперимента. Если вы хотите запускать одновременно несколько экспериментов, то обязательно должны обеспечить независимость этих экспериментов — то есть пользователь должен попадать в группы разных экспериментов независимо и случайно. Именно это свойство и обеспечивает разная соль для каждого эксперимента.

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

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

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

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

Пример экспериментов

На предыдущем шаге мы выбрали 2 варианта переключения ленты, с которыми готовы провести эксперимент. Что мы хотим от эксперимента:

  • Понять, правда ли предлагаемые варианты лучше по значимым метрикам текущего варианта переключения лент.
  • Если лучше, то какой из 2х вариантов выбрать.
  • Что именно изменит внедрение того или иного варианта.
  • На основе доступных данных, принять решение и выкатить один из вариантов или оставить текущий вариант.

Подготовка и запуск эксперимента:

  • Заводим на бекенде новую «соль» под новый эксперимент. Вместе с информацией о пользователе на фронт будет приходить значение от 0 до 99 (остаток от деления результата хеширования id пользователя с солью)
  • Реализуем 2 новых варианта на фронтенде и логику отображения каждого из вариантов. В зависимости от значения 0-99 от бекенда, пользователь попадает в одну из трех групп, которые видят свой вариант переключения ленты (1 группа — то, как работает сейчас, 2 группа — вариант 2, 3 группа — вариант 4).
  • Выкатываем все в продакшн — пользователи начали видеть новое переключение ленты, эксперимент начался.

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

Анализ результатов эксперимента. Как мы сказали ранее, нужно определиться с метриками, на которые может влиять эксперимент и по которым мы будем принимать решение о его внедрении. Мы выбрали следующие метрики, которые напрямую связаны с постами и лентой:

  • timespent — среднее время в сервисе в день
  • swipe_rate — отношение лайков в ленте к общему количеству свайпов
  • распределение свайпов по типам лент
  • количество свайпов на пользователя (полезно смотреть и среднее и медиану)

Далее важно определиться, по каким срезам/сегментам пользователей анализировать указанные метрики. В нашем случае мы выбрали 2 сегмента — новые и старые пользователи.

После того, как прошло достаточно времени, чтобы метрики могли прокраситься (получить стат значимые отличия), но желательно не меньше 1 недели, можно приступать к анализу результатов эксперимента.

Абсолютные числа мы по понятным причинам показывать не можем, но можем показать +/— значения метрики от базового варианта. Если ячейка таблицы серая, значит мы не получили стат значимой разницы от базового варианта. Если зеленая — стат значимый плюс, если красная — стат значимый минус.

Результаты эксперимента

Как видим, для сегмента старых пользователей у обоих новых вариантов стат значимо меняется только распределение свайпов по типам лент на около 5% — пользователи начинают больше смотреть разные типы лент. По другим метрикам стат значимых изменений нет. При этом между вариантом 2 и 4 также нет стат значимой разницы.

Зато для сегмента новых пользователей оба варианта показывают стат значимый рост по трем из четырех метрик — проведенное время растет на около 30%, распределение свайпов по типам лент меняется на около 10% и среднее количество свайпов на пользователя растет больше, чем на 50%.

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

Какой же вариант выбрать — 2 или 4? Т.к. по рассматриваемым метрикам стат значимой разницы не обнаружено, то можно взять в рассмотрение другие доступные метрики и попытаться найти различие там.

Если различий снова нет, то выбираем вариант, за который проголосовало большинство пользователей на Side-by-Side, то есть вариант 2.

Выводы — внедряем вариант 2 переключения типов лент на всех пользователей. Для новых пользователей ожидаем повышение среднего количества свайпов более, чем на 50% и проведённого времени в сервисе в первый день на 30%, а также ожидаем изменение распределения свайпов по типам постов для новых и старых пользователей.

Вариант 2 раскатывается на всех пользователей

Итоговый процесс

Рассмотренный процесс отобразили на схеме:

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

#aura #аура

0
3 комментария
John Doe

Ребята, вы троллите?) Я минут 5 искал отличия между вариантами 1 и 2 и не нашел

Ответить
Развернуть ветку
Aura.top
Автор

В галерее 4 скрина, каждый скрин состоит из двух фото, на которых представлено одно и тоже меню, но с разными выбранными типами ленты. Точно посмотрели всю галерею, а не 2 фото первого скрина?)

1 вариант - иконки белые на серой подложке, 2 вариант - серые иконки без подложки =)

Ответить
Развернуть ветку
John Doe

Да, серую подложку не замечал) Классная получилась статья, спасибо)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
0 комментариев
Раскрывать всегда