Налаштування лічильника переглядів товару в 1С-Бітрікс

Для демонстрації популярності товару лічильник переглядів — найшвидший спосіб. Покупки накопичуються повільно, а перегляди — уже через пару днів навіть у новинки з'являються реальні цифри. Бітрікс не веде такого лічильника за замовчуванням, але ми налаштовуємо його із захистом від накрутки та без втрати продуктивності. За 8 років досвіду роботи з Бітрікс ми виробили оптимальний алгоритм.

Вбудований модуль статистики: чому не підходить

Модуль statistic пише кожен хіт у таблицю b_stat_page_hit з полем PATH. Теоретично можна рахувати перегляди за URI сторінки. Практично — таблиця розбухає до мільйонів рядків, запити стають гальмівними, а модуль часто вимикають на високонавантажених проектах. Для каталогу з 50 000 товарів цей варіант нежиттєздатний.

Власний лічильник через властивість інфоблоку

Правильне рішення — зберігати лічильник прямо у властивості інфоблоку. Створюємо числову властивість VIEW_COUNT (b_iblock_property) та інкрементуємо її при кожному відкритті детальної сторінки. Обробник пишемо в component_epilog.php компонента bitrix:catalog.element:

if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die(); $elementId = $arResult["ID"]; $iblockId = $arResult["IBLOCK_ID"]; $currentCount = (int)$arResult["PROPERTIES"]["VIEW_COUNT"]["VALUE"]; CIBlockElement::SetPropertyValuesEx( $elementId, $iblockId, ["VIEW_COUNT" => $currentCount + 1] ); 

Код виконується після відправлення HTML-буфера клієнту, тому не сповільнює відмальовку.

Як захистити лічильник від накрутки ботами?

Без фільтрації лічильник полетить у космос за день. Мінімальний захист:

• Перевіряти $_SERVER['HTTP_USER_AGENT'] на наявність рядків Googlebot, YandexBot, Bingbot.
• Запам'ятовувати перегляди в сесії: $_SESSION['viewed_products'][$elementId] = time(). Якщо минуло менше 30 хвилин — не інкрементуємо.

Додатково можна вести таблицю логів з IP та часом, але сесія достатньо надійна для 95% випадків.

Чому потрібно використовувати атомарний INCREMENT?

При високому навантаженні — більше 100 переглядів на хвилину на один товар — звичайний SetPropertyValuesEx створює гонку: два запити можуть прочитати одне й те саме значення та записати однаковий інкремент. Рішення — атомарний UPDATE:

$DB->Query("UPDATE b_iblock_element_prop_s{$iblockId} SET PROPERTY_VIEW_COUNT = COALESCE(PROPERTY_VIEW_COUNT, 0) + 1 WHERE IBLOCK_ELEMENT_ID = " . intval($elementId)); 

Ім'я колонки PROPERTY_VIEW_COUNT залежить від ID властивості — його можна дізнатися через CIBlockProperty::GetList. Такий запит не блокує читання та гарантує точність навіть при 5000 запитів на хвилину.

Таблиця порівняння методів

Виведення лічильника в шаблоні

У шаблоні bitrix:catalog.element виводимо значення:

$viewCount = (int)$arResult["PROPERTIES"]["VIEW_COUNT"]["VALUE"]; echo '<span>' . $viewCount . ' переглядів</span>'; 

Для правильного відмінювання закінчень використовуйте функцію sklon:

function sklon($num, $forms) { $num = abs($num) % 100; if ($num > 10 && $num < 20) return $forms[2]; $num = $num % 10; if ($num == 1) return $forms[0]; if ($num >= 2 && $num <= 4) return $forms[1]; return $forms[2]; } echo $viewCount . ' ' . sklon($viewCount, ['перегляд', 'перегляди', 'переглядів']); 

Кешування та лічильник переглядів

Стандартне кешування компонента bitrix:catalog.element конфліктує з лічильником: при увімкненому кеші інкремент не відбувається. Рішення — виносити код інкременту в component_epilog.php, який завжди виконується після віддачі кешу та не кешується.

Альтернативний підхід — AJAX-інкремент: сторінка віддається з кешу, JavaScript робить POST-запит на /local/ajax/view-count.php через секунду після завантаження. Мінус: скрипт може не спрацювати у частини користувачів.

Аналітика на основі лічильника

Накопичений лічильник корисний не тільки для відображення:

• Сортування «за популярністю» в каталозі через ORDER BY PROPERTY_VIEW_COUNT DESC.
• Сегментація товарів: «гарячі» (500+ переглядів), «теплі» (50–500), «холодні» (менше 50).
• Виявлення трендів: товари з лічильником, що швидко зростає за останні 7 днів — кандидати для акції.

Лічильник переглядів — довірчий сигнал: «Цей товар переглянули 2 400 разів» психологічно рівнозначно соціальному доказу. Дані лічильника експортуються в CSV через кастомний скрипт або виводяться в адміністративний звіт через CAdminList. Це дозволяє будувати маркетингові сегменти на основі реальної активності аудиторії за категоріями та брендами.

Рекомендації щодо порогів захисту

При налаштуванні сесійного захисту від накрутки рекомендуємо виставляти TTL не менше 30 хвилин. Для високонавантажених проектів з більш ніж 100 одночасними відвідувачами використовуйте Redis-кеш замість сесій PHP — це знижує навантаження на файлову систему та прискорює перевірку при піковому трафіку. Для IP-захисту ведіть окремий лічильник звернень з часовим вікном 10 хвилин: більше 5 переглядів одного товару з одного IP за 10 хвилин — блокуємо інкремент.

Що входить у налаштування під ключ

Ми виконуємо повний цикл робіт:

• Створення числової властивості VIEW_COUNT в інфоблоці каталогу
• Написання обробника в component_epilog.php з фільтрацією ботів
• Реалізація захисту від повторного рахунку через сесію
• Опціонально: атомарний інкремент для високонавантажених проектів
• Виведення лічильника з правильними закінченнями в шаблоні
• Тестування на навантаження до 100 одночасних запитів

Результат — лічильник, який не накручується ботами, не гальмує сайт і коректно працює при будь-якому кешуванні. Для розрахунку вартості та термінів зв'яжіться з нами — оцінимо ваш каталог і навантаження за один робочий день.