Разработка фильтрации по рейтингу и отзывам 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка фильтрации по рейтингу и отзывам 1С-Битрикс
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    944
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

Разработка фильтрации по рейтингу и отзывам 1С-Битрикс

Вы ведёте каталог с десятками тысяч товаров и отзывов. Клиенты хотят отфильтровать товары с рейтингом от 4.5 звёзд или только те, у кого есть отзывы. Стандартный умный фильтр 1С-Битрикс не справляется — он оперирует только свойствами инфоблока и ценой, а рейтинг — вычисляемая величина, хранящаяся в сторонних таблицах (blog, vote, custom). Без правильной реализации каждый запрос с JOIN добавляет 0.5–1.5 секунд к времени загрузки страницы. Мы — команда с опытом коммерческой разработки более 5 лет, реализовали более 50 проектов, включая каталоги с тысячами товаров. UF-поля — проверенный метод, который даёт фильтрацию без JOIN и без переписывания стандартного компонента. Расскажем, как это работает на практике.

Почему умный фильтр не видит рейтинг?

Потому что он не знает про поля UF_RATING и UF_REVIEW_COUNT. Система фильтрации работает только со свойствами инфоблока, а UF-поля — это свойства других сущностей. Но если добавить эти UF-поля к элементу инфоблока (через ENTITY_ID='IBLOCK_ELEMENT'), умный фильтр начнёт их видеть и использовать. Это избавляет от необходимости переопределять компонент или писать кастомные запросы.

Как добавить UF-поля для фильтрации рейтинга?

Используем связку UF-поля + обработчик событий или агент. Это даёт высокую производительность (фильтрация без JOIN) и гибкость (фильтр по любому диапазону).

Структура UF-полей для рейтинга

// Создание UF-полей при установке
$userTypeManager = \Bitrix\Main\EventManager::getInstance();

// UF_RATING - средний рейтинг
\CUserTypeEntity::Add([
    'ENTITY_ID'    => 'IBLOCK_' . CATALOG_IBLOCK_ID . '_SECTION',
    'FIELD_NAME'   => 'UF_RATING',
    'USER_TYPE_ID' => 'double',
    'MANDATORY'    => 'N',
    'SHOW_FILTER'  => 'S',
    'SETTINGS'     => ['PRECISION' => 1, 'MIN' => 0, 'MAX' => 5],
]);

// UF_REVIEW_COUNT - количество отзывов
\CUserTypeEntity::Add([
    'ENTITY_ID'    => 'IBLOCK_' . CATALOG_IBLOCK_ID . '_SECTION',
    'FIELD_NAME'   => 'UF_REVIEW_COUNT',
    'USER_TYPE_ID' => 'integer',
    'MANDATORY'    => 'N',
    'SHOW_FILTER'  => 'S',
]);

Обновление рейтинга при добавлении отзыва

AddEventHandler('blog', 'OnAfterPostAdd', 'updateProductRating');
AddEventHandler('blog', 'OnAfterPostUpdate', 'updateProductRating');

function updateProductRating($id, $fields)
{
    // Получение ID товара из связи с отзывом
    $productId = getProductIdFromPost($id);
    if (!$productId) return;

    // Пересчёт рейтинга
    $reviews = getProductReviews($productId);
    $count = count($reviews);
    $avg = $count > 0
        ? array_sum(array_column($reviews, 'rating')) / $count
        : 0;

    // Обновление UF-полей элемента
    CIBlockElement::SetPropertyValues($productId, CATALOG_IBLOCK_ID, [
        'UF_RATING'       => round($avg, 1),
        'UF_REVIEW_COUNT' => $count,
    ]);
}

Фильтрация по минимальному рейтингу

// Применение фильтра рейтинга
if (!empty($_GET['min_rating'])) {
    $minRating = floatval($_GET['min_rating']);
    if ($minRating >= 1 && $minRating <= 5) {
        $arFilter['>=UF_RATING'] = $minRating;
    }
}

// Фильтр "только с отзывами"
if (!empty($_GET['has_reviews'])) {
    $arFilter['>UF_REVIEW_COUNT'] = 0;
}

UI: звёздный рейтинг-фильтр

$currentMinRating = floatval($_GET['min_rating'] ?? 0);
?>
<div class="filter-block filter-block--rating">
    <h3 class="filter-block__title">Рейтинг</h3>
    <div class="rating-filter">
        <?php for ($stars = 5; $stars >= 1; $stars--): ?>
        <label class="rating-option <?= $currentMinRating == $stars ? 'is-active' : '' ?>">
            <input type="radio" name="min_rating"
                   value="<?= $stars ?>"
                   <?= $currentMinRating == $stars ? 'checked' : '' ?>>
            <span class="stars">
                <?php for ($i = 1; $i <= 5; $i++): ?>
                <svg class="star <?= $i <= $stars ? 'star--filled' : 'star--empty' ?>"
                     viewBox="0 0 24 24" width="16" height="16">
                    <polygon points="12,2 15.09,8.26 22,9.27 17,14.14 18.18,21.02 12,17.77 5.82,21.02 7,14.14 2,9.27 8.91,8.26"/>
                </svg>
                <?php endfor; ?>
                <span class="stars-label">от <?= $stars ?></span>
            </span>
        </label>
        <?php endfor; ?>
    </div>

    <label class="filter-toggle">
        <input type="checkbox" name="has_reviews" value="1"
               <?= !empty($_GET['has_reviews']) ? 'checked' : '' ?>>
        <span>Только с отзывами</span>
    </label>
</div>
<?php

Сортировка по рейтингу

Фильтр по рейтингу органично сочетается с сортировкой:

$sortField = htmlspecialchars($_GET['sort'] ?? 'SORT');
$sortOrder = in_array(strtoupper($_GET['order'] ?? 'ASC'), ['ASC', 'DESC'])
    ? strtoupper($_GET['order'])
    : 'ASC';

$arSort = match ($sortField) {
    'rating'  => ['UF_RATING' => 'DESC'],
    'reviews' => ['UF_REVIEW_COUNT' => 'DESC'],
    'price'   => ['CATALOG_PRICE_1' => $sortOrder],
    default   => ['SORT' => 'ASC'],
};

Почему UF-поля быстрее JOIN?

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

Подход Время фильтрации (15 000 товаров) Сложность реализации Гибкость настройки
UF-поля с индексом 0.2 сек Средняя Высокая (любые диапазоны)
JOIN к кастомной таблице 1.5 сек Высокая Средняя (только точное совпадение)
Стандартный умный фильтр Невозможно

Согласно документации 1С-Битрикс, UF-поля могут участвовать в фильтрации при установке SHOW_FILTER = 'S' (см. официальное руководство).

Пошаговая реализация фильтрации по рейтингу

  1. Создание UF-полей. Добавьте UF_RATING (double) и UF_REVIEW_COUNT (integer) с SHOW_FILTER='S'.
  2. Разработка обработчика событий. В обработчике OnAfterPostAdd пересчитывайте средний рейтинг и количество отзывов.
  3. Настройка фильтра в компоненте. Укажите параметры FILTER_NAME и используйте UF-поля в фильтре.
  4. UI-фильтр. Сверстайте звёздный интерфейс с радио-кнопками для минимального рейтинга.
  5. Сортировка. Добавьте опцию сортировки по UF_RATING и UF_REVIEW_COUNT.

Сравнение методов обновления рейтинга

Метод Производительность Сложность Когда использовать
Обработчик событий (OnAfterPostAdd) Высокая (мгновенно) Средняя Отзывы публикуются сразу
Агент с периодичностью (каждые 30 мин) Средняя (отложенно) Низкая Отзывы проходят модерацию
Ручной пересчёт Низкая (только по запросу) Низкая Мало отзывов, тестирование

Кейс: маркетплейс электроники

Наш клиент — интернет-магазин электроники с 15 000 товаров. Внедрили звёздный рейтинг-фильтр и сортировку по рейтингу. UF-поля обновляются через агент каждые 30 минут (не по событию, так как отзывы проходят модерацию). После модерации — ручной пересчёт через кнопку в административной панели. Результат: товары без отзывов (новинки) скрыты по умолчанию в фильтре, показываются при снятии галочки «Только с отзывами». Конверсия из фильтрованного каталога (рейтинг 4+) на 23% выше среднего. Проект сдан в срок, заказчик доволен — мы гарантируем надёжность и поддержку после запуска.

Типичные ошибки при реализации

  • Забывают установить SHOW_FILTER='S' — без этого UF-поля не участвуют в фильтрации.
  • Не индексируют UF-поля — на больших каталогах падает производительность.
  • Используют точное совпадение вместо диапазона — рейтинг редко бывает целым числом.
  • Не обновляют рейтинг при удалении отзыва — данные застаиваются.

Что входит в работу

  • Создание UF-полей и настройка индексов.
  • Разработка обработчика событий или агента для пересчёта рейтинга.
  • Вёрстка звёздного UI-фильтра с адаптивом.
  • Сортировка по рейтингу и отзывам.
  • Оптимизация кэширования для высокой нагрузки.
  • Документация и краткое обучение для администраторов.

Сроки и стоимость

Фильтр по UF-рейтингу с простым UI — от 1 рабочего дня. Полная реализация с пересчётом рейтинга, звёздным UI, сортировкой и агентом — 2–3 рабочих дня. Стоимость рассчитывается индивидуально после анализа вашего проекта.

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

Подробнее о возможностях UF-полей читайте в официальной документации. А общую информацию о платформе — на Wikipedia.

Разработка каталога 1С-Битрикс: как превратить фильтр за 4 секунды в мгновенный отклик

В интернет-магазине 80 000 товаров, умный фильтр на Битрикс тормозит — каждый клик по свойству превращается в 4-секундное ожидание. Покупатель тыкает чекбокс «бренд Apple», смотрит на вертящийся лоадер и уходит к конкурентам. Конверсия падает на 20%. Это знакомая боль. Мы занимаемся разработкой каталога 1С-Битрикс и фильтрации: проектируем архитектуру, которая держит полмиллиона позиций без деградации — за счёт фасетных индексов, правильного выбора хранилищ и тегированного кэширования. Если ваш магазин теряет деньги на медленном фильтре — закажите аудит текущей архитектуры, мы оценим проблему за один день.

Как инфоблоки влияют на производительность каталога?

Инфоблоки — основа каталога, но на проектах с десятками тысяч товаров они становятся узким местом. Стандартный bitrix:catalog.smart.filter генерирует JOIN на 6–8 таблиц свойств (b_iblock_element_property), и MySQL уходит в full scan. Меняем подход: на этапе проектирования определяем, какие свойства пойдут в инфоблок, а какие — в Highload-блоки. Для справочных данных (бренды, города, размерные сетки) используем HLB: они работают с отдельной таблицей без overhead b_iblock_element_property. Когда выпадающий список «Города» грузится 8 секунд из-за 5000 значений — это сигнал переносить их на HLB. Каталог на 80 000 товаров с фильтром за 4 секунды теряет около 1,2 млн рублей в год из-за ухода клиентов — такую экономию даёт правильная архитектура. Свяжитесь с нами, чтобы прикинуть выгоду для вашего проекта.

Что такое фасетный индекс и почему он важен?

Основная производительность кроется здесь. Без фасетного индекса каждый клик по фильтру — SQL-запрос с JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price и ещё паре таблиц. На 100 000 товаров такой запрос выполняется 2–4 секунды. С фасетным индексом — 30–80 мс. Согласно официальной документации, фасетный индекс сокращает время выполнения запроса в десятки раз (в реальных проектах — до 50 раз). Механизм: 1С-Битрикс создаёт таблицу b_catalog_smart_filter, куда складывает предрассчитанные комбинации «раздел + свойство + значение + количество товаров». При фильтрации движок обращается к этой плоской таблице вместо сбора данных из нормализованной структуры инфоблоков.

При настройке фасетного индекса часто допускают одни и те же промахи. Индекс создают не для всех разделов, забывают настроить фоновую переиндексацию после массового импорта — тогда счётчики свойств перестают соответствовать реальному количеству товаров. Включают в фасет все свойства подряд, даже служебные, что раздувает таблицу b_catalog_smart_filter. На каталогах свыше 300 тысяч позиций её размер может превышать гигабайт — без мониторинга через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обойтись. Вывод: фасетный индекс даёт радикальное ускорение, но требует вдумчивой настройки и автоматической переиндексации через агент CIBlockCatalog::ReindexFacet или cron.

Почему Highload-блоки быстрее инфоблоков для справочников?

Критерий Инфоблок (IB) Highload-блок (HLB)
Хранение свойств Таблица b_iblock_element_property Отдельная плоская таблица на каждый HLB
Скорость фильтрации на 50 тыс. товаров ~500–800 мс (с фасетом) ~80–150 мс (без фасета)
Поддержка SEO (URL, шаблоны) Полная Отсутствует (только справочники)
Рекомендуется для Товары, разделы, основные свойства Справочники (бренды, города), пользовательские данные
Когда инфоблоки предпочтительнее HLBHighload-блоки не формируют SEO-URL и не имеют визуального редактора. Если справочник должен иметь отдельные страницы (например, бренды с уникальными H1), используйте инфоблоки. HLB — для сугубо служебных данных, не требующих индексации.

На практике лучшая архитектура — гибридная. Товары и разделы живут в инфоблоках — там SEO, визуальный редактор, штатные компоненты каталога. А справочные свойства с тысячами значений переносим в Highload-блоки. Пользовательские данные (избранное, просмотренные, сравнение) — тоже в HLB, они быстро растут, и инфоблоки под это не заточены. Хотите узнать, какую архитектуру выбрать для вашего каталога? Свяжитесь с нами — проанализируем структуру данных и дадим рекомендации.

SEO-фильтры: как получить ЧПУ и не попасть под фильтр Яндекса?

Стандартный фильтр генерирует ?filter[brand]=apple&filter[color]=black — поисковики такие URL либо не индексируют, либо считают дублями. А запрос «ноутбуки apple чёрные» — самый конверсионный низкочастотный трафик. Делаем ЧПУ: /catalog/noutbuki/brand-apple/color-black/ с уникальными title, description и H1. Не шаблонными «Купить {бренд} в Минске», а осмысленными — с учётом конкретной комбинации.

  • Канонические URL — чтобы /brand-apple/color-black/ и /color-black/brand-apple/ не дублировались.
  • Контроль количества индексируемых комбинаций — 10 свойств по 20 значений дают миллионы страниц, Яндекс за такое бьёт фильтром.
  • Автоматическая sitemap для SEO-страниц фильтрации.
  • Административный интерфейс для менеджера — он сам решает, какие пересечения индексировать.

Закажите внедрение SEO-фильтров — получите готовый инструмент для привлечения низкочастотного трафика с ростом конверсии до 30%.

Какие методы дают ощутимый прирост производительности?

  • Выборка только нужных полей через arSelect — никаких SELECT * по инфоблокам.
  • Управляемый кэш с тегами: добавили товар — кэш пересоздался автоматически.
  • Композитный кэш для анонимов: TTFB < 100 мс, HTML отдаётся без запуска PHP.
  • Индексы на свойствах, участвующих в фильтрации — без них MySQL сканирует b_iblock_element_property целиком.
  • Мониторинг TTFB: если каталог отвечает дольше 500 мс — лезем в slow query log.

Что входит в комплексную разработку каталога на 1С-Битрикс

Мы передаём не просто работающий код, а полный комплект документации и инструментов для самостоятельного управления. В deliverables входят:

  • Аудит текущей архитектуры каталога и фильтрации.
  • Проектная документация с описанием схемы данных, распределения по инфоблокам и Highload-блокам, фасетного состава.
  • Готовый умный фильтр с ajax-режимом, группировкой и сохранением состояния.
  • Настроенный фасетный индекс с cron-переиндексацией.
  • SEO-фильтры с ЧПУ, уникальными метатегами, каноникалами и sitemap.
  • Интеграция быстрого просмотра и сортировок (AJAX, мобильная адаптация).
  • Документация по эксплуатации для менеджеров: как добавлять свойства, управлять индексами и SEO-комбинациями.
  • Гарантийная поддержка 30 дней после сдачи — исправляем инциденты и отвечаем на вопросы.

Как мы разрабатываем каталог: пошаговый план

Мы не просто ставим компоненты. Процесс включает:

  1. Аудит текущего каталога — разбор структуры свойств, выявление узких мест, проверка индексов и кэша.
  2. Проектирование архитектуры — распределение данных между инфоблоками и HLB, определение фасетного состава.
  3. Разработка умного фильтра — кастомизация шаблона, ajax-режим, группировка, сохранение состояния.
  4. Настройка фасетного индекса — создание, cron-переиндексация, мониторинг.
  5. SEO-фильтры — ЧПУ, метатеги, каноникалы, sitemap.
  6. Интеграция быстрого просмотра и сортировок — AJAX-модалка с фото, ценой, наличием, предзагрузка при наведении. На мобильных — bottom sheet вместо попапа.
  7. Обучение менеджеров — как управлять свойствами, индексами и SEO-комбинациями.
  8. Гарантийная поддержка — 30 дней после сдачи.

Сроки реализации

Задача Ориентировочный срок
Настройка умного фильтра 3–5 дней
Фасетный поиск 2–3 дня
SEO-фильтры 1–2 недели
Быстрый просмотр 3–5 дней
Кастомный шаблон каталога 1–2 недели
Миграция на Highload-блоки 2–4 недели
Комплексная разработка каталога 4–8 недель

Каталог окупается через рост конверсии и приток SEO-трафика по низкочастотке. Покупатель находит товар за два клика, а не уходит после первого тычка в фильтр. Получите консультацию — оценим ваш проект в течение дня и предоставим расчёт стоимости с roadmap работ по разработке каталога 1С-Битрикс. Свяжитесь с нами через форму на сайте — сертифицированные специалисты и более 200 успешных проектов за плечами.