ecommerce-аналитика в битрикс24: какие цифры реально важны
На аудитах вижу одно и то же: у магазина подключена сквозная аналитика, отчёты красиво выглядят — а решения по ним не принимаются. Потому что смотрят не на те цифры. Разбираю, какая ecommerce-аналитика в Битрикс24 реально нужна магазину и где она чаще всего ломается технически.
почему обычных crm-отчётов магазину мало
Стандартные отчёты Битрикс24 — воронка, конверсия по стадиям, план продаж — считались для B2B-цикла сделки: один лид, один менеджер, недели переговоров. У интернет-магазина логика другая: сотни мелких заказов в день, короткий цикл, решает не менеджер, а связка «канал трафика → цена → скорость доставки».
На моих проектах магазин, который смотрит только на «конверсию воронки», обычно упускает три вещи: сколько реально стоит один заказ по каналам (не лид, а именно оплаченный заказ), какая доля выручки идёт от повторных покупателей, и просаживается ли средний чек на конкретных этапах акций. Без этих трёх цифр решения принимаются на глаз.
Дальше — какие отчёты я обычно настраиваю первыми и почему именно в этом порядке.
отчёт 1: стоимость заказа по каналам, а не по лидам
Частая ошибка — считать CPL (стоимость лида), а не CPO (стоимость оплаченного заказа). Разница может быть в 2-3 раза: с Авито приходит дешёвый лид, но конверсия в оплату у него ниже, чем у контекстной рекламы. Если смотреть только на CPL, бюджет уходит не туда.
В Битрикс24 это считается через связку UTM-меток на источнике лида и поля «Оплачено» на сделке: отчёт CRM-аналитика → «Источники» с фильтром по стадии «оплачен», а не по факту создания. Требует, чтобы форма на сайте передавала UTM в сделку — на моих аудитах это не настроено примерно в половине магазинов, которые уже платят за рекламу.
Практический ориентир: если CPO по каналу выше среднего чека минус себестоимость — канал убыточный, сколько бы лидов он ни давал.
отчёт 2: доля повторных покупок и её динамика
Магазин без учёта повторных продаж живёт в режиме «постоянно покупаем трафик» — LTV клиента никто не считает, хотя именно повторные покупки чаще всего дают 25-35% выручки на зрелом магазине. В CRM это сегмент клиентов с 2+ закрытыми сделками, отчёт делается через список компаний/контактов с фильтром по количеству сделок.
На одном из моих проектов (магазин запчастей) выяснилось: повторные клиенты — 22% базы, но 38% выручки, при этом ни одной автоматической рассылки или напоминания для них не было настроено. Добавили робота «нет заказа 60 дней → задача менеджеру» — доля повторных выросла до 27% за квартал.
Если у вас нет числа «доля выручки от повторных покупателей» прямо сейчас — это первый отчёт, который стоит включить, раньше любых рекламных дашбордов.
отчёт 3: средний чек по этапам воронки, а не только на выходе
Средний чек считают обычно один раз — по факту оплаты. Но это не показывает, где чек проседает. Полезнее смотреть чек по стадиям: «оформлен» vs «оплачен» vs «получен». Если чек на входе выше, чем на выходе — где-то отваливаются дорогие заказы (например, клиент передумал после звонка с уточнением по доставке в отдалённый регион).
Настраивается как поле «Сумма» в отчёте «Воронка продаж» с разбивкой по стадиям — штатный отчёт CRM, не нужны доработки. Смотреть раз в неделю, не раз в квартал: сезонность и акции быстро меняют картину.
Если разница между входным и выходным средним чеком больше 15% — почти всегда причина в логистике или в скрипте подтверждения заказа, а не в качестве трафика.
где эти отчёты технически ломаются
Три частые причины, почему аналитика показывает неправду, а не просто «мало данных»:
Если аналитика у вас пока не настроена вообще, а магазин уже работает на потоке заказов — обычно проще сразу заложить это в общий проект настройки CRM для интернет-магазина, чем чинить отчёты по одному после.
Форма на сайте не передаёт UTM в сделку — тогда «Источники» в CRM показывают в основном «прямой заход», хотя реальный источник другой. Проверяется одним тестовым заказом с UTM в адресной строке.
Заказы с маркетплейсов (Wildberries, Ozon) заводятся отдельно от заказов сайта — тогда общая аналитика по каналам считает только часть бизнеса. Нужна отдельная интеграция или ручной импорт статусов, иначе цифры по марже вообще нельзя сравнивать. Подробнее — в статье про маркетплейсы против своего магазина.
Повторный заказ создаётся как новая карточка контакта, а не привязывается к существующей — тогда доля повторных покупателей занижена искусственно. Причина обычно в том, что телефон/почта не нормализуются при импорте — тут нужна ручная настройка дедупликации.
сквозная аналитика — когда она действительно нужна
Сквозную аналитику «реклама → сделка → деньги» имеет смысл подключать не с первого дня, а когда магазин уже даёт от 15-20 заказов в день и есть минимум 2 постоянных рекламных канала. Раньше этого порога — она даёт мало данных для статистически значимых выводов, а стоит времени на настройку.
Я подробно разбирал техническую сторону в статье сквозная аналитика в Битрикс24 — там про связку с Яндекс.Метрикой и коллтрекингом. Здесь же — акцент именно на то, какие цифры из этой аналитики магазину смотреть в первую очередь: не общий ROMI, а ROMI в разрезе конкретной товарной категории, потому что маржинальность у категорий обычно разная в разы.
с чего начать, если аналитики пока нет вообще
Если сейчас нет ни одного из трёх отчётов выше — не пытайтесь настроить всё сразу. Порядок, который работает на практике:
Неделя 1: убедиться, что UTM доходят до сделки (тестовый заказ + проверка поля источника). Без этого остальные отчёты будут врать.
Неделя 2: включить стандартный отчёт CRM-аналитика с разбивкой по источникам и стадии «оплачен» — не факт создания заказа.
Неделя 3: сегмент повторных клиентов + один робот-напоминание для тех, кто не покупал 60+ дней.
Дальше — по необходимости: сквозная аналитика, если каналов трафика больше двух, ABC-анализ товаров, если ассортимент больше 200 позиций.
интеграция с 1С — где чаще всего теряются данные о марже
Отдельная проблема ecommerce-аналитики — маржинальность. CRM видит сумму заказа, но не всегда видит себестоимость, если она хранится в 1С, а не синхронизируется в карточку товара. Тогда отчёт «выручка по каналам» есть, а «прибыль по каналам» — нет, и решения принимаются по неполным данным.
Решается синхронизацией себестоимости из 1С в справочник товаров Битрикс24 — обычно раз в сутки достаточно, real-time не нужен для этой задачи. Подробно про варианты обмена — в статье варианты обмена 1С и Битрикс24.
На одном проекте (оптово-розничная торговля стройматериалами) без синхронизации себестоимости менеджеры две недели гнали трафик на категорию с фактической маржой в 6% вместо ожидаемых 20% — цифра просто нигде не отображалась, а решение о бюджете принимали по выручке. После настройки ежедневной выгрузки себестоимости из 1С картина стала видна сразу, и бюджет перераспределили на категорию с реальной маржой 24%.
сезонность и акции — почему нельзя сравнивать «в лоб»
Ещё одна ошибка — сравнивать конверсию или средний чек до и после акции без поправки на сезон. Чёрная пятница или предновогодние недели дают всплеск заказов сами по себе, независимо от качества воронки, и если сравнивать «ноябрь после внедрения нового скрипта» с «сентябрь до» — вывод будет ложным.
На практике сравниваю не соседние месяцы, а сопоставимые периоды год к году, либо контрольную группу: часть трафика получает старый скрипт, часть — новый, за одну и ту же неделю. Это требует, чтобы в CRM были размечены источники трафика по времени запуска акции — обычно через дополнительное поле «кампания» на сделке, а не только UTM-метку канала.
Отдельно стоит фиксировать долю заказов с промокодом и её динамику: рост доли заказов со скидкой при том же объёме выручки — сигнал, что аудитория подсаживается на акции, а не на продукт, и маржа будет проседать на дистанции даже при растущей выручке.
Простое правило, которое использую сам: если после акции доля заказов с промокодом не падает обратно к базовому уровню в течение 2-3 недель — акция изменила поведение постоянных покупателей, а не привлекла новых. Это повод пересмотреть глубину скидки, а не радоваться росту заказов.