Все

Как в Авито разработали метрику для поиска распространённых проблем крупных пользователей

2025-08-05 12:12 Статьи analytics
Привет! Меня зовут Яша Финкельберг, я senior аналитик в Авито. Одна из базовых ценностей Авито, прописанная в нашем манифесте, — «Всё начинается с потребностей пользователя». Мы постоянно следим за удовлетворённостью продавцов и покупателей площадки и ищем способы улучшать их взаимодействие с Авито.
Уровень удовлетворённости отслеживаем разными способами, например, проводим опросы, замеряем метрики CES и CSAT. Чтобы находить более детальные драйверы, сегментировать запросы и ставить предсказуемые цели в работе с обращениями, мы решили разработать собственную метрику для работы с опытом пользователей — weighted contact rate (wCR).
В статье я расскажу, почему мы решили дополнить существующие метрики нашей, и дам пайплайн разработки, по которому уже вы сможете внедрить что-то подобное у себя в компании. Текст будет полезен аналитикам крупных компаний.

Контекст: почему решили разработать новую метрику

Авито — платформа, на которой торгуют частные лица и компании, что создаёт разброс в потребностях для каждой группы. Трудности у них тоже отличаются: то, что мешает маленькому частнику, не интересует крупного продавца и наоборот. Из-за этого сложно найти проблемы, характерные для конкретного сегмента. Чтобы решить эту задачу, мы разработали новую метрику и сделали это на примере крупных профессиональных продавцов.
Один из основных методов, который мы используем, для измерения удовлетворённости профессиональных пользователей — опросная метрика Customer Effort Score (CES).
Это отличный измеритель, но, как и у любого инструмента, у него есть ряд особенностей.
Есть плюсы:
  • позволяет понять влияние инициатив на уровне конкретных изменений в A/B-тестах;
  • показывает полный спектр того, что волнует пользователей.
  • помогает услышать не только проблемы, но и пожелания по улучшениям, идеи и новые потребности;
  • позволяет сравнивать нас с конкурентами.
И минусы:
  • сложно понять, что именно повлияло на метрику: изменение в продукте, ценовая политика, внешние факторы или что-то ещё;
  • данные сложно декомпозировать;
  • опасно ставить цели, поскольку метрики могут сильно меняться из-за внешних обстоятельств.
Минусы мешают использовать CES для поиска проблем конкретной группы продавцов, поэтому пришла идея считать метрику с учётом особенностей сегмента. Мы выбрали метрику Contact rate (CR).
CR — это отношение количества обращений в поддержку к бизнес-метрике, которая учитывает особенности вертикали или категории.
Планировали, что наша новая метрика будет подсвечивать текущие проблемы пользователей на основе данных из службы поддержки с поправкой на вес продавца в выручке Авито.
Обращения отображают текущие проблемы клиентов — если люди пишут нам, значит, их что-то волнует прямо сейчас и, скорее всего, они будут готовы предоставить подробные данные о своей проблеме. Таким образом, данные из поддержки будут закрывать нашу главную потребность, которую не закрывала CES: мы сможем ставить управляемые цели для сегментов, основываясь на конкретных данных здесь и сейчас.

Доказали связь обращений в поддержку с поведением пользователей

Важно было не просто придумать метрику, а ещё понимать, как она связана с поведением пользователя на площадке — могло ли быть так, что продавец пишет обращение, но при этом проблема не влияет на его работу с Авито. Поэтому на первом этапе мы решили выяснить, есть ли корреляция между оттоком пользователей и их обращениями в поддержку.
Сначала сравнили два сегмента продавцов: тех, кто обращался в поддержку, и тех, кто не обращался, но получили неверные выводы. Оказалось, что продавцы, которые писали в поддержку, были активнее и чаще пользовались платными услугами продвижения. На первый взгляд может показаться, что обращения в поддержку — признак активности и успешности продавца, но это не так: сам факт обращения может означать только нейтральный либо негативный опыт.
Здесь мы столкнулись с ложной корреляцией (spurious correlation) из-за смешивающего фактора (confounding variable). В данном случае смешивающий фактор — общая активность продавца. Чем чаще человек использует Авито, тем больше у него поводов обратиться в поддержку. Если убрать влияние активности, то обращения в поддержку, наоборот, должны указывать на проблемы, поэтому напрямую сравнивать эти два сегмента нельзя — выводы будут неверными.
A/B-тесты провести тоже не получилось, поскольку нельзя сказать продавцам: «Вы пишите в поддержку, а вы — нет».
В итоге пришли к методу мэтчинга. Решили сравнить группы и выяснить — влияют ли обращения пользователей в поддержку на их отток в последующем. Вот как это было:
  1. Сперва исследовали ключевые параметры. Для каждого направления бизнеса и целевой метрики мы подбирали факторы, которые лучше всего предсказывают эти показатели в будущем. Такой отступ в будущее помогает выявить причинно-следственную связь, а не просто найти корреляцию.
  2. Затем мы искали «пользователей-близнецов». Подбирали пары максимально похожих продавцов — тех, кто обращался в поддержку, и тех, кто не обращался. Учитывали все ключевые параметры, которые нашли раньше: активность, историю покупок, количество обращений в поддержку.
  3. Потом сравнили «выровненные» группы. После мэтчинга разница между группами должна была зависеть только от фактора обращения в поддержку. Так, например, мы выяснили, что клиенты, которые обращались за помощью, в среднем чаще уходили с платформы и тратили меньше бюджета на услуги продвижения.

Повысили точность разметки данных

Запросы пользователей нужно было категоризировать, чтобы понимать — на что стоит обратить внимание сейчас, а что можно положить в бэклог и вернуться позже. Все пользовательские обращения по умолчанию размечали боты, сами продавцы или сотрудники службы поддержки. Это снижало точность метрики, поскольку в сценарии всегда действовал человеческий фактор и одинаковые проблемы падали в разные категории.
Так как наша метрика не событийная и мы не можем просто посчитать конкретные клики пользователя, нужно было разобраться, как оценить точность в разметке и исправить ошибки.
Для этого начали создавать собственную модель классификации обращений, но быстро поняли, что дальнейшая разработка — долго, трудно и дорого. Поэтому взяли внутреннюю 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 выглядит так:
Формула расчёта метрики weighted contact rate
Подробнее про бакетирование в A/B-тестах мы писали отдельную статью: «Как устроено A/B-тестирование в Авито».

Шаг 3: разработка методов интерпретации метрики

Метрика weighted contact rate (wCR) готова, но возник вопрос — как интерпретировать её в моменте, чтобы сразу предпринимать какие-то действия и улучшать пользовательский опыт. Мы стали создавать удобный инструмент, который будет сразу показывать значимые результаты, а не шум. У нас было две задачи: сравнивать показатели между периодами и выявлять основные причины обращений.
Сравниваем периоды. Чтобы анализировать динамику изменений, мы использовали подход, похожий на A/B-тестирование. Брали данные за два месяца, применяли уже проверенное бакетирование, такое же, как при расчёте минимально детектируемого эффекта, и сравнивали показатели с помощью t-теста.
Этот метод позволил нам использовать единый критерий, чтобы отделять случайные колебания метрики от действительно значимых изменений.
Сравнение периодов для всей метрики через разработанный подход для MDE
Сравнение периодов через стандартный Т-тест
Искали драйверы для обращений. Для этого мы применили подход из факторного анализа — метод каменистой осыпи. Сначала ранжировали все типы обращений по частоте, затем находили на графике точку, где массовые проблемы переходят в редкие случаи. Всё, что было до этой точки, мы считали значимыми драйверами и фокусировались именно на них. Остальные единичные проблемы отправляли в бэклог для дальнейшего изучения.
Такой подход помог быстро выявлять действительно важные для пользователей запросы и отсекать единичные обращения.
Как выглядит ранжирование обращений по методу каменистой осыпи
Разработали методы прогноза. Поскольку метрика wCR хорошо декомпозируется, мы смогли создать модель для её прогнозирования. Основная формула выглядит как отношение количества обращений в поддержку к числу крупных продавцов на платформе. Числитель мы прогнозируем, учитывая сезонность и запланированные изменения в сервисе, а знаменатель — это известное количество активных продавцов.
Для автоматизации расчётов мы перешли от стандартной метрики CR (Contact Rate) к взвешенной wCR с помощью линейной модели. В этом нам помог коэффициент перехода Coeff wCR to CR. Сама модель учитывает множество факторов, что делает прогнозы более точными. Ключевыми показателями здесь выступают N Листеров — количество платящих продавцов с активными объявлениями и, собственно, CR — невзвешенная метрика обращений.
Формула, по которой прогнозируем возможный рост обращений в поддержку
Что в итоге. Наша метрика уже начала работать: например, благодаря wCR мы подсветили и решили часть проблем крупных продавцов с Автозагрузкой объявлений. Провели эксперимент, в котором показывали крупным продавцам способ, как подключить этот инструмент для работы на Авито.
В результате количество обращений с вопросом: «Как подключить?» уменьшилось в 2 раза на одного продавца. Это соответствует ≈ 2% всего wCR Автозагрузки, при оценке через прокси. Сейчас знакомство пользователей профессионального кабинета с Автозагрузкой работает полноценно.

Кратко: как мы разрабатывали новую метрику

Создали новую метрику для оценки пользовательского опыта крупных продавцов, дополняющую классические CR, CES и CSAT. Теперь можем учитывать обращения в поддержку, взвешенные по активности и тратам пользователей, и получать более управляемые и декомпозируемые результаты, что далее используется для постановки целей.
Вот из каких этапов состоял процесс разработки:
  1. Сравнили «пользователей-близнецов» — тех, кто обращался в поддержку, и таких же не обращавшихся. Это помогло понять, как проблемы на площадке влияют на поведение пользователей.
  2. Нашли, откуда будем брать данные для расчёта показателей, и улучшили разметку обращений с помощью внутренней LLM Авито.
  3. Применили методы бакетирования и CUPED, чтобы снизить шум и повысить точности в A/B-тестах.
  4. Интерпретировали wCR — проанализировали динамику с помощью псевдо A/B и нашли основные драйверы обращений с помощью методики каменистой осыпи.
wCR новая метрика работает — помогает нам выявлять и решать проблемы пользователей в более сжатые сроки, прогнозировать количество обращений в поддержку, а также приоритизировать задачи.
Подписывайтесь на «Коммуналку аналитиков» в Телеграме. Там аналитики Авито рассказывают, как выглядит работа в Авито изнутри: делятся мыслями, успехами и фейлами, постят мемы и, конечно, общаются с подписчиками в комментариях.
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.