Данные собирают руками из кабинетов
Отчёт к середине месяца уже не сходится: часть выгрузок сделана до правок, часть после. На его основе нельзя принимать решения.
Данные и аналитика
Интеграция аналитики: события, сквозная аналитика и BI
Отчёт сходится с учётом, а не с кабинетом рекламы
Показатели собираются из первичных систем, а не из выгрузок, сделанных вручную в разное время. Настраиваем передачу событий и целей, связываем источник трафика с заказом и оплатой, отдаём данные в BI или хранилище и держим регулярную сверку с учётом — чтобы расхождение было видно сразу и с указанием причины, а не обсуждалось на планёрке.
Почему отчётам не верят
Проблема почти всегда не в самой аналитике, а в том, что её данные не связаны с деньгами и собираются вручную. Ниже четыре причины, по которым цифры перестают быть аргументом.
Цели считают клики, а не деньги
Реклама отчитывается о заявках, а не об оплаченных заказах. Канал с дешёвыми заявками может приносить убыток, и это не видно.
Источник трафика теряется по пути
Метки не доходят до заказа: заявка из CRM уже не связана с кампанией, которая её принесла. Приходится верить на слово.
Аналитика и учёт показывают разное
В отчёте продажи есть, в учёте — отгрузки и возвраты. Спор о «правильной» цифре занимает больше времени, чем сам разбор.
Как данные попадают в отчёт
Аналитика — это не одна система, а цепочка: событие на сайте, метка в заказе, оплата в учёте, справочники в хранилище. Разрыв на любом шаге обнуляет всю цепочку.
Сущность
Направление
Что важно учесть
События на сайте
Сайт → веб-аналитика и рекламные кабинеты
Передаются с едиными названиями и параметрами. Если цель называется по-разному на разных страницах, отчёт разваливается на несвязанные строки.
Источник и метки
Сайт → заказ и CRM
UTM-метки и идентификатор визита сохраняются в заявке и переносятся в заказ. Без этого канал нельзя связать с оплатой, и сквозная аналитика остаётся теорией.
Заказы, оплаты, возвраты
Учёт и CRM → аналитика
Факт оплаты и возврат возвращаются в аналитику: канал оценивается по деньгам, а не по числу обращений. Возвраты учитываются отдельно, иначе канал выглядит лучше, чем он есть.
Справочники для отчётов
Учёт → BI
Товары, категории, менеджеры, каналы. Выгружаются как справочники, чтобы в отчёте были читаемые названия, а не идентификаторы.
Первичные данные
Системы → хранилище или BI
Передаются либо готовые агрегаты, либо первичные записи — в зависимости от того, нужно ли считать показатели по своим правилам.
Сверка
Учёт → отчёт сверки
Регулярное сравнение ключевых показателей с учётной системой. Расхождение разбирается по причинам, а не списывается на «погрешность аналитики».
На каждом шаге фиксируется, кто источник данных и как проверяется передача. Иначе отчёт выглядит убедительно, но опирается на данные, которых уже нет.
События и цели: что настраиваем
Набор событий — предмет договорённости, а не техническая мелочь. От него зависит, какие вопросы вообще можно будет задать отчёту.
- Единый список событий и целей — один источник названий для сайта и рекламных кабинетов
- События передаются с параметрами: товар, категория, сумма, способ оплаты
- Цели настраиваются на значимые шаги, а не на каждый клик по кнопке
- Проверка передачи событий после каждого изменения сайта или формы
- Тестовые и служебные заявки помечаются, чтобы не портить отчётность
- Согласие на обработку данных учитывается при передаче идентификаторов
С чем сверяем аналитику
Сверка — это не поиск виноватого, а способ понять, какие записи не попали в отчёт и почему. Разбираем четыре группы показателей.
Заказы
Сравниваются оформленные заказы в аналитике и в учётной системе за один период. Расхождение обычно даёт отмену, тестовая заявка или заказ, созданный вручную.
Оплаты
Считаются только фактически поступившие деньги. Канал, который приводит к заявкам без оплаты, виден именно на этом шаге.
Возвраты
Возвраты вычитаются из результата канала: без этого аналитика показывает выручку, которой у бизнеса уже нет.
Справочники
Названия товаров, менеджеров и каналов сверяются с учётом, чтобы в отчёте не появилось дублирующих строк вроде «ООО Ромашка» и «Ромашка ООО».
Выгрузка в BI и хранилище
Способ выгрузки выбирается по задаче, а не по привычке: кому-то достаточно готовых отчётов, кому-то нужны первичные данные и собственные правила расчёта.
Готовые отчёты
Данные уходят в BI-систему, где уже настроены дашборды. Подходит, когда нужен понятный отчёт без отдельной инфраструктуры.
Выгрузки в хранилище
Первичные данные складываются в хранилище, и показатели считаются по правилам компании. Нужно, когда источников несколько и важна история за длительный период.
Расписание и инкремент
Выгрузка идёт по расписанию и передаёт только изменения, а не весь объём заново. Так отчёт обновляется без нагрузки на рабочие системы.
Как мы настраиваем аналитику
Начинаем с вопросов, на которые должны отвечать цифры, и только затем определяем события и выгрузки. Так отчёт получается пригодным для решений, а не просто заполненным данными.
-
01
Аудит и схема
Разбираем системы, сущности и потоки. Фиксируем, что считается источником правды и где сейчас расходятся данные.
-
02
Контракт обмена
Описываем поля, форматы, частоту и правила сопоставления справочников. Согласуем до начала разработки.
-
03
Прототип
Проверяем обмен на реальных данных в ограниченном объёме: несколько десятков записей в обе стороны.
-
04
Внедрение
Включаем полный обмен с очередью, повторными попытками, журналом и защитой от дублей.
-
05
Эксплуатация
Мониторинг, сверка расхождений, обновление коннекторов при изменениях API на стороне сервиса.
Что делает обмен надёжным
Это не «дополнительные опции», а обязательная часть любой интеграции, которую мы сдаём.
Идемпотентность
Повторная доставка одного и того же события не создаёт вторую сделку, второй заказ или второй платёж.
Очередь и повторные попытки
Если внешняя система недоступна, операция ждёт и повторяется по расписанию, а не теряется.
Журнал обмена
Видно, что и когда ушло, что вернулось и что не прошло. Неудачную операцию можно повторить вручную.
Лимиты провайдера
Учитываем ограничения по частоте запросов, чтобы не получить блокировку со стороны сервиса.
Сверка расхождений
Регулярная сверка ключевых сущностей между системами: расхождение видно в отчёте, а не в конце квартала.
Мониторинг и оповещения
При остановке обмена приходит уведомление ответственным, а не выясняется из жалобы клиента.
Все категории интеграций
Обмен редко ограничивается одной категорией: магазин обычно связан и со складом, и с платежами, и с маркетплейсами.
Частые вопросы об интеграции аналитики
Если вашего вопроса здесь нет — задайте его в форме ниже.
Чем сквозная аналитика отличается от обычной веб-аналитики?
Веб-аналитика видит визит и корзину, но не знает, чем закончилась сделка: оплата приходит в учётную систему, а не в браузер. Сквозная аналитика связывает источник трафика с конкретным заказом и оплатой, поэтому рекламный канал оценивается по деньгам, а не по числу заявок. Для этого в заказ передаётся идентификатор визита и UTM-метки, а из учёта возвращается факт оплаты.
Какие события нужно передавать в аналитику?
Минимальный набор — те, на которые опираются решения: просмотр карточки, добавление в корзину, начало оформления, оформленный заказ, оплата, повторная покупка. Мы не раздуваем список: каждое лишнее событие усложняет отчётность и повышает риск расхождения. Состав событий и их параметры фиксируются в одном месте, чтобы название цели не менялось от страницы к странице.
Почему цифры в аналитике и в учёте не совпадают и что с этим делать?
Расхождение нормально, потому что системы считают разное: аналитика — визиты и события, учёт — отгрузки, оплаты и возвраты. Задача не в том, чтобы цифры совпали до копейки, а в том, чтобы разница была объяснимой и измеряемой. Для этого настраивается регулярная сверка: отменённые заказы, возвраты, оплаты не по заказу и тестовые записи выделяются отдельными строками отчёта.
Нужно ли поднимать отдельное хранилище и BI?
Не всегда. Если отчётов немного, достаточно выгрузок в готовую BI-систему или сводных таблиц, которые обновляются по расписанию. Хранилище нужно, когда источников несколько, история важна за длительный период, а показатели должны считаться по одним правилам. Мы предлагаем минимальный вариант, который закрывает задачу, и описываем, когда имеет смысл переходить к хранилищу.
Что нужно от нас, чтобы начать?
Доступы к системам, из которых берутся данные, и доступ к аналитике, куда они должны попадать. Дальше нужен ответ на вопрос, какие решения принимаются по этим цифрам: под него определяется набор показателей. Если правила расчёта уже есть в таблицах или отчётах, они пригодятся — по ним мы сверим результат.
Разберём, какие цифры вам нужны
Расскажите, какими отчётами пользуетесь сейчас и какие решения по ним принимаете. Предложим схему сбора данных, состав событий и способ выгрузки.
Бесплатный аудит
Разбор технической части сайта: скорость, SSR, фильтры
Аудит текущей рекламы: где сливается бюджет
Анализ конкурентов в вашей нише
Прогноз CPL, ROAS и окупаемости
План действий на первый месяц
Получите бесплатный аудит интернет-магазина
За 3 рабочих дня разберём: где вы теряете заявки, какие каналы недооценены, и что даст рост в первые 30 дней.
За этот месяц
42 компании получили аудит
30 мин
реакция
3 дня
аудит
100%
доступ к кабинетам
Заявка на аудит
Без обязательств. С конкретными цифрами.