Коротко: настройка считается работающей, когда число заказов в GA4 совпадает с CRM в пределах 10%. Всё остальное — следствие этой проверки.
Настройка, которая «вроде работает»
GA4 почти всегда настроен формально: счётчик стоит, заказы падают, отчёты открываются. Проблема в том, что между «счётчик установлен» и «данными можно пользоваться» лежит набор требований, которые обычно пропускают.
Проверка простая и занимает пять минут: совпадает ли число заказов в GA4 с числом заказов в CRM. Если расхождение больше 10%, остальные отчёты можно не смотреть — они построены на неполных данных.
| Событие | Когда срабатывает | Параметры | Зачем |
|---|---|---|---|
| view_item_list | Показ категории или выдачи | items, item_list_name | Считать просмотр ассортимента |
| view_item | Открытие карточки товара | items, value, currency | Считать интерес к конкретному SKU |
| add_to_cart | Добавление в корзину | items, value, currency | Считать намерение купить |
| begin_checkout | Первый шаг оформления | items, value, currency | Видеть потери на чекауте |
| purchase | Подтверждённая оплата | transaction_id, value, items | Считать выручку и заказы |
| refund | Возврат средств | transaction_id, value | Не завышать выручку |
Без transaction_id заказы невозможно сверить с CRM — а значит, нельзя доверять ни одной цифре о выручке.
Ошибки, которые обнуляют работу
Отчёт, построенный на данных с расхождением в 20% с CRM, опаснее отсутствия отчёта: по нему принимают решения, believing в его точность.
| Ошибка | Как проявляется | Чем грозит | Как закрыть |
|---|---|---|---|
| Нет client_id в заказе | Заказ не связывается с визитом | Невозможна сквозная аналитика | Передавать идентификатор в параметр заказа |
| Дубли транзакций | Заказов больше, чем в CRM | Завышение выручки и конверсии | Дедупликация по transaction_id |
| Не учтены возвраты | Выручка выше фактической | Неверная unit-экономика | Событие refund и сверка с CRM |
| Разные валюты | Суммы несопоставимы | Ошибка в расчёте маржи | Единая валюта и курс на дату |
| Нет разбивки по устройствам | Мобильные и десктоп вместе | Скрытые противоположные эффекты | Обязательное измерение device |
| Нет сверки с CRM | Расхождение не замеряется | Решения по неверным данным | Еженедельная сверка заказов |
Сверку с CRM ставят первой: она дешёвая и сразу показывает, можно ли вообще доверять остальным отчётам.
Как проверить настройку за один день
- Сверка заказов. Число и сумма заказов в GA4 против CRM за последние семь дней. Допустимое расхождение — до 10%.
- Сверка воронки. Есть ли все пять событий и не обрывается ли цепочка на каком-то шаге.
- Проверка дублей. Повторные transaction_id в выгрузке — признак неисправной передачи.
- Проверка устройств. Есть ли данные по мобильным и десктопу раздельно.
- Проверка возвратов. Появляются ли refund в данных и влияют ли они на выручку.
FAQ: GA4 для e-commerce
Почему в GA4 меньше заказов, чем в CRM?
Три причины: часть заказов оформляется по телефону или в офлайне, часть теряется при блокировке счётчика, часть не доезжает из-за ошибок передачи. Норма — до 10% расхождения, всё остальное требует разбора.
Обязательно ли передавать transaction_id?
Да. Без него нельзя удалить дубли и нельзя сверить данные с CRM — а значит, нельзя доверять ни выручке, ни конверсии, ни расчёту unit-экономики.
Нужно ли настраивать пользовательские параметры?
Только те, по которым вы принимаете решения. Обычно это идентификатор клиента, источник заказа и тип устройства. Остальное захламляет отчёты.
Как учитывать возвраты?
Событием refund с указанием transaction_id и суммы. Без этого выручка в отчёте выше фактической, а экономика считается по завышенной базе.
Можно ли обойтись без серверной передачи данных?
Можно, но с потерями: блокировщики и ограничения браузеров съедают часть заказов. Серверная передача нужна там, где точность выручки критична.
Как часто проверять настройку?
Сверку заказов — еженедельно, полную проверку — раз в квартал и обязательно после каждого релиза: именно выкладки чаще всего ломают передачу событий.