Google Tag Manager стає Google Tag: що змінюється в архітектурі та інтеграції з Google Ads

Google представив оновлення Optimize your Google Tag Manager container («Оптимізація контейнерів Менеджера тегів Google»). У довідці описано оптимізацію, завдяки якій контейнер GTM може надсилати дані до сервісів Google без окремого завантаження бібліотеки gtag.js, а налаштування Google tag стають спільними.

На практиці ці зміни стосуються не лише Google Tag Manager, а й інших сервісів Google, зокрема GA4 та Google Ads. Один із наслідків, який може помітити спеціаліст, — поява другого Google tag у Data Manager.

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

1. Google Tag Manager. Розберемо, що змінилося в архітектурі, що варто перевірити перед міграцією та як пройти її крок за кроком.
2. Google Ads. Подивимося, як читати карту Data Connection Map у Data Manager, за яких умов там з'являється другий тег і чи потрібно спеціалісту щось із цим робити.

Частина 1. Суть апдейту: Контейнер GTM тепер сам є Google-тегом

З жовтня 2026 року користувачам Google Tag Manager доступне оновлення для оптимізації ефективності контейнера. Це оновлення фундаментально змінює архітектуру роботи з тегами. Воно зачіпає не лише сам GTM, а й прямо впливає на екосистему Google Ads, GA4 та Floodlight.

Як працює “старе” налаштування?

Раніше зв'язок працював лише в один бік: будь-який Google Tag виступав оболонкою для базового контейнера GTM, але сам контейнер GTM не мав повних можливостей Google Tag. Через це для роботи Google-тегів усе одно доводилося додатково завантажувати бібліотеку gtag.js.

Що змінилося після оновлення?

Тепер зв'язок став двостороннім: ваш контейнер Google Tag Manager сам стає повноцінним Google Tag. Більш детальні технічні пояснення та розбір архітектури можна почитати у статті Сімо Ахави. А ми одразу будемо переходити до практики.

Перед міграцією

• перевірка вихідного коду сайту на наявність автономно встановленого gtag.js.

Потрібно переконатися, що на сайті немає окремо встановленого коду Google tag для Google Ads або GA4, який працює незалежно від GTM.

Чому це важливо? Якщо на сайті одночасно використовуються пряма інтеграція через gtag.js і Google tag, налаштований у межах оптимізованого контейнера GTM (Destination), може виникнути дублювання ініціалізації або надсилання даних. Це, своєю чергою, може призвести до некоректного обліку подій і конверсій. В ідеалі всі відповідні інтеграції мають бути централізовані в GTM, без паралельних прямих встановлень на рівні коду сайту.

Нещодавній кейс про те, наскільки підступним може бути такий розсинхрон, яскраво ілюструє нещодавній випадок у чаті курсу "PRO ANALYTICS". На одному з проєктів після об'єднання тегів на сайті залишався додатковий сторонній gtag.js, який завантажувався через зовнішній віджет. Наслідок виявився дуже специфічним: при першому переході користувача відправлялися всі події, але при подальшій навігації (наприклад, перехід у кошик чи на сторінку подяки) спрацьовував лише page_view, а всі події електронної комерції (e-commerce) повністю блокувалися. Найпідступніше те, що в режимі відлагодження все працювало ідеально, а проблему вдалося відстежити лише на «проді» — після блокування скрипту віджету через GTM та перевірки сирих даних у таблицях BigQuery

• проведення аудиту налаштувань тегів

Перш ніж змінювати будь-що у GTM, варто провести аудит акаунтів GA4 та Google Ads. Особливу увагу слід приділити налаштуванням User-Provided Data (даних, наданих користувачем).

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

Де перевіряти налаштування збору User-Provided Data (даних, наданих користувачем) в інтерфейсах?

1. GA4 → Admin (Адміністратор) → Data collection (Збирання даних)

2. Google Tag → Configure tag settings (Налаштувати параметри тегу)

Зверніть увагу, типова й дуже часта помилка виникає через те, що GA4 та Google Tag розходяться в налаштуваннях збору персональних даних. Ще одна підступна річ — це Collect automatically-detected user-provided data (збирати автоматично виявлені дані, надані користувачем). Воно може зчитати абсолютно все зі сторінки (включаючи робочий номер телефону чи email компанії в хедері або футері). Через це система може почати сприймати контакти самого сайту за персональні дані відвідувача.

Чому зручно виправити всі розбіжності до запуску візарда міграції?

Навіть якщо ви вирішите проігнорувати розсинхрон на етапі аудиту, Google все одно не дасть це скіпнути. Під час проходження оновлення в GTM система зупинить вас питанням і змусить прийняти рішення:

“Обрані вами теги Google мають різні налаштування. Виберіть, налаштування якого тегу використовувати як дефолтні для цього контейнера Tag Manager. Вони забезпечать єдину логіку обробки даних для подій із вашого контейнера. Ви завжди зможете перевизначити їх у конкретних тегах подій”.

Google пропонує обрати один із тегів як «еталонний», чиї налаштування стануть дефолтними для всього контейнера. Щоб не вгадувати наосліп, який із тегів налаштований правильніше, і не підтягнути випадково криві параметри з GA4 у Google Ads (або навпаки), значно безпечніше зробити так, щоб налаштування були «ОК» з усіх боків ще до запуску міграції.

Після завершення аудиту та підготовки можна переходити безпосередньо до процесу імплементації “рекомендованої Google оптимізації, щоб швидше й легше додавати теги”

Покрокова міграція в GTM

Крок 1. Переходимо до огляду (Overview) і стартуємо за допомогою кнопки Get started (Почати) на картці тегу.

Крок 2: Вибираємо теги для міграції:

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

Зверніть увагу на доступи: якщо залишити Read access, користувачі з доступом до Google Ads / GA4 зможуть бачити вміст контейнера GTM у режимі перегляду (Read-only).

Крок 3: Вибираємо дефолтні налаштування контейнера.

• Обираємо «еталонний» тег: визначаємо той тег (наприклад, GA4 чи Google Ads), із якого GTM скопіює централізовані налаштування — User-Provided Data, кросдоменне відстеження (Cross-domain tracking) та фільтри внутрішнього трафіку.
• Перевірка конфігурації: Перед остаточним вибором можна додатково звірити параметри кожного тегу, натиснувши View settings.
• Фіксація змін: Натискаємо кнопку Add to workspace у правому верхньому куті.

Що змінюється в інтерфейсі GTM після міграції

• Оновлений Overview (Огляд) та контроль версій у GTM

Після фіксації конфігурації у візарді ви знову опинитеся на головному екрані Overview (Огляд). Тут ви одразу побачите оновлену візуальну карту: замість звичної схеми з окремими Google Tags тепер відображається прямий зв'язок між самим GTM-контейнером та його Destinations (цільовими сервісами). Стара сутність «Google tags» повністю зникає з віжуалу. А трохи нижче, у розділі Pending Changes (Зміни, що очікують на розгляд), з'явиться список внесених змін.

Головний плюс апдейту — повноцінне версіонування налаштувань: усі нові конфігурації більше не застосовуються наосліп. Вони додаються до вашої робочої області як чернетка (Pending Changes). На відміну від старих налаштувань у кабінетах GA4 чи Ads, тепер зміни тегів повністю інтегровані в стандартне середовище GTM. Вони НЕ впливають на live-версію сайту, доки ви детально не перевірите їх у режимі Preview (попередній перегляд) та свідомо не опублікуєте зміни. Якщо ж після публікації щось піде не так — ви завжди можете відкотити контейнер до попередньої версії за один клік.

• Наскрізні налаштування у вкладці Settings (Налаштування): тут з’являється новий розділ централізованого управління Destinations (цільовими сервісами), який діє одразу на всі підключені сервіси Google.

Зміна типу тегів у вкладці Tags (Теги): класичні Google Tag перетворюються на Destinations (теги призначення Google Ads / GA4 на скріншоті нижче)

• Зміни у галереї тегів: ще один цікавий маркер оновлення можна помітити під час створення нового тегу в GTM. Якщо ви спробуєте додати новий тег через галерею шаблонів, то побачите, що класичний Google Tag перемістився в окремий розділ “на периферію” — Other Google (Інші продукти Google), там також і Conversion Linker, який тепер позначений як Legacy (застарілий).

Перевірка налаштувань в режимі Preview (Попередній перегляд) і нові фічі

• З'явилася нова вкладка Hits sent безпосередньо на рівні GTM-контейнера, з якої видно усі надіслані запити у Google Ads та GA4 в одному місці.

• Замість кількох окремих тегів, як це було в попередній конфігурації, можна бачити один Google tag, а ID GA4 і Google Ads прописані як Destinations (місця призначення)

• У вкладці з тегами з’явилися Tag settings (Налаштування тегів) для перевірки активних централізованих параметрів.

• Як виглядає Hit від Conversion Linker (Тег зв'язування конверсій), якщо його залишити, під час дебагу: Тег продовжує спрацьовувати і працює дублюючим шаром.

Обов’язково видаляємо Conversion Linker з контейнера після міграції.

Ми розібрали, як працює оптимізація контейнера GTM, що потрібно перевірити перед міграцією та які зміни відбуваються в архітектурі передачі даних. Але що побачить спеціаліст Google Ads на іншому боці цієї інтеграції?

Частина 2. Google Ads: як відображаються оновлені теги в Data Manager (Менеджер даних)

Давайте перейдемо до Data Manager (Менеджер даних) і розглянемо карту Data Connection Map (Карта передавання даних). Саме тут можна побачити зв'язки між джерелами даних Google Ads та підключеними Google tags. І розберемося, чому після оптимізації GTM у Data Manager може з'явитися другий Google tag, що він означає, як правильно читати схему підключень і, головне, чи потребує така зміна якихось дій з боку спеціаліста.

На скріншоті нижче — реальний приклад такої ситуації: у Data Manager відображаються два Google tags.

Data Manager (Менеджер даних) - Data Connection Map (Карта з'єднання даних)

Почнемо з того, що Google Ads оновив інтерфейс Data Manager (Менеджер даних). Тепер у ньому є інтерактивна карта Data Connection Map (Карта з'єднання даних), яка візуалізує весь шлях даних — від джерела до конкретної активації. Вона вмикається тумблером у верхній частині розділу, хоча в багатьох акаунтах цей перемикач уже зник, і карта відкривається за замовчуванням.

Навіщо це нам?

Data Manager (Менеджер даних) — це спроба Google централізувати роботу з first-party даними рекламодавця: як онлайн-джерелами (сайт, застосунки), так і офлайн-даними (наприклад, CRM). За логікою Google, чим повніші й чистіші ці сигнали, тим краще працюють автоматизовані стратегії, зокрема Smart Bidding.

А Data Connection Map (Карта з'єднання даних) — це не нова функція збору даних, а спосіб побачити весь цей шлях на одному екрані: звідки дані приходять, через що проходять і де використовуються. Для нас, практиків, це можливість за пару хвилин зрозуміти, що куди підключено, особливо в акаунті, який ми бачимо вперше.

Як працює оновлена карта Data Connection Map?

• Основний вигляд: Ліворуч розміщені джерела даних — Google tags та Connected products (CRM, API та інші конектори). Вони ведуть у центр — рекламний акаунт (тут є перемикач вигляду між керуючим акаунтом MCC та поточним акаунтом), а далі праворуч розподіляються за Data usage (типом використання) на дві ключові точки призначення: Conversions (Конверсії) та Audience segments (Аудиторії).

• Інтерактивна деталізація: Якщо натиснути на будь-яку комірку (наприклад, Connected products), з'являється спливаюче вікно з переліком іконок підключених продуктів - на скриншоті нижче це BigQuery, Google Sheets та HTTP-конектори.

• За кліком на Expand map карта повністю розгортається, показуючи точні назви джерел, їхню кількість та конкретні напрямки використання - назви конверсій або аудиторій. Достатньо навести курсор на конкретне джерело, щоб побачити, куди саме "течуть" дані: аж до конкретної дії-конверсії або назви списку аудиторії. Також доступні зручні фільтри, щоб ізолювати й подивитися шлях лише одного джерела.

• Оперативне виявлення помилок: якщо джерело даних зламане, ви побачите це миттєво — вузол підсвічується червоним індикатором, а на картці з'являється кнопка Fix it (для швидкого переходу на вкладку збійного конектора).

Сподіваюся, з картою Data Connection Map тепер усе зрозуміло. Дуже рекомендую самостійно проклацати її у своїх акаунтах — це інтерактивний інструмент із чималою кількістю корисних кнопочок і можливостей. До того ж їхнє відображення та доступний функціонал можуть дещо відрізнятися залежно від конфігурації акаунта :)

А тепер повернімося до скріншота, з якого я почала другу частину статті, і розберемося, за яких умов у Data Manager можна побачити два Google tags та звідки вони беруться.

2 Google tags: чому і за яких умов можуть з'явитися два теги?

Як було раніше: звичний потік даних до Google Ads

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

• Google Tag (AW-XXXXX): глобальний скрипт Google Ads, який виступав базовим тегом для збору аудиторій та ремаркетингу.

У Data Manager (Менеджері даних) це виглядало так, тобто був наявний 1 Google tag, як ми до цього всі звикли

Після міграції, тобто імплементації “рекомендованої Google оптимізації, щоб швидше й легше додавати теги”, в Data Manager (Менеджері даних) присутні вже 2 теги, які відображаються і на карті, і в переліку Google tag:

1. Тег AW-XXXX (класичний Google Ads Tag).
2. Тег GTM-XXXX (сам контейнер GTM, який визнано повноцінним Google Tag).

Для порівняння також покажу скріншот з іншого акаунта, у якому міграцію вже проведено, але немає підключених офлайн-джерел даних через інші конектори, бо візуальне відображення Data Connection Map у акаунтах відрізняється.

Якщо натиснути на кнопку Manage (Керувати) або на меню з трьома крапками біля першого Google tag, ці дії ведуть, як всі вже звикли, відповідно до налаштувань тегу та до перегляду статистики, яку збирає тег Google Ads (AW-XXXXX). Тут все як і було раніше.

А якщо натиснути Manage (Керувати) біля другого Google tag (того, що на скріншоті відображається без меню з трьома крапками), відкриється відповідний контейнер Google Tag Manager. Рівень доступу до нього залежатиме від прав, визначених для користувача на кроці 2 процесу міграції.

Що це означає на практиці

Тож 2 теги у кабінеті — це нова норма двосторонньої інтеграції 🙂

• AW-XXXX — це класичний тег Google Ads, тепер він працює як Destination (тег призначення). Дані в нього йдуть як і раніше, статистику подій, наприклад динамічного ремаркетингу, можна подивитися в меню з трьома крапками.
• GTM-XXXX — це сам контейнер Google Tag Manager, який після оптимізації також отримує статус Google Tag. Тому кнопка Manage (Керувати) тут веде просто в GTM.

Як це інтерпретувати?

Поява другого Google tag у Data Manager сама по собі не означає, що на сайті з'явився ще один незалежний скрипт або що потрібно щось переналаштовувати в Google Ads. У цій конфігурації GTM-контейнер також відображається як Google tag, а карта Data Connection Map показує зв'язок між контейнером і місцем призначення Google Ads. Тому, якщо ви бачите таку картину в рекламному акаунті, насамперед варто правильно ідентифікувати обидва теги та зрозуміти їхню роль у схемі передачі даних.

Тож звикаємо до двох тегів в Data Manager, але з відкритими очима :)

Висновки: до чого варто бути готовими?

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

Що варто винести з цього оновлення:

• Перед міграцією — аудит. Перевірте, чи немає на сайті паралельних встановлень gtag.js, та узгодьте налаштування тегів, особливо User-Provided Data у GA4 і Google Ads. Саме зараз варто навести лад у конфігураціях, перш ніж об'єднувати їх під спільними налаштуваннями.
• Після міграції — перевірка. Переконайтеся, що нова конфігурація коректно працює в Preview, дані надходять до потрібних сервісів, а конверсії не дублюються. Не забудьте також перевірити Conversion Linker та прибрати його з контейнера.
• Два Google tags у Data Manager — не привід для паніки. Якщо міграцію виконано коректно, поява тегів AW-XXXX та GTM-XXXX є очікуваною поведінкою нової архітектури. Видаляти один із них або повертатися до старої конфігурації не потрібно.
• Не забувайте про доступи. Під час міграції ви фактично встановлюєте новий зв'язок між GTM та іншими продуктами Google, тому варто перевірити, хто і на якому рівні отримує доступ до контейнера.

Головне — не сприймати це оновлення як чергову автоматичну оптимізацію, яку достатньо просто увімкнути. Воно змінює логіку взаємодії між GTM, GA4 та Google Ads, а отже, потребує розуміння того, як саме побудована ваша система збору та передачі даних.