Воронка конверсий - идея

К нам на сайт / в приложение приходят X пользователей в неделю
30% из них кликают на карточку товара = 0.3Х
Из этих 30% аж половина (50%) жмет “добавить в корзину” = 0.3 * 0.5X
Ну а реально оплачивают из нажавших всего 10% = 0.3 * 0.5 * 0.1X = 0.015 Х


💡 Базовых идей в воронке конверсий 3
1. Заказы = Трафик * конверсия из захода в приложение в заказ

2. Конверсия из захода в приложение в заказ (CR appstart-order) раскладывается на произведение поэтапных конверсий:
CR appstart-order = CR appstart-item click * CR item click - add to cart * CR add to cart - order

3. Мы можем работать над отдельными этапами воронки. Если улучшаем конверсию на одном этапе и не снижаем конверсию на других этапах + не влияем на трафик, то мы растим заказы. Вот про эту идею часто забывают 🥲. Разберем ее детальнее завтра


Зачем такая концепция нужна?

1. Определить, на каком этапе пути пользователя есть проблемы
В кейсе выше CR appstart-order = 1.5% (0.015 Х)
Кажется, можно лучше (спойлер: не всегда). Тут выглядит проблемной конверсия из добавления в корзину в оплату (CR add to cart - order = 10%)
Тут уже можно дальше закапываться и смотреть, что не так: оплата картой не работает? Юзер добавил товар в корзину, а при оплате видит, что его нет в наличии? Доставка стоит 100500 руб?

2. Упростить понимание бизнеса:
Сравните запрос: “Что-то у нас мало заказов - что делать?” и “Давайте посмотрим, какой этап воронки конверсий у нас проседает”

3. Ускорить ваши А/В 😇
Дисперсия поэтапных конверсий (того же CR add to cart - order) обычно кратно ниже дисперсии общей конверсии (CR appstart-order) и тем более заказов

Поэтому для роста условно “CR add to cart - order” на 1 пп нужно в разы меньше наблюдений, чем для роста на 1 пп “CR appstart-order”. На есть нюансы из-за базовой идеи №3

Нюансы воронки конверсий

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

Представьте, что вы решили добавить на главной странице огромный баннер “Скидка 90% на все по промокоду DISCO”. Клиенты радостно выбирают товары, добавляют в корзину, собираются оплатить и тут.. не видят поля, куда ввести промокод. Что происходит с точки зрения метрик:
- CR app start - item click — растет
- СR item click - add to cart — растет
- СR add to cart - order — падает
- Общая конверсия CR appstart-order — скорее всего не меняется

По идее баннер размещен на главной странице, поэтому влияет в первую очередь на CR app start - item click. Если аналитик не подумал посмотреть в А/В остальные метрики, то он мог бы решить, что фича отличная, а это не так!
———————

Пример выше немного вымышленный, …хотя посмотрите на главные страницы некоторых приложений 😅

Но вот вам менее очевидные кейсы из реальной жизни:

- Убрали принудительную регистрацию при старте приложения. Нужно регистрироваться только при оформлении заказа

- Стали показывать стоимость доставки не только на корзине, но на каждом этапе воронки

- Добавляем раздел “Избранное” на маркетплейсе машин

- Добавляем фичу “Подписаться на скидки на данный товар”

Можете подумать, как себя поведут разные конверсии в этих кейсах. Ну а разбор будет уже завтра 👀

Разбор кейсов с конверсиями случился не вчера, а сегодня)

Про влияние на другие этапы конвесрий, как эти конверсии считать и влияние на траффик


1. Убрали принудительную регистрацию при старте приложения. Нужно регистрироваться только при оформлении заказа

- Растим CR app start - item click, тк убрали барьер новичкам на первом шаге
- Почти наверняка роняем CR add to cart - order, тк новичкам теперь придется тут проходить регистрацию - не все захотят и отвалятся
- CR item click - add to cart неочевидно, но возможно немножко уроним 🥲 Тк на этом этапе стало больше новичков, котоыре еще не особо знакомы с приложением и вообще не особо уверены, нужо ли оно им

В итоге, надо конечно же смореть на общую конверсию CR app start - order
Но ее очень сложно прокрасить. Тут кейс с регистрацией (актуально только для новичка). Поэтому можно смотреть CR app start - order по новичкам. Она будет скорее всего более чувствительной в АВ 👍

Второй кейс очень похож на первый

Call-to-action: когда можете повлиять на другие этапы воронки, то смотрите в первую очередь на общую конверсию!

2. Добавляем раздел “Избранное” на маркетплейсе машин
Покупка машины - дело довольно редкое для обычного пользователя. Поэтому тут я бы считал конверсию не по сессиям (у юзера 10 сессий, в 3 совершил покупку, CR = 3/10), а бинарно с окном, скажем, в месяц. То есть 0/1, купил ли машину чере змесяц после первого App-start

Если будете использовать не бинарную общую конверсию, а другую - скорее всего могут получиться странноватые выводы 🥶
При этом для пошаговых конверсий, например CR app start - item click конверсию по сессиям использовать вполне ОК

В этом кейсе, при использовании удачных конверсий
- CR app start - item click (по сессиям) вероятно немножко вырастет или не изменится. Потому что юзер может чуть чаще возвращаться в приложение, чтобы сравнить условно новинки со своим избранным
- CR item click - add to cart (0/1) вероятно, вырастет. Пользователь, долго выбирая на сайте, теперь не забывают свои старые выборы, а добавляет их в ”Избранное”

Важный момент: CR item click - add to cart (по сессиям) может упасть. Если число item-click вырастет, а число add to cart - нет (или вырастет меньше)

Call-to-action: Будьте акуратны в выборе конверсий. В случае редких событий лучше считать бинарную конверсию 0/1, а не по сессиям (купил в 3 сессиях из 10)


3. Добавляем фичу “Подписаться на скидки на данный товар”

Вероятнее всего это увеличит трафик (кол-во сессий, app start). И возможно даже и вырастит, но слабее кол-во item click и order
Поэтому на сессиянных конверсиях вы можете увидеть падение всех этапов воронки и даже общей CR app start - order
но тк траффик растет, то кол-во заказов растет!

orders = кол-во App start * CR app start - order

Call-to-action: Думайте, не влияете ли вы экспериментом на траффик
Note: в кейсе со сидками не забудьте и про денежные метрики) О них - в следующих постах о юнит экономике и PnL

Нас уже почти 2к 🚀
Кажется, пора еще раз всем представиться и завести наконец хорошую навигацию по каналу

➡️ Навигация по каналу

На связи Ваня Максимов @Ivan_maksimov - ML team lead в Яндекс.Лавке, 7+ лет в DS

Забустить канал, чтобы я публиковал больше сторис, можно по ссылке 😄

Пишу алгоритмы, чтобы ваш любимый миндальный круассан всегда был в наличии и по хорошей цене 😇
Если чуть серьезнее, то делаю автозаказ товаров и ценообразование в Лавке

А еще увлекаюсь Recsys и А/В. Построил с нуля перс рекомендации и АВ платформу в Delivery Club

На канале пишу о том, как преодолеть путь от ML модели до реального Value для бизнеса. И какие грабли я собрал на этом пути


👍 Самые залайканные / обсуждаемые посты

- Серия про оптимизацию цен на товары
- Что тебя ждет при переходе team lead —> head of ML
- 13 способов ускорить АВ тест или “не CUPED-ом единым”
- Лучше модель с ROC AUC 50% или 85%? Все не так очевидно
- Серия постов о метриках регрессии: от RMSE до WAPE и SMAPE
- Отсортируй товары “по популярности” - делов на 30 минут! Стой, а почему 3 спринта?
- Какая трансформация фичи влияет на перформанс CatBoost? Спойлер: log(x) - влияет!


Популярные хэштеги
#ab, #metrics, #recsys, #timeseries, #pricing


💡Написать мне: @Ivan_maksimov
Например, вы можете обсудить свой DS-кейс, позвать рассказать что-то интересное на конференции или в вашей компании, записаться на консультацию по data science

Топ-5 граблей Юнит Экономики
…и при чем тут воронка конверсий

Юзер за время пользования приложением должен приносить больше денег (LTV - LifeTime Value), чем потратили на его привлечение (CAC - Customer Acquisition Cost)
UE = LTV - CAC > 0

Если так, то мы часть избыточно заработанных денег (UE > 0) тратим на привлечение новых пользователей —> Они тоже приносят UE > 0 —> повторяем этот цикл и получаем стабильный рост компании


Ну а дальше начинаем детализировать нашу формулу
UE = ARPU * LifeTime - CAC

➡️ UE = (ARPPU * Conversion) * Lifetime - CAC

ARPU - Average Revenue Per User за какой-то период. Обычно 1 или 3 мес
ARPPU - Average Revenue Per _Paying_ User за какой-то период. Обычно 1 или 3 мес
Conversion - конверсия из захода в приложение в первую покупку
LifeTime - среднее время жизни пользователя в мес
CAC - Customer Acquisition Cost

Вокруг улучшения этих 4 составляющих крутится вся продуктовая работа и куча мифов. Развеять которые поможет иногда не такая уж простая аналитика (интегралы для кривой ретеншена, ML-модели LTV и оттока и тп)

Ну хоть с первой составляющей, Conversion, уже все понятно по прошлому посту …или нет?🙃

Иконостас и доставка еды

Пару лет назад мы тестили фичу с маленьким виджетом топ-3 популярных фастфудов (он же иконостас). Занимает в ~9 раз меньше длины экрана 😱

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

(!) А ещё она блочила развитие перс рекомендаций, т к юзеры просто не долистывали до них


➡️ UE = ARPPU * Conversion * Lifetime - CAC

Базово хотели не уронить конверсию в покупку (составляющая ARPPU), и освободилось место на главной странице под перс рекомендации

Но в последний момент добавили барьерную метрику: не уронить конверсию новичка (Conversion)


Дизайн сделали, разработали фичу, запустили А/В и..

Конверсия в покупку не меняется, а конверсия новичка драматически падает. Без барьерной метрики на конверсию новичка мы бы выкатили фичу

Оказалось, забыли добавить на иконку ресторана плашку с конкретной скидкой новичку (-20%, бесплатная доставка), которая была в основой ленте 😣

➡️ Не забывайте, что конверсии бывают как минимум 2ух типов:

Посессионная конверсия в заказ (float, часть ARPPU) = кол-во заказов / кол-во сессий

Конверсия новичка (0/1) = был ли заказ в течений N недель после первого App-start пользователя

И меняться они могут в разные стороны

Курсы по АВ

Я думал в этом году перезапустить свой курс по АВ в формате симулятора. Уже даже сделал 1/5 уроков

Но тут обнаружил, что сразу 2 очень мощных ребят запустили свои курсы-симуляторы по А/В

- Симулятор АВ от Karpov.courses. Есть пакет для продуктов (в Google sheet) и аналитиков (python)
- Симулятор АВ от ProductDo, заточенный именно под продактов

Не реклама: за каналами слежу уже давно, некоторые курсы от ребят сам проходил 👍

Кажется, не имеет смысла жестко конкурировать именно в А/В - я подумаю про другие ниши

Кстати, на какую тему вы бы хотели увидеть курс-симулятор от меня? Напишите в комментарии ⬇️

Гуси и цены на такси
Wild goose chase paradox

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

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

Что происходит в дождь? ☔️

Время подачи машины ~ желающие уехать / (кол-во машин * среднее время в пути)

А в дождь просходит настоящая катастрофа

1. Число желающих уехать резко растёт

2. Сильно снижается эффективность 1 машины = время в пути растет

Это происходит из-за пробок и снижения плотности свободных такси на км^2

Иногда это приводит к тому, что время ожидания такси критически растет - люди начинают отменять поездки

И вот таксист долго едет к первому клиенту - заказ отменен. Ему назначают второй далёкий заказ (далёкий, тк он условно единственный свободный таксист на все Химки), он опять долго едет - заказ отменен. И так по кругу

В итоге, таксист ездит к клиентам, но не успевает - заказы отменяются. Это похоже на погоню за "дикими гусями" (wild goose chase). Они улетают до того, как их схватят 🦆

Открыла парадокс компания Uber, почитать подробнее можно тут

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

Ответ про фичи для CatBoost

Опрос про трансформацию фичей для CatBoost собрал максимум комментариев за историю канала (сейчас их 35!)
И еще мне немало накидали на вентилятор в реакциях)) Так что тема выглядит актуальной - разбираемся в ней 💪


(x - mean(x))^2
Влияет на перформанс CatBoost

Был отличный пример в комментариях для x = (-4;4), mean(x) = 0, —> (x - mean(x))^2 = (4; 4)
раньше -4 и 4 можно было разделить CatBoost-ом, а после трансформации - нельзя

Зачем тогда так делать?
- Иногда полезно считать “нестандартность” наблюдения. Например, нам может быть важно, отличается ли условно время в пути от среднего
- Еще это супер фича для эмбеддингов - можно считать, насколько эмбеддинг пользователя отличается от среднего эмбеддинга (почти как cos-инусная близость)


round(x, some step)
Влияет на перформанс CatBoost

При округлении вы снижаете число возможных разбиений датасета деревом
- Очень полезная история для робастности прогноза на высоко-дисперсных фичах (средний чек, кол-во кликов и тп)
- Для борьбы с переобучением на выбросах
- Для экономии памяти и ускорения вычислений. Вообще бывает полезно округлять float64 фичи до int8 / int16. С помощью этого и еще пары трюков (я как-нибудь напишу об этом пост) я умдрялся переводить расчеты со Spark на python с ускорением в 10 раз 🚀
Кек, но правда - вам не всегда нужен spark:)


log(x)
Вообще-то говоря, может влиять!

На собеседовании от вас скорее всего ждут ответа “Нет, не влияет. Дерево перебирает все возможные пороги разбиения. И нет разницы, выбрать порог x > A или log(x) > log(A)”

Но в реальности может влиять из-за 2ух факторов:
1/ Дерево перебирает не все пороги разбиения 🙃
За кол-во порогов отвечает параметр max_bin, который по дефолту в катбусте на CPU = 254. И кстати, он прилично аффектит на скорость обучения вашей модели

2/ Пороги разбиения (квантизация фичей) выбираются по дефолту не по квантилям распределения (робастно к монотонным трансформациям вроде логарифма), а иначе. В catboost по дефолту - GreedyLogSum. Поэтому логарифмирование Х при некоторых способах разбиения может влиять на выбор порогов —> влияет на перформанс

Серый АВ - что делать дальше?

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

1. Проверьте ваш MDE и процедуру тестирования
Убедитесь, что нет багов, и вы можете детектить достаточно маленькие эффекты (MDE - minimum detectable effect). Часто разумный эффект на крупной метрике задетектить статистически невозможно - переходите к прокси. Например, от общей конверсии к конверсии определенного шага воронки

2. Около 70% АВ тестов серые, и это нормально
В тестах мы проверяем гипотезы. И какими бы гениальными вы ни были, 2 из 3 ваших невероятных идей ничего не принесут в бизнес-метриках - это неприятно, но факт. Поэтому лучше учиться быстро проверять много гипотез, а не делать ставку на одну крупную

3. Серый АВ дает знание о том, чего делать дальше НЕ нужно
Знать, что точно не работает - прекрасно. Поэтому обычно из пула гипотез (про персональные рекомендации, способы оплаты и тп) тестируют самую сильную. И если она не работает - возможно, вам нужно копать в другую сторону

4. А что еще хорошего приносит ваша фича?
Может быть, технической стабильности - теперь не нужно дежурить по ночам? Или лучше RPS? Или прозрачность для бизнеса? В денежных метриках это не измерить, но такие вещи тоже очень важны


В общем, если ваш АВ вдруг стал серым, вспомните про эти 4 пункта,
выдохните, и продолжайте тестировать новые гипотезы 😉

Bias-variance tradeoff: Спрашивают на каждом собесе, применяют в реальности единицы

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

Ошибка = Bias^2 + Variance + sigma^2

Bias - как точно мы попадаем в среднем в истину

Variance - Как сильно колеблется наша предсказания функция относительно истинной

Sigma^2 - Неснижаемая дисперсия данных

И мы можем за счёт регуляризации снижать Variance за счёт роста Bias, и наоборот. Прекрасная теоретическая выкладка, но что с этим в реальности-то делать? 🤔

Давайте сначала посмотрим на простом примере, какая тут ситуация с Bias и Variance


UPD: Ценителям очень точных определений лучше посмотреть на них по ссылке в посте:) Текстом я писал определения с некоторыми допущениями для более широкой аудитории

Я недавно стрелял из лука, поэтому вопрос (а после будут выводы) по этой мишени

Bias-variance tradeoff p.2

Bias, по моему опыту, важен в двух кейсах: Causal inference и Предсказание условного мат ожидания конкретного распределения

Часто мы предсказываем, например, кол-во продаж. В теории, оно имеет распределение Пуассона. И имея несмещенное предсказание среднего (Bias ~ 0), можно легко получать все квантили распределения по формуле

В простейшем случае Causal inference через линейную регрессию важно иметь Bias ~ 0, чтобы были несмещенные коэффициенты. Кстати, поэтому в случае causal inference не стоит использовать регуляризацию в линейной регрессии (она смещает коэффициенты к 0)