Задача для аналитиков: повысить эффективность поиска
С объявлением итогов конкурса.
Материал подготовлен при поддержке сервиса Юла
«Юла» — это сервис, где пользователи выкладывают свои объявления. На нём продаются квартиры и самодельные украшения, готовый бизнес или услуги — практически что угодно.
Поиск — один из самых важных продуктов сервиса. К поисковой выдаче относятся как запросы с текстовым поиском, так и запросы на выдачу объявлений в определённой категории и подкатегории.
Большинство запросов делается без дополнительных фильтров, но существенная часть пользователей их использует — отсеивают выдачу по цене или расстоянию, например.
В чём задача
Предложить изменения в поисковой выдаче, чтобы увеличить количество контактов по объявлениям. Контакт — это нажатие на кнопку «Позвонить» или отправка сообщения продавцу в чат.
В архиве — три CSV-таблицы. Это сырые логи запросов пользователей: как они искали объявления, какими фильтрами пользовались и связались ли с продавцами.
Аналитика может помочь вам решить задачу, но этот этап не является обязательным.
Условия и призы
На решение есть две недели: закончим принимать работы 28 октября в 23:59. Оценивать работы будет Егор Данилов, директор по продукту «Юлы». Он определит три лучших решения, прокомментирует свой выбор, а их авторы разделят призовой фонд следующим образом:
- Первое место — 300 тысяч рублей.
- Второе место — 200 тысяч рублей.
- Третье место — 100 тысяч рублей.
Что конкретно делать
В этой задаче нет правильного ответа. Вам нужно представить собственное видение в виде текста на одну-две страницы. Можете добавить в него таблицы или иллюстрации, дать ссылки на код, а затем загрузить в эту форму:
Помимо изменений, опишите, как будете оценивать результат эксперимента — на какие метрики будете смотреть и почему. Ещё нужно рассказать, что вы предпримите, если эксперимент уменьшит количество контактов по объявлениям.
Огромное спасибо всем, кто принял участие в нашем конкурсе. Мы не ожидали, что получим больше сотни работ.
Было сложно выбрать победителей: многие решения вращались вокруг схожих идей. Например, что нужно направить больше трафика на фильтры, которые лучше конвертируют поиски в контакты.
Как и говорилось в задаче конкурса, мы не оценивали предложенные решения с точки зрения вероятности их успеха. Мы выбрали победителей исходя из комплексной оценки работ по нескольким параметрам:
- Анализ данных.
- Умение построить гипотезы на основе данных.
- Аргументация решения, исходя из данных.
- Визуализация предложенного решения.
- Решение на случай, если предложенный эксперимент уменьшит количество контактов.
В результате в конкурсе победили:
1 место: Станислав Демченко
2 место: Константин Валиотти
3 место: Алексей Скуратов
Мы свяжемся с победителями по почтовому адресу, указанному в заявке.
Несколько комментариев по присланным работам:
- Задача была для аналитиков. Отличных идей было много, но предпочтение отдавалось решениям, где данные стали основой. Неважно, это анализ датасета или опрос знакомых — приоритет таких работ был выше, чем у построенных на личном опыте.
- Не все предложили сценарий на случай просадки метрик: часто озвучивался простой откат эксперимента. Но анализ неудачного эксперимента может дать хорошую пищу для дальнейших размышлений.
- Многие справедливо писали, что ключевая метрика успеха – сделки, а не контакты. Но для анализа влияния на сделки участникам нужно было бы потратить значительно больше времени, поэтому мы упростили задание.
- Многие уделили внимание технической стороне, но не менее важно понятно защитить свое решение: визуализировать его или логично вывести из анализа данных.
Поле search_id - это вроде id сессии?
Если я набирают в поиске "диваны". Получаю запись в таблице searches с search_id. Если я потом уточняю поиск "с доставкой" при сохранении исходного поискового запроса, то запись в таблице searches будет с тем же search_id?
Нет, это другой поисковый запрос.
Но если я напишу в поиске 'диваны'
То в таблице у нас с вами будут разные user_id, но в поле search_id у нас с вами будет один айдишник
Комментарий недоступен
Я официальный) Если что, спросите меня
@Daria Yakovleva
Как так получается, что search_id со значением 6236343631633764316361353535616661663864313534383433396637336436 в таблице filter_explorer_views встречается 54 раза и при том что имеет одинаковый user_id, но разные category_id, subcategory_id, cnt. Значения cnt имеют разброс от 1 до 18. Что обозначает search_id. Мне логика его совершенно непонятна и не объясняет Ваше пояснение выше. Прошу ответить.
Александр выше все классно разъяснил
Потому что там есть 2 типа поиска. По дефолту и по категории/тексту.
Вот когда человек ищет по дефолту, тогда в данных это main и в данном типе подразумевается, что пользователь не выбирает категорию.
У одного search_id может быть несколько разных категорий, потому что по дефолту ему выпадает список ближайших и "самых интересных" позиций из разных категорий. И вот когда пользователь сначала открыл и посмотрел iphone, вернулся назад и в том же списке открыл и посмотрел стиральную машину, тогда мы получаем в рамках одного seach_id две разные категории.
Валерия, спасибо за помощь с ответом! Всё очень правильно и понятно объяснили)
это все Александр ☺️
Дарья, подскажите, пожалуйста, это ок что если сгруппировать запросы по типу сортировки, то 96% идут с сортировкой по дистанции, еще 3% сортировка по дате публикации. очень странно выглядит.
кажется что поиски с главной страницы создаются автоматически при заходе на сайт и там всегда стоит фильтр по умолчанию ( то есть не сортировки)
Дарья, ответьте, пожалуйста на комментарий ниже. Почему почти все запросы идут по сортировке удаленности?