Настройка воронки продаж в аналитике Битрикс24: полный гайд

Настройка воронки продаж в аналитике Битрикс24

60% сделок зависают на стадии «Коммерческое предложение» — классический сигнал проблем в воронке. Без аналитики не увидеть, что менеджеры не отправляют КП или оно слабое. Мы за 7+ лет настроили воронки для 50+ проектов — от небольших студий до крупных дилеров с тысячами сделок. Наша гарантия: конверсия между стадиями вырастает на 15–30% после правильной настройки. Типичная ошибка — перегружать pipeline десятком стадий без чётких критериев. Сжатие до 5–7 этапов с обязательными атрибутами перехода сразу выявляет узкое место. В одном проекте замена стадии «В процессе» на «Счёт выставлен» и «Ожидание оплаты» дала рост конверсии в 25% за месяц. Получите консультацию — проанализируем вашу CRM бесплатно.

В этой статье разберём, как устроить аналитическую воронку, которая показывает не только цифры, но и причины провалов. Рассмотрим настройку через штатную аналитику и REST API с BI-дашбордом. Начнём с ревизии стадий — это основа любой воронки. Затем настроим отчёт и дашборд. Автоматическая настройка через REST API в 3 раза быстрее ручного создания отчётов.

Проблемы, которые решаем

Раздутые pipeline — 15 стадий, где конверсия между соседними 98% — мусор. Укрупняем до 5–7 этапов с чёткими критериями.

Стадии-помойки — «В процессе» или «Требует уточнения»: сделки висят неделями. Вводим обязательный атрибут перехода и лимит времени.

Потеря причин проигрыша — без атрибута «Провал» не понять, почему уходят. Добавляем обязательное поле «Причина» при закрытии.

Почему сделки застревают на этапе КП?

В Битрикс24 типичная картина: менеджер создал сделку, отправил КП и забыл. Воронка показывает это как 0% переходов на следующую стадию. Решение — автоматизация: событие «Отправка КП» (через почту или CRM-форму) должно запускать триггер на смену стадии. Настраиваем это через Бизнес-процессы или REST API.

Какую воронку выбрать: лидов или сделок?

Если включены лиды — нужны обе. Сначала конверсия из лида в сделку, затем конверсия по сделкам. Сквозной воронки из коробки нет — строим через BI-дашборд (например, с помощью REST API и DataLens). Это позволяет увидеть, сколько входящих лидов реально приносят деньги.

Как мы настраиваем аналитическую воронку

Шаг 1. Ревизия стадий CRM. Проверяем, соответствуют ли они реальному процессу. Удаляем формальные этапы.

Шаг 2. Настройка отчёта. Выбираем тип (конверсия, деньги, количество), фильтры (период, менеджер, источник).

Шаг 3. Создание дашборда. Добавляем виджеты: воронка в разрезе источников, сравнение с прошлым периодом, таблица проигранных сделок с причинами.

Шаг 4. Обучение. Показываем руководителю, как читать отчёт и реагировать на сигналы.

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

Настройка занимает от 2 до 8 часов в зависимости от сложности CRM. Стоимость рассчитывается индивидуально. Закажите предварительную оценку — укажем точные сроки.

Пример из практики

Один из клиентов — дилер спецтехники — использовал 10 стадий, но конверсия была 98% между всеми этапами. После сжатия до 6 стадий и добавления обязательных атрибутов (дата отправки КП, причина проигрыша) мы выявили, что 40% сделок зависали на этапе «Согласование». Причина — нет чёткого срока ответа. Внедрили автоматический переход через бизнес-процесс: если согласование затягивается более 3 дней, сделка переходит в «Просроченное согласование». Конверсия на следующую стадию выросла на 20%.

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

• Ревизия существующих стадий (документируем проблемные места)
• Настройка 1 аналитической воронки (тип — конверсия)
• Создание дашборда с 3–5 виджетами
• Инструкция для руководителя (PDF)
• Чек-лист типичных ошибок (прилагаем)
• 7+ лет опыта — более 50 проектов по Битрикс24

Чек-лист: ключевые точки контроля

• Стадия «Проигрыш» с обязательной причиной помогает анализировать провалы
• Длительность сделки на каждой стадии не превышает норму — проверяйте еженедельно
• Конверсия между соседними стадиями отличается более чем на 5% — сигнал к действию
• Сравнивайте периоды хотя бы раз в месяц для выявления трендов

Получите консультацию — оценим вашу CRM и предложим план настройки.

Почему аналитика 1С-Битрикс часто вводит в заблуждение

Счётчики стоят, пиксели повешены, CRM подключена — а цифры расходятся во все стороны. Конверсия e-commerce не передаётся в dataLayer. UTM-теряются на редиректах ЧПУ. Маркетолог видит 100 лидов, коммерческий директор — 70 сделок, и каждый считает по-своему. Решения принимаются по ощущениям, а рекламный бюджет улетает в никуда.

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

Как аналитика 1С-Битрикс решает проблему расхождения данных

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

Яндекс.Метрика: настройка e-commerce без потерь

Базовая настройка — и почему её обычно делают криво

Счётчик Метрики ставят все. Правильно — единицы.

• Установка через 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 с учётом скидок

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
            }]
        }
    });
});

Данные, которые уходят в Метрику

Google Analytics 4: почему Битрикс требует ручной настройки?

Чем GA4 отличается от Universal Analytics

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% транзакций в отчётах.

Пользовательские параметры, которые реально нужны

Не надо передавать всё подряд. Пять параметров, дающих 80% пользы:

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

Сквозная аналитика: замыкаем цепочку от клика до сделки

Метрика видит визиты. CRM видит сделки. Рекламный кабинет видит расходы. А связь между ними — разрыв. Менеджер закрыл сделку на 500К, но Метрика показывает источник (direct), потому что клиент пришёл по прямой ссылке из закладок, а первый контакт был через Директ три месяца назад.

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI. <cite>По нашим данным, после внедрения сквозной аналитики клиенты перераспределяют бюджет в пользу каналов с высоким LTV, и ROI растёт в среднем на 25% за квартал.</cite>

Как собираем

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-трафик конвертируется хуже, зато возвращается. Без этого анализа вы рискуете переплачивать за каналы, которые дают одноразовых покупателей.

Что входит в настройку аналитики 1С-Битрикс

• Аудит текущего dataLayer и исправление ошибок
• Настройка корректного e-commerce трекинга для Метрики и GA4
• Разработка пользовательских событий под бизнес-требования
• Интеграция сквозной аналитики (Roistat/Calltouch) с Битрикс24
• Создание дашбордов в DataLens/Looker Studio
• Документация по всем событиям и параметрам
• Обучение маркетологов и коммерческого отдела работе с отчётами
• Техническая поддержка на месяц после запуска

Сроки

Закажите аудит или настройку аналитики

Проверим, не теряете ли вы деньги на аналитике: проведём аудит текущей настройки за один день. Закажите настройку сквозной аналитики — получите дашборд с реальным ROI по каждому каналу уже через две недели. Получите консультацию по коррекции dataLayer и выбору подходящего инструмента сквозной аналитики для вашего Битрикс-проекта.