GrowthHacking в Авито Доставке

Привет! Я Миша Лобанов, старший аналитик юнита Маркетплейс, занимаюсь улучшением опытом покупателей в Авито Доставке.

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

Одним из способов «хакнуть» дальнейшее развитие продукта — прибегнуть к GrowthHacking подходу. В нем мы тестируем гипотезы, которые дешевые в реализации, разнонаправленные и самое главное — много. 

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

Такой подход имеет как преимущества, так и свои недостатки, которые далее хочу разобрать на разных этапах цикла всего тестирования:

Подготовка к тестированию

Ключевым артефактом здесь выступает правильно выстроенный роадмап тестов на горизонте планирования (например — квартала). Это позволит увидеть потенциальные пересечения тестируемых блоков продукта с другими командами, учесть релизы мобильных платформ и сервисов, распределить нагрузку на техническую команду, а также обеспечить «подушку безопасности» на случай потенциальных рисков и влетов, когда речь идет о конечном ресурсе команды. Не менее важно — запланировать нагрузку на самого аналитика, так как при подведении итогов можно столкнуться с более затратным анализом результатов, чем обычно. Например, это может быть связано с противоположным гипотезе результатом или с неожиданными прокрасами метрик и сегментов, которые изначально не закладывались в гипотезу, но понимание их природы поможет выстроить дальнейшую стратегию развития продукта, либо скорректировать планы по текущим экспериментам. Важно не злоупотреблять объемными анализами и разумно распределять ресурс аналитика, иначе идея Growth Hacking экспериментов себя изживает.

Универсальный формат учета, удобный для всех участников процесса

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

Четко поставленные гипотезы перед стартом каждого экспериментом

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

Важно погрузить команду в специфику проводимых GH экспериментов

Не стоит забывать, что необходимо подсвечивать специфику проводимых экспериментов не только заказчикам, но и вовлеченным в тестирование членам команды. Важно заранее обговорить и провести онбординг команды в проблему множественной проверки гипотез и подходов к анализу GH экспериментов, позже это может уменьшить количество запросов на подробный анализ или ложных поисков прокрасов метрик в отдельных сегментах («Прокрас где-то есть, нужно его еще поискать и тогда тест будет зеленым»). Стоить помнить, что если из 20-ти проводимых тестов стабильно зеленых единицы (1-2), то такой результат почти всегда случаен (по мат.ожиданию). То же касается и метрик: чем больше метрик мы сравниваем, тем больше вероятность, что мы получим случайный прокрас, поэтому стат.значимость результатов с большим набором метрик должна быть выше (также не забываем про снижение мощности при повышении стат.значимости, решаем эту проблему через поправки, например Холма-Бонферонни).

Своевременное подсвечивание итогов

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

Делегирование

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

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

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

Применение дополнительных техник засчитывания эффекта в AB

Как правило, GH эксперименты имеют менее выраженное влияние, чем в обычном AB, поэтому, зачастую требуется применение методов снижения дисперсии, таких как стратификация, линеаризация, CUPED и др. Также можно напрямую работать с полученным эффектом, применяя соответствующие методики, например Adjusted Uplift, чтобы отделить реальный эффект наших изменений  от случайных флуктуаций.

Хранение истории и документация результатов

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