Скоринг фичей на основе метрик воронки. Funnel Scoring Model. Часть 2

Привет!

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

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

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

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

Вот тут можно посмотреть пример таблицы, скопировать его себе и покрутить формулы, а дальше я проведу по нему подробнее:

Шаг 1. Собираем модельные данные

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

Воронка для нашего примера будет состоять из нескольких, следующих друг за другом, шагов:

  1. поиск (вход в воронку)
  2. карточка товара
  3. подробное описание
  4. оформление заказа
  5. оплата

В воронку люди будут попадать из пяти разных каналов трафика с разным уровнем мотивированности.

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

Зеленым я отметила блоки, которые нужно отредактировать. Все остальные данные для модели считаются через встроенные формулы.
Зеленым я отметила блоки, которые нужно отредактировать. Все остальные данные для модели считаются через встроенные формулы.

Нам нужно 4 блока данных:

- Сколько уников пришло из разных каналов (users).
Это цифра в блоке Traffic channels рядом с названием каждого канала. Каналов может быть сколько угодно.
Здесь, кстати, надо сразу определиться, в чем мы дальше будем считать всю модель — в униках или в сессиях. Мы рассматриваем ситуацию, в которой клиенты покупают точно не чаще раза в месяц, поэтому берем уников. Если у вас бизнес, в котором люди покупают чаще — модель не очень подойдет (либо ее надо будет как-то сильно адаптировать). Об этом я напишу дальше.

- Конверсия в совершение поиска в каждом из каналов (c2search) — метрика мотивированности трафика.
Это цифра в процентах около каждого из каналов трафика.
Если у вас достаточно аналитики и вы можете посчитать то, сколько пользователей из каждого канала дошли до входа в основную воронку — супер. Используйте эти данные.
Если вы почему-то не можете посчитать эти данные, но на всех лендингах есть только две опции — перейти в начало воронки (например, сделать поиск) или закрыть страницу — то можно воспользоваться встроенным в любую систему аналитики показателем exit rate (не путать с bounce rate!). Exit rate показывает, для какой доли юзеров ваша страница была последней в сессии, то есть дальше они не пошли. От него можно посчитать с2search, то есть конверсию в попадание в воронку по формуле 100%-exit_rate.

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

- Наконец, нам нужен средний чек (AOV).

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

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

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

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

Шаг 2. Делаем калькулятор.

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

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

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

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

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

Скроем все служебные блоки и получим вот такую готовую скоринговую таблицу:

В такую таблицу остается только вносить в соответствующие ячейки прогноз изменения показателей в процентах. Дальше все само посчитается.
В такую таблицу остается только вносить в соответствующие ячейки прогноз изменения показателей в процентах. Дальше все само посчитается.

Шаг 3. Скорим фичи с помощью калькулятора — примеры!

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

Фича: пуш в приложение по брошенному описанию товара

Гипотеза: будет возвращать в воронку тех, кто не перешел дальше с просмотра деталей товара в оформление заказа с вероятностью 8%

Обоснование: настроили руками отправку по двадцати товарам из разных категорий, получили увеличение конверсии в 8% перехода к оформлению.

Результат: +8% к обороту

Что здесь интересного:
конверсии шагов воронки — это множители друг на друга. C = c1*c2*c3*c4*c5. То есть, если вы при проверки гипотезы получили увеличение финальной конверсии в 8% — это математически то же самое, что увеличение на 8% какого-то шага. В реальной жизни обычно увеличивается конверсия нескольких шагов по чуть-чуть и в сумме дает эти 8%, но для моделирования не обязательно так углубляться.

Фича: товары, похожие на этот

Гипотеза: если на карточке товара будут еще похожие товары, то:
1) увеличится вероятность дохождения до деталей на 5%,
2) органический и срс трафик, который лендится на карточки товаров будет идти по воронке на 5% лучше. Из органики 20% падает на карточки товаров, из срс — 5%.

Обоснование: встроили бесплатную триалку рекомендательного сервиса и увидели такой рост конверсии. Для cpc-канала получили улучшение в 5% на специально запущенных кампаниях на товары, для которых работала эта бесплатная триалка. Объем трафика в органике на карточки знаем из аналитики.

Результат: +5,29% к обороту

Что здесь интересного: ставить улучшение в нескольких ячейках сразу — легально, и очень часто так и происходит. Кроме того, если улучшение касается только какой-то доли трафика, то долю улучшения надо взвесить по доле трафика (20% в органике лендятся на товар и получают улучшение в 5% = 20%*5% = 1%)

Фича: баннер на ТТК

Гипотеза: повесим огромный лаконичный баннер с доменом и понятным слоганом на Трешке. В Москве 8 млн машин, из них в месяц 50% хотя бы раз проезжают по ТТК. Бренд-лифт от баннера оцениваем в 0,5% от числа проехавших машин (20к). Из них 2/3 (13400) введет название в поиск, 1/3 (6700) — наберет название домена. 13400 это 38% органики, 6700 это 21% тайпина. Однако трафик будет низкомотивированный, поэтому мы предполагаем снижение конверсии в переход в воронку на 30% для этого сегмента.

Обоснование: референсы по цифрам получены от брендингового агенства на базе их предыдущих кейсов. Снижение конверсии низкомотивированного трафика — наше предположение.

Результат: +8,16% к обороту

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

Фича: консультация эксперта как допуслуга

Гипотеза: при оформлении заказа на сайте с витаминами будем предлагать купить консультацию с нутрициологом.

Обоснование: взяли живого нутрициолога и попробовали догонять письмами после покупки тех, кто купил витамины, получили конверсию в покупку дополнительной услуги в 15%. Услуга стоила 50$, при базовом чеке в 321$ это 15,6%.

Результат: +2,34% к обороту

Что здесь интересного:
различные дополнительные услуги увеличивают чек, но не для всех пользователей, а только для той доли, которая конвертируется в покупки этих дополнительных услуг: 15%*15.6% = 2,34% увеличения чека.

Фича: починить топ-20 критикал багов на карточке товара

Гипотеза: мы теряем до 12% в конверсии перехода в следующий шаг на багах карточки товара.

Обоснование: посчитали, что суммарно все фичи карточки, которые запустили за последние полгода подняли конверсию в аб-тестах на 23%, а мы ожидали суммарного эффекта в 35%. После запусков остались известные нам недочищенные баги с высоким приоритетом, о которых мы знаем из обратной связи. Кажется, они не дают нам дорасти в конверсии до ожидаемого результата.

Результат: +12% к обороту

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

Вот результирующая таблица:

Вот так мы вводим весь наш бэклог в таблицу, а в конце сортируем по убыванию результирующего показателя, например, GMV
Вот так мы вводим весь наш бэклог в таблицу, а в конце сортируем по убыванию результирующего показателя, например, GMV

И побеждает в чемпионате починка багов! Я сделала так ради поучительности истории, очевидно скоринг не всегда заканчивается таким образом.

Дополнительно мы видим, что есть фичи, которые не так сильно влияют на финансовый результат, но увеличивают, например, аудиторию продукта (баннер на ТТК). В настоящем продукте с настоящими фичами появляется возможность выделить те из них, которые увеличат узнаваемость бренда, снизят и повысят конверсию, увеличат количество заказов — и сделать множество других полезных выводов.

Шаг 4. Делаем себе удобно

В своей версии этого фреймворка можно добавить в таблицу для удобства дополнительные столбцы:

  • название команды, которая будет делать фичу и имя продакта (или другого руководителя), какие-то другие лейблы, которые помогают ориентироваться в бэклоге — бизнес-вертикаль, проект и т. д.
  • комментарии и ссылки на подробности по проекту
  • факторы ICE. Impact у нас уже практически есть, он считается от GMV. Можно добавить Confidence, поскольку мы работаем с гипотезами разной степени проработки, и Effort — оценить с командой стоимость разработки
  • ожидаемые даты старта разработки и релиза — можно заполнять после общения с технической командой
  • ссылку на эпик в Jira, статус задачи и флаг «готово/не готово»
  • колонку для фактического результата после запуска фичи — чтобы сравнить свою предварительную оценку с реальностью и сделать выводы

Что в итоге

Мы видим, как внедрение нагенеренных командой фичей отобразится на результатах компании! Круто, правда? Можно почелленджить обоснования друг друга, повоевать за ресурсы, разочароваться в идеях, которые казались гениальными и присмотреться к тем, которые вышли в топ!

Однако у фреймворка есть некоторые ограничения:

1. Он не учитывает трудозатраты.

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

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

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

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

2. Модель подходит только для прямых вороночных продуктов.

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

3. Новые и повторные.

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

4. Модель подходит для бизнесов, где пользователи покупают не часто.

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

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

5. Хотя в оценке фигурируют деньги — их не стоит принимать слишком близко к сердцу.

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

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

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

4
1 комментарий