Умный фильтр показывает отбор товаров по заданным свойствам. Например, искать белый айфон оптимально по бренду «Apple» и цвету «белый». Раньше, обрабатывая запрос, фильтр перебирал все товары каталога. Процесс занимал до 10 секунд и более. Фасета заранее просчитывает и составляет варианты запросов, сохраняет в системе и выдает по запросу. Она в несколько раз сокращает время работы фильтра, снижая нагрузку на ваш магазин.
Героев нужно знать в лицо
Сложнейшую работу в фасетном фильтре выполнили:
Максим Смирнов (гениальная разработка фасеты в один клик):
Анна Овчинникова (няшный js в выборе свойств и адаптивность фильтра):
[spoiler]
Устанавливаем обновление
Обновление доступно клиентам и партнерам, которые устанавливают бета-версии обновлений.
Создаем фасетный индекс
После установки обновления система предложит «создать фасетный индекс». На экране появится зеленая плашка, знакомая пользователям нашего продукта:
Переходим из плашки к созданию индекса. Если вы закрыли данную плашку, и она больше не появляется, найти создание индекса можно по пути:
Рабочий стол -> Контент -> Инфоблоки -> Фасетные индексы
Выбираете нужный каталог и нажимаете «Создать». В моем случае это два инфоблока, связанных между собой: основной и инфоблок торговых предложений. Создаю индексы для обоих.
Индексы созданы, можно расходиться. При добавлении нового товара в каталог индексы работают автоматически. Вот в чем гениальность реализации от Максима Смирнова - вы нажимаете кнопку, а дальше «все работает само».
Будьте внимательны! Действие для объемных каталогов с большим количеством свойств и элементов может занять продолжительное время. Создавайте фасетный индекс в часы наименьшей нагрузки на ваш магазин.
Умный фильтр 1.0
Дальше в игру вступает визуальная часть, созданная Анной. Нужно произвести некоторые настройки.
Давайте посмотрим, как выглядит фильтр после установки дистрибутива 14,5 версии продукта:
В нем нет фильтрации по размерам и цветам. Они отсутствовали, так как их появление в фильтре могло быть представлено только чек-боксами или числовыми диапазонами - это не эффективно. Также в фильтре не могли использоваться свойства с типом «справочник» (на их основе были сделаны цвета, что еще больше сужало схему выбора).
Красота умного фильтра 2.0
Давайте посмотрим, что появилось в настройке свойств инфоблока:
В 14,5 версии продукта была только одна галочка «Показывать в умном фильтре». Вы могли или добавить свойство в умный фильтр или не добавлять. Но повлиять на визуальное представление свойства было невозможно.
С 15 версии появилась галочка «Показывать развернутым». При ее выборе свойство отображается в публичной части в развернутом виде:
На скриншоте свойства «Производитель» и «Артикул» показаны в свернутом виде, свойство «Материал» - в развернутом. (У данного свойства стоит галочка «Показывать развернутым»).
Также появилась возможность выбирать вид отображения свойства:
Список меняется в зависимости от выбранного типа у свойства. В первом случае у свойства выбран тип «справочник», во втором «список».
Давайте добавим свойство «Бренд» в умный фильтр:
Чтобы свойство появилось в умном фильтре, и вы могли задать вид, в котором будет показано свойство необходимо включить опции «Показывать на странице редактирования элемента» и «Показывать в умном фильтре» (установить галочки).
«Выпадашка» - «Вид в умном фильтре» дает возможность (в зависимости от типа свойства) задать, как будет выглядеть ваше свойство в умном фильтре.
Если вы хотите показывать пользователю при входе свойство в развернутом виде, установите галочку напротив «Показать развернутым».
Фильтр изменился. Мы вывели свойство «Бренд» с типом «Справочник», выбрали его представление в виде «Флажков с названиями и картинками» и установили опцию «Раскрывать свойство при входе пользователя».
Свойства «Цвет» и «Размер» тоже хочется видеть в умном фильтре.
Не буду показывать на скриншотах, как меняются настройки, покажу результат:
В виде «выпадашек» я вывел свойства цвета (с картинками и названиями) и размер одежды.
Вы можете изменить положение свойства в фильтре(поднять или опустить), меняя их сортировку в списке.
Обратите внимание! Когда вы добавляете или убираете свойство в умном фильтре, необходимо повторно произвести создание фасетного индекса.
Функциональный выбор цен
Хотелось бы обратить ваше внимание на новый вид контрола для цен. Для демонстрации я записал небольшое видео:
У контрола "выбора сумм" появилось четыре цвета. Обозначение:
- светло серый – в диапазоне нет подходящих товаров
- темно серый – цвет показывает сектор наличия товаров в выбранном диапазоне (вы можете сузить диапазон цен)
- светло синий – товар для отбора находится за диапазоном выбора
- темно синий – в выбранном диапазоне есть товары
Изменился вид контролов диапазона. В старом фильтре они были круглыми, их нельзя было приближать, и диапазон суммы мог оставался слишком широким. Новые контролы могут сойтись вплотную, регулируя минимальные диапазоны. Также их можно перемещать одновременно.
Приятного вам использования. Не забывайте в комментариях задавать свои вопросы.
.
а я говорю про стабильные обновления для боевых сайтов!
Добавлено: iblock 15.0.5 вышел в релиз. В настройках свойства типа Справочник вижу варианты с картинками.
Юрий, расскажите, пожалуйста, про техническую сторону фасета.
Да, при появлении нового свойства, требуется создание индекса, иначе откуда будут браться данные для вывода, вся суть фасеты, в просчитанных данных, для всех комбинаций.
Покажите, пожалуйста, скрин, где должна быть эта плашка? Я вижу только отображение индекса в "Рабочий стол - Контент - Инфоблоки - Фасетные индексы", причём там ни удалить, ни пересоздать нельзя
upd:
выяснилось, что кнопки эти появляются только если у хотя-бы одного иблока значение PROPERTY_INDEX == "I"....
То есть пока система не решит, что можно бы переиндексировать - переиндексировать никакой возможности нет. Зачем так сделано?
Например при выгрузке товаров из 1с при деактивации/удалении товара не обновляется максимальная цена в фасете мин-макс цены (если товар и был по максимальной цене). То есть при удалении товаров УЖЕ нужно переиндексировать всё заново... однако в интерфейсе кнопка переиндексации в этом случае отсутствует.
Либо как в вашем скриншоте, это будут баннеры, выведенные компонентом новостей, которые сообщают какие скидки есть и когда будут, без конкретного списка товаров. Что можно сделать и сейчас.
Предположим сделали мы баннер. Сказали в нем "зимняя скидка 50%".
Как покупателю увидеть список всех товаров, к которым применена эта скидка?
Или как в рассылке дать ссылку сразу на страницу со списком товаров только к этой скидке?
Если такого списка нет - эффективность акции ниже. Особенно если каталог товаров большой.
Речь про про битриксный функционал, а не про частные решения которые можно сделать.
Отличный пример магазин Вилдберриес
На лету фильтровать все товары, которые к скидке относятся, вряд ли возможно поэтому я и спросил про фасету.
Если посмотреть таблицу фасетов этого инфоблока, то у элементов без раздела FACET_ID тоже нулевой.
Как быть с этой проблемой?
Спасибо за бдительность!
Исправление этой проблемы выйдет в обновлении iblock 15.0.5. При необходимости получить это исправление можно обратиться в ТП. Основной причиной является то, что фасетный индекс сейчас не может работать без указания раздела. Индекс будет доработан, но несколько позже.
А цены торговых предложений в фильтре уже работают?
Спасибо за бдительность!
Например: "размер 60", он есть у товара в торговых предложениях, но он не активен.
3) Если отчистить каталог, и через API вставить товары и торговые предложения, то фильтр ничего не показывает!!! Необходимо в настройках каталога снимать все галки со свойств участвующих в умном фильтре и ставить обратно!
4) При установке обновлений, даже после создания фасетных индексов, не создаются правильные (на сколько это возможно) комбинации в умном фильтре. Лечится так же как и в п.3.
Все компоненты стандартные.
Очень жаль, что люди тратят время на функционал типа вывод галочек и всякую требухню необходимую только для битрикса из коробки. При смене дизайна все равно никто это не использует.... А вот нужный функционал так и не сделан...
Все товары удалили через админку.
После через API вставили товар, потом торговые предложения к этому товару с их свойствами. Новые свойства не создавались, заполнялись уже существующие.
Далее заходим в публичной части с отключенным кешем в каталог, где есть умный фильтр. В фильтре пусто.
Потом в админке снимает все галки с "показывать в умном фильтре", сохраняем. Потом ставим их обратно. И в умном фильтре в публичной части все появилось.
Вариант решения - после вызова CIBlockElement::SetPropertyValuesEx делать вызов
Например, Маркетплейс?
Очень странно, что там фильтр вышел еще с завода "не умный". Когда он поумнеет?
Да и подбор партнеров или типов проектов на сайтах клиентов сделать можно влегкую через умный фильтр.
В идеале, такой функционал сразу внедрять не только в коробки, которыми будут пользоваться другие, но и на свои проекты.
А то сейчас как в шутке"я не ем продукцию своей фабрики".
Если убрать фильтр по секции (нужен сквозной фильтр с первого уровня каталога), то запрос на получение данных (SELECT F.FACET_ID ,F.VALUE ,MIN(F.VALUE_NUM) MIN_VALUE_NUM ,MAX(F.VALUE_NUM) MAX_VALUE_NUM ...) занимает ~9 секунд. Как-то не очень.
Если выкинуть из запроса подключения таблиц b_iblock, b_lang, b_iblock_element запрос занимает уже ~4 секунды. Можно ли сделать галки в настройках компонента фильтра для параметров ACTIVE_DATE и CHECK_PERMISSIONS? На обычном каталоге товаров совсем не нужно проверять активность этих элементов и права к ним, а на производительности это сказывается.
Далее, если добавить к таблице индекс по полю FACET_ID, то время запроса сократится до ~2 секунд. Вопрос, такой индекс не создан сразу по какой-то определённой причине?
вроде бы и функционал был заявлен ещё в середине осени (кажется, октябрь), обещали выпустить СТАБИЛЬНУЮ версию до конца ноября, но эта версия вышла только в конце января. Ок, но одно непонятно - почему всё ещё глючит???
Установил обновления - часть товаров в умном фильтре вообще пропала, где-то не видны свойства... Перечитал статью, перепроверил, не работает. Уже устал писать в техподдержку, но придётся опять.
И почему ответ техподдержки идет вразрез с написанным и показанным тут видео?
На каком объеме данных тестировалось? У нас например в секции 16 000 товаров. На обычном фильтре работает 150 секунд. Решит ли это нашу проблему.
Хотя я считаю не оптимально делать каталог в котором на ветке уровня содержится 16 000 элементов (может как то их побить на подразделы), при большой посещаемости этакий ддос собственного магазина.
Редакция 15.0.6
там 3 шаблона и не один не работает.
Такая проблема не только у меня, вот, целый топик
Например, свойство чекбокс "Не показывать снятые с производства" по умолчанию включено. Траффик по товара ещё идет, по этому из каталога товары не удалишь, но в наличие нет, по этому основной массе покупателей показывать этот товар смысла нет.
Или например, свойство "Показывать товар"
В Наличии - по умолчанию, показываются товары в наличие в интернет магазине
Есть в Магазине - при необходимости можно посмотреть товары которые есть в офлайн магазинах
Любой - все товары
(Как реализовано в ситилинке)
Решается только переделкой компонента умного фильтра, то есть добавлением нужных параметров фильтрации в $arElementFilter в компоненте. Нужно либо автоматом брать значения фильтра уже установленного для раздела, либо дать возможность в параметрах передавать массив с дополнительным фильтром.
3. В зависимости от типа свойства в этих полях разные значения (может быть ссылка на код значения, либо ссылка на строку таблицы *_val)
Вообще по фасетному поиску был доклад Максима Смирнова на конференции партнёрской -
как итог: часть товаров никак не обзаведется индексом, хотя у всего инфоблока ! назначены фасетные индексы, и никак фасетные индексы выключить не возможно. Единственный вариант передать принудительно в getList через arrFilter 'Active'=>'N'
Но я вас обрадую еще больше! Товары пропадают не только из поиска. Они еще из секций (компонент catalog.section) пропали.
Активные товары. Которые были раньше на сайте. Взяли и пропали.
Выхода из ситуации пока нашел 2:
1. фильтр с "ACTIVE" => "", "ACTIVE" => "N"
2. Таблица b_iblock, ищем нужный инфоблок, в нем находим PROPERTY_INDEX, убираем значение Y, (оставляем пустым) сохраняем.
После этого механизм фасетов отключается для данного инфоблока. Повторить нужное количество раз.
Проверено на версии 15.0.6.
Обычный CIBlockElement::Update сильно вешает систему.
"строка значения свойств" => строка "список id товаров"
да?
вы это в таблице кешируете и выборка по ключу быстро отрабатывает при большом числе записей?
кеширование в файл думаю не реально, будет 1000000 файлов.
Половина товаров на сайте из каталога пропала. В чем проблема?
Мужики, вы чего? Бажный код помещать в листинг обновлений и объявлять это "фичей". Вас заочно уже 2-3 недели проклинают.
Преамбула: имеем информационный блок iblock id 11. Щелкнули волшебную кнопку, которая добавила фасетные индексы. При добавлении новых разделов в инфоблок (и АКТИВНЫХ товаров в этот раздел) компонент bitrix:catalog.section выводит пустые списки именно на новых разделах. Соответствующие фасетные индексы для таблицы b_iblock_11_index при создании элементов не добавляются.
Решение: кушайте, не обляпайтесь, или фасетные индексы НЕ ВОЗМОЖНО отключить. Потому что бажный код был включен ! прямо в "комбайн" запросов JOIN для выборки CiblockElement::GetList. Чтобы товары, которые "пропали" из-за того, что им не назначены фасетные индексы, появились, остается только финт ушами (добавить в фильтр 'ACTIVE'=>'" или же 'ACTIVE'=>"N";).
В итоге bitrix для раздела с id 66, созданного штатными средствами битрикса, содержащего 34 активных товара, находящегося в инфоблоке с фасетными индексами с id 11 формирует следующий запрос к базе данных:
и возвращает 0 элементов! 0 элементов !
а при установке в фильтре флага 'ACTIVE'=>'' (это единственный метод "избежать" join ! на фасетные индексы!
34 элемента (естественно ! что у всех элементов флаг ACTIVE = 'Y' в панели управления ! )
(но у таких разделов умный фильтр "пропадает")
Bitrix 15.0.6. Малый бизнес.
Жду решения этой проблемы. Благодаря навязанным фасетным индексам теперь приходится выбирать: или отказаться от деактивации товаров на сайте, так как это единственный способ на сегодня отрубить эти бажные фасетные индексы, или же ! отказаться от добавления новых разделов и потерять часть товаров, которые при добавлении/обновлении штатными средствами почему - то "пробегают лесом" мимо связанных таблиц фасетных индексов.
Это вообще как понимать? Вредительство и саботаж.
Приносим извинения за причинённые неудобства.
Спасибо за привлечения внимания к проблеме.
Таблица b_iblock, ищем нужный инфоблок, в нем находим PROPERTY_INDEX, убираем значение Y, (оставляем пустым) сохраняем.
После этого механизм фасетов отключается для данного инфоблока. Повторить нужное количество раз.
А для скорости исправления, можно писать в Техническую Поддержку, ну и конечно на ваше усмотрение дублировать тут, это даст дополнительное внимание к проблема.
Юрий, а планируется ли вообще, и если да то когда, объяснить умному фильтру что 100 рублей меньше $90 и сделать опцию в настройках по фильтрации в 1 задаваемой валюте со всеми вытекающими?
Мы продаем товары, закупаемые в разной валюте и для нас это очень важно
Мы продаем товары, закупаемые в разной валюте и для нас это очень важно
почти 3 месяца прошло, а воз и ныне там.
Судя по коду попытки фильтрации по цене в одной валюте были, но как видно, не очень успешны.
Опишу такой кейс: есть товары где цена как в рублях так и в долларах.
установив диапазон цены только в поле "от" или только в поле "до" - все работает ок.
Но стоит только установить значение в оба поля (например от = 299 до = 300) то выводятся товары с ценой прописанной в долларах.
Вывод настроен в рублях и выводит товары со стоимостью в районе 18 000 руб. (т.е. как раз около 300 долларов по курсу 60 за 1 )
Дайте ответ, когда почините?
Покопались в базе ibloc-ов, выяснилось что из-за импорта номенклатуры из разных источников бренд в свойствах товаров написан в разных регистрах. Отдельно есть таблица с брендами, где хранится название бренда и соответствие его значения полю в XML. Получается, что когда написание бренда в карточке и в таблице брендов не совпадает по регистру, то выводится просто пустое поле бренда, в умном фильтре галочка без значения, а в карточках не отображаются некоторые бренды.
Судя по всему виной всему яваскрипт, который чувствителен к регистру, но не уверен.
потому что те программисты, которые делали сайт понимают в этом продукте еще меньше меня, как ни странно). Я хочу сделать некоторые свойства, которые участвуют в фильтрации, выпадающим списком. Я настраиваю этот пункт в отображениях раздела и даже пробовала в самом свойстве, но на сайте эти изменения не отображаются. Как быть? Может где-то еще надо вносить изменения?после сортировки свойств на группе ( телевизоры например ) нажимаю применить, сохранить, свойства опять разбросаны, как сделать нужную мне сортировку и сохранить все изменения.
\Bitrix\Iblock\PropertyIndex\Manager::updateElementIndex(ID_инфоблока, ID_элемента); -то импорт будет длиться вечность, нет ли какого метода по окончании импорта обновить фасетный индекс сразу для всего какталога?
Дано: Каталог 13 тыс. товаров, интеграция с 1С, идет наполнение каталога. Процесс долгий и наверное бесконечный. После того как прилетают товары с новыми значениями свойств, битрикс требует пересоздать фасетный индекс. Пока это не произойдет отображаются пустые страницы каталога. Ситуация повторяется с различной периодичностью, но иметь лежащий на боку сайт, пока кто-то не заметит и не пересоздаст ВРУЧНУЮ фасетный индекс недопустимо.
Цель: zero level administration
Вопрос: имеется ли возможность через события битрикс контролировать состояние фасетного индекса и в случае необходимости его пересоздавать?
модуль iblock - 15.5.12
Не добавляются строки с ценами в таблицу "b_iblock_1_index", тестировалось для новых и существующих записей b_iblock_element
Если в HL связка по привязка к элементу HL это вообще не учитываться а жаль.
Какие есть варианты работы с умным фильтром когда у заказчика много очень вариантов свойства?
Очень интересны наработки когда свойств от 10 000 и более.
Есть номенклатура товаров: ~25 000 товаров, ~1 000 каталогов/подкаталогов.
Допустим, для умного фильтра хочу создать свойство "Цвет". Цвет есть у множества товаров разных подкаталогов.
Как лучше с точки зрения быстродействия сайта/фасетного индекса/умного фильтра:
а) создать одно свойство "Цвет" для всей номенклатуры: с сотней значений: белый, черный, синий и т. д.
б) создать для каждого необходимого подкаталога (допустим, их будет сотня) отдельное свойство "Цвет": и для каждого подкаталога значений свойства будет не больше десятка.
То есть, какая "матрица" быстрее будет работать: "одно свойство/сто значений" или "сто свойств/десять значений"?