Привет! Это Илья Петряшин, старший дата-сайентист в команде горизонтальных ML-технологий в Авито, и Артём Трофименко, старший аналитик по коммуникациям в Авито.
Мы вместе создали главную продуктовую метрику Авито: единую для всех вертикалей, понятную бизнесу, аналитикам, дата-сайентистам и точно отражающую ценность сервиса для пользователей.
В статье расскажем, зачем нам понадобилась такая метрика, с какими трудностями столкнулись и как прошли путь от формализации понятия «договорённость» до обучения модели и внедрения метрики в аналитику и цели компании.
Содержание
Немного контекста: как устроен путь пользователя на Авито
Авито — это не один продукт, а целая экосистема, внутри которой сосуществует шесть вертикалей, где пользователи совершают сделки друг с другом: Товары, Недвижимость, Авто, Услуги, Работа, Путешествия.
Каждая из вертикалей работает по двум моделям: классифайдной и транзакционной.
Классифайдная модель — схема, когда продавец и покупатель знакомятся через Авито, но сделка происходит за пределами платформы: списались в чате, созвонились, встретились и договорились. Например, так происходят сделки с автомобилями.
Транзакционная модель — схема, когда вся сделка проходит внутри Авито: доставка товаров, запись на услуги, краткосрочные бронирования.
Завершённое соглашение и есть главная ценность Авито.
Рассмотрим путь пользователя в сервисе. С точки зрения аналитики, мы наблюдаем классическую воронку:
покупатель заходит на Авито →
видит объявление о продаже наушников →
пишет продавцу →
они договариваются и назначают встречу →
сделка завершается →
ценность создана.
Кажется, чтобы оценить ценность, достаточно подсчитать все завершённые сделки, но на практике так не выходит: многие из них остаются за пределами системы и их сложно отследить. Поэтому нужны другие подходы.
Мы решили шагнуть выше по воронке и вместо завершённых сделок считать контакты продавца и покупателя. Но тут тоже обнаружились ограничения.
Например, если мы хотим купить телефон и пишем сразу десяти продавцам ради скорости ответа или скидки, то фиксируем десять контактов. Хотя максимум один из этих контрактов может принести реальную ценность и привести к сделке.
Почему формализовать договорённость — сложно
Проанализировав воронку, мы обнаружили, что между контактом и завершением сделки проходит достаточно много времени и что между этими этапами есть ещё один важный шаг — договорённость.
Без неё покупатель не приедет осматривать авто, а клиент не запишется на маникюр, если предварительно не узнает у мастера, что он точно делает желаемую процедуру. Это и есть ключевой этап взаимодействия двух пользователей, который ближе к фактической сделке и лучше всего отражает ценность Авито.
Формализовать и вообще определять договорённость — непростая задача, и поразмыслив об этом, мы решили обучить ML-модель, которая сама будет определять договорённости и считать их. Но столкнулись с проблемами:
«Договорённость» — это нечто абстрактное, и у нас нет хорошо работающего инструментария, который бы помог конкретизировать это понятие.
Каждая команда по-своему трактует понятие «договорённость»:
для дата-сайентистов важно, чтобы её можно было легко отделить от недоговорённости;
бизнес считает каждую ситуацию уникальной и требует тонко детализировать;
аналитикам нужно, чтобы договорённости одинаково считались во всех вертикалях.
Договорённость не всегда можно формализовать. В части сделок формулировки более явные, например: «встретимся в такое-то время». В части — размытые, вроде: «давай созвонимся позже», «подумаю», «может быть, приеду».
В одном чате люди могут несколько раз договариваться о сделке и в итоге передумывать.
Договорённости бывают разные. У нас есть много вариантов, каким образом люди договариваются, поэтому для формализации понятия кажется логичным присваивать чату конкретный тег. Но в какой-то момент таких тегов может стать слишком много, часть из них будут похожи по смыслу, из-за чего асессоры и продуктовая команда не могут выстроить единую логику. Отсюда риск получить плохую разметку и слабую модель.
Несмотря на эти проблемы, мы не остановились и продолжили искать решение задачи.
Ищем решения: 5 главных шагов
Мы решили пойти от обратного.
Шаг 1. Упрощаем постановку задачи. Давайте посмотрим на ещё один сгенерированный чат и зададим себе вопрос — «Это договорённость или нет?».
На этот вопрос есть всего 2 ответа: либо да, либо нет, и чат выше явно является договорённостью. Таким образом, мы приходим к тому, чтобы делить вообще все чаты на:
договорённости;
недоговорённости.
Таким образом, наша задача сводится к бинарной классификации чатов, где классы противоположны по смыслу. Процесс разметки становится простым, потому что размечать противоположные по смыслу сущности достаточно легко.
Делать это смогут как асессоры, которые готовят данные для обучения моделей, так и продуктовая команда, которая формализует понятие договорённости. В итоге на выходе мы получим качественно размеченные данные с хорошей формализацией договорённости.
Шаг 2. Разрабатываем единую инструкцию. Мы собрали представителей бизнеса, аналитиков и дата-сайентистов и начали работу с ответа на вопрос: «Что такое хорошая инструкция?». Договорились, что хорошая инструкция должна:
соответствовать бизнес-пониманию от вертикали;
быть консистентна логике определения договорённостей в целом;
легко и понятно восприниматься.
Но у каждой из команд оставались свои замечания:
Чтобы откалибровать видение между всеми командами, мы взяли реальные данные и приступили к созданию первой версии инструкции.
В процессе столкнулись со множеством случаев, когда мы даём разные ответы на одни и те же данные. Это связано с наличием серых зон в инструкции, из-за которых появляется неоднозначность в разметке.
Чтобы устранить их, мы итеративно выявляли систематические ошибки разметки, отдельно прорабатывали каждую из них и уточняли инструкцию. Как раз чтобы избежать таких ошибок в будущем. После каждой итерации инструкция становилась всё более точной и понятной для всех участников.
В результате многократных обсуждений и корректировок мы пришли к согласованной версии инструкции, которая учитывает мнение всех заинтересованных сторон, легко воспринимается сторонним человеком, непротиворечиво диктует, что есть договорённость, а что — нет, и имеет примеры для большинства корнер-кейсов.
Инструкцию утвердили и стали думать: «Можем ли мы улучшить что-то ещё?».
Шаг 3. Начинаем работать с разметкой. Процесс выглядел так:
Разметили рабочей группой немного данных.
Обучили на них асессоров.
Сформировали и разметили асессорами боевой пул.
Провалидировали часть разметки — смотрели на расхождения валидаторов и асессоров и отслеживали кейсы, где асессоры систематически ошибались — чаще всего это происходило в сложных кейсах. Потом отправляли им фидбэк для дообучения.
Шаг 4. Прорабатываем редкие кейсы в процессе разметки. На этапе калибровки проработали все часто встречающиеся кейсы из серых зон, чтобы максимально точно разграничить их.
Тем не менее некоторые редкие кейсы всё же не попали к нам в поле зрения, так как мы не могли охватить все данные. О таких кейсах мы узнавали исходя из расхождения асессоров с валидаторами, и благодаря этому выявляли более мелкие систематические ошибки. Кроме того, асессоры в процессе разметки сами могут выявлять спорные кейсы, поскольку размечают гораздо больше данных.
Исходя из этих кейсов мы точечно доустраняем оставшиеся участки серых зон уже в процессе разметки, чтобы сделать бизнес-понимание договорённости чётче.
Шаг 5. Проверям, как работает обученная модель. Поскольку наша цель — научить модель предсказывать договорённости покупателей и продавцов, мы использовали реальные данные о сделках для валидации получившейся модели.
Вот как мы убеждались, что предсказания модели соответствуют реальным договорённостям:
при снятии объявления пользователь отметил в опросе: «продано на Авито»;
пользователь оставил отзыв после получения услуги;
продавец или покупатель подтвердил сделку в опросе от Авито внутри чата.
После того как модель устроила и команду, и бизнес на её основе мы сделали главную метрику Авито.
Резюмируем: как мы учились измерять ценность сделок на Авито
По результатам работы мы смогли сделать сложное простым и оцифровали ценность Авито для пользователя понятным бизнесу способом.
Вот ключевые этапы, которые мы прошли:
Искали инсайты на разных этапах воронки. Мы не можем быть уверены, что сделка произошла во всех случаях, из-за особенностей классифайдной модели. Поэтому мы пошли искать другие показатели на разных этапах воронки и обнаружили, что наибольшая ценность сделки проявляется на этапе договорённости между продавцом и покупателем.
Корректировали подход и учили модель формализовать договорённости. Пришли к бинарной постановке задачи определения договорённости, которая оказалась проще и понятнее для всех участников процесса. С помощью чёткой инструкции решили трудности с трактовкой и формализацией понятия, и эта же инструкция стала основой для разметки данных и обучения модели.
Двигались итеративно. Улучшали инструкцию и дообучали асессоров в процессе, чтобы получить качественную разметку и минимизировать систематические ошибки.
Обучали модель на реальных данных. Использовали данные о реальных сделках и проверяли модель на точность предсказаний.
В результате получили метрику, которая понятна бизнесу, используется в аналитике, помогает замерять эффективность продукта во всех вертикалях Авито, участвует в целеполагании компании, топ-менеджмента и применяется в A/B-тестах.
Больше интересных подробностей от DS-инженеров Авито есть в телеграм-канале «Доска AI-объявлений». Заглядывайте читать посты и общаться в комментариях.
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.
cosmichorror
Выключите вы там в Авито своего любопытного бота уже.. Вы договорились? Как прошла сделка? Достал!!