Привет! Меня зовут Яша Финкельберг, я senior аналитик в Авито. Одна из базовых ценностей Авито, прописанная в нашем манифесте, — «Всё начинается с потребностей пользователя». Мы постоянно следим за удовлетворённостью продавцов и покупателей площадки и ищем способы улучшать их взаимодействие с Авито.
Уровень удовлетворённости отслеживаем разными способами, например, проводим опросы, замеряем метрики CES и CSAT. Чтобы находить более детальные драйверы, сегментировать запросы и ставить предсказуемые цели в работе с обращениями, мы решили разработать собственную метрику для работы с опытом пользователей — weighted contact rate (wCR).
В статье я расскажу, почему мы решили дополнить существующие метрики нашей, и дам пайплайн разработки, по которому уже вы сможете внедрить что-то подобное у себя в компании. Текст будет полезен аналитикам крупных компаний.
Содержание:
Доказали связь обращений в поддержку с поведением пользователей
Шаг 2: модификация и расчёт минимально детектируемого эффекта
Контекст: почему решили разработать новую метрику
Авито — платформа, на которой торгуют частные лица и компании, что создаёт разброс в потребностях для каждой группы. Трудности у них тоже отличаются: то, что мешает маленькому частнику, не интересует крупного продавца и наоборот. Из-за этого сложно найти проблемы, характерные для конкретного сегмента. Чтобы решить эту задачу, мы разработали новую метрику и сделали это на примере крупных профессиональных продавцов.
Один из основных методов, который мы используем, для измерения удовлетворённости профессиональных пользователей — опросная метрика Customer Effort Score (CES).
Это отличный измеритель, но, как и у любого инструмента, у него есть ряд особенностей.
Есть плюсы:
позволяет понять влияние инициатив на уровне конкретных изменений в A/B-тестах;
показывает полный спектр того, что волнует пользователей.
помогает услышать не только проблемы, но и пожелания по улучшениям, идеи и новые потребности;
позволяет сравнивать нас с конкурентами.
И минусы:
сложно понять, что именно повлияло на метрику: изменение в продукте, ценовая политика, внешние факторы или что-то ещё;
данные сложно декомпозировать;
опасно ставить цели, поскольку метрики могут сильно меняться из-за внешних обстоятельств.
Минусы мешают использовать CES для поиска проблем конкретной группы продавцов, поэтому пришла идея считать метрику с учётом особенностей сегмента. Мы выбрали метрику Contact rate (CR).
CR — это отношение количества обращений в поддержку к бизнес-метрике, которая учитывает особенности вертикали или категории.
Планировали, что наша новая метрика будет подсвечивать текущие проблемы пользователей на основе данных из службы поддержки с поправкой на вес продавца в выручке Авито.
Обращения отображают текущие проблемы клиентов — если люди пишут нам, значит, их что-то волнует прямо сейчас и, скорее всего, они будут готовы предоставить подробные данные о своей проблеме. Таким образом, данные из поддержки будут закрывать нашу главную потребность, которую не закрывала CES: мы сможем ставить управляемые цели для сегментов, основываясь на конкретных данных здесь и сейчас.
Доказали связь обращений в поддержку с поведением пользователей
Важно было не просто придумать метрику, а ещё понимать, как она связана с поведением пользователя на площадке — могло ли быть так, что продавец пишет обращение, но при этом проблема не влияет на его работу с Авито. Поэтому на первом этапе мы решили выяснить, есть ли корреляция между оттоком пользователей и их обращениями в поддержку.
Сначала сравнили два сегмента продавцов: тех, кто обращался в поддержку, и тех, кто не обращался, но получили неверные выводы. Оказалось, что продавцы, которые писали в поддержку, были активнее и чаще пользовались платными услугами продвижения. На первый взгляд может показаться, что обращения в поддержку — признак активности и успешности продавца, но это не так: сам факт обращения может означать только нейтральный либо негативный опыт.
Здесь мы столкнулись с ложной корреляцией (spurious correlation) из-за смешивающего фактора (confounding variable). В данном случае смешивающий фактор — общая активность продавца. Чем чаще человек использует Авито, тем больше у него поводов обратиться в поддержку. Если убрать влияние активности, то обращения в поддержку, наоборот, должны указывать на проблемы, поэтому напрямую сравнивать эти два сегмента нельзя — выводы будут неверными.
A/B-тесты провести тоже не получилось, поскольку нельзя сказать продавцам: «Вы пишите в поддержку, а вы — нет».
В итоге пришли к методу мэтчинга. Решили сравнить группы и выяснить — влияют ли обращения пользователей в поддержку на их отток в последующем. Вот как это было:
Сперва исследовали ключевые параметры. Для каждого направления бизнеса и целевой метрики мы подбирали факторы, которые лучше всего предсказывают эти показатели в будущем. Такой отступ в будущее помогает выявить причинно-следственную связь, а не просто найти корреляцию.
Затем мы искали «пользователей-близнецов». Подбирали пары максимально похожих продавцов — тех, кто обращался в поддержку, и тех, кто не обращался. Учитывали все ключевые параметры, которые нашли раньше: активность, историю покупок, количество обращений в поддержку.
Потом сравнили «выровненные» группы. После мэтчинга разница между группами должна была зависеть только от фактора обращения в поддержку. Так, например, мы выяснили, что клиенты, которые обращались за помощью, в среднем чаще уходили с платформы и тратили меньше бюджета на услуги продвижения.
Повысили точность разметки данных
Запросы пользователей нужно было категоризировать, чтобы понимать — на что стоит обратить внимание сейчас, а что можно положить в бэклог и вернуться позже. Все пользовательские обращения по умолчанию размечали боты, сами продавцы или сотрудники службы поддержки. Это снижало точность метрики, поскольку в сценарии всегда действовал человеческий фактор и одинаковые проблемы падали в разные категории.
Так как наша метрика не событийная и мы не можем просто посчитать конкретные клики пользователя, нужно было разобраться, как оценить точность в разметке и исправить ошибки.
Для этого начали создавать собственную модель классификации обращений, но быстро поняли, что дальнейшая разработка — долго, трудно и дорого. Поэтому взяли внутреннюю LLM-модель и стали проверять корректность разметки в ней, используя техническую документацию службы поддержки.
Так мы научились быстро и дёшево проверять, правильно ли подобраны категории для запросов, и получать более корректные показатели нашей метрики.
А теперь пайплайн.
Шаг 1: сегментация запросов в поддержку
Мы искали способ отделить обращения крупных продавцов от общей массы запросов в поддержку. Так как мы знали, что эти пользователи активно продвигают свои объявления, то решили взвешивать данные на траты за продвижение. Исследовали два варианта решения задачи: взвешивать на деньги каждое обращение или попытаться кластеризовать пользователей, например, провести сегментацию на небольших, средних и крупных продавцов.
Метод сегментации подошёл нам больше, так как чувствительность у него выше. Получился такой алгоритм: берём запросы в поддержку по сегментам, считаем для них contact rate, взвешиваем на деньги сегментов и изучаем те, что подходят для исследования.
Например, таким способом нам удалось вычленить проблемы у продавцов с автозагрузкой и оспариванием звонков. Автозагрузка — инструмент, который позволяет управлять большим количеством объявлений в автоматизированном режиме. А оспаривание звонков — процесс, когда продавцы хотят избежать снятия средств за звонок, если он был нецелевым.
Обычно contact rate по этим вопросам не входит в топ-50, так как опции используют только крупные продавцы. Но при взвесе на сегменты проблемы вошли в топ-10 и попали в фокус внимания.
С доставкой произошла обратная ситуация. Проблема часто встречается в запросах частных продавцов, поскольку они активно пользуются услугой. А для крупных пользователей доставка не в приоритете, поэтому бо́льшая часть проблем не входит в топ-50.
Шаг 2: модификация и расчёт минимально детектируемого эффекта
Обычно в тестах каждый пользователь считается независимым наблюдением, но наша метрика многосоставная, поэтому стандартный расчёт минимально детектируемого эффекта (MDE) не подходил.
Мы попробовали сделать следующее: сначала рассчитывали MDE для отдельных сегментов, а затем агрегировали результаты по ним. С таким подходом приходилось опираться на два допущения: значения для различных сегментов независимы между собой; коэффициент взвеса можно считать константой.
Этот подход не сработал, так как оба допущения были ложными — и значения для сегментов и коэффициенты связаны между собой и не являются на самом деле независимыми.
Тогда мы решили использовать полное бакетирование. A/A-тест показал нормальное распределение ошибки, что подтвердило работоспособность метода. Подробнее о том, когда надо рассчитывать метрику для каждого бакета с нуля, есть в моей документации на GitHub.
Если бы метрика была Ratio, можно было бы посчитать вариабельность знаменателя и числителя отдельно, а потом, используя дельта-метод, рассчитать дисперсию дроби. Но в нашем случае метрика слишком сложная.
Дальше мы решили оптимизировать MDE. Объединение двух сегментов с самым крупными продавцами нам не подошло — из-за малого количества пользователей дисперсия возросла. Поэтому применили метод CUPED (Controlled-experiment Using Pre-Experiment Data). Эта техника использует предэкспериментальные данные для повышения чувствительности тестов.
В результате мы смогли успешно провалидировать метод для бакетированных данных, получили достоверные и реалистичные результаты тестирования.
Финальная формула расчёта wCR выглядит так:
Подробнее про бакетирование в A/B-тестах мы писали отдельную статью: «Как устроено A/B-тестирование в Авито».
Шаг 3: разработка методов интерпретации метрики
Метрика weighted contact rate (wCR) готова, но возник вопрос — как интерпретировать её в моменте, чтобы сразу предпринимать какие-то действия и улучшать пользовательский опыт. Мы стали создавать удобный инструмент, который будет сразу показывать значимые результаты, а не шум. У нас было две задачи: сравнивать показатели между периодами и выявлять основные причины обращений.
Сравниваем периоды. Чтобы анализировать динамику изменений, мы использовали подход, похожий на A/B-тестирование. Брали данные за два месяца, применяли уже проверенное бакетирование, такое же, как при расчёте минимально детектируемого эффекта, и сравнивали показатели с помощью t-теста.
Этот метод позволил нам использовать единый критерий, чтобы отделять случайные колебания метрики от действительно значимых изменений.
Искали драйверы для обращений. Для этого мы применили подход из факторного анализа — метод каменистой осыпи. Сначала ранжировали все типы обращений по частоте, затем находили на графике точку, где массовые проблемы переходят в редкие случаи. Всё, что было до этой точки, мы считали значимыми драйверами и фокусировались именно на них. Остальные единичные проблемы отправляли в бэклог для дальнейшего изучения.
Такой подход помог быстро выявлять действительно важные для пользователей запросы и отсекать единичные обращения.
Разработали методы прогноза. Поскольку метрика wCR хорошо декомпозируется, мы смогли создать модель для её прогнозирования. Основная формула выглядит как отношение количества обращений в поддержку к числу крупных продавцов на платформе. Числитель мы прогнозируем, учитывая сезонность и запланированные изменения в сервисе, а знаменатель — это известное количество активных продавцов.
Для автоматизации расчётов мы перешли от стандартной метрики CR (Contact Rate) к взвешенной wCR с помощью линейной модели. В этом нам помог коэффициент перехода Coeff wCR to CR. Сама модель учитывает множество факторов, что делает прогнозы более точными. Ключевыми показателями здесь выступают N Листеров — количество платящих продавцов с активными объявлениями и, собственно, CR — невзвешенная метрика обращений.
Что в итоге. Наша метрика уже начала работать: например, благодаря wCR мы подсветили и решили часть проблем крупных продавцов с Автозагрузкой объявлений. Провели эксперимент, в котором показывали крупным продавцам способ, как подключить этот инструмент для работы на Авито.
В результате количество обращений с вопросом: «Как подключить?» уменьшилось в 2 раза на одного продавца. Это соответствует ≈ 2% всего wCR Автозагрузки, при оценке через прокси. Сейчас знакомство пользователей профессионального кабинета с Автозагрузкой работает полноценно.
Кратко: как мы разрабатывали новую метрику
Создали новую метрику для оценки пользовательского опыта крупных продавцов, дополняющую классические CR, CES и CSAT. Теперь можем учитывать обращения в поддержку, взвешенные по активности и тратам пользователей, и получать более управляемые и декомпозируемые результаты, что далее используется для постановки целей.
Вот из каких этапов состоял процесс разработки:
Сравнили «пользователей-близнецов» — тех, кто обращался в поддержку, и таких же не обращавшихся. Это помогло понять, как проблемы на площадке влияют на поведение пользователей.
Нашли, откуда будем брать данные для расчёта показателей, и улучшили разметку обращений с помощью внутренней LLM Авито.
Применили методы бакетирования и CUPED, чтобы снизить шум и повысить точности в A/B-тестах.
Интерпретировали wCR — проанализировали динамику с помощью псевдо A/B и нашли основные драйверы обращений с помощью методики каменистой осыпи.
wCR новая метрика работает — помогает нам выявлять и решать проблемы пользователей в более сжатые сроки, прогнозировать количество обращений в поддержку, а также приоритизировать задачи.
Подписывайтесь на «Коммуналку аналитиков» в Телеграме. Там аналитики Авито рассказывают, как выглядит работа в Авито изнутри: делятся мыслями, успехами и фейлами, постят мемы и, конечно, общаются с подписчиками в комментариях.
Знаком ли вам опыт разработки специализированной метрики? Помогла ли она вам в работе? Делитесь историями в комментариях.
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.