Якщо на вашому сайті працює Google Tag Manager, Google змінює те, як Tag Manager запускається на ваших сторінках. У примітці до випуску від 8 жовтня 2026 року Google пише, що кожен контейнер Tag Manager (місце в Tag Manager, де зберігаються теги вашого сайту) запускатиметься одразу після завантаження, а не чекатиме на команду gtag('config') на сторінці. Ця зміна Google Tag Manager gtag config найважливіша для сайтів, де Tag Manager поєднано з окремим кодом тегу Google, і для контейнерів із правилами (тригерами), які запускають теги на будь-яку подію.
Google надіслав листи власникам контейнерів, які вважає налаштованими неправильно. Скільки їх, Google не повідомив, а його довідка щодо виправлення досі каже, що оновлення вийде “незабаром”.
Що змінилося в Google Tag Manager 8 жовтня?
За словами Google, контейнери Tag Manager більше не чекатимуть на рядок gtag('config'), тобто команду, яка повідомляє тегу Google, в який обліковий запис надсилати дані і з якими налаштуваннями. У примітці до випуску від 8 жовтня (українською цієї нотатки поки немає, переклад наш) сказано: усі фрагменти контейнера Google Tag Manager (gtm.js) ініціалізуватимуться під час завантаження контейнера, незалежно від команд gtag(‘config’).
Фрагмент - це кілька рядків коду, вставлених на кожну сторінку сайту. Тег - невеликий шматок коду, який повідомляє, що відбувається на сайті, наприклад перегляд сторінки чи надсилання форми. Тег передає ці дані в інструмент на кшталт Google Analytics або Google Ads. Сайт може завантажувати теги Google одним із двох фрагментів:
| Фрагмент Tag Manager | Фрагмент тегу Google | |
|---|---|---|
| Який файл завантажує | gtm.js | gtag.js |
| Який ідентифікатор використовує | Починається з GTM- | Ідентифікатор продукту, наприклад G- або AW- |
Обидва фрагменти пишуть у dataLayer, чергу повідомлень на сторінці, яку читає Tag Manager. Досі контейнер міг помітити рядок gtag('config') в іншому місці сторінки й дочекатися його, і деякі сайти на це покладалися. Примітка до випуску змінює і те, що бачить контейнер: команди config тепер з’являтимуться в dataLayer як видимі події gtag.config.
Яких сайтів стосується зміна Google Tag Manager gtag config?
Зачеплено дві групи сайтів. Листи Google отримала перша група, у якої, за термінологією Google, непідтримуваний спосіб застосування. У другої групи налаштування може бути правильним з погляду Google, але є правила (тригери), які запускають теги на будь-яку подію.
Змішані налаштування. Довідка Google про налаштування gtag.js описує сайти, які завантажують ідентифікатор G-, AW- або DC через шлях фрагмента Tag Manager. У її прикладі неправильного налаштування стоїть стандартний фрагмент GTM-, а за ним окремий рядок gtag('config'). Щодо таких сайтів Google попереджає, що на них “можуть спостерігатися неочікувані зміни в роботі тегів”, а їхні власники “отримали сповіщення електронною поштою”.
Тригери з шаблоном для всіх подій. Тригер (в українському інтерфейсі Google - активатор) - це правило, яке каже тегу, коли спрацьовувати. Тригер спеціальної події може зіставляти назви подій за шаблоном .*, який збігається з будь-якою подією в dataLayer. Примітка до випуску Google попереджає (переклад наш): якщо у ваших контейнерах Google Tag Manager є тригери спеціальних подій із шаблоном-підстановкою, через цю зміну такі теги можуть спрацювати.
Англомовна довідка Google про тригери спеціальних подій і раніше радила вужчий шаблон, бо .* збігається й з подіями, які Tag Manager і тег Google надсилають автоматично. PPC Land зазначає, що ризик таких тригерів стосується і сайтів з правильним, на думку Google, налаштуванням: стандартний фрагмент gtag.js сам містить виклик config.
Коли Google оголосив про зміну gtag config?
Попередження з’явилося за кілька тижнів до примітки до випуску. PPC News Feed повідомив про попередження в довідці Google 27 серпня 2026 року. 20 серпня користувач форумів підтримки WordPress.org опублікував лист, який клієнт отримав від Google. У листі йшлося (переклад наш): починаючи з 2 жовтня 2026 року всі фрагменти gtm.js ініціалізуватимуться під час завантаження контейнера.
Примітка до випуску датована 8 жовтня. Довідка Google щодо виправлення досі каже: “Незабаром фрагменти коду Менеджера тегів Google (gtm.js) буде оновлено”. Як зазначають і PPC Land, і Relevant Audience, Google не повідомив, чи дійшла зміна до всіх контейнерів в один день, чи впроваджується поступово.
Чого Google не сказав
Google не назвав остаточного терміну й не оцінив, яку частину даних може зачепити зміна. Relevant Audience зазначає, що в примітці до випуску не згадано обмежень за країнами чи регіонами, і довідка щодо виправлення їх теж не називає.
Є й практична прогалина. Лист пішов тому, хто вказаний у контейнері. Relevant Audience звертає увагу: якщо це колишній працівник або попередній веброзробник, попередження могло так і не дійти до того, хто веде сайт сьогодні.
Що це означає для вашого бізнесу
На наш погляд, це привід уважно перевірити налаштування аналітики. Завдання - перевірити, що завантажують ваші сторінки, вибрати одне з двох виправлень Google, якщо налаштування змішане, і переконатися, що кожна заявка рахується один раз. Ми йшли б такими кроками в такому порядку, до будь-яких змін у рекламних кабінетах.
- З’ясуйте, кому належить контейнер. Щоб щось перевірити, потрібен доступ до Tag Manager, і власником має бути бізнес, а агенція додана як користувач. У нашому матеріалі про те, як вибрати маркетингову агенцію, пояснюємо, чому облікові записи мають бути у вас.
- Подивіться, який фрагмент завантажують сторінки. Відкрийте сайт, перегляньте вихідний код сторінки й знайдіть “googletagmanager.com”. Якщо в адресі є gtm.js з ідентифікатором, що починається з GTM-, ваш контейнер підключено підтримуваним способом. Якщо в gtm.js стоїть ідентифікатор G-, AW- або DC чи поруч із фрагментом Tag Manager є окремий рядок
gtag('config'), у вас саме те налаштування, про яке попереджав Google. - Виберіть одне з двох виправлень Google. Поставте фрагмент тегу Google (gtag.js) на кожну сторінку й приберіть фрагмент gtm.js та всі окремі рядки config. Або, якщо через Tag Manager працюють інші ваші теги, залиште фрагмент з вашим ідентифікатором GTM- і налаштуйте тег Google усередині контейнера. Перенесіть усі налаштування, які передавав старий рядок config, і не чіпайте налаштування згоди на cookie, щоб теги й далі враховували вибір відвідувача в cookie-банері.
- Знайдіть у контейнері тригери з
.*. Відкрийте список тригерів і знайдіть тригери спеціальних подій, які збігаються з усіма подіями. Звузьте кожен до потрібних йому назв подій: тег, що спрацьовує на gtag.config, може надіслати ті самі дані повторно й, наприклад, порахувати одну заявку за дві. - Перевірте в Tag Assistant і на реальній заявці. Tag Assistant - інструмент Google для перевірки тегів на сайті, і, згідно з довідкою Google, ідентифікатор вашого тегу має мати там зелений або синій значок статусу. Потім надішліть тестову заявку з телефона й перевірте, що її враховано один раз, як ми описуємо в розборі про те, чому Google Ads дає кліки, але не заявки. У нашому веденні реклами Google Ads ми перевіряємо відстеження до будь-яких змін ставок.
- Звірте цифри з поштою або CRM. Покладіть заявки з пошти чи CRM поруч із конверсіями, які Google показує за ті самі дні, до і після 8 жовтня. Таку саму звірку ми робимо в роботі з CRM та аналітикою, і якщо цифри перестали збігатися, насамперед дивіться на теги.
