Задача для аналитиков: повысить эффективность поиска
С объявлением итогов конкурса.
Материал подготовлен при поддержке сервиса Юла
«Юла» — это сервис, где пользователи выкладывают свои объявления. На нём продаются квартиры и самодельные украшения, готовый бизнес или услуги — практически что угодно.
Поиск — один из самых важных продуктов сервиса. К поисковой выдаче относятся как запросы с текстовым поиском, так и запросы на выдачу объявлений в определённой категории и подкатегории.
Большинство запросов делается без дополнительных фильтров, но существенная часть пользователей их использует — отсеивают выдачу по цене или расстоянию, например.
В чём задача
Предложить изменения в поисковой выдаче, чтобы увеличить количество контактов по объявлениям. Контакт — это нажатие на кнопку «Позвонить» или отправка сообщения продавцу в чат.
В архиве — три CSV-таблицы. Это сырые логи запросов пользователей: как они искали объявления, какими фильтрами пользовались и связались ли с продавцами.
Аналитика может помочь вам решить задачу, но этот этап не является обязательным.
Условия и призы
На решение есть две недели: закончим принимать работы 28 октября в 23:59. Оценивать работы будет Егор Данилов, директор по продукту «Юлы». Он определит три лучших решения, прокомментирует свой выбор, а их авторы разделят призовой фонд следующим образом:
- Первое место — 300 тысяч рублей.
- Второе место — 200 тысяч рублей.
- Третье место — 100 тысяч рублей.
Что конкретно делать
В этой задаче нет правильного ответа. Вам нужно представить собственное видение в виде текста на одну-две страницы. Можете добавить в него таблицы или иллюстрации, дать ссылки на код, а затем загрузить в эту форму:
Помимо изменений, опишите, как будете оценивать результат эксперимента — на какие метрики будете смотреть и почему. Ещё нужно рассказать, что вы предпримите, если эксперимент уменьшит количество контактов по объявлениям.
Огромное спасибо всем, кто принял участие в нашем конкурсе. Мы не ожидали, что получим больше сотни работ.
Было сложно выбрать победителей: многие решения вращались вокруг схожих идей. Например, что нужно направить больше трафика на фильтры, которые лучше конвертируют поиски в контакты.
Как и говорилось в задаче конкурса, мы не оценивали предложенные решения с точки зрения вероятности их успеха. Мы выбрали победителей исходя из комплексной оценки работ по нескольким параметрам:
- Анализ данных.
- Умение построить гипотезы на основе данных.
- Аргументация решения, исходя из данных.
- Визуализация предложенного решения.
- Решение на случай, если предложенный эксперимент уменьшит количество контактов.
В результате в конкурсе победили:
1 место: Станислав Демченко
2 место: Константин Валиотти
3 место: Алексей Скуратов
Мы свяжемся с победителями по почтовому адресу, указанному в заявке.
Несколько комментариев по присланным работам:
- Задача была для аналитиков. Отличных идей было много, но предпочтение отдавалось решениям, где данные стали основой. Неважно, это анализ датасета или опрос знакомых — приоритет таких работ был выше, чем у построенных на личном опыте.
- Не все предложили сценарий на случай просадки метрик: часто озвучивался простой откат эксперимента. Но анализ неудачного эксперимента может дать хорошую пищу для дальнейших размышлений.
- Многие справедливо писали, что ключевая метрика успеха – сделки, а не контакты. Но для анализа влияния на сделки участникам нужно было бы потратить значительно больше времени, поэтому мы упростили задание.
- Многие уделили внимание технической стороне, но не менее важно понятно защитить свое решение: визуализировать его или логично вывести из анализа данных.
На первом месте предложения:
отсекать слишком низкие цены (не релевантные товары),
и по у молчанию активировать фильтр дистанции до продавца (что и так было).
Юла, вам просто хотелось понять, что вы и так сделали что могли. Ну это мизерные предложения, конверсию они вам мало изменят, очевидно)
Сергей, мы не оценивали предложения. Без проверки в продукте невозможно понять, какое из них хорошее, а какое плохое. Мы оценивали умение проанализировать данные, построить гипотезы на основе них, предложить решения и обработать случай если гипотеза не подтвердилась.
Вариант Станислава Демченко точно так же, как и мой, построен на помощи покупателю найти релевантный товар. Но Станислав в отличии от меня не анализирует хронологию действий покупателя.
Станислав: "пользователи, совершающие контакт, более склонны к заданию price_filter".
Я: "Получив конечный список подходящих (по мнению покупателя) товаров, он переходит к выбору по параметру цена/качество. Если не хватает денег или не устраивает качество, то покупатель возвращается к теме потребительских свойств и пересматривает их"
То есть Станислав понял, что готовый к покупке пользователь начинает доставать кошелек и считать деньги. Вполне логично, что готовый в совершению покупки пользователь будет использовать фильтр по цене намного чаще, чем пользователь, который еще не нашел нужный товар и значит не готов к совершению покупки. И так же это значит, что пользователь в первую очередь ищет товар по свойствам, а только потом уже использует ценовой фильтр для найденных товаров со схожими свойствами. Этот вывод напрашивается даже из наблюдения Станислава, но он не смог к нему прийти.
Из-за этой ошибки Станислав уже в русле логики своего вывода делает предложение, которое лишает покупателя права самостоятельного выбора (урезает список эмоциональных покупок).
Станислав: "ввести
автоматический фильтр, который бы устанавливал границы доверительного интервала по цене при поиске, если пользователь сам не делал этого. Основная задача данного фильтра заключалась бы в отсечении снизу
хотя бы части этих нерелевантных объявлений."
То есть Станислав предлагает управлять ценой, без разрешения вмешиваясь в процесс выбора пользователем. Причем он предлагает покупателю начать поиск товара в обратном неестественном порядке: сначала определиться с ценой, а потом уже перейти к выбору по потребительским свойствам.
Я предложил 5 пунктов (подробно в моей работе), которые должны помочь пользователю последовательно добраться до того момента, когда появится готовность купить товар, а значит сделать выбор по цене: "Результат в данном случае – это некий список товаров, который постоянно пользователь сокращает. Сокращение списка – путь к действию «купить» или то, что «влияет на изменение количества контактов»."
Таким образом в моей работе присутствует анализ хронологии действий пользователя и есть объяснение, почему это важно.
Кроме того Станислав увидел и сообщил, что к совершению покупки пользователя не приводит действующая система категорий и подкатегорий. Он увидел проблему, но оставил её без анализа и решения.
Станислав: "Таким образом,
имеет смысл рассматривать поведение пользователей целиком, безотносительно категорий."
Я же посвятил всю свою работу именно этой проблеме.
Станислав не понял проблему неудобства пользователя "категорий и подкатегорий", поэтому сделал дополнительное похожее предложение с теми же ошибками:
"Дополнительно предлагается реализовать гистограмму цен, чтобы пользователь имел ориентир
по распределению цен в его поисковом запросе и тем, какую часть этой
выборки система не показала после применения автоматического фильтра"
Анализ удобства (мотивации) использования фильтров у Станислава отсутствует, поэтому он предложил еще один такой же неудобный фильтр.
Моя же работа такой анализ содержит. Например:
"Чтобы визуально пользователь всегда понимал, что у него включено и выключено."
"С помощью этого пользователь будет продолжать отсеивать/сокращать общий список, постепенно фиксируя свои промежуточные решения о том, какие параметры для него важны больше или меньше."
"такие товары можно будет сравнивать с появившимися новыми и любыми другими на одной странице без дополнительных манипуляций."
"Если пользователь не определился с выбором за одно посещение, то надо дать ему возможность продолжить поиск с того, на чем он остановился."
То есть я подробно проанализировал процессы, которые приводят пользователя к искомому товару, а "Юлу" к увеличению продаж.