Всем привет! Меня зовут Алина Бабенко, я acting DS-менеджер в Авито. Наша команда занимается моделями монетизации в поиске и рекомендациях: мы оцениваем ожидаемую выручку от действий пользователей и используем её в ранжировании. В этой статье я расскажу, какие модели используем для расчёта ожидаемой выручки, как оцениваем их качество, а также зачем корректируем ставки.
Материал будет полезен дата-сайентистам и тимлидам, которые работают с монетизацией на маркетплейсах и в сервисах для объявлений.
В этой статье
Какие продукты взяли в основу монетизации
Продавцы на Авито могут платить за разные действия пользователей: клики, контакты в чате, бронирования, сделки и другие целевые события. Есть отдельные категории клиентов, которые предпочитают оплачивать звонки, это, например, крупные дилеры или застройщики. От того, какое действие считается целевым, зависит и расчёт ожидаемой выручки.
Монетизация встречается во всех направлениях Авито, например, в товарах, вакансиях, недвижимости. Каждое из направлений имеет свои особенности, которые мы учитываем при обучении моделей.
Тем не менее во всех случаях задача всегда одинаковая: оценить ожидаемую выручку от взаимодействия пользователя с объявлением.
Наша основная метрика — рост выручки за счёт улучшения модели.
Важное уточнение
В конечном счёте Авито работает для людей — покупателей и продавцов. Одни должны продавать свои товары и оказывать услуги, а другие — получать качественную выдачу, поэтому модели не должны ухудшать поиск ради роста выручки.
Какие модели используем в ранжировании
В поиске и в рекомендациях модели работают по-разному:
— В поиске мы считаем несколько различных факторов для объявления. Это могут быть ожидаемая выручка, конверсия, определённое качество объявлений. Все признаки взвешиваем и ранжируем по итоговому скору.
— В рекомендациях фиксируем определённые места, в которых ранжирование происходит по ожидаемой выручке, а всё, что происходит в других сегментах, эту выручку не учитывает.
Эти нюансы мы и используем для развития наших моделей.
Классическая пользовательская воронка для сервиса с объявлениями выглядит так: показ → клик → контакт → сделка. Под каждую часть воронки можно обучать отдельную модель. У нас работают три типа моделей.
1️⃣ CTR-модель считает вероятность клика по объявлению после того, как пользователь его увидел. Эта модель особенно важна для продавцов, которые платят за клик. Она обучается на истории показов и кликов, а затем оценивает, насколько конкретное объявление заинтересует пользователя.
2️⃣ CVR-модель оценивает вероятность, что после клика пользователь совершит целевое действие. Например, напишет продавцу в чат, позвонит или оформит бронирование. В отличие от CTR-модели, которая работает на уровне показов, CVR обучается уже на данных о кликах и помогает оценить качество привлечённого трафика.
3️⃣ Модель корректировки предсказывает вероятность клика и использует её для уточнения ставки. Дальше расскажу о ней подробнее.
Как корректируем ставки на клик под качество трафика
Продавцы не хотят, чтобы им поднимали цены за клик, а мы не желаем создавать для них избыточную финансовую нагрузку. Это значит, что нам надо не поднимать стоимость клика, а приводить к продавцам максимально релевантных покупателей. Другими словами, монетизация должна работать как можно более эффективно для продавца.
Идея в том, чтобы адаптировать ставку под вероятность целевого действия. То есть повышаем ставку, если пользователь, скорее всего, совершит ожидаемое действие для объявления и понижаем, если эта вероятность низкая. В результате более ценный трафик получает больший вес в аукционе, но средняя стоимость для продавца остаётся прежней.
Обычно для обучения подобных моделей мы используем функцию log loss, но в этот раз так не получится, потому что она не учитывает ограничение — нам надо держать среднюю ставку за клик. Чтобы решить эту задачу, мы используем query cross-entropy loss. Он состоит из двух компонентов: классического log loss и log loss для группы, где группа — это клики по одному объявлению.
Благодаря этому модель учится сохранять среднее значение скоринга около единицы и одновременно корректировать ставку для более или менее конверсионного трафика. Такой подход не повышает средние расходы продавца и улучшает эффективность аукциона.
По сути, модель перераспределяет бюджет между разными типами пользователей, сохраняя среднюю стоимость клика на прежнем уровне.
Как оцениваем качество моделей в поиске
Для оценки CTR-моделей классический ROC-AUC подходит не всегда. Проблема связана со спецификой поисковой выдачи: пользователь обычно сравнивает объявления внутри одного запроса, а не между всеми объектами платформы.
Например, в выдаче по запросу «кресло» вряд ли окажутся ноутбуки или ботинки. Если считать ROC-AUC глобально по всем объектам, метрика начинает учитывать множество заведомо простых сравнений между объявлениями, которые никогда не будут сравниваться между собой. В итоге может показывать хороший результат даже тогда, когда качество ранжирования внутри конкретного запроса почти не меняется.
Поэтому мы используем stratified ROC-AUC. Эта метрика считается отдельно для каждого поискового запроса, а затем результаты агрегируются с весом, равным числу кликов. Такой подход позволяет оценивать именно качество ранжирования внутри выдачи, где пользователь принимает решение, и делает метрику более чувствительной к изменениям, которые действительно влияют на поисковый опыт.
Важность калибровки
Для ранжирования по ожидаемой выручке важен не только порядок объектов в выдаче, но и абсолютные значения вероятностей. Дело в том, что именно эти вероятности участвуют в расчёте ожидаемой выручки и умножаются на ставки. Если модель плохо откалибрована, её скор перестаёт отражать реальную вероятность события, а ожидаемая выручка превращается из денежной оценки в относительную метрику, которую уже нельзя напрямую использовать в расчётах.
Для оценки калибровки мы используем метрику RIG: RIG = 1 − log loss / entropy
Что делаем с проблемой атрибуции
Теперь перейдём к задачам, которые возникают при обучении таких моделей. Одна из самых сложных — атрибуция.
Представим пользователя, который проходит стандартный путь поиска нужного товара на Авито. Допустим, он ищет велосипед:
1. Вводит первый запрос «велосипед»;
2. Кликает по объявлению;
3. Уточняет запрос до «горного велосипеда»;
4. Снова кликает;
5. Ещё сильнее уточняет запрос;
6. Наконец, пишет продавцу.
Возникает вопрос: какому клику приписывать контакт?
Мы можем использовать разные подходы, чтобы на него ответить:
Last-click attribution. Контакт относится к последнему клику перед действием. Плюс подхода — простота. Минус — игнорируется вклад предыдущих взаимодействий.
First-click attribution. Контакт относится к первому клику. Логика здесь такая: пользователь заметил объявление именно тогда. Но такой подход тоже может искажать данные.
Multi-touch attribution. Контакт распределяется между несколькими кликами с разными весами. Сейчас мы исследуем именно такой подход. Потому что ранние запросы пользователя часто бывают шумными:
— человек ещё не понимает, что именно ищет;
— клики могут быть случайными;
Можно посмотреть на проблему под другим углом: возможно, нужно думать не над тем, куда атрибуцировать контакты, а наоборот, исключать из анализа более ранние клики, так как по мере уточнения запроса они становятся более целевыми. Отсюда возникает концепция транзитных выдач:
— ранним кликам даём меньший вес;
— поздним — больший;
Таким образом снижаем уровень шума в данных.
Как боремся с position bias в оценке кликов
Пользователи просматривают выдачу сверху вниз. Из-за этого верхние позиции в среднем приносят больше кликов и чаще попадают в наши данные. При этом наша задача сделать так, чтобы CTR-модель, которая предсказывала клик, не зависела от позиции.
Если обучать CTR-модель напрямую на таких данных, модель начинает путать реальную привлекательность объявления с эффектом от позиции. В итоге она учится воспроизводить текущее ранжирование.
Мы знаем два способа борьбы с position bias — с помощью трёх CatBoost-ов и inverse propensity weighting. Кратко рассмотрим оба.
Метод с тремя CatBoost решает проблему позиционирования в четыре шага:
1️⃣ Обучаем первый CatBoost на всех фичах и дополнительно на фиче позиции.
2️⃣ Обучаем второй CatBoost также на всех фичах, кроме позиции.
3️⃣ Берём разницу скорингов двух моделей и предполагаем, что она отражает вклад позиции.
4️⃣ Передаём эту разницу как стартовые значения в третий CatBoost.
Рассчитываем, что третий CatBoost обучит тот самый чистый CTR без позиционной поправки. Его мы и будем использовать в нашей ожидаемой выручке.
Метод inverse propensity weighting. Этот подход описан в работах по unbiased learning to rank. Мы оцениваем вероятность клика для каждой позиции, затем взвешиваем все объекты обратно пропорционально этой вероятности.
Если позиция получает слишком много кликов из-за расположения, её вклад уменьшается. В результате log loss становится несмещённым, а модель учится на более честных данных.
Как переходим от CatBoost к deep learning
Одно из направлений развития наших моделей — переход от бустингов к deep learning. На задачах предсказания CTR этот переход уже показывает хорошие результаты. Для обучения таких моделей у нас есть огромный объём данных о показах, кликах и других пользовательских взаимодействиях, поэтому модели могут находить закономерности, которые сложно извлечь с помощью классических бустингов. В результате качество CTR-моделей на deep learning уже превосходит CatBoost.
Однако этот успех не означает, что тот же подход можно без изменений перенести на другие задачи монетизации. Если клик обычно происходит сразу после показа объявления, то путь до сделки может растягиваться на дни или даже недели.
Особенно заметно это в вертикалях вроде недвижимости и путешествий, где пользователь долго изучает предложения, меняет запросы, сравнивает варианты, возвращается к просмотру и может отменить бронирование уже после совершения целевого действия.
По сути, вместо одного события мы пытаемся моделировать длинную последовательность пользовательских решений. Именно поэтому предсказание сделок остаётся более сложной задачей, чем предсказание кликов.
В индустрии уже появляются подходы, которые пытаются учитывать такие длинные пользовательские сценарии. Например, похожие архитектуры описывали в Airbnb.
Вся статья кратко
? Продавцы платят за целевые действия, например, клики, звонки, чаты, бронирования и сделки. Это основа монетизации Авито. В поиске выручка учитывается вместе с другими факторами, в рекомендациях — только на выделенных позициях.
? Планируем протестировать корректировки ставок под вероятность целевого действия так, чтобы средняя цена клика для продавца оставалась неизменной.
? Качество ранжирования оцениваем внутри каждого запроса с помощью ROC-AUC.
? В атрибуции распределяем вес между кликами, чтобы снизить шум ранних запросов.
? Влияние позиции убираем через три CatBoost-модели или взвешивание по вероятности клика.
? Планируем развивать наши модели в сторону DL, поскольку это может резко повысить качество их работы.
В любом случае модели монетизации — это постоянный поиск ответов на вызовы. Во многих задачах пока нет единственно правильного ответа. Поэтому мы постоянно проверяем новые гипотезы и готовы пересматривать даже те решения, которые уже показывают хороший результат.
Значительная часть нашей работы — это исследование гипотез, эксперименты и поиск компромиссов между качеством поиска, выручкой и удобством для продавцов.
Мы пишем про DS не только на Харбе, но и в телеграме: DS-инженер, например, рассказывал, в каких задачах применяет AI-инструменты. А ещё обсуждали неудавшийся релиз Mythos — Fable 5 и комичные детели вокруг этой новости.
Ну в общем, чего мы вам тут рассказываем. Сами переходите в канал «Доска AI-объявлений» и читайте посты.
Кстати, если вам интересна работа в бигтехе — Хабр совместно с ЭКОПСИ проводит большое исследование IT-брендов работодателей. В прошлом году в нём поучаствовали 34 000 специалистов. Если у вас есть опыт — он точно будет учтён