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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Появляется задача — понять на раннем этапе еще до разработки, будет ли этот вариант хорошим или нет. Конечно можно сделать много вариантов и запустить на все честные эксперименты (под экспериментами мы понимаем 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 минут. На наш взгляд, это достаточно дешево и очень быстро для такого вида исследований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#aura #аура