3 червня 2026 року Google додав кероване налаштування Google Tag Gateway для веб-сайтів, які вже доступні через Amazon CloudFront. Практичною зміною є доступність: Tag Assistant тепер допоможе користувачеві створити необхідну поведінку джерела та шляху CloudFront у консолі AWS. Механізм вимірювання — це звичне перенаправлення першої сторони, і його значення в реальному світі потрібно вимірювати, а не виводити з мови запуску.
Що представив випуск 3 червня
До випуску CloudFront уже можна було налаштувати вручну як шлюз. Новий робочий процес виявляє існуючий дистрибутив CloudFront для веб-сайту, відкриває Tag Assistant поруч із консоллю AWS і попередньо заповнює джерело та поведінку, необхідні для зарезервованого шляху вимірювання.
Ви все ще переглядаєте та створюєте ресурси AWS, чекаєте на зміну розповсюдження, замінюєте сценарій тегів на сайті та перевіряєте звернення в Tag Assistant. Це керована інтеграція, а не новий аналітичний продукт AWS і не розгортання контейнера server-side GTM одним клацанням миші.
Що CloudFront робить під капотом
Поведінка CloudFront надсилає запити на зарезервований шлях, наприклад /metrics, до джерела Google fps.goog. Ручна конфігурація Google вимикає кешування, дозволяє потрібні методи HTTP та використовує політику запиту походження AllViewerExceptHostHeader. Тому шлюз пересилає кожен запит вимірювання; це не кеш подій конверсії.
Геолокація є важливою деталлю. Google зазвичай отримує місцезнаходження з IP-адреси браузера, але за шлюзом він бачить CDN. CloudFront має правильно передавати інформацію про місцезнаходження глядача. Відсутні заголовки можуть спотворити географічні звіти та характерну для регіону поведінку згоди.
Що не змінилося
GTG все ще обслуговує підтримувані теги Google і пересилає підтримувані вимірювання в Google. Він не перевіряє вартість покупок у вашому комерційному сервері, не створює відсутні події, не запускає теги Meta CAPI і не надає вам клієнтів, тригерів і змінних sGTM.
Тег Google все ще залежить від роботи браузера. Згода, політика безпеки вмісту, помилки JavaScript, послідовність тегів, рівень даних і складна фільтрація можуть вплинути на результат. Шлях першої сторони може зменшити один клас блокування, не роблячи налаштування блокованим.
Маркетингові заяви потребують виміряної базової лінії
Google описує GTG як покращене відновлення сигналу, точність звітів і ефективність перетворення. У нотатці про випуск CloudFront і посібнику з налаштування не публікується універсальне підвищення, специфічне для CloudFront. Це чесна відправна точка: напрямок правдоподібний, але розмір залежить від конкретного місця.
Сайт, який втрачає запити лише тому, що імена хостів Google відфільтровано, може відновити більше, ніж сайт, основними проблемами якого є відмова в згоді, несправні події електронної комерції чи узгодження серверної частини. Повідомляйте про прийняті події, суміш згоди, комбінацію веб-переглядачів і вплив блокувальників разом із будь-яким відсотком до та після.
Виняток маршрутизації EEA має значення
Google документує важливий виняток для трафіку Європейської економічної зони: дані вимірювань Google Analytics надходять безпосередньо до регіональних кінцевих точок Google замість шляху CDN. Звернення до конверсії Google Ads продовжуються через шлюз. Така очікувана поведінка може зробити просте порівняння кількості мереж непослідовним.
Для європейських брендів проаналізуйте окремо GA4 і Google Ads і перевірте значення за замовчуванням для певного регіону. Конфігурація геолокації CloudFront не є необов’язковими метаданими; це може вплинути як на звітність, так і на поведінку згоди.
Хто отримає найбільшу користь від нового робочого процесу?
Найкраще підходить бренд, на виробничому веб-сайті якого вже використовується CloudFront, чиї вимірювання в основному базуються на Google і чия команда може безпечно переглянути зміни в розподілі. Випуск економить час ручного налаштування та робить правильні базові налаштування більш доступними.
Компанії, якій потрібні кілька рекламних API, керування даними на сервері або серверні події, не слід розглядати робочий процес як кінцевий стан. Використовуйте його як цілеспрямоване покращення доставки Google або поєднайте обслуговування сценаріїв першої сторони з реальним шляхом збору sGTM.
Не називайте результат підйомом, поки не погодитеся з ним
Більше запитів на панелі мережі веб-переглядача не є автоматично більш прийнятними перетвореннями. Порівняйте обробку цільової адреси та віднесені конверсії із замовленнями або кваліфікованими потенційними клієнтами з вихідної системи.
Обґрунтований план розгортання CloudFront
Розглядайте кероване налаштування як зміну інфраструктури та вимірювальний експеримент.
- 01
Зафіксуйте базову лінію перед запуском
Записуйте від двох до чотирьох репрезентативних тижнів показники згоди, мікс браузерів, прийняті події GA4, конверсії Google Ads і загальні показники вихідної системи.
- 02
Підтвердьте передумови та право власності
Перевірте тег Google, правильний розповсюдження веб-сайту CloudFront, доступ до AWS, власника відкату та зарезервований шлях, який не конфліктує з програмою.
- 03
Запустіть робочий процес Tag Assistant
Відкрийте налаштування тегів Google, проскануйте веб-сайт, виберіть CloudFront і перегляньте джерело та поведінку, які Tag Assistant просить створити в AWS.
- 04
Перегляньте поведінку CloudFront
Підтвердьте пріоритет шляху, вимкнене кешування, дозволені методи, політику запиту джерела та пересилання інформації про місцезнаходження переглядача, перш ніж її використає робочий трафік.
- 05
Замініть і перевірте сценарій тегу
Розгорніть наданий сценарій, запустіть перевірку працездатності та підтвердьте в Tag Assistant, що звернення використовують зарезервований основний шлях.
- 06
Перевірте згоду та регіональну поведінку
Тестування надано та відмовлено в згоді з ЄЕЗ та поза ЄЕЗ. Очікуйте задокументований виняток маршрутизації GA4 і перевірте Google Ads окремо.
- 07
Виміряйте і звірте результат
Порівняйте стабільні когорти, де це можливо, а потім узгодьте прийнятні події призначення та віднесені конверсії з бізнес-результатами. Зберігайте шлях відкату, поки не буде зрозумілий результат.
Зміни в підтримці CloudFront охоплюють, а не межі продукту GTG
Інтеграція в червні 2026 року має значення, оскільки вона дає можливість керованого налаштування GTG для багатьох брендів, які вже використовують AWS CloudFront. Це зменшує перешкоди в інфраструктурі та зменшує ймовірність базової помилки маршрутизації.
Його продуктивність поки умовна. Випуск не створює вихідних подій, не замінює згоду, не обробляє дані в sGTM і не гарантує збільшення конверсії. Опублікуйте свій власний узгоджений результат із контекстом трафіку та згоди, необхідним для його тлумачення.
Інтеграція CloudFront: типові запитання
Коли Google запустив керовану інтеграцію CloudFront?
Примітки до випуску Менеджера тегів Google датуються 3 червня 2026 року. До цього CloudFront був можливий через ручну маршрутизацію; випуск додав керований робочий процес Tag Assistant.
Чи інтеграція CloudFront повністю автоматична?
No. Tag Assistant допоможе вам у консолі AWS і налаштуваннях попереднього заповнення, але ви переглядаєте та створюєте джерело та поведінку, розгортаєте сценарій заміни та тестуєте результат.
Чи кешує CloudFront події вимірювань?
Не повинно. Ручне налаштування Google визначає політику CachingDisabled для зарезервованої поведінки вимірювання.
Чи кожен сайт матиме більше конверсій?
Жодного універсального результату не задокументовано. Будь-які зміни залежать від причин поточної втрати, згоди, комбінації браузера та блокувальника, якості реалізації та обробки призначення.
Чому GA4 і Google Ads можуть показувати різні маршрути в ЄЕЗ?
Google каже, що дані EEA Google Analytics надходять безпосередньо до регіональних кінцевих точок Google, тоді як звернення до конверсії Google Ads продовжуються через шлюз.