Задача для аналитиков: повысить эффективность поиска

С объявлением итогов конкурса.

Материал подготовлен при поддержке сервиса Юла

«Юла» — это сервис, где пользователи выкладывают свои объявления. На нём продаются квартиры и самодельные украшения, готовый бизнес или услуги — практически что угодно.

Поиск — один из самых важных продуктов сервиса. К поисковой выдаче относятся как запросы с текстовым поиском, так и запросы на выдачу объявлений в определённой категории и подкатегории.

Большинство запросов делается без дополнительных фильтров, но существенная часть пользователей их использует — отсеивают выдачу по цене или расстоянию, например.

Взглянуть, как это работает, можно на сайте или приложениях iOS и Android.

В чём задача

Предложить изменения в поисковой выдаче, чтобы увеличить количество контактов по объявлениям. Контакт — это нажатие на кнопку «Позвонить» или отправка сообщения продавцу в чат.

В архиве — три CSV-таблицы. Это сырые логи запросов пользователей: как они искали объявления, какими фильтрами пользовались и связались ли с продавцами.

Аналитика может помочь вам решить задачу, но этот этап не является обязательным.

Расшифровка столбцов в таблицах

Условия и призы

На решение есть две недели: закончим принимать работы 28 октября в 23:59. Оценивать работы будет Егор Данилов, директор по продукту «Юлы». Он определит три лучших решения, прокомментирует свой выбор, а их авторы разделят призовой фонд следующим образом:

  • Первое место — 300 тысяч рублей.
  • Второе место — 200 тысяч рублей.
  • Третье место — 100 тысяч рублей.

Что конкретно делать

В этой задаче нет правильного ответа. Вам нужно представить собственное видение в виде текста на одну-две страницы. Можете добавить в него таблицы или иллюстрации, дать ссылки на код, а затем загрузить в эту форму:

или
Приём работ завершён
(function(d, w, ver) { var s = d.createElement('script'); s.src = 'https://www.google.com/recaptcha/api.js?' + ver; s.async = true; var container = d.getElementById('ula-form-wrapper'); if (container) { s.onload = function() { var ulaForm = d.querySelector('[data-ula-form]'), ulaFile = d.querySelector('[data-ula-file]'); if (!ulaForm) return false; var ulaInputs = [].slice.call(ulaForm.querySelectorAll('input')).slice(0, 3), ulaSubmitBtn = ulaForm.querySelector('[type="submit"]'); ulaInputs.forEach(function(ulaInput) { ulaInput.addEventListener('change', function(e) { ulaInput.parentElement.classList.remove('is-error'); }); }); ulaFile.addEventListener('change', function(e) { var textSpan = ulaFile.parentElement.children[1].children[0], svgIcon = ulaFile.parentElement.querySelector('svg'); textSpan.innerText = getFileName(ulaFile); if (svgIcon) svgIcon.remove(); }); ulaForm.addEventListener('submit', function(e) { e.preventDefault(); var response = (grecaptcha) ? grecaptcha.getResponse() : ''; if (!response.length) return false; if (ulaSubmitBtn.className.indexOf('is-loading') !== -1) { return false; } if (ulaSubmitBtn.innerText === 'Готово!') { ulaSubmitBtn.innerText = 'Отправить'; return false; } for (let i = 0; i < ulaInputs.length; i++) { ulaInputs[i].parentElement.classList.remove('is-error'); if (ulaInputs[i].value.length === 0) { ulaInputs[i].parentElement.classList.add('is-error'); ulaInputs[i].focus(); return false; } } ulaSubmitBtn.classList.add('is-loading'); var formData = new FormData(ulaForm); Promise.all([wait(), ajax(ulaForm.getAttribute('action'), formData)]).then(function(data) { var res = data[1]; ulaSubmitBtn.classList.remove('is-loading'); if (res && res.rm === 'Success') { ulaSubmitBtn.innerText = 'Готово!'; } else { } }).catch(function() { ulaSubmitBtn.classList.remove('is-loading'); }); }); function ajax(url, data) { return new Promise(function(resolve, reject) { var request = new XMLHttpRequest(); request.open('POST', url, true); request.setRequestHeader('X-This-Is-CSRF', 'THIS IS SPARTA!'); request.onload = function() { if (this.status >= 200 && this.status < 400) { var resp = this.response; resolve(JSON.parse(resp)); } else { reject(); } }; request.onerror = function() { reject(); }; request.send(data); }); } function getFileName(input) { var fullPath = input.value; if (fullPath) { var startIndex = (fullPath.indexOf('\\') >= 0 ? fullPath.lastIndexOf('\\') : fullPath.lastIndexOf('/')); var filename = fullPath.substring(startIndex); if (filename.indexOf('\\') === 0 || filename.indexOf('/') === 0) { filename = filename.substring(1); } return filename.slice(0, ); } } function wait() { return new Promise(function(resolve, reject) { setTimeout(function() { resolve(); }, 1000); }); } }; } d.body.appendChild(s); })(document, window, 5);

Помимо изменений, опишите, как будете оценивать результат эксперимента — на какие метрики будете смотреть и почему. Ещё нужно рассказать, что вы предпримите, если эксперимент уменьшит количество контактов по объявлениям.

Огромное спасибо всем, кто принял участие в нашем конкурсе. Мы не ожидали, что получим больше сотни работ.

Было сложно выбрать победителей: многие решения вращались вокруг схожих идей. Например, что нужно направить больше трафика на фильтры, которые лучше конвертируют поиски в контакты.

Как и говорилось в задаче конкурса, мы не оценивали предложенные решения с точки зрения вероятности их успеха. Мы выбрали победителей исходя из комплексной оценки работ по нескольким параметрам:

  • Анализ данных.
  • Умение построить гипотезы на основе данных.
  • Аргументация решения, исходя из данных.
  • Визуализация предложенного решения.
  • Решение на случай, если предложенный эксперимент уменьшит количество контактов.

В результате в конкурсе победили:

Мы свяжемся с победителями по почтовому адресу, указанному в заявке.

Несколько комментариев по присланным работам:

  • Задача была для аналитиков. Отличных идей было много, но предпочтение отдавалось решениям, где данные стали основой. Неважно, это анализ датасета или опрос знакомых — приоритет таких работ был выше, чем у построенных на личном опыте.
  • Не все предложили сценарий на случай просадки метрик: часто озвучивался простой откат эксперимента. Но анализ неудачного эксперимента может дать хорошую пищу для дальнейших размышлений.
  • Многие справедливо писали, что ключевая метрика успеха – сделки, а не контакты. Но для анализа влияния на сделки участникам нужно было бы потратить значительно больше времени, поэтому мы упростили задание.
  • Многие уделили внимание технической стороне, но не менее важно понятно защитить свое решение: визуализировать его или логично вывести из анализа данных.

Общий срок проведения конкурса: с 14.10.19 по 18.11.2019 (регистрация участников до 28.10.19). Информация об организаторе, правилах, количестве призов, сроках, месте и порядке их получения — на этой странице.

0
239 комментариев
Написать комментарий...
Nice Man

На первом месте предложения:

отсекать слишком низкие цены (не релевантные товары),

и по у молчанию активировать фильтр дистанции до продавца (что и так было).

Юла, вам просто хотелось понять, что вы и так сделали что могли. Ну это мизерные предложения, конверсию они вам мало изменят, очевидно)

Ответить
Развернуть ветку
Егор Данилов

Сергей, мы не оценивали предложения. Без проверки в продукте невозможно понять, какое из них хорошее, а какое плохое. Мы оценивали умение проанализировать данные, построить гипотезы на основе них, предложить решения и обработать случай если гипотеза не подтвердилась.

Ответить
Развернуть ветку
Эдуард Балагуров

Вариант Станислава Демченко точно так же, как и мой, построен на помощи покупателю найти релевантный товар. Но Станислав в отличии от меня не анализирует хронологию действий покупателя. 

Станислав: "пользователи, совершающие контакт, более склонны к заданию price_filter".
Я: "Получив конечный список подходящих (по мнению покупателя) товаров, он переходит к выбору по параметру цена/качество. Если не хватает денег или не устраивает качество, то покупатель возвращается к теме потребительских свойств и пересматривает их"

То есть Станислав понял, что готовый к покупке пользователь начинает доставать кошелек и считать деньги. Вполне логично, что готовый в совершению покупки пользователь будет использовать фильтр по цене намного чаще, чем пользователь, который еще не нашел нужный товар и значит не готов к совершению покупки. И так же это значит, что пользователь в первую очередь ищет товар по свойствам, а только потом уже использует ценовой фильтр для найденных товаров со схожими свойствами. Этот вывод напрашивается даже из наблюдения Станислава, но он не смог к нему прийти.

Из-за этой ошибки Станислав уже в русле логики своего вывода делает предложение, которое лишает покупателя права самостоятельного выбора (урезает список эмоциональных покупок).

Станислав: "ввести
автоматический фильтр, который бы устанавливал границы доверительного интервала по цене при поиске, если пользователь сам не делал этого. Основная задача данного фильтра заключалась бы в отсечении снизу
хотя бы части этих нерелевантных объявлений."

То есть Станислав предлагает управлять ценой, без разрешения вмешиваясь в процесс выбора пользователем. Причем он предлагает покупателю начать поиск товара в обратном неестественном порядке: сначала определиться с ценой, а потом уже перейти к выбору по потребительским свойствам.

Я предложил 5 пунктов (подробно в моей работе), которые должны помочь пользователю последовательно добраться до того момента, когда появится готовность купить товар, а значит сделать выбор по цене: "Результат в данном случае – это некий список товаров, который постоянно пользователь сокращает. Сокращение списка – путь к действию «купить» или то, что «влияет на изменение количества контактов»."

Таким образом в моей работе присутствует анализ хронологии действий пользователя и есть объяснение, почему это важно. 

Кроме того Станислав увидел и сообщил, что к совершению покупки пользователя не приводит действующая система категорий и подкатегорий. Он увидел проблему, но оставил её без анализа и решения. 

Станислав: "Таким образом,
имеет смысл рассматривать поведение пользователей целиком, безотносительно категорий."

Я же посвятил всю свою работу именно этой проблеме.

Станислав не понял проблему неудобства пользователя "категорий и подкатегорий", поэтому сделал дополнительное похожее предложение с теми же ошибками:

"Дополнительно предлагается реализовать гистограмму цен, чтобы пользователь имел ориентир
по распределению цен в его поисковом запросе и тем, какую часть этой
выборки система не показала после применения автоматического фильтра"

Анализ удобства (мотивации) использования фильтров у Станислава отсутствует, поэтому он предложил еще один такой же неудобный фильтр. 

Моя же работа такой анализ содержит. Например:

"Чтобы визуально пользователь всегда понимал, что у него включено и выключено."

"С помощью этого пользователь будет продолжать отсеивать/сокращать общий список, постепенно фиксируя свои промежуточные решения о том, какие параметры для него важны больше или меньше."

"такие товары можно будет сравнивать с появившимися новыми и любыми другими на одной странице без дополнительных манипуляций."

"Если пользователь не определился с выбором за одно посещение, то надо дать ему возможность продолжить поиск с того, на чем он остановился."

То есть я подробно проанализировал процессы, которые приводят пользователя к искомому товару, а "Юлу" к увеличению продаж. 

Ответить
Развернуть ветку
Эдуард Балагуров

Продолжим. 

Станислав: "Вторая гипотеза заключается в большей важности сортировки по дистанции ... Из данных видно, что те, кто совершают контакт чаще пользуются сортировкой по дистанции."

 В этом месте хочется пошутить про каких-то хакеров, которые сумели выйти в электрическую сеть. 

 Дело в том, что пользователь осознаёт, что намеревается приобрести товар у другого такого же пользователя. Бесплатной доставки не будет. Для преодоления расстояния до продавца, чтобы приобрести товар, придется потратить время и деньги. Это те затраты, которые пользователь суммирует с указанной ценой товара, чтобы получить конечную реальную цену. 

 Это Капитан Очевидность. Довольно странно это вообще анализировать в таком конкурсе. 

 "Обработать случай если гипотеза не подтвердилась" в работе Станислава вообще отсутствует даже формально. Не осуждаю по той причине, что указал постом выше.

 Но при этом я всё-таки выполнил условие конкурса:
"Метрики работоспособности идеи – количество и частота использования фильтров, количество возвратов на сайт для продолжения/возобновления поиска. Первый риск в том, что мои предложения тесно взаимодействуют с визуальной (для пользователя) реализацией. То есть идея может не работать полностью или частично по причине неудобного для пользователя дизайна. Но это решается методом проб и ошибок. Второй риск в том, что механизм окажется интуитивно непонятным. Пользователей надо научить. Если эксперимент уменьшит количество контактов по объявлениям, то в первую очередь нужно проанализировать процесс реализации эксперимента." 

 Итого. При сравнении работ мои анализ и решения оказались на порядок более глубокими и в хорошем смысле сложными, чем у Станислава. Анализ - это не калькулятор с очевидными выводами, а умение правильно определить точки входа/выхода процессов.

Ответить
Развернуть ветку
Nice Man

Вы нанимаете кого-то из выигравших?

Ответить
Развернуть ветку
Егор Данилов

Сергей, в условиях конкурса не было условия, что победителям потом обязательно нужно устроиться в Юлу. Я буду рад, если кому-то из участников понравятся задачи, которые мы решаем, и они пришлют нам свои резюме. Например, мы сейчас ищем руководителя аналитики в монетизацию: https://hh.ru/vacancy/33140983

Ответить
Развернуть ветку
Nice Man

А зачем вам оценивать умение кого-то проанализировать что-то? Не проверить себя. Не нанять. Только в рамках пиара?)

Ответить
Развернуть ветку
Эдуард Балагуров

Егор, я вот, если честно, не очень понял ту часть задания, где нужно "обработать случай если гипотеза не подтвердилась". Если аналитик предлагает решение, то оно однозначно кажется ему наилучшим. Заранее без результатов и их проверки невозможно предложить действия, если решение не сработало. Не может же аналитик запланировать ошибку и заранее на неё указать, объяснив метод исправления. Это будет абсурдом. 
Вся задача для конкурса сравнима с поиском ошибки. И участники нашли очень разные ошибки, которые по-разному обосновали, предложили исправить. Таким образом Ваше решение "обработать случай" выглядит как "провести конкурс для аналитиков с общим фондом 600 тысяч рублей". Это не новое, но и не самое обычное решение, которое вряд ли было принято на основе анализа статистических данных. 

Ответить
Развернуть ветку
236 комментариев
Раскрывать всегда