Чому виручка в GA4 не збігається з CRM: 9 причин і як звірити

«У GA4 за вересень 1 120 замовлень, а в CRM — 1 390. Кому вірити?» Це, мабуть, найчастіше запитання на старті будь-якого проєкту. Коротка відповідь: гроші — за CRM, поведінка — за GA4. Але розбіжність треба розуміти і контролювати, бо вона іноді сигналізує про реальну поломку.

#Нормальна і ненормальна розбіжність

GA4 — система аналітики браузера, а не бухгалтерія. Невелика розбіжність неминуча. Тривожні ознаки:

• розбіжність раптово зросла (було 5%, стало 20%);
• у GA4 замовлень більше, ніж у CRM (дублікати);
• розбіжність різна за пристроями або способами оплати.

#9 причин розбіжностей

#1. Блокувальники реклами і браузерні обмеження

Частина відвідувачів блокує скрипти аналітики. Їхні покупки є в CRM, але не в GA4.

#2. Відмова від cookies (consent mode)

Якщо користувач не дав згоди, GA4 отримує обмежені сигнали або не отримує нічого — залежно від налаштувань (consent mode).

#3. Оплата на сторінці платіжного сервісу

Клієнт оплатив на сторінці LiqPay, monobank чи WayForPay і закрив вкладку, не повернувшись на «Дякуємо». Подія purchase на сайті не спрацювала. Лікування — серверна подія після callback платіжки (серверний трекінг).

#4. Замовлення поза сайтом

Телефон, месенджери, Instagram Direct, маркетплейси, менеджер вручну вносить у CRM. GA4 їх ніколи не побачить — і не має.

#5. Дублікати purchase

Оновлення сторінки «Дякуємо», повернення на неї з листа, подвійний тег (модуль платформи + GTM). Наслідок — у GA4 більше замовлень.

#6. Статуси і повернення

CRM показує оплачені й невідмінені; GA4 — всі оформлені. Якщо refund не відправляється, повернені замовлення лишаються в GA4.

#7. Дата замовлення і часовий пояс

GA4 записує подію в часовому поясі ресурсу на момент оформлення; CRM може рахувати за датою оплати або в іншому поясі. На межах днів і місяців цифри «з'їжджають».

#8. Валюта і податки

value з ПДВ на сайті і без — у CRM; доставка включена в одній системі і ні в іншій; не передається currency, і GA4 ігнорує суму.

#9. Тестові та внутрішні замовлення

Тести менеджерів і розробників у GA4 без фільтра внутрішнього трафіку.

#Як звіряти: щотижнева процедура

1. Порівняти кількість замовлень і виручку за тиждень: CRM vs GA4 (в BigQuery, не в інтерфейсі).
2. З'єднати за transaction_id — знайти ID, які є лише в одній системі.
3. Згрупувати «втрачені» замовлення за способом оплати, пристроєм, джерелом.
4. Знайти дублікати в GA4.

-- замовлення з CRM, яких немає в GA4 (BigQuery)
WITH ga AS (
  SELECT DISTINCT ecommerce.transaction_id AS id
  FROM `project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260921' AND '20260927' AND event_name = 'purchase'
)
SELECT c.payment_method, c.device, COUNT(*) AS missing
FROM `project.crm.orders` c
LEFT JOIN ga ON ga.id = c.order_id
WHERE c.order_date BETWEEN '2026-09-21' AND '2026-09-27'
  AND c.status = 'paid' AND ga.id IS NULL
GROUP BY 1, 2
ORDER BY missing DESC;

Якщо «втрачені» сконцентровані в одному способі оплати — проблема в редиректі з платіжки. Якщо на iOS — у браузерних обмеженнях або помилці скрипта на мобільному checkout.

#Що показувати в дашборді

• «Покриття трекінгу»: частка замовлень CRM, знайдених у GA4, за тижнями — як технічна метрика якості;
• окремо — частка замовлень без джерела;
• виручку, ROAS і юніт-економіку рахувати за CRM, а GA4 використовувати для воронки й поведінки.

#Чекліст звірки

• transaction_id у GA4 дорівнює ID замовлення в CRM
• Захист від повторного purchase
• Серверне підтвердження оплачених замовлень
• refund для повернень
• Однакові правила ПДВ і доставки у value
• Внутрішній трафік відфільтровано
• Платіжні домени у виключених рефералах
• Щотижнева метрика покриття трекінгу

#Приклад: звіряємо один тиждень

Ілюстративні числа за тиждень:

Йдемо від оплачених у CRM до GA4, по одній причині:

Коли в кожного кроку є число, розбіжність перестає бути загадкою і стає списком задач. Тут захист від перезавантаження — швидке виправлення, оплатам на зовнішній сторінці потрібен серверний трекінг, а розрив через згоду легітимний — його просто треба задокументувати.

У розбіжності виручки зазвичай є ще одна складова: value у GA4 може по-іншому, ніж CRM, враховувати доставку і ПДВ. Порівняйте середній чек в обох джерелах для замовлень, що є в обох. Якщо він систематично різний — це проблема визначення, а не втрачених замовлень.

#SQL: зіставлення на рівні замовлень

З експортом у BigQuery зіставляйте замовлення по одному, а не порівнюйте підсумки:

WITH ga AS (
  SELECT ecommerce.transaction_id AS order_id,
         COUNT(*)                    AS ga_events,          -- >1 означає дублі
         MAX(ecommerce.purchase_revenue) AS ga_value
  FROM `project.analytics_123456.events_*`
  WHERE _TABLE_SUFFIX BETWEEN @from AND @to AND event_name = 'purchase'
  GROUP BY 1
)
SELECT
  CASE
    WHEN ga.order_id IS NULL AND o.source = 'phone'     THEN 'офлайн-замовлення'
    WHEN ga.order_id IS NULL AND o.payment_redirect     THEN 'зовнішня оплата без повернення'
    WHEN ga.order_id IS NULL                             THEN 'немає (згода/блокувальник/помилка)'
    WHEN ga.ga_events > 1                                THEN 'дубль у GA4'
    WHEN ABS(ga.ga_value - o.revenue_net) > 1            THEN 'різна сума'
    ELSE 'збіг'
  END AS status,
  COUNT(*) AS orders,
  SUM(o.revenue_net) AS crm_revenue
FROM clean.orders o
LEFT JOIN ga ON ga.order_id = o.order_id
WHERE o.status = 'paid' AND o.order_date BETWEEN @from_date AND @to_date
GROUP BY 1 ORDER BY orders DESC;

Зробіть і зворотну перевірку: ID транзакцій GA4, яких взагалі немає в CRM. Зазвичай це тестові замовлення, скасовані, які порахували на оформленні, або тег, що спрацьовує не на тій сторінці.

#Яке число куди

Найчастіша помилка у звітах — виручка GA4 на тому ж екрані, що й виручка CRM, без підписів. Показуйте одне число про гроші, а GA4 — для поведінки і часток.

#Час: чому «вчора» ніколи не збігається точно

Навіть за ідеального трекінгу щоденні числа розходяться з причин, що не мають стосунку до втрачених замовлень:

• Часові пояси. Ресурс GA4 звітує в налаштованому поясі, CRM може зберігати час в UTC. Замовлення о 23:30 за місцевим часом може потрапити на різні дати.
• Дата створення чи оплати. GA4 фіксує момент спрацювання purchase. CRM може датувати замовлення створенням, оплатою чи відправкою. Оплата на рахунок і накладений платіж надходять через кілька днів.
• Затримка обробки. Дані GA4 за останні день-два ще можуть змінитися. Звіряйте із запізненням у 2–3 дні, а не за вчора.
• Повернення і редагування. CRM оновлює замовлення при частковому поверненні чи редагуванні. GA4 зберігає початкову покупку, якщо ви не надсилаєте подію refund.
• Накладений платіж. У бізнесах, де значна частка замовлень оплачується при отриманні, «оплачено» настає лише після доставки, а частина посилок повертається. Порівнюйте GA4 з усіма оформленими онлайн-замовленнями, а гроші — окремо з викупленими.

Тому я звіряю тижневі підсумки із запізненням у 3 дні і позначаю лише розбіжності, що виходять за очікуваний діапазон для кожної причини. Щоденне порівняння здебільшого дає хибні тривоги.

#Розумна ціль

Універсального «прийнятного» відсотка немає: він залежить від частки телефонних замовлень, способів оплати і рівня згоди. Практичний підхід — виміряти розбіжність протягом кількох «чистих» тижнів, пояснити кожну складову, як у прикладі вище, і далі сповіщати, коли росте непояснена частина. Стабільна пояснена розбіжність — це нормально. Розбіжність, що раптово змінилася, означає, що щось зламалося.

#Часті запитання

#Яка розбіжність між GA4 і CRM нормальна?

Залежить від аудиторії, частки офлайн-замовлень і налаштувань згоди. Важливіше за абсолютне значення — стабільність: різкий стрибок означає поломку.

#Чи можна «дотягнути» GA4 до 100%?

Ні, і не треба. Ціль — зрозуміла, стабільна розбіжність і гроші за CRM.

#Як рахувати ROAS, якщо GA4 не бачить частини замовлень?

Брати виручку з CRM і атрибутувати за UTM, збереженими разом із замовленням. Тоді покриття GA4 менш критичне (атрибуція).

#Чи допоможе серверний трекінг?

Він закриває частину втрат (оплата на сторонніх сторінках, блокувальники клієнтських скриптів), але згоди користувача все одно треба поважати.