Симптом «продажі є, а в GA їх удвічі менше» майже ніколи не має однієї причини. Це сума кількох дірок, кожна з яких забирає свою частку. Нижче — як я їх розділяю і як доводжу цифрою, а не припущенням. Дані на схемі — навчальний приклад, щоб було видно сам метод.
Аудит починається не з GTM, а з опорної цифри: скільки замовлень насправді було. Її дає ваша CRM або адмінка магазину за той самий період. Далі кожен наступний рівень зіставляється з попереднім — і стає видно, на якому саме кроці зникають події.
| Перехід | Типова причина втрати | Чим доводжу | Частота |
|---|---|---|---|
| CRM → dataLayer | подія purchase не стріляє на частині сценаріїв: оплата карткою повертає на іншу сторінку подяки, замовлення в один клік, оформлення з кошика в мобільній версії, замовлення менеджером по телефону |
перелік усіх сценаріїв оформлення + прохід кожного вручну з відкритим Preview | дуже часто |
| CRM → dataLayer | подія стріляє, але без transaction_id або з новим id при перезавантаженні сторінки подяки — GA4 ріже дублі або, навпаки, плодить їх |
звірка id у dataLayer з номером замовлення в CRM на вибірці | дуже часто |
| dataLayer → тег GTM | тригер прив'язаний до Page View замість Custom Event: push приходить після того, як тег уже відпрацював — гонка, яка губить події нерівномірно |
Preview + порядок подій у Tag Assistant на реальному замовленні | дуже часто |
| dataLayer → тег GTM | Consent Mode: до згоди на куки теги не стріляють, а банер частина людей просто не чіпає | порівняння частки подій у розрізі стану згоди | часто |
| тег → GA4 | блокувальники реклами і браузери з жорстким захистом ріжуть запити до google-analytics.com — на українському трафіку це відчутна частка |
порівняння кількості подій із серверним джерелом за той самий період | часто |
| тег → GA4 | людина закриває вкладку одразу після оплати, запит не встигає піти | перевірка, чи використано sendBeacon, і затримки редіректу |
часто |
| GA4 → звіт | події доходять, але не рахуються як покупки: не той параметр currency, value рядком замість числа, порожній масив items |
DebugView на живій покупці + сирі дані в BigQuery | дуже часто |
| GA4 → звіт | внутрішній трафік і боти відфільтровані надто широко, або навпаки — сесії склеюються і атрибуція розмазує конверсії | перевірка фільтрів потоку даних і налаштувань атрибуції | рідше |
Беру вивантаження замовлень із CRM за конкретний період і фіксую: скільки замовлень, на яку суму, у якій валюті, які статуси рахуємо продажем. Без цієї цифри перевіряти немає з чим.
Виписую кожен шлях, яким у вас узагалі може виникнути замовлення, і проходжу кожен руками з увімкненим GTM Preview. Саме тут зазвичай і виявляється найбільша діра — один зі сценаріїв просто не має події.
Заповнюю ту саму лінійку, що на схемі вище, вашими числами. На виході — не «щось губиться», а «стільки-то відсотків тут, стільки-то там», кожна частка з доказом.
Пишу так, щоб розробник міг узяти і зробити, не ставлячи уточнень: точна структура
dataLayer.push по кожній події, типи полів, у який момент життя сторінки
стріляти, що робити з transaction_id при перезавантаженні, як поводитися
до отримання згоди. Плюс критерій приймання по кожному пункту.
Коли розробники зроблять — проходжу ті самі сценарії ще раз і перезбираю лінійку на свіжому періоді. Показую ту саму таблицю «було / стало» по кожному рівню.
Частина втрат від блокувальників у браузері не лікується налаштуванням тегів у принципі. Тоді рішення — серверний GTM: сайт шле подію на ваш власний домен, а вже звідти вона йде в GA4. Це окрема робота і вона потребує вашої інфраструктури, тому я не пропоную її наосліп — спершу міряю, скільки саме цей канал вам поверне, і показую цифру. Якщо повертає мало, чесно скажу, що не варто.
Не обіцяю «буде 100% збігу з CRM». Такого не буває ні в кого: частина людей фізично не доносить подію до Google. Обіцяю інше — назвати кожну частку втрат окремо, прибрати ті, що прибираються, і показати цифрою, скільки залишилося і чому саме стільки. Різниця між «у нас сходиться» і «ми знаємо, чому не сходиться, з точністю до відсотка» — це і є результат аудиту.