Топ-14 помилок у роботі з Google Tag Manager та як їх уникнути

Декілька років тому я проводив відкритий вебінар на тему найпопулярніших помилок в Google Tag Manager, але з тих пір пройшло вже багато часу: кількість популярних помилок, які я зустрічаю, зросла, а вебінар бачили не всі. Тому вирішив зібрати оновлену версію найчастіших помилок у текстовому форматі.

Ця стаття не дуже складна, але все ж орієнтована на людей, які вже мають досвід роботи з GTM. Якщо ви тільки починаєте своє знайомство з цим прекрасним інструментом - то для початку рекомендую ознайомитись із моїми іншими матеріалами:

• Що таке Google Tag Manager, навіщо він потрібен і як його використовувати у бізнесі. Основи роботи з GTM
• Як підключити Google Analytics 4 (Google Tag) через Google Tag Manager
• Відстеження кліків на посилання за допомогою Google Tag Manager: Практичний посібник з прикладами
• Відстеження кліків на елементи сайту за допомогою Google Tag Manager: Розширений посібник
• Відстеження скролінгу на сторінках за допомогою Google Tag Manager: Розширений посібник
• Відстеження відправки форми за допомогою базового тригера GTM
• Відстеження відправки форми за допомогою тригера Видимість елемента
• Відстежуємо взаємодію користувачів із формами за допомогою Google Tag Manager

Нижче повний перелік помилок, про які я хочу поговорити сьогодні:

• Помилка 1. Відправляти івенти по кліку на кнопку, а не при фактичній відправці форми
• Помилка 2. Налаштовувати тригери, використовуючи змінну Click Text
• Помилка 3. Публікувати версії замість використання режиму попереднього перегляду
• Помилка 4. Не вказувати назву версії при її створенні
• Помилка 5. Вважати, що якщо тег запущено, дані 100% були успішно відправлені в потрібну систему
• Помилка 6. Плутати змінні Page URL і Page Path
• Помилка 7. Не використовувати регулярні вирази і думати, що чим більше тригерів та тегів, тим краще
• Помилка 8. Не використовувати CSS-селектори і замість цього бігати до розробників, щоб вони додали ID до елементів
• Помилка 9. Думати, що кнопка завжди складається з одного елементу
• Помилка 10. Забувати, що CSS-селектори мають властивість змінюватись з часом
• Помилка 11. Невірне або частково використовувати dataLayer
• Помилка 12. Ігнорувати налаштування Consent Mode, які змінюють правила гри
• Помилка 13. Давати доступ на рівні акаунту GTM, а не на рівні контейнера
• Помилка 14. Не використовувати GTM, бо він погано впливає на швидкість сайту
• Замість висновку

Розпочнемо. Усі помилки ми будемо розглядати за наступним планом:

• В чому проблема
• Можливі рішення

Помилка 1. Відправляти івенти по кліку на кнопку, а не при фактичній відправці форми

Так, так, вам не здалося. Це одна з найпопулярніших помилок.

У чому проблема?

Давайте розглянемо приклад реальної форми на сайті proanalytics.academy та розберемо в чому тут проблема.

Якщо людина заповнює два поля: ім’я й контакти та натискає кнопку “Відправити” - форма відправляється. Тому з першого погляду може здатися, що відслідкувати клік на таку кнопку достатньо для трекінгу конверсії. Але насправді це не так.

Уявіть наступну ситуацію: людина заповнила ім’я, але забула електронну пошту. Тоді після кліку на кнопку “Відправити” з’являється помилка, і форма не відправиться.

Якщо тригер для тега в GTM налаштовано на клік на кнопку, то цей “порожній” клік фіксуватиметься в аналітиці як відправка форми. Саме тому подібне налаштування є НЕправильним.

Найчастіші причини такої помилки:

• Люди просто не знають, як налаштувати іншим чином, тому відстежують просто клік на кнопку відправки. Як ми вже зрозуміли, це неправильно, бо клік не завжди дорівнює відправці форми.
• Люди знають, як відстежувати форму, але все одно налаштовують її некоректно. Вони думають, що налаштували відстеження відправки форми, але фактично налаштували клік на кнопку. Чому так відбувається? Не всі форми зроблені правильно, а саме передають браузерну подію Submit в момент успішної відправки форми.

Яке рішення?

Незалежно від того, в яку категорію ви потрапляєте, для того щоб не допустити таку помилку, рішення одне: завжди потрібно перевіряти налаштування на пустій та напівпустій формі. Тобто спочатку ви намагаєтесь відправити форму, в якій не заповнені поля та перевіряєте, чи передається івент в аналітику. Потім заповнюєте частину і знову перевіряєте. Це дуже важливі кроки, про які багато хто забуває. Але потрібно тренувати себе та перевіряти всі варіанти: заповнену форму, напівзаповнену і пусту.

Помилка 2. Налаштовувати тригери, використовуючи змінну Click Text

У чому проблема?

Якщо потрібно відстежувати клік на кнопку або відправку форми (тільки що обговорили, чому останнє невірно, але факт в тому, що багато хто дійсно робить одразу дві помилки), багато людей вибирають змінну Click Text і налаштовують тригер на основі тексту кнопки. Тобто в умові прописують текст кнопки, наприклад, “Відправити”:

Це поганий варіант, оскільки дуже складно не пропустити якісь можливі сценарії. Поясню: на сайті можуть бути різні мовні версії, і текст кнопки буде змінюватися залежно від мови. Треба не забути перерахувати всі можливі варіанти. І звісно нормальний спеціаліст такі кейси не пропустить. Але є ще одна ситуація, про яку багато хто забуває - Google Translate та його аналоги. Користувачі можуть заходити з інших країн та використовувати перекладачі. Через це текст кнопки може змінитися для конкретного користувача на зовсім неочікуваний для вас варіант. Наприклад, з "Submit" на "申し出る". Це спричинить те, що івент не спрацює.

Яке рішення?

Не використовуйте Click Text для налаштування тригерів.

Не варто повністю відмовлятися від цієї змінної. В жодному разі. Її можна використовувати для передачі параметрів івенту, але НІКОЛИ не використовуйте змінну Click Text для налаштування тригерів. Краще опануйте роботу з CSS-селекторами.

Помилка 3. Публікувати версії замість використання режиму попереднього перегляду

У чому проблема?

Коли ви внесли певні налаштування в Google Tag Manager, важливо перевірити їх перед публікацією версії. Проте багато хто цього не робить. Причини різні: або поспішають, або дуже впевнені в тому, що вони точно не можуть помилятись, або просто не вміють користуватись режимом попереднього перегляду. У будь-якому випадку це веде до хаосу в GTM.

Коли ви публікуєте версію, створюється нова версія GTM. Чому ж тоді погано створювати окрему версію при кожній зміні? Кожна створена версія відображається на вкладці версій і коли потрібно зрозуміти момент де почали з'являтися певні помилки - доводиться перебирати всі ці версії, і, як наслідок, важче зрозуміти, де щось пішло не так. Наприклад, у мене на одному акаунті було шість версій за півгодини, і кожна була опублікована, хоча можна було просто скористатися режимом попереднього перегляду. Виглядало це приблизно ось так:

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

• Version 10 - Налаштував передачу івента успішної відправки форми для GA4
• Version 11 - Намагався налаштувати передачу івента успішної відправки форми для GA4, опублікував минулу версію, але зробив помилку в тригері, тому публікую ще одну з правками
• Version 12 - Налаштував передачу івента успішної відправки форми для GA4, тепер вже точно фінально
• Version 13 - Налаштував передачу івента успішної відправки форми для GA4 final final

Тому ми з вами підходимо до наступної помилки. Ах, точно, мало не забув про рішення.

Яке рішення?

Навчіться працювати з режимом попереднього перегляду.

Щоб перевірити свої налаштування, використовуйте кнопку Preview (Попередній перегляд). Вона дозволяє побачити зміни на сайті без публікації нової версії. Після натискання кнопки Preview (Попередній перегляд) ви бачите події на сайті і можете перевірити, чи все працює правильно, без публікації версії.

Помилка 4. Не вказувати назву версії при її створенні

У чому проблема?

Вище я вже писав, що історія версій дозволяє дуже зручно контролювати, що, коли та ким було зроблено в GTM. Оскільки з тег-менеджером зазвичай працює декілька спеціалістів у компанії, гарною практикою є ведення документації. Більшу частину цієї роботи тег-менеджер насправді робить за вас. Усе що залишається вам:

• вказувати зрозумілі назви для тегів, тригерів та змінних;
• вести Event Map (Карту подій);
• та вказувати назву версії під час публікації;

І якщо відсутність Event Map я не вважаю помилкою при роботі з Google Tag Manager (читайте нижче в примітці, чому), то відсутність назви версії точно є помилкою. Просто подивіться на скрін нижче - наскільки вам зрозуміло, які налаштування проводились у цьому менеджері тегів за останній рік?

Яке рішення?

Завжди при створенні версії вказуйте її назву. Звісно, добре ще вказувати й опис, але давайте почнемо хоча б з назви))

Помилка 5. Вважати, що якщо тег запущено, дані 100% були успішно відправлені в потрібну систему

У чому проблема?

Багато хто помилково вважає, що, якщо ваш тег в попередньому перегляді знаходиться у блоці Tags Fired - то код успішно виконався і дані відправлені в потрібну систему. Я не знаю, звідки з'явився цей міф, але це не так.

Якщо дослівно перекласти Tags Fired, отримаємо Теги запущено. Тобто, зверніть увагу, ніхто не говорить нам: Теги успішно виконані чи Дані відправлені до GA4. Все що нам кажуть, це те, що тег був запущений. Але ми памятаємо, що, хоча в більшості випадків в GTM ми використовуємо шаблони тегів, насправді під кожним із них ховається код. З огляду на це стає зрозумілим, що код може з якоїсь причини не виконати потрібну вам дію (наприклад ви вказали невірні дані в відповідні поля) або взагалі ваш кастомний код повернув помилку.

Ось один з таких прикладів: Тег був запущений, але виконався з помилкою. І це ще досить “легкий” кейс. У тому плані, що GTM нам допомагає і показує статус Failed.

Насправді можуть бути і складніші ситуації, коли, наприклад, код у тезі виконався успішно, статус Succeeded, але помилка була в самому коді - він не робив те, що задумав автор. Ну або коли тег виконався успішно, все було так, як задумано, але сервер, на який ви відправляли дані, не прийняв запит. Про всі такі ситуації ви не дізнаєтесь з наявності вашого тегу в блоці Tags Fired.

Яке рішення?

Рішення просте: на додаток до режиму попереднього перегляду в GTM використовуйте додаткові інструменти, наприклад:

• функціонал в інтерфейсі системи, в яку відправляєте дані для перевірки коректності відправки івентів, наприклад, DebugView в інтерфейсі GA4;
• інструменти розробника в браузері (мова про вкладку Network);
• спеціальні розширення для браузера (Meta Pixel Helper, Adswerve)

Помилка 6. Плутати змінні Page URL і Page Path

У чому проблема?

Часто бачу, що люди не розуміють різниці між цими змінними, і це призводить до некоректних налаштувань. Давайте розберемо приклад: ви хочете відстежувати івент лише на головній сторінці сайту, наприклад, клік на кнопку “Почати навчання”.

Я не буду ускладнювати зараз налаштування CSS-селекторами, тому уявимо, що нам достатньо тригеру, який ви бачите на скріні нижче:

Але це буде просто клік, без фільтра по сторінці. А нас, як ви пам'ятаєте, цікавить лише головна. Часто я зустрічаю налаштування, коли беруть URL з головної сторінки та використовують його в налаштуваннях тригера. Виглядає ось так:

Але це неправильно. Швидше за все, такий івент буде спрацьовувати лише в деяких випадках. Причина в тому, що Page URL, крім протоколу, домену та шляху сторінки, також містить GET-параметри. Про них в умові нічого не зазначено. Розумію, що може бути складно. Давайте на прикладі: якщо користувач перейде по лінку з UTM-міткою, наприклад. такою: https://proanalytics.academy/uk/utm_source=facebook&utm_medium=cpc

йому все ще покажеться головна сторінка, але тригер уже не спрацює. Оскільки https://proanalytics.academy/uk/ НЕ дорівнює https://proanalytics.academy/uk/?utm_source=facebook&utm_medium=cpc

Яке рішення?

Використовуйте змінну Page Path, оскільки вона містить лише шлях до сторінки, без GET-параметрів або інших частин URL. Тобто наше налаштування мало б виглядати так:

Помилка 7. Не використовувати регулярні вирази і думати, що чим більше тригерів та тегів, тим краще

У чому проблема?

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

Регулярні вирази дозволяють значно спростити налаштування. Наприклад, замість того, щоб створювати окремі тригери для кожної сторінки, де має спрацьовувати тег, можна використовувати регулярні вирази і об'єднати всі умови в один тригер. Це не лише заощаджує час, але й зберігає структуру контейнера чистою і зрозумілою.

Але у вас є дві мовні версії сайту: українська та англійська. Звісно, можна створити два окремі тригери, але це не дуже зручний варіант. У нашому випадку це лише дві сторінки, але що робити, якщо потрібно включити 4, 5 або 10 сторінок?

Яке рішення?

Навчіться використовувати регулярні вирази. Фінальне налаштування тригеру буде виглядати так:

Помилка 8. Не використовувати CSS-селектори і замість цього бігати до розробників, щоб вони додали ID до елементів

У чому проблема?

Багато хто налаштовує відстеження на основі класів або ID елементу, що знаходяться в коді. І, загалом, я не маю нічого проти такої практики. Проте буває так, що ID немає, а класи повторюються для кількох елементів, частина з яких не потрібна для відстеження. У таких випадках налаштування через ID або клас елемента може викликати проблеми. І зазвичай в таких випадках йдуть до розробників і просять їх додати певні ID до певних елементів. Але це потребує часу і наявності розробника, який може бути зайнятий або навіть відсутнім на проєкті.

Яке рішення?

Використовуйте CSS-селектори для відстеження будь-якого елемента, незалежно від верстки сайту.

CSS-селектори дають вам більше гнучкості і дозволяють відстежувати кліки на різні елементи, навіть якщо вони не мають унікальних ідентифікаторів. Дуже зручно, скажіть?

Знайти та скопіювати CSS-селектор можна в коді сайту, натиснувши правою кнопкою миші на потрібний елемент, а потім вибравши Inspect -> Клікнути правою кнопкою миші на код елемента -> Натиснути Copy -> Copy selector. І далі ви налаштовуєте тригер з умовою Click Element matches CSS selector [і власне ваш селектор]. Детальніше на скріні:

Проте що робити, якщо треба відстежити кліки на декілька схожих елементів? Тоді створювати 20 тригерів - не дуже раціонально використаний час. Відповідь знову криється в регулярних виразах, бо їх можна використовувати і в парі з CSS-селекторами.

Помилка 9. Думати, що кнопка завжди складається з одного елементу

Я часто бачу, як люди налаштовують відстеження кліків на кнопки і думають, що кнопка — це завжди один елемент. Але це не завжди так (сподіваюсь, вам ще не приїлась ця фраза, бо це тільки середина статті))). Давайте розберемо наступний приклад кнопки.

Виглядає як звичайна кнопка “Додати в кошик”, але давайте глянемо в код:

Тут видно, що кнопка складається з 3 елементів: власне сама кнопка (тег <button>), іконка (тег <i>) та текст “Add to Cart” (тег <span>). Іноді може бути й ще більше складових.

Чому це важливо? Якщо в налаштуваннях тригера ви вкажете лише один з елементів, наприклад, центральний текст, то відстежуватиметься лише текст, а кліки по краях кнопки — НІ. Зверніть увагу на скрін нижче для кращого розуміння: кліки в області, які не виділені, не будуть відстежуватися.

Яке рішення?

Перш за все візьміть собі за правило уважно досліджувати зі скількох елементів складається кнопка. Ну і, звісно, не забувайте вказувати всі можливі елементи в налаштуваннях тригера. Якщо ви налаштовуєте відстеження кліків за допомогою CSS-селекторів, можна використовувати такі рішення:

• Перерахуйте всі можливі селектори через кому. У моєму випадку це виглядатиме так:

#content > div.row > div > div > div.button-group > button:nth-child(1),#content > div.row > div > div > div.button-group > button:nth-child(1) > i,#content > div.row > div > div > div.button-group > button:nth-child(1) > span

• Використайте комбінацію CSSX,CSSX * для того щоб скоротити запис. Де CSSX - це селектор найвищого (батьківського) елементу. В моєму випадку тег <button>. Фінально буде виглядати так:

#content > div.row > div > div > div.button-group > button:nth-child(1),#content > div.row > div > div > div.button-group > button:nth-child(1) *

Останній варіант особливо актуальний, коли кнопка складається з великої кількості елементів.

Помилка 10. Забувати, що CSS-селектори мають властивість змінюватись з часом

У чому проблема?

Як би сильно я не полюбляв CSS-селектори, але в них є один мінус, який інколи може призвести до значних проблем з аналітикою: CSS-селектори з часом можуть змінюватись. Звісно, це не відбувається само по собі. Раніше я проводив паралель між селекторами та географічними координатами, але є одна відмінність: місто, яке знаходиться за конкретними координатами, зазвичай ніхто не переносить за іншими координатами. А ось з елементами на сайті все складніше: в певний момент ми можемо вирішити змінити розміщення елемента на сайті, і, звісно, його координати швидше за все теж зміняться.

Чому це погано? Зміна селекторів призведе до проблем з трекінгом і, відповідно, до невірних або взагалі відсутніх даних.

Яке рішення?

Найкраще рішення в цьому випадку - це співпраця між членами команди: зазвичай перед тим, як вносити якісь зміни на сайт, треба сформулювати гіпотезу, і дизайнер готує новий варіант сторінки. Далі цей дизайн потрапляє до розробника і через певний час з'являється на тестовій версії сайту. Уже на цьому етапі бажано підключити аналітику та оцінити, чи зміни в дизайні вплинуть на існуючі селектори. Якщо це так, то вам потрібно внести відповідні зміни у вашому GTM. Тоді при релізі нової версії сторінки аналітика продовжить працювати коректно.

Помилка 11. Невірно або частково використовувати dataLayer

У чому проблема?

Дуже часто я бачу ситуацію на проєктах, коли спочатку розробника просять передати дані, потрібні для налаштування Ecommerce в GA4, до Data Layer, а потім ще просять налаштувати окремі коди для роботи динамічного ремаркетингу в Google Ads, Meta Ads чи в інших системах. Ця додаткова робота розробника не має ніякого сенсу. Усі потрібні дані в цьому випадку вже є в Data Layer: дані які потрібні для Ecommerce в GA4 та налаштування динамічного ремаркетингу в будь-якій рекламній системі є однаковими. Структура трохи відрізняється, але саме дані ті ж самі.

Яке рішення?

Трансформуйте існуючі в Data Layer дані Ecommerce з допомогою Custom HTML тегу, змінної типу Custom JavaScript, або готових рішень з галереї шаблонів в потрібний вам для рекламних кабінетів формат і заощадьте свій час та нерви.

Детальніше про роботу Data Layer у Google Tag Manager.

Помилка 12. Ігнорувати налаштування Consent Mode, які змінюють правила гри

У чому проблема?

Напевно, вже кожен чув і знає, що таке налаштування Consent Mode (згоди користувача), але помічаю, що не всі розібрались з тим, як це впливає на наші налаштування GTM. Ось один із прикладів: у налаштуваннях тегу вказано умову запуску “1 раз на сторінку” і додано два тригери: при завантаженні сторінки - Initialization (на випадок, якщо у користувача вже надана згода на попередніх сторінках) і кастомний івент (повинен спрацьовувати, коли користувач приймає консент на поточній сторінці).

Ідея супер, логіка наче вірна, але консент змінює правила, і це налаштування не буде працювати як задумано. Що ж відбудеться насправді:

1. Користувач заходить на сайт вперше і бачить банер. У цей момент спрацьовує наш тригер Initialization, але тег не запуститься, тому що згоду користувач ще не встиг надати. Наш тег потрапить в новий блок Tags Blocked by Consent Settings.

2. Користувач надає згоду, і виконується наш кастомний івент. Згода наявна, умови для тригеру підходять… але тег знову не запуститься, оскільки він вже запускався раніше (так, він тоді був заблокований консентом, але все ж він “запускався”, а в нас стоїть умова запуску “Один раз на сторінку”)

Як ви зрозуміли - при такому налаштуванні з цієї сторінки івенти в аналітику не потраплять.

Які рішення?

Тримайте руку на пульсі і не забувайте вчасно актуалізувати свої знання, бо нові зміни в інтерфейсі часто призводять до змін правил роботи інструменту загалом. Ну і треба розібратися з налаштуванням консенту.

Помилка 13. Давати доступ на рівні акаунту GTM, а не на рівні контейнера

У чому проблема?

Хоча ця помилка й не стосується налаштувань, але вона настільки часта, що я не можу про неї не згадати. Коли ви запитуєте або надаєте доступ до Google Tag Manager, то не забувайте, що в GTM доступ вищого рівня не поширюється на нижній. Тобто якщо дати доступ рівня User на рівні акаунту, то користувач не отримає доступу до жодного з контейнерів.

Хоча акаунт у нього почне відображатись в інтерфейсі, але він буде пустий:

Яке рішення?

Не забувайте надавати доступ і на рівні контейнера і перевіряйте наявність доступу не ввечері перед дедлайном)

Помилка 14. Не використовувати GTM, бо він погано впливає на швидкість сайту

У чому проблема?

Ну і останнє, але точно не найменш важливе. Часто бачу ситуацію, коли розробник чи SEO спеціаліст відмовляється використовувати на проєкті GTM. Вони аргументують це тим, що він значно знижує швидкість роботи сайту. Інколи вони навіть можуть провести тест і показати, що якщо знести GTM, то швидкість сайту збільшується. Але як завжди є нюанс: при проведенні такого тесту дуже часто забувають про один маленький, але важливий нюанс. Через менеджер тегів завантажується багато інших кодів, і тому просто знести GTM і показати, що швидкість сайту збільшилась буде недостатньо. Для правильного тесту потрібно знести GTM і всі коди, які були в GTM, поставити напряму на сайт і вже тоді провести замір. Зазвичай в таких випадках ви не побачите статистично значущої різниці у швидкості завантаження сайту з GTM і без нього.

Які рішення?

Перевіряйте інформацію, а не просто погоджуйтесь з тим, що вам кажуть. Ось гарна стаття з дослідженнями як GTM впливає на швидкість завантаження сайту.

Ну а якщо ви дійсно хочете підвищити швидкість вашого сайту, то краще розгляньте варіант використання GTM Server-Side. Раніше я вже розповідав детальніше про переваги використання та про процес налаштування.

Замість висновку

Сподіваюся, стаття була для вас корисною, і більшість із цих помилок були не про вас)

Якщо вам цікава ця тема, і ви хочете навчитися робити більше корисних налаштувань у GTM, наприклад, налаштувати відстеження ecommerce, проводити наскрізну аналітику чи налаштовувати аудиторії ремаркетингу, то вас точно зацікавить курс PRO GTM . Переглянути програму та записатися можна за цим посиланням.