Подбор по параметрам как на Ситилинке. Умный фильтр 1С-Битрикс

Вы можете сделать такой сайт как Ситилинк? Да, все точно так же.


Поиск, подбор, фильтр — будем считать эти слова синонимами. На входе параметры, на выходе результат.


Что это такое? При чем тут citilink.ru и его подбор товаров по параметрам?

Большой каталог товаров обычно разбивают на группы.

Например, в интернет-магазине садовых принадлежностей могут продаваться газонокосилки и грунт.

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

В таком поиске легко указать несовместимый набор параметров и увидеть

Извините, ничего не найдено. Задайте другой набор параметров

Универсальный поиск с указанием всех характеристик неудобен. С каждым новым неуспешным запросом шансы удержать клиента на сайте тают на глазах. Так зачем же вообще давать пользователю возможность загнать себя в угол?

Чтобы не запутаться в большом каталоге, где много параметров, делают умный фильтр.

Умный фильтр

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

Умный фильтр — это если вы выбрали мужскую строгую обувь, — и красный цвет из фильтра исчез сам.

Умный фильтр — это когда удобно искать и не думаешь как он работает.

Это как подбор товаров на Ситилинке

Проще показать.

Группа «Планшеты» — http://www.citilink.ru/catalog/mobile/tablet_pc/


Шаг 1

Шаг 2

Шаг 3

Изначально Фильтр (он справа) содержит полный набор товаров и параметров. Товаров доступно 912.

png;base643bda5cf2fc2dc8c6.png

Укажем только “Волгоград”. Товаров стало 202, число хитов, новинок и уцененных товаров изменилось, диапазон цен сузился, товаров Acer осталось только 7.

png;base64e2647d8da630d7af.png

Выберем “Акция”. Оказалось, что все три товара по акции -- фирмы Samsung

png;base643bda5cf2fc2dc8c6.png


То, как сделал Ситилинк — классика. Она прекрасна, но у нее есть недостатки.
  • фильтр работает с перезагрузкой страницы. Страница тяжелая, ждать долго;

  • несколько брендов можно выбрать только переключившись в особый режим «Несколько условий»;

  • не всегда бегунки цены соответствуют выбранному набору. например, сейчас выбран 1 товар 
    png;base6457a3deb4f7550183.png , а цену по-прежнему можно выбрать из диапазона.

Почему это так популярно?

Во-первых, если параметров много, такой подбор действительно удобен.

Во-вторых, популярность сайтов Эльдорадо, М.Видео и Яндекс.Маркет, где сделан такой поиск, вызывает желание иметь такой же.

В-третьих, большинство людей, задумывающих магазин, не знают насколько сложно иногда сделать «как на ситилинке». Они воспринимают такой элемент как стандартный.

Кто назвал его Умный фильтр?

Термин для этого понятия введен компанией 1С-Битрикс и активно всего применяется ее клиентами и партнерами.

Как показывает Яндекс , так еще называют сетевые фильтры и фильтры Photoshop.

Я не знаю более удачного названия для этого понятия, поэтому буду использовать его.

Что тут сложного?

Умный фильтр доставляет много сложностей.

Человеку, ответственному за ввод описаний товаров на сайте (или товароведу, работающему в 1С) нужно
  • ввести все значения всех характеристик товаров и не сделать ошибок;

  • применять справочники, а не вручную вводить значения полей.

Программисту сложно
  • сделать автоматически работающий механизм, учитывая сколько бывает типов товаров, параметров, зависимостей, дизайнов каталога;

  • реализовать подбор так, чтобы он работал достаточно быстро при большом числе товаров и параметров.

Администратору сервера придется
  • бороться с высокой нагрузкой;

  • писать в поддержку хостинга и ругаться с программистами.

Это же есть в Битриксе, почему разработчики хватаются за голову?

Действительно, еще осенью 2012 года умный поиск был выпущен компанией 1С-Битрикс и включен в демонстрационный интернет-магазин.

Это разбудило интерес к такому виду поиска и создало целый поток запросов от клиентов.

Это привело к появлению на сайтах удобных инструментов, а у партнеров — интересных заказов.

В 1С-Битрикс для настройки умного фильтра для каждой группы товаров указываются те свойства, которые будут заполнены. Именно по этому вручную настроенному списку в первую очередь и работает умный фильтр. Если ничего не настроить — всегда будут использоваться все созданные для инфоблока свойства.

Чем примечателен штатный компонент bitrix:catalog.smart.filter , включенный в редакции с «интернет-магазином»? Этот компонент:
  • работает только с инфоблоками типа «торговый каталог»;
  • не работает с SKU (торговые предложения с характеристиками из 1С) доработано в 12.5.0;

  • некорректно работает с ценами в разных валютах: 10 долларов меньше чем 11 рублей;

  • без ухищрений не работает с числом свойств более 180 (это ограничение не столько умного фильтра, сколько инфоблоков и особенностей их реализации, но когда начинаешь работать с сотнями свойств для многих групп товаров, вероятность наткнуться на это ограничение растет);

  • порождает много запросов, сильно грузит сервер, расходует много памяти.

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

Сказать, что реализация умного фильтра компанией 1С-Битрикс идеальна — нельзя (сервис  Есть идея  на сайте Битрикса не даст соврать). Но как база для развития — очень даже ничего.

Как реализуется умный фильтр? Есть более простые варианты?

Есть несколько способов реализовать умный фильтр. Они отличаются степенью «ума». Ребята из компании Sibirix написали отличную статью про то,  каким должен быть идеальный фильтр в интернет-магазине .

Посмотрим, как можно приблизиться к идеалу.

Умный фильтр или «старший умный был детина»

Если объяснять на пальцах, то все предельно просто — фильтр знает, какие товары есть в продаже, собирает их свойства и выводит.

Возьмем для примера интернет-магазин косметики. Всего на сайте 41 бренд, 20 стран, 38 назначений, 20 видов товаров, а эффект — так и вовсе задается в произвольной форме для каждого товара в отдельности.

Разнообразие — велико.

Выглядит это так (до активации фильтра, в корневом разделе каталога):

png;base64e39ac147a0d53913.png

Если же зайти в какой-то относительно «бедный» товарами раздел, например «Косметика для лица», то фильтр не покажет бОльшую часть характеристик.

Умный фильтр.png

Выглядит так, будто ничего нет. Куда же пропало богатство — тысячи товаров 41 бренда и их свойства?

Да никуда оно не пропало. Просто сейчас пользователь находится в разделе “Косметика для лица”, нету там ни одного товара из Франции, России и других стран, нет там детских товаров, как и прочих десятков вариантов, которые предложил бы старый добрый глупый фильтр.

Еще пример работы умного фильтра в другом разделе. 

Деактивация галочек

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

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

Умный фильтр умнее, чем может показаться. Бренд American Crew на картинке заблокирован потому, что установка этой галочки не добавляет товаров в выдачу, не имеет смысла.

Недостаточно умный фильтр, или «средний был и так и сяк»

Фильтры, описанные выше, широко распространились не так давно, а в Битриксе появились только в 2012 году. До тех пор приходилось выкручиваться своими силами и использовать простой фильтр, чуть-чуть поучив его уму-разуму.

Пример такой реализации — наш интернет-магазин моторных масел.

Почти умный фильтр.png

В основе тот же принцип — если уж нет литровой автокосметики, то пользователь ее и не сможет указать. И действительно, если попробовать каждую галочку в фильтре по отдельности, товары всегда будут находиться и страшные слова «Ничего не найдено» мы сразу не увидим.

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

Почти умный фильтр сглупил.png

Почему выдача пустая? Где же товары? А нет таких товаров, фильтр такого типа не умеет проверять недопустимые комбинации.

Обычный фильтр, или «младший вовсе был дурак»

Как говорится, лучше один раз увидеть:

Глупый фильтр.png

Форма жуткая, и вы такие много раз видели.

Это пример антиюзабили и работы против продаж. Делать так не надо.

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

Умный фильтр тормозит. Всегда?

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

Умный фильтр знает о каталоге товаров все.

Если дойти до уровня кода умного фильтра в Битриксе, весь фокус кроется в одной строчке (в версии 14.0.2 модуля Каталог) это строка 46 файла /bitrix/components/bitrix/catalog.smart.filter/component.php:

$rsElements = CIBlockElement::GetPropertyValues($this->IBLOCK_ID, $arElementFilter);

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

Как можно сделать чтобы подбор по параметрам работал быстро?

Небольшой экскурс в историю — как же учили фильтры уму-разуму раньше, пока это не сделал Битрикс.

За основу брался многострадальный компонент catalog.filter и подвергался бесчеловечным экспериментам.

Параметры нашего каталога (это интернет-магазин мебели):
  • 58916 товаров;

  • 148 разделов;

  • 236 свойств.

Поставим штатный умный фильтр Битрикса и взглянем на показатели при включенном кешировании.
Показатели умного фильтра с кешированием.png

А теперь сбросим кеш (или сделаем запрос на фильтрацию).

Показатели умного фильтра без кеширования.png

Это при том, что на странице был увеличен разрешенный объем памяти до 1 Гб, так как с 512 Мб памяти фильтр не мог корректно закончить свою работу.

Сравним с показаниями обычного фильтра в аналогичных ситуациях:
Глупый фильтр с кешированием.png

Глупый фильтр без кеширования.png

Разница налицо. Компонент работает, бессовестно тратя ресурсы и время.

7 секунд, 2 из которых на запросы к БД на хорошем выделенном сервере — много!

Давайте все просто перепишем? Будет летать!

Основная причина перерасхода времени и денег -- 
преждевременная оптимизация и добавление функций

Первое приближение

Кастомизируем компонент простого фильтра и научим его выбирать не все свойства, а только те, которые наполнены у товаров данного раздела. Для этого нужно предварительно узнать, у скольких товаров каждое конкретное свойство хранит значение. Если, например, число товаров, у которых заполнено свойство «Объем», равно нулю, то и получать это свойство не нужно.

Теперь, фильтр стал выглядеть более компактно (т.к. пропали неиспользуемые свойства), а показатели изменились до следующих значений:

Полуумный фильтр с кешированием.png
Полуумный фильтр без кеширования.png

Да, запросов стало больше, и время пострадало, но все равно меньше чем умный фильтр. Да и за рамки 512 МБ памяти не вылезли.

Второе приближение

А теперь скроем все значения свойств, для которых товаров нету и сравним показатели. Потребуются более тяжелые запросы — по каждому свойству нужно будет получать не у скольких товаров оно заполнено, но и сами значения. То есть, нам мало знать, что свойство «Ширина» используется у тридцати товаров — нам нужно знать, чему ширина у этих товаров равна.

Все, что нужно изменить относительно первого приближения — выдергивать не общее число товаров, а значения.
Почти умный фильтр с кешированием.png

Почти умный фильтр без кеширования.png

Как видно, число запросов практически не изменилось, но сильно пострадало время выполнения. Время тратится на разбор огромных массивов данных, полученных из БД и на отсев ненужных значений. В качестве бонуса — теперь для числовых свойств (таких как цены, размеры, объем и т.п.) известны диапазоны, которые можно вывести как подсказку ищущему.

Если сравнить с показателями штатного умного фильтра (7,3 секунды, 227 запросов, требует 1 гигабайт памяти для работы), то выигрыш, безусловно, налицо.

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

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

Когда у вас начнутся проблемы с производительностью или памятью — будете их решать. Это вполне возможно, и способов много.

Итоги. Когда и кому нужен подбор по параметрам?

Умный подбор по параметрам нужен, если
  • товары в разных группах имеют разные свойства;

  • покупатель хочет искать, перебирая параметры;

  • товаров больше 20 в каждой группе;

  • параметров в каждой группе не более 10.

Умный подбор по параметрам не стоит делать, если
  • вы не в силах заполнить качественно значения всех характеристик всех товаров;

  • товаров мало, и их проще увидеть глазами, чем разбираться в логике фильтра.

Владельцы и разработчики магазинов, помните, что клиенту нужен товар, а не фильтр. Делайте как Apple, и вам повезет.

png;base6435eae926c52ea43a.png



Комментарии (2)

...
  • Денис
  • 04.03.2014 13:55:48
Степан, а если вынести параметры товаров и перечень идентификаторов в служебные поля разделов? Точно также, как обычно выносят цены торговых предложений в поля товара? Таким образом, тяжесть запросов мы перекладываем на момент занесения и редактирование товара. Как считаете?
...
Денис, это интересная и хорошая идея. Несмотря на небольшую денормализацию данных, получится выигрыш по производительности для обычного посетителя. Процедура пересчета служебных полей раздела должна будет вызываться на событие добавления, обновления и удаления товара, его цен, торговых предложений, количества товара на складе. Потенциально слабым местом представляется случай, когда для обновления свойств товара используют метод SetPropertyValuesEx и подобные - которые события не вызывают.
Стоит попробовать, спасибо за идею!