Driveback — 10 причин расхождения транзакций в Google Analytics и CRM

Условие

Опишите 10 причин расхождения количества транзакций в Google Analytics и CRM (фактических заказов в системе компании).

Решение

Расхождение GA ↔ CRM — классика ecommerce. Каркас: «сбои сбора → различия в учёте → ботовый/тестовый трафик → таймзоны и периоды».

10 причин

1. AdBlock/трекинг-блокировщики. Часть посетителей блокирует gtag/measurement.js — транзакция не уходит в GA, но в CRM есть. Особенно для Firefox, Brave, iOS 14+ (ITP).

2. Failed gtag calls (race condition при window.unload). Пользователь покупает и быстро закрывает вкладку — beacon не успевает уйти. CRM имеет, GA — нет.

3. Sampling в GA UA (limited Session Quota): на больших объёмах GA показывает сэмплированные данные. В отчёте «миллионы», а в API — ошибка ±10%.

4. Дубли транзакций в GA: если страница thank-you перезагружена, событие purchase отправляется ещё раз. CRM фиксирует один заказ — GA два.

5. Разные таймзоны и периоды: GA — таймзона аккаунта (часто UTC или Pacific), CRM — таймзона компании. Заказ в полночь по Москве может попасть в разные сутки.

6. Разные определения «успешной транзакции»:

   • В CRM — всё подтверждённые/оплаченные/доставленные?
   • В GA — все, кто дошёл до thank-you, включая отмены, fraud, returns.

7. Возвраты, отказы, отмены: в CRM поток «order placed → cancelled» = 0 для финансов, в GA purchase уже отправлен и не «исчезает».

8. Internal/test orders: тестовые заказы менеджеров, internal-IP → должны фильтроваться в GA, но часто не настроено. В CRM — есть флаг is_test.

9. Bot-трафик: GA отправляет события от botов (особенно если нет фильтра bots), CRM по факту покупки — нет.

10. Cross-domain / iframe / SPA: переход на чекаут в другом домене (например, payment.example.com), tag не сконфигурирован — transaction event не отправляется. Single-page app без manual page_view tracking теряет события.

Бонус (часто встречаются)

• Cookie consent banner: пользователь не согласился — события не идут.
• Different identifier domains: transactionId в GA = order_uuid, в CRM = order_number — мэппинг не однозначный.
• Транзакции без deduplication: при ретраи сервера заказ отправляется в GA дважды (server-side gtag).
• Партиальный fail GA пайплайна: измерительный сервер недоступен 30 минут — данных нет, в CRM — есть.
• GA4 vs UA differences: после миграции на GA4 — другая семантика purchase (event-based, не transaction-based) — численно разница до 5–10%.

Проверка / диагностика

-- Сравнение по дню
SELECT d.day, ga.tx_count AS ga_tx, crm.tx_count AS crm_tx,
       (ga.tx_count - crm.tx_count) * 1.0 / NULLIF(crm.tx_count, 0) AS rel_gap
FROM ga_daily ga JOIN crm_daily crm USING (day)
ORDER BY day;

Если rel_gap стабильно ~5% — это «нормальная погрешность от blockers». Если скакнул в день X — баг в коде (часто после релиза).

Дальше:

• сверьте по transaction_id (LEFT JOIN GA → CRM): какие из CRM не нашли в GA;
• проверьте sources: блокировщики чаще на iOS Safari + macOS Firefox;
• проверьте мобильные приложения — там SDK + другие гремлины.

Подводные камни

1. Не отвечать «GA сэмплирует» в одно слово — это лишь одна причина.
2. Не путать UA (sessions, transactions) и GA4 (events) — модели отличаются.
3. «Возвраты» — это не баг GA, это разные определения.

Эталонный ответ

10 причин: AdBlock/ITP, race-condition, sampling, дубли gtag, разные таймзоны, разные определения «успеха», cancels/returns, тестовые заказы, боты, SPA/cross-domain. Расследование начинается с join по transaction_id и поиска систематического смещения.