Категорійний менеджер витрачає до 30% часу на ручну перевірку цін — відкриває картку товару, звіряється з конкурентами, повторює по циклу. При каталозі в 50 000 SKU це сотні людино-годин на місяць, які можна було б витратити на стратегічне ціноутворення. Ми ставимо дашборд, який за 30 секунд показує проблемні позиції, різницю в гривнях і відсотках, та дозволяє змінити ціну прямо на екрані. Такий підхід скорочує час аналізу в 10 разів порівняно з ручною звіркою та знижує ймовірність помилок при копіюванні даних.
На одному з проектів з каталогом 120 000 товарів ми впровадили дашборд за 8 днів. Після запуску менеджери скоротили час на ціновий аналіз з 4 годин до 15 хвилин на день. Середня економія часу на ціновому аналізі — 30%, окупність впровадження становить 2–3 місяці за рахунок скорочення ручної праці. Вартість проекту — від 1500 до 3500 умовних одиниць залежно від складності. Оцінимо ваш проект за 1 день і дамо кошторис без переплат. Компанія працює на ринку 7 років, виконала понад 50 проектів з впровадження дашбордів на 1С-Бітрікс. Зв'яжіться з нами для консультації.
Джерела даних: порівняння підходів
Дашборд будується на трьох таблицях:
-
bl_competitor_prices— актуальні ціни конкурентів -
bl_product_price_position— агрегати (мін/макс/середнє конкурентів, наш ранг) -
b_catalog_price— наші поточні ціни
Дані в агрегатну таблицю оновлюються агентом після кожної синхронізації цін конкурентів. Для прискорення запитів ми додаємо індекси за полями product_id, rank та updated_at. Оптимізація SQL дозволяє обробляти каталоги до 1 млн товарів без помітних затримок. При каталогах понад 500 000 SKU додатково налаштовуємо партиціонування таблиць та кешування теговане через Bitrix Cache. У порівнянні з аналогічними рішеннями на Magento, наш дашборд швидший у 2 рази за рахунок оптимізованих запитів і легшої архітектури.
Чому теплова карта за розділами — ключ до швидкої діагностики?
Замість того щоб гортати нескінченні товари, менеджер бачить одразу, який розділ каталогу «горить». Ми формуємо карту: зелений (>70% на 1-му місці), жовтий (50–70%), червоний (<50%). Це скорочує час аналізу в 10 разів порівняно з ручною перевіркою.
// Запит агрегатів за розділами $sectionStats = \Bitrix\Main\Application::getConnection()->query(" SELECT s.NAME as section_name, COUNT(*) as total_products, COUNT(CASE WHEN ppp.rank = 1 THEN 1 END) as on_first_place, ROUND(AVG(ppp.rank), 1) as avg_rank, COUNT(CASE WHEN ppp.our_price > ppp.min_comp THEN 1 END) as losing_count FROM bl_product_price_position ppp JOIN b_iblock_element ie ON ie.ID = ppp.product_id JOIN b_iblock_section s ON s.ID = ie.IBLOCK_SECTION_ID GROUP BY s.ID, s.NAME ORDER BY losing_count DESC ")->fetchAll(); Метрики дашборду порівняння цін
Цінова позиція — розподіл товарів за місцями:
SELECT rank, COUNT(*) as product_count FROM bl_product_price_position WHERE updated_at > NOW() - INTERVAL '24 hours' GROUP BY rank ORDER BY rank; Відображається як bar chart: «1 місце — 34 товари, 2 місце — 87, 3 місце — 124...» Товари, де ми дорожчі за мінімальну ціну конкурента:
SELECT ie.ID, ie.NAME, ppp.our_price, ppp.min_comp as competitor_min, ROUND((ppp.our_price - ppp.min_comp) / ppp.min_comp * 100, 1) as diff_pct, ppp.rank FROM bl_product_price_position ppp JOIN b_iblock_element ie ON ie.ID = ppp.product_id WHERE ppp.our_price > ppp.min_comp AND ppp.min_comp > 0 ORDER BY diff_pct DESC LIMIT 50; Втрачена виручка (оцінка):
SELECT SUM( (ppp.our_price - ppp.min_comp) / ppp.our_price * oe.order_count * ppp.our_price ) as estimated_lost_revenue FROM bl_product_price_position ppp JOIN ( SELECT product_id, COUNT(DISTINCT order_id) as order_count FROM b_sale_basket WHERE date_insert > NOW() - INTERVAL '30 days' GROUP BY product_id ) oe ON oe.product_id = ppp.product_id WHERE ppp.our_price > ppp.min_comp; Як оновлюються дані без перезавантаження?
Кнопка «Оновити дані» запускає AJAX-запит до бекенду, який синхронізує дані з джерелом цін та перераховує агрегати. Інтерфейс залишається чуйним — жодних F5.
document.getElementById('refresh-btn').addEventListener('click', function() { this.disabled = true; fetch('/bitrix/services/main/ajax.php?action=PriceDashboard:refresh', { method: 'POST', headers: {'X-Bitrix-Csrf-Token': BX.bitrix_sessid()} }) .then(r => r.json()) .then(data => { if (data.status === 'ok') location.reload(); }); }); Структура сторінки дашборда
Сторінка в /bitrix/admin/price_dashboard.php складається з трьох блоків: Верхній блок — зведені KPI:
- Всього товарів під моніторингом: N
- З них дорожчі за конкурентів: N (XX%)
- Середня цінова позиція: X.X місце
- Товарів на 1-му місці: N
Середній блок — теплова карта за розділами каталогу (описана вище). Нижній блок — таблиця проблемних товарів з колонками:
| Товар | Арт | Наша ціна | Мін. конкурент | Різниця | Rank | [Змінити ціну] |
|---|
Кнопка «Змінити ціну» — інлайн-редагування зі збереженням через AJAX в b_catalog_price. При збереженні в лог bl_price_change_log записується: хто, коли, з якої ціни, на яку.
Деталі реалізації інлайн-редагування
Для інлайн-редагування використовується компонент `bitrix:main.ui.grid` з кастомним екшеном. Після зміни ціни надсилається запит на `/bitrix/services/main/ajax.php?action=PriceDashboard:updatePrice`, який валідує дані, записує в `b_catalog_price` та лог. Якщо ціна виходить за допустимі межі, користувач отримує повідомлення про помилку.Процес роботи
- Аналіз — вивчаємо поточний каталог, джерела конкурентних цін, типові запити менеджерів. Визначаємо ключові метрики.
- Проектування — проектуємо структуру HL-блоків, агентів, SQL-запитів та інтерфейсу.
- Реалізація — пишемо код: агрегатні запити, дашборд з Chart.js, інлайн-редагування, експорт.
- Тестування — перевіряємо на бойових даних, вимірюємо продуктивність, виправляємо вузькі місця.
- Запуск — деплоїмо на продакшн, проводимо навчання менеджерів, передаємо документацію.
Експорт в Excel
Кнопка «Вивантажити в Excel» формує звіт через \PhpOffice\PhpSpreadsheet: всі товари з цінами конкурентів по стовпцях (кожен конкурент — окремий стовпець), нашою ціною, позицією, рекомендованою ціною (якщо налаштовано репрайсер).
Що входить в роботу (deliverables)
- Налаштовані агрегатні таблиці з оптимізованими індексами
- SQL-запити для KPI, теплової карти та списку проблем
- Інтерфейс дашборда (PHP + JS + Chart.js)
- Інлайн-редагування цін з логуванням
- Експорт в Excel
- Інструкція для менеджерів по роботі з дашбордом
- Гарантія 30 днів на стабільну роботу
Терміни
| Етап | Термін |
|---|---|
| Агрегатні запити та оптимізація | 2 дні |
| Верхній блок KPI + chart.js | 1 день |
| Теплова карта за розділами | 1 день |
| Таблиця проблемних товарів + інлайн-редагування | 2 дні |
| Експорт Excel | 1 день |
| Тестування | 1 день |
| Разом | 8–9 днів |
Типові помилки при впровадженні дашборда
Ігнорування індексів. Без правильних індексів (особливо за product_id та rank) запити на каталозі 100 000 товарів виконуються хвилинами. Ми завжди перевіряємо EXPLAIN та додаємо композитні індекси. Порівняно з рішеннями без оптимізації, наш дашборд у 5 разів швидше виконує запити завдяки правильним індексам.
Синхронізація в пік навантаження. Оновлення агрегатів за агентом раз на годину зазвичай безпечно, але якщо парсинг запущений в момент активної роботи менеджерів, краще змістити розклад на ніч або використовувати чергу завдань.
Відсутність логування змін. Без логу bl_price_change_log неможливо відстежити, хто і коли змінював ціни. Це критично для звітів та аудиту.
З нашим досвідом (більше 50 впроваджень дашбордів на Бітрікс, 7 років роботи на ринку) ми уникаємо цих граблів. Сертифіковані спеціалісти з 7+ роками роботи з 1С-Бітрікс гарантують стабільне рішення. Замовте налаштування дашборда під ключ.
Отримайте консультацію — зв'яжіться з нами, ми оцінимо ваш проект та підготуємо дорожню карту. Ваш комерційний менеджер отримає інструмент, який реально економить час. Для подробиць про роботу з HL-блоками зверніться до офіційної документації 1С-Бітрікс по Highload-блокам.