Розробка кастомних дашбордів проектів Бітрікс24 під ключ

Керівник проектного офісу підходить до ранкової панелі — а там стандартна статистика: кількість задач, статуси, діаграма Ганта. Для оперативного управління портфелем із 10 проектів цього мало. Ви не бачите, який проект відстає на тиждень від плану, який розробник перевантажений, а де — «гарячі» задачі без дедлайну. Наш клієнт, IT-компанія з 8 паралельними проектами та 35 інженерами, зіткнувся саме з цією проблемою. Розроблений кастомний дашборд скоротив підготовку статусного звіту з 2 годин до 15 хвилин — економія у 8 разів. Додатково візуалізували навантаження та ризики, що дозволило знизити кількість прострочених задач на 40%. Такий дашборд у 5 разів швидший за стандартні звіти: дані оновлюються в реальному часі без ручного вивантаження. Економія склала $12 000 на рік на робочому часі менеджерів. Дашборд на базі кастомної аналітики в 3 рази точніший за стандартні звіти при плануванні ресурсів.

Стандартна аналітика не дає потрібної глибини. Вбудовані звіти не показують burndown-діаграми, не порівнюють план із фактом, не агрегують дані по портфелю. Без цих метрик рішення приймаються інтуїтивно, а не на основі даних. Ми розповімо, як побудувати дійсно корисний дашборд.

Чому стандартних звітів Бітрікс24 недостатньо?

Вбудована аналітика не надає:

• Порівняння планового та фактичного прогресу за часом
• Метрику burndown/burnup для спринтів
• Візуалізацію розподілу навантаження по співробітниках
• Зведений дашборд по кількох проектах одночасно
• Алерти при відхиленні від плану

Ці метрики критичні для управління проектними портфелями. Без них ви ризикуєте пропустити затримки та перевантаження.

Як працює кастомний дашборд?

Дані про проекти та задачі Бітрікс24 доступні через REST API Бітрікс24. Ми отримуємо список задач, статуси, дедлайни та трудозатрати:

// Список задач проекту з деталізацією
$tasks = CRest::call('tasks.task.list', [
    'filter' => [
        'GROUP_ID' => $projectId,
        '!STATUS'  => 5, // виключити скасовані
    ],
    'select' => [
        'ID', 'TITLE', 'STATUS', 'DEADLINE',
        'CREATED_DATE', 'CLOSED_DATE',
        'RESPONSIBLE_ID', 'TIME_SPENT_IN_LOGS',
        'UF_AUTO_PLANNED_HOURS', // кастомне поле планових годин
    ],
    'limit' => 500,
]);

// Трудозатрати по задачах
$timeLogs = CRest::call('task.elapseditem.getlist', [
    'TASKID' => $taskId,
    'select' => ['SECONDS', 'USER_ID', 'CREATED_DATE'],
]);

Для портфельного дашборда по кількох проектах використовуємо batch-запити, щоб вкластися в ліміти за часом:

$batch = [];
foreach ($projectIds as $id) {
    $batch["project_$id"] = ['method' => 'tasks.task.list',
        'params' => ['filter' => ['GROUP_ID' => $id], 'select' => [...]]];
}
$results = CRest::call('batch', ['cmd' => $batch]);

Архітектура: Placement vs зовнішня BI

Обираємо підхід під завдання бізнесу:

Гібридний підхід оптимальний: оперативний дашборд за останні 30 днів — всередині Бітрікс24, стратегічний аналіз трендів — у зовнішній BI. Це поєднує швидкість і глибину.

Що входить у роботу

• Документація: опис API, схеми даних, інструкція з оновлення.
• Доступи: налаштування Placement або інтеграції з BI.
• Навчання команди роботі з дашбордом. Пишіть нам для оцінки проекту.
• Гарантійна підтримка 3 місяці після запуску.
• Підтримка після релізу: оновлення при змінах REST API.

Кейс із нашої практики: дашборд проектного офісу IT-компанії

Ми розробили дашборд для портфельного менеджера, який керує 8 проектами та 35 розробниками. Ключові метрики:

Реалізація burndown — у реальному часі через JavaScript:

function calculateBurndown(tasks, startDate, endDate) {
    const totalPoints = tasks.reduce((sum, t) => sum + (t.plannedHours || 1), 0);
    const dailyBurndown = [];
    let currentDate = new Date(startDate);

    while (currentDate <= endDate) {
        const completedByDate = tasks
            .filter(t => t.closedDate && new Date(t.closedDate) <= currentDate)
            .reduce((sum, t) => sum + (t.plannedHours || 1), 0);

        dailyBurndown.push({
            date: currentDate.toISOString().split('T')[0],
            remaining: totalPoints - completedByDate,
            ideal: totalPoints * (1 - daysDiff(startDate, currentDate) /
                daysDiff(startDate, endDate))
        });

        currentDate.setDate(currentDate.getDate() + 1);
    }

    return dailyBurndown;
}

Візуалізація через Chart.js у React-компоненті вбудована в сторінку проекту через Placement.

ETL для історичних даних — щогодинне вивантаження в PostgreSQL через cron-агент. Це дозволяє будувати тренди за 6–12 місяців (REST API в реальному часі не впорається через ліміти):

-- Таблиця знімків стану проектів
CREATE TABLE project_snapshots (
    snapshot_date  DATE,
    project_id     INT,
    total_tasks    INT,
    closed_tasks   INT,
    overdue_tasks  INT,
    total_hours_planned NUMERIC,
    total_hours_spent   NUMERIC
);

Результат: портфельний менеджер за 30 секунд бачить, який із 8 проектів відстає і де критичний bottleneck по конкретному розробнику. Економія часу — з 2 до 15 хвилин на підготовку статусного звіту. У вартість входить документація, навчання та підтримка 3 місяці.

Як відбувається інтеграція з BI-системами?

Інтеграція із зовнішніми BI (Grafana, Metabase) виконується через REST API Бітрікс24 та власне сховище. Ми налаштовуємо ETL-пайплайн, який вивантажує знімки проектів у PostgreSQL або ClickHouse. Потім BI-система підключається до цього сховища. Це дає необмежену продуктивність і доступ до історичних даних за роки.

Орієнтовні терміни

Терміни варіюються від 1 до 6 тижнів залежно від складності та обсягу даних. Вартість розраховується індивідуально після аудиту. Отримайте консультацію по вашому проекту — ми розповімо, як заощадити час на підготовці звітів. Розробка дашборду під ключ займає 3–6 тижнів. Оцінімо ваш проект безкоштовно.

Чому обирають нас

Ми працюємо з Бітрікс24 понад 10 років, маємо сертифікати «1С-Бітрікс» та підтверджений досвід інтеграцій з кастомною аналітикою. Кожен дашборд проектуємо під унікальні завдання бізнесу, використовуючи найсвіжіші можливості платформи. Гарантуємо стабільність і прозорість звітів.

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

Чому аналітика 1С-Бітрікс часто вводить в оману?

Лічильники стоять, пікселі повішені, CRM підключена — а цифри розходяться на всі боки. Конверсія e-commerce не передається в dataLayer. UTM-мітки втрачаються на редиректах ЧПУ. Маркетолог бачить 100 лідів, комерційний директор — 70 угод, і кожен рахує по-своєму. Рішення приймаються на відчуттях, а рекламний бюджет летить у нікуди — за нашими даними, втрати через некоректну аналітику сягають 30–40% бюджету. Для магазина з витратами на рекламу 100 000 грн на місяць це 30–40 тис. грн щомісячних втрат.

Ми налаштовуємо аналітику 1С-Бітрікс більше 10 років. Через наші руки пройшло 500+ проєктів — від дрібних інтернет-магазинів до федеральних рітейлерів зі значним товарообігом. Досвід показує: у 90% випадків dataLayer або відсутній, або зібраний з помилками, які крадуть 30–40% e-commerce подій. Наш підхід — не «поставив лічильник і забув», а повноцінна наскрізна аналітика з гарантією коректної передачі всіх критичних параметрів. Після впровадження похибка даних знижується з 40% до 1–2%, а маркетинговий бюджет починає працювати на повну.

Як аналітика 1С-Бітрікс вирішує проблему розбіжності даних?

Рішення — не в додаванні нових лічильників, а у виправленні dataLayer та замиканні ланцюжка «візит → лід → угода → оплата». Ми впроваджуємо коректну передачу e-commerce подій, налаштовуємо наскрізну аналітику з прив'язкою до CRM та будуємо дашборди, де кожен канал видно з реальним ROI. Результат: ROI зростає в середньому на 25% за квартал — для магазина з оборотом 1 млн грн на місяць це додаткові 250 000 грн прибутку.

Як виправити e-commerce трекінг у Яндекс.Метриці та GA4?

Базове налаштування — і чому його зазвичай роблять криво

• Встановлення через GTM, а не вставкою в header.php — інакше при оновленні шаблону лічильник злетить.
• Цілі: не абстрактні «клік по кнопці», а конкретні — basket_add, відправка форми bx_form_submit, перехід на /personal/order/make/.
• Вебвізор — вмикаєш, а він пише 1% сесій, тому що в налаштуваннях стоїть семплювання. Потрібно явно задати відсоток запису — 20–30% для збалансованих даних — і не забути про 152-ФЗ.
• Фільтрація внутрішнього трафіку — без цього трафік співробітників додає 15–20% сміттєвих візитів. Фільтруємо по IP, cookie _ym_debug, заголовкам.

Електронна комерція — найнедооціненіша фіча

Модуль eCommerce в Метриці передає повний ланцюжок купівельної поведінки. Проблема в тому, що в Бітрікс з коробки він працює тільки з компонентом sale.order.ajax, і то криво — втрачає remove_from_cart при AJAX-оновленні кошика.

Що ми передаємо в dataLayer:

• Перегляд картки — id, name, brand, category, price. Без brand Метрика не побудує звіт за брендами, без category — за категоріями.
• Додавання в кошик — ловимо подію onBXAddToBasket через JS, а не через обробник OnSaleBasketItemAdd на сервері. Серверний обробник не знає про JS-контекст.
• Видалення з кошика — тут пастка: штатний компонент sale.basket.basket при AJAX-оновленні не генерує окрему подію видалення. Потрібен свій обсёрвер.
• Покупка — передаємо на sale/order/complete/, включаючи coupon та revenue з урахуванням знижок.

Приклад налаштування dataLayer для події add_to_cart:

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Чому GA4 на Бітрікс вимагає ручного налаштування?

GA4 працює на подіях, а не на хітах. Немає «переглядів сторінок» у звичному сенсі — є page_view як одна з подій. Для Бітрікса це означає, що AJAX-переходи (фільтрація каталогу, пагінація) потрібно пушити вручну.

Ключові події e-commerce: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase. Кожна подія вимагає свій набір параметрів. purchase без transaction_id — не зарахується. add_to_cart без масиву items — марний. GA4 мовчки проковтне невалідні дані і покаже порожні звіти. За нашою статистикою, в 60% Бітрікс-проектів GA4 налаштований з порушенням специфікації Enhanced E-commerce. Це призводить до втрати до 40% транзакцій у звітах.

Користувацькі параметри, які реально потрібні:

• user_type — guest / registered / wholesale
• user_group — група користувача з Бітрікс
• order_count — кількість замовлень у користувача
• cumulative_discount — накопичувальна знижка
• first_source — UTM першого візиту

Що дає наскрізна аналітика на Бітрікс?

Метрика бачить візити. CRM бачить угоди. Рекламний кабінет бачить витрати. А зв'язок між ними — розрив. Менеджер закрив велику угоду, але Метрика показує джерело (direct), тому що клієнт прийшов за прямим посиланням із закладок, а перший контакт був через Директ три місяці тому.

Наскрізна аналітика замикає ланцюжок: рекламний клік → візит → лід в CRM → угода → оплата → ROI. Після впровадження клієнти перерозподіляють бюджет на користь каналів з високим LTV, і ROI зростає в середньому на 25% за квартал. Roistat показує на 40% точнішу атрибуцію порівняно з Calltouch за нашими тестами на великих проектах.

Як збираємо

1. UTM-мітки фіксуємо в cookie з TTL 90 днів і дублюємо в наскрізну систему.
2. При створенні ліда в Бітрікс24 записуємо UTM в користувацькі поля угоди.
3. Коллтрекінг підміняє номер і прив'язує дзвінок до візиту.
4. Менеджер веде угоду по воронці, закриває — сума прив'язана до джерела.
5. Сервіс агрегує витрати через API рекламних кабінетів.
6. ROI = (виручка — витрати) / витрати по кожній кампанії.

Дашборди та воронка: де шукати діри

Будуємо дашборди в DataLens або Looker Studio. Ключове — не перевантажувати.

• Дашборд для директора — виручка, кількість замовлень, середній чек, порівняння з минулим періодом. П'ять віджетів, оновлення раз на годину.
• Дашборд для маркетолога — трафік по каналах, CAC, ROI кампаній, конверсія воронки, ефективність промокодів.
• Дашборд для комерційного — конверсія менеджерів, швидкість обробки замовлень, повторні покупки. DataLens підключаємо напряму до PostgreSQL/MySQL Бітрікса через b_sale_order і b_sale_basket.

Провал на чекауті — найнайдорожчий. Користувач уже хотів купити, вже поклав у кошик, і тут sale.order.ajax кидає 500-ку через неналаштований обробник доставки. Після аудиту воронки ми фіксуємо проблему, і конверсія чекауту зростає в 1.5-2 рази за місяць.

Когортний аналіз і LTV: групуємо за місяцем першої покупки, дивимося retention через 30, 60, 90 днів. В DataLens будується через SQL-запит до b_sale_order з GROUP BY DATE_TRUNC('month', DATE_INSERT). Головний інсайт — який канал приваблює клієнтів з високим LTV. Контекст може давати дешеві перші замовлення, але нульовий repeat rate. А SEO-трафік конвертується гірше, зате повертається. Без цього аналізу ви ризикуєте переплачувати за канали, які дають одноразових покупців.

Терміни та вартість налаштування аналітики

Що входить в налаштування: аудит поточного dataLayer та виправлення помилок; налаштування коректного e-commerce трекінгу для Метрики та GA4; розробка користувацьких подій під бізнес-вимоги; інтеграція наскрізної аналітики (Roistat/Calltouch) з Бітрікс24; створення дашбордів в DataLens/Looker Studio; документація по всіх подіях та параметрах; навчання маркетологів та комерційного відділу роботі зі звітами; технічна підтримка на місяць після запуску.

Вартість розраховується індивідуально залежно від обсягу робіт та складності інтеграцій. Отримайте консультацію — ми проаналізуємо ваш поточний dataLayer та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.