Як DataLayer GA4 визначає, чи є ваші аналітики справжніми
Пояснює, як dataLayer з’єднує веб-сайти та GTM із GA4, чому прості події порушують звітність у сфері е-комерції, та як правильно структурувати та відлагоджувати даних-пакети.
Джерела: **The DataLayer Is the Most Important Thing in Your GA4 Implementation**
Усі одержимі панелями керування GA4. Майже ніхто не звертає уваги на десять рядків JavaScript, які визначають, чи говорять ці панелі правду.
add_to_cart. Цифра становить 4 200. У той же час показник доходу в звіті про електронну комерцію дивно близький до нуля. Поширюється плутанина. Створюється тема в Slack. Зрештою хтось пише „людині з аналітикою“. Ця людина вже підозрює, що сталося, ще до того, як відкриє Tag Manager.
Подія була викликана, але не містила жодної інформації.
Це найпоширеніша проблема під час налаштування GA4, і, як не дивно, вона майже не пов’язана з самим GA4. Справжня проблема криється на рівень нижче, у простому масиві JavaScript, який більшість початківців знають за назвою, але рідко розуміють на практиці: dataLayer.
Ця стаття присвятована саме цьому масиву. Це не загальний огляд процесу „налаштування GA4“, а єдиний фактор, який визначає, чи є ваш весь механізм вимірювання надійним, чи лише декоративним.
Спочатку — карта
Перш ніж писати будь-який код, корисно побачити реальний шлях, яким проходять ваші дані:
Веб-сайт
↓
dataLayer
↓
GTM (Google Tag Manager)
↓
GA4
Корисною аналогією є замовлення їжі в переповненому та шумному ресторані:
Веб-сайт — це кухня: місце, де відбувається справжня робота, наприклад, коли клієнт натискає «Додати до кошика».
dataLayer — це чек замовлення, який шеф прикріплює до картки; він нічого не готує, а просто фіксує точно те, що було приготовано, для кого та з якими змінами.
GTM — це сервер: він читає цей чек, визначає, які етапи (теги) потребують інформації, та передає її далі.
GA4 — це бухгалтерський облік ресторану: він фіксує все, що сталось, але лише на основі того, що було фактично записано у отриманому чеку.
Якщо кухня просто оголошує „Хтось замовив щось!“ у кімнаті без письмового замовлення, офіціант не має нічого конкретного, що можна було б передати, і в журналі операцій з’являється порожній галочок замість справжньої транзакції. Саме так виглядає у практиці проста подія без параметрів. Замовлення — це даний, який надсилається через dataLayer, і саме він перетворює всю цю структуру на справжню систему, а не на гру в здогадки.
Що таке dataLayer насправді
Якщо позбутися жаргону, dataLayer — це просто звичайний масив JavaScript, приєднаний до window, у який ваш сайт додає звичайні об’єкти. Ось і весь механізм. Не існує жодного вбудованого з’єднання з Google — принаймні доки скрипт контейнера Tag Manager не під’єднає до нього слухача.
Ініціалізація зазвичай виглядає так: window.dataLayer = window.dataLayer || [];
Ця одна рядок робить щось більш тонке, ніж здається. Він не просто створює новий масив, видаляючи все, що вже там є — він перевіряє наявність існуючого масиву та ініціалізує новий лише у разі його відсутності. Саме цю помилку неодноразово вказували досвідчені користувачі GTM: якщо присвоювати значення до dataLayer безпосередньо за допомогою знака =, а не додавати елементи до нього, це тихо порушує механізм, від якого залежить GTM, адже щойно завантажується скрипт-контейнер, GTM перевизначає вбудований метод push() масиву. Зробіть цю помилку хоча б один раз — а це робить майже кожен — і ви можете провести цілий день, намагаючись зрозуміти, чому контейнер „просто не працює“, без жодних помилок, які б вказали на причину.
Після того, як скрипт GTM виконується на сторінці, він підключається до методу push(). З цього моменту кожен об’єкт, який ви додаєте, відображається у внутрішній моделі даних GTM — структурі, яка насправді керує його змінними та тригерами. На практиці GTM починає приділяти менше уваги самому необробленому масиву та замість цього стежить за точкою входу, через яку проходить кожен запит push.
Чому початківцю варто цим цікавитися? Тому що це змінює те, що насправді означає виклик dataLayer.push(). Ви не „надсилаєте подію до Google Analytics“. Ви записуєте структурований запис із часовою міткою у власній пам’яті вашого сайту — запис, який будь-який інструмент може використати пізніше, чи то GTM, платформа для обробки даних клієнтів, піксель Facebook чи якийсь інший аналітичний сервіс, який ви ще не впровадили. GA4 — це просто один із багатьох споживачів цих даних.
Чому взагалі існує dataLayer
Цілком логічне запитання: чому б просто не активувати функцію відстеження GA4 безпосередньо у обробнику події onclick кнопки? Люди робили саме це протягом багатьох років, коли analytics.js та gtag.js були стандартним підходом. У вузькому сенсі це працює. Але цей підхід крихкий саме тоді, коли починається масштабування.
dataLayer існує для того, щоб розділити два аспекти, які ніколи не повинні бути тісно пов’язані між собою: що насправді відбулося на сайті та який інструмент аналітики саме в цей момент працює.
По суті, dataLayer призначений для зберігання будь-якої інформації, яку ви хочете передати зі свого сайту до будь-якого підключеного інструменту — причина його існування полягає у тому, що отримання однакових даних безпосередньо з маркапу страниці є ненадійним, оскільки цей маркап може змінюватися з причин, які зовсім не пов’язані з відстеженням. Іншими словами, ваша команда з розробки продукту повинна мати свободу переробити кнопку „Додати до кошика“, змінити її клас чи сховати її всередині модального вікна, а система відстеження не повинна цього помічати чи перейматися — тому що вона з самого початку не читала цю кнопку. Вона читала навмисно створений, чітко описаний звіт про те, що відбулося.
Ось суттєва різниця між вилученням підказок зі сторінки силою та прямим отриманням фактів. Силиваний підхід руйнується в момент зміни структури сторінки. Пряме отримання фактів залишається ефективним під час переробок, тестів типу A/B, міграцій фреймворків та зміни персоналу, адже угода зберігається безпосередньо в самому сигналі, а не десь у DOM.
Тепер код, який все змінює
Ось описаний у аналізі сигнал:
Порівняйте це з тим, що зазвичай робить початківець: підключає тег GTM безпосередньо до події кліку, повністю ігноруючи об’єкт dataLayer, з тригером, який фактично говорить: «коли хтось натискає цю кнопку, відправте тег add_to_cart до GA4».
На перший погляд обидва методи здаються такими, ніби вони „створюють подію add_to_cart“. Якщо відкрити звіт у реальному часі GA4, можна побачити ідентичні рядки з позначкою add_to_cart у кожному випадку. Саме це робить різницю між ними настільки ризикованою: вона залишається прихованою, поки хтось не спробує отримати дані, які мали б супроводжувати цю подію.
Ось справжня різниця, пояснена детальніше:
Чесно кажучи, ця єдина таблиця — це суть усього цього опису в скороченому вигляді. Подія без доданих параметрів — це просто позначка, яку немає чим підтвердити. Це як різниця між свідком, який каже „щось сталося“, та тим, хто каже „червоний седан проїхав на червоне світло о 16:12“. Лише друга версія має значення в суді, і лише друга версія допомагає членам ради прийняти рішення про те, чи варто продовжувати фінансувати певну лінійку продуктів.
Подія проти параметра: те, що плутають початківці
У моделі GA4 кожен запит містить саме одну назву події (add_to_cart), а при правильному налаштуванні — набір параметрів події (product_id, product_name, price тощо).
Подія вказує на категорію того, що сталось. Параметри розкривають деталі цього конкретного випадку.
Початківці часто сприймають назву події як повну інформацію. Це не так; це лише заголовок. Сама назва add_to_cart майже нічого не говорить про конкретику: не вказує, який саме товар, його ціну, кошик чи валюту, а також те, чи була дія здійснена на сторінці пошуку чи в розділі з пов’язаними товарами. Усі ці відповіді знаходяться у параметрах, і жодна з них не надходить автоматично — GA4 не має змоги самостійно вивести, здогадатися чи отримати цю інформацію.
Це також пояснює, чому просте „створення події“ за допомогою магістралей та тригерів GTM, без налаштування жодних змінних, дає результат, який виглядає повним, хоча структурно є порожнім. Подія виконується, у звіті з’являється рядок, і все здається гаразд, поки хтось не запитає про середню вартість товарів у кошику минулого місяця — тоді вже немає що відповісти.
Дані е-комерції: де ігнорувати це вже неможливо
Звичайні події взаємодії, такі як перегляди сторінок, відстеження прокрутки чи звичайні кліки, можуть дозволяти собі певну нестачу деталей. Події е-комерції — ні. Увесь звітній механізм е-комерції в GA4, який охоплює дохід, кількість переглядів товарів, співвідношення додавань до кошика та покупок, а також ефективність кожного продукту, залежить від подій на кшталт add_to_cart, view_item, begin_checkout та purchase, які мають надаватися разом із належним чином структурованим масивом items та параметрами на рівні транзакції.
Якщо під час передачі даних у dataLayer бракує масиву items, який містить item_id, item_name, price та quantity для кожного товару, GA4 не може автоматично заповнити цю прогалину. У його звітах про е-комерцію будуть відображатися нулі та порожні клітинки поруч із кількістю транзакцій, яка явно дорівнює не нулю. Саме така неузгодженість — записані транзакції без відповідного доходу — є однією з найчастіше повідомлених проблем у налаштуваннях GA4, і майже завжди вона пов’язана з однією причиною: неповним об’єктом, який передається у dataLayer.
Саме тому зрілі реалізації дотримуються схеми ecommerce dataLayer, визначеної Google, замість того щоб створювати власні назви полів. Це не формальності заради них самих; це спільна мова, яка використовується вашим сайтом, вбудованими змінними е-комерції GTM та звітами про е-комерцію GA4. Якщо ви відхилитеся від цієї схеми, наприклад, назвавши поле item_price замість price або розмістивши об’єкт на один рівень глибше, ніж очікується, вбудовані змінні просто не зможуть знайти ваші значення, навіть якщо дані фактично знаходяться там.
Скористання власних змінних: як змусити GTM правильно читати ваші події
Хоча інформація потрапляє до dataLayer у правильний спосіб, GTM все одно потребує вказівок щодо того, де її шукати. Саме для цього існують Змінні шару даних: це іменовані посилання, які наказують GTM шукати певний ключ, наприклад price, у об’єкті, який щойно було додано, та передавати це значення будь-якій тегу, яка його запитує.
Коли щось додається до dataLayer, GTM не сканує сам масив у пошуках даних для заповнення змінних. Натомість він читає інформацію зі своєї внутрішньої моделі даних, яка заповнюється на основі цих доданих даних. Змінні шару даних посилаються на цю внутрішню модель, а не безпосередньо на масив, що захищає процес розрішення змінних GTM у разі, якщо інший скрипт пізніше змінить або перезапише цей масив.
Практично кажучи, це означає, що для кожного поля, яке ви передаєте — такого як product_id, product_name та price — особа з доступом до контейнера GTM мусить створити відповідну змінну Data Layer та потім прив’язати її до відповідного параметра у тегу події GA4. Якщо пропустити цей крок, не має значення, наскільки ретельно ви передали дані через dataLayer: GTM все одно запустить подію згідно з інструкціями, але не надішле жодних додаткових деталей, просто тому, що йому не сказано, які поля взяти.
Це друга причина, одразу після слабких або відсутніх передач даних, через яку команди зазвичай втрачають інформацію: правильно налаштована передача даних через dataLayer, але тег GTM, який ніколи не налаштовувався для їх читання.
Відлагодження: як насправді перевірити все це
Ніколи не варто просто вірити, що ваш dataLayer робить те, що ви думаєте. Спостерігайте за процесом безпосередньо. Два інструменти полегшують це:
- Режим перегляду GTM. Він відображає кожну тег, яка була активована, кожен тригер, який перевірявся, а також, що найважливіше, кожен запуск dataLayer у послідовності, з можливістю розгортання повного вмісту кожного об’єкта. Якщо ціна відсутня у показаному тут запуску, вона ніколи не потрапить до GA4, і жодні зміни в налаштуваннях GTM не зможуть змінити цей результат.
Гарна звичка, яку варто сформувати: перш ніж припускати, що GTM не може „відстежувати щось“, спочатку перевірте консоль та подивіться на dataLayer. Якщо замовлення так і не було оформлене, не можна звинувачувати кухню у тому, що вона не приготувала страву.
Є ще одна, менш очевидна проблема під час дебаггінгу, на яку варто звернути увагу: внутрішня модель даних GTM зберігає лише останню значення, внесені для будь-якого конкретного ключа. Тож якщо два окремі скрипти на одній сторінці вносять суперечливі значення під ідентичним ключем до того, як активується ваш тег, той скрипт, який виконується останнім, тихо перезаписує інший. Це часта причина того, що відстеження працює нормально під час тестування, але не функціонує в продакшені, зазвичай через те, що якийсь сторонній скрипт, яким ви не керуєте, вносить свої дані після ваших.
Якість даних: те, що насправді захищає бізнес
Усе, про що йшлося досі, існує для досягнення однієї мети — створення даних, достатньо надійних для прийняття реальних рішень.
„Завжди використовуйте .push() з dataLayer.“ — Сімо Ахава, експерт Google Tag Manager
Це вузьке технічне правило, але воно відображає щось більше. Налаштування аналітики рідко зазнають краху одночасно. Вони поступово руйнуються — по одному несумісному ключу чи пропущеному полю — поки звіт, який раніше був надійним, просто перестає ним бути, часто без того, щоб хтось помітив саме момент цього.
Кілька практик допомагають відрізнити реалізацію, за якою можна справді складати звіти, від тієї, що лише здається функціональною:
- Сувора послідовність у найменуваннях. Якщо поле сьогодні називається product_id, після наступного циклу розробки — productId, а після ще однієї переробки — item_id, у результаті утворюються три несумісні версії даних, які неможливо об’єднати в один запит.
Розглядати якість даних як одноразову перевірку не враховує суті проблеми. Це більше схоже на систему водопостачання: її не помічають, поки все працює правильно, але як тільки виникають проблеми, це стає дуже помітним та дорогим.
Висновок
Справжньою причиною плутанини є не GA4 та не GTM, хоча їх постійно звинувачують. Усе зводиться до простішого запитання: чи фіксував ваш веб-сайт коли-небудь чітко те, що насправді відбулося?
Виклик методу dataLayer.push({ event: "add_to_cart", ... }) — це не дрібний технічний нюанс, і його не можна ототожнювати з простим проходженням майстра налаштувань GTM та вважанням, що робота завершена. Це різниця між бізнесом, який може точно сказати, що робили його клієнти та яка була цінність цих дій, та тим, хто може лише знизати плечима та сказати, що щось відбулося чотири тисячі двісті разів, не знаючи чого саме.
Панелі керування знаходяться нижче в цьому ланцюгу. Саме у dataLayer спочатку записується правда або припущення, яке її замінює.
Якщо наступний звіт GA4 здається некоректним, пропустіть інтерфейс GA4. Відкрийте консоль, введіть dataLayer та перегляньте запис самостійно.