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