ROI-аналітика рекламних каналів у Бітрікс24

Стикаємося з цим постійно: замовник просить «зробіть ROI-дашборд», але без коректного збору даних та правильної атрибуції будь-які цифри — ворожіння. Вбудована аналітика Бітрікс24 CRM показує воронку угод та джерела лідів, але не відповідає на питання: скільки грошей витрачено на кожен канал відносно виручки. ROI-аналітика — обчислюваний показник, що потребує даних з двох систем: витрати з рекламних систем та доходи з CRM. Налаштування повної картини включає збір ланцюжка дотиків, вибір моделі атрибуції, імпорт витрат та візуалізацію. Наш досвід: понад 50 проєктів з інтеграції Бітрікс24, сертифіковані інженери, гарантія прозорої звітності. На одному з проєктів щомісячна економія рекламного бюджету після впровадження ROI-аналітики склала значну суму при великих вкладеннях — за рахунок перерозподілу бюджетів між каналами.

Яку модель атрибуції обрати?

Перш ніж налаштовувати звіти — визначтеся, якому дотику приписується конверсія.

First-click — перший канал, через який користувач прийшов на сайт. Показує, що приваблює нову аудиторію.

Last-click — останній канал перед конверсією. Стандарт GA4 та Яндекс.Метрики, але переоцінює ретаргетинг і брендові запити.

Linear — рівномірний розподіл між усіма дотиками. Вимагає зберігання повної історії.

Для B2B з довгим циклом угоди (місяць і більше) оптимальна комбінація first-click + last-click — два звіти одночасно. Для e-commerce достатньо last-click. Мультитач-атрибуція дає в 1.3 раза більш точну оцінку ROAS порівняно з last-click, але й складніша в реалізації.

Зберігання ланцюжка дотиків: як організувати?

Для мультитач-атрибуції потрібна таблиця подій відвідувань, пов'язаних з лідом/угодою. Нижче — приклад ORM-класу Бітрікс24:

class TouchpointTable extends \Bitrix\Main\ORM\Data\DataManager
{
    public static function getTableName(): string { return 'local_crm_touchpoints'; }

    public static function getMap(): array
    {
        return [
            new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]),
            new \Bitrix\Main\ORM\Fields\StringField('SESSION_ID'),
            new \Bitrix\Main\ORM\Fields\IntegerField('LEAD_ID'),
            new \Bitrix\Main\ORM\Fields\IntegerField('DEAL_ID'),
            new \Bitrix\Main\ORM\Fields\StringField('UTM_SOURCE'),
            new \Bitrix\Main\ORM\Fields\StringField('UTM_CAMPAIGN'),
            new \Bitrix\Main\ORM\Fields\StringField('UTM_MEDIUM'),
            new \Bitrix\Main\ORM\Fields\StringField('UTM_TERM'),
            new \Bitrix\Main\ORM\Fields\IntegerField('TOUCH_ORDER'), // 1=first, N=last
            new \Bitrix\Main\ORM\Fields\DatetimeField('CREATED_AT'),
        ];
    }
}

Дані збираються через JavaScript-код на сайті: при кожному візиті з UTM-параметрами — запис у cookie/localStorage, при відправці форми — передача всього ланцюжка на сервер. Це стандартний підхід, рекомендований офіційною документацією.

Як обчислити ROI?

class RoiReportBuilder
{
    public function buildReport(string $dateFrom, string $dateTo, string $attributionModel = 'last'): array
    {
        $deals = $this->getWonDeals($dateFrom, $dateTo);
        $costs = $this->getAdCosts($dateFrom, $dateTo);

        $revenueByChannel = [];
        foreach ($deals as $deal) {
            $channel = $this->getChannel($deal, $attributionModel);
            $revenueByChannel[$channel] = ($revenueByChannel[$channel] ?? 0) + $deal['OPPORTUNITY'];
        }

        $result = [];
        foreach ($costs as $channel => $cost) {
            $revenue = $revenueByChannel[$channel] ?? 0;
            $result[] = [
                'channel'  => $channel,
                'spend'    => $cost,
                'revenue'  => $revenue,
                'profit'   => $revenue - $cost,
                'roi'      => $cost > 0 ? round(($revenue - $cost) / $cost * 100, 1) : null,
                'roas'     => $cost > 0 ? round($revenue / $cost, 2) : null,
                'cpl'      => $cost > 0 ? round($cost / max(1, $this->getLeadsCount($channel, $dateFrom, $dateTo)), 0) : null,
            ];
        }

        usort($result, fn($a, $b) => ($b['roi'] ?? -PHP_INT_MAX) <=> ($a['roi'] ?? -PHP_INT_MAX));
        return $result;
    }
}

Метрики ROAS (Return on Ad Spend) і CPL (Cost Per Lead) доповнюють ROI: ROAS показує, скільки рублів виручки приніс кожен рубль витрат; CPL — вартість ліда. Після впровадження ROI-аналітики вартість ліда знижується на 15-25%.

Дашборд у Бітрікс24

Для відображення ROI-аналітики — два варіанти.

Варіант 1: Кастомний звіт у /local/php_interface/admin/ — таблиця з фільтром за періодом, перемиканням моделі атрибуції, експорт в Excel.

Варіант 2: Вбудовуваний застосунок Бітрікс24 (React) — дашборд на окремій сторінці. Дані беруться з кастомного бекенду. Графіки через Recharts або ApexCharts.

// React-компонент ROI-дашборда
function RoiDashboard() {
  const [period, setPeriod] = useState({ from: startOfMonth, to: today });
  const [model, setModel] = useState<'first' | 'last' | 'linear'>('last');

  const { data, isLoading } = useQuery({
    queryKey: ['roi', period, model],
    queryFn:  () => fetchRoiReport(period, model),
  });

  return (
    <div>
      <PeriodSelector value={period} onChange={setPeriod} />
      <ModelSelector value={model} onChange={setModel} />
      {isLoading ? <Spinner /> : (
        <>
          <RoiTable data={data?.channels} />
          <SpendVsRevenueChart data={data?.channels} />
        </>
      )}
    </div>
  );
}

Ключові звіти в системі

Зведена таблиця по каналах — основний звіт:

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

Воронка по джерелах — конверсія лід → кваліфікований → угода в розрізі каналів. Канал з дешевими лідами, але низькою конверсією, часто поступається дорожчому з якісними лідами.

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

• Аудит поточної схеми збору UTM та інтеграцій
• Вибір та налаштування моделі атрибуції
• Створення кастомної таблиці touchpoints і JavaScript-збирача
• Імпорт витрат з рекламних систем (cron-завдання)
• Розробка ROI-звіту з візуалізацією (адмінка або React-застосунок)
• Документація та навчання співробітників
• Гарантійна підтримка 1 місяць після здачі

Скільки часу займає налаштування?

Базовий ROI-звіт (last-click, один канал) — від 1 тижня. Багатоканальний дашборд з кількома моделями атрибуції — від 3 до 5 тижнів. Оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами — обговоримо деталі та підготуємо комерційну пропозицію. Отримайте консультацію прямо зараз.

Досвід нашої команди — понад 7 років в інтеграціях Бітрікс24, сертифіковані спеціалісти. Гарантуємо прозорість даних і окупність інвестицій в аналітику.

Покрокова інструкція: як налаштувати ROI-дашборд за 5 кроків

1. Визначте модель атрибуції (first/last/linear) виходячи з циклу продажів.
2. Встановіть JavaScript-збирач UTM-ланцюжка на всі сторінки сайту.
3. Створіть HL-блок або ORM-таблицю для зберігання дотиків.
4. Налаштуйте імпорт витрат з Яндекс.Директ, VK Ads, Google Ads через REST API.
5. Розробіть дашборд з фільтрами та вивантаженням в Excel.

Чому аналітика 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 та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.