Якщо ви вже використовуєте server-side GTM, не створюйте другий конкуруючий конвеєр вимірювань Google лише для того, щоб додати Google Tag Gateway. Комбінований шаблон, рекомендований Google, розділяє два шляхи однакового походження: шлях сценарію пересилає запити gtm.js або gtag.js до Google, тоді як шлях збору пересилає події вимірювання на ваш сервер тегів. Контейнер сервера залишається місцем обробки та маршрутизації подій.
Комбінована архітектура
Налаштування з однаковим джерелом може використовувати такі шляхи, як www.example.com/scripts для завантаження основного сценарію Google і www.example.com/metrics для контейнера сервера. CDN або балансувальник навантаження направляє кожен префікс до іншого джерела. Google попереджає, що обидва шляхи не повинні використовуватися та не повинні містити /gtm.
Браузер завантажує веб-контейнер або тег Google через шлях сценарію. Потім тег Google налаштовується для надсилання вимірювань на шлях збору. Клієнт sGTM заявляє про цей запит, створює подію та запускає відповідні теги сервера.
Під час запуску обидва корисні
Ця комбінація корисна, якщо вам потрібні переваги стійкості веб-переглядача завдяки завантаженню сценарію від першої сторони, а також потрібні трансформації sGTM, мінімізація даних, місця призначення не від Google або можливість спостереження. Google чітко рекомендує завантажувати сценарій першої сторони разом із додаванням тегів на стороні сервера для довговічності налаштування.
Це менш корисно, коли GTG буде лише дублювати функціональні можливості, які вже надаються правильно налаштованим завантажувачем sGTM першого виробника та маршрутом збору. Перевірте поточні шляхи перед додаванням нового правила. Після змін архітектура має стати зрозумілішою, а не просто містити більше продуктів.
Перехоплення повторюваних подій
Небезпечний шаблон надсилає ту саму конверсію Google безпосередньо через шлях пересилання GTG, а також надсилає її через sGTM, де тег сервера надсилає її знову. Обидва мережеві запити можуть бути успішними, залишаючи завищені конверсії, які виглядають як покращене відновлення.
Визначте одного власника доставки для кожної події та пункту призначення. Стабільні ідентифікатори транзакцій або ідентифікатори подій все ще корисні, але дедуплікація має бути механізмом безпеки, а не основною архітектурою. Попередньо перегляньте разом контейнери браузера та сервера та підрахуйте вихідні запити призначення.
Одне походження краще, ніж субдомен випадкового відстеження
Документи Google із однаковим походженням є найкращою практикою для забезпечення безпеки та довговічності файлів cookie на сервері. Шлях на хості веб-сайту, наприклад www.example.com/metrics, має те саме походження. Субдомен, наприклад metrics.example.com, є основним, але не того самого джерела.
Для маршрутизації з однаковим джерелом зазвичай потрібен CDN або балансувальник навантаження та ретельний пріоритет шляху. Пересилайте всі файли cookie та рядки запитів, необхідні серверу тегів, маршрутизуйте кожен клієнтський шлях, включаючи задокументований підшлях /_/*, і перевіряйте кінцеву точку справності перед зміною робочих тегів.
Згода та конфіденційність все ще контролюють потік
Обслуговування першою стороною – це транспортне рішення, а не дозвіл. Ініціалізуйте параметри згоди за замовчуванням перед вимірюванням, передайте стан згоди в запит на збір і налаштуйте теги сервера, щоб вибір забороненого зберігання або реклами оброблявся відповідно до плану.
Мінімізуйте дані на межі сервера. Перегляньте, які файли cookie, заголовки, параметри запиту та поля подій надходять у контейнер сервера, а потім дозвольте лише ті поля, які потрібні кожному призначенню. GTG видаляє сторонні файли cookie сторонніх розробників на власному шляху пересилання, але ваш шлях збирання sGTM має власні обов’язки щодо обробки даних.
Чітке правило прийняття рішень
Якщо у вас немає sGTM і вам потрібні лише вимірювання з підтримкою Google, одного GTG може бути достатньо. Якщо у вас є sGTM, увімкніть власний сценарій Google, який обслуговує цю архітектуру, і зберігайте збір вимірювань у контейнері сервера.
Якщо дві команди володіють GTG і sGTM, опублікуйте карту маршруту та матрицю володіння подією перед запуском. Правило CDN, налаштування веб-контейнера та тег сервера можуть змінювати куди відбувається та сама подія; незадокументоване перекриття є звичайним джерелом дублювання.
Використовуйте два шляхи, а не два власники вимірювань
Шлях сценарію та шлях збору навмисно відрізняються. Шлях сценарію завантажує код Google першої сторони; шлях збору надсилає події в sGTM. Не дозволяйте, щоб обидва шляхи незалежно забезпечували однакову конверсію.
Налаштуйте GTG за допомогою server-side GTM
Точні меню відрізняються залежно від CDN, але обов’язки та послідовність перевірки залишаються незмінними.
- 01
Переконайтеся, що серверний контейнер готовий до виробництва
Використовуйте розгортання робочих тегів, робочий сервер попереднього перегляду, елементи керування доступом, моніторинг і спеціальний домен перед зміною маршруту браузера.
- 02
Зарезервуйте два невикористаних шляхи з однаковим джерелом
Виберіть один шлях сценарію, наприклад /scripts, і один шлях збору, наприклад /metrics. Жоден шлях не може конфліктувати з сайтом або містити /gtm.
- 03
Прокладіть шлях збору до sGTM
Налаштуйте CDN або балансувальник навантаження для пересилання повного префікса колекції, файлів cookie та рядків запитів на сервер додавання тегів, включаючи шляхи, необхідні клієнтам сервера.
- 04
Додайте URL-адресу колекції в налаштуваннях контейнера сервера
Встановіть для URL-адреси контейнера сервера ту саму URL-адресу джерела, включаючи префікс шляху, а потім підтвердьте, що очікуваний клієнт вимагає запит попереднього перегляду.
- 05
Спрямуйте шлях сценарію для GTG
Передайте зарезервований префікс сценарію до джерела шлюзу Google і оновіть джерело gtm.js або gtag.js для завантаження через цей шлях.
- 06
Наведіть події Google на шлях збору
Установіть server_container_url або еквівалентний параметр тегу Google для кінцевої точки /metrics, щоб вимірювання надходило до sGTM замість того, щоб двічі переходити безпосередньо до того самого пункту призначення.
- 07
Налаштуйте клієнтів, теги та згоду
Перевірте пріоритет клієнта, перетворення подій, перевірку згоди, теги призначення та стабільні ідентифікатори подій у контейнері сервера.
- 08
Перевірте весь маршрут
Підтвердьте, що сценарій завантажується з /scripts, один запит досягає /metrics, клієнт сервера заявляє його, і для кожного пункту призначення надходить точно один очікуваний запит.
- 09
Монітор після випуску
Сповіщайте про збої в працездатності та незвичайний обсяг, переглядайте діагностику призначення та звіряйте покупки чи потенційні клієнти з правдою вихідної системи.
Виконуйте додаткові шари, а не паралельні конвеєри
GTG і sGTM добре працюють разом, коли шлюз обробляє доставку сценаріїв першої сторони, а sGTM володіє обробкою подій. Двосторонній шаблон робить цю межу видимою та перевіреною.
Конфігурація не вдається, якщо одне й те саме перетворення має двох власників доставки. Документуйте шляхи, зберігайте ідентифікатор однієї події, перевіряйте стани згоди та підраховуйте запити, які фактично залишають сервер.
GTG плюс sGTM: типові запитання
Чи має кожне налаштування sGTM також використовувати Google Tag Gateway?
Google рекомендує обслуговування сценаріїв першої сторони, але спочатку перевірте наявний завантажувач і маршрути. Деякі налаштування sGTM уже обслуговують залежності першої сторони, і їм може знадобитися лише оновлення конфігурації.
Чи можуть GTG і sGTM використовувати той самий шлях?
Шаблон CDN від Google використовує окремі шляхи: один для сценаріїв і один для збору подій. Окремі маршрути запобігають конфліктам походження та пояснюють відповідальність.
Як запобігти повторюваним переходам Google?
Виберіть одного відправника для кожної конверсії. Якщо sGTM надсилає запит Google призначення, не надсилайте також еквівалентний прямий запит браузера. Перевірте кількість вихідних запитів у попередньому перегляді та діагностиці призначення.
Субдомен – це те саме, що обслуговування з одного походження?
Ні. Субдомен є основним, але те саме походження означає ту саму схему, ім’я хоста та порт, що й веб-сайт. Google перелічує обидва файли cookie як такі, що підтримують серверні файли cookie, але називає те саме походження найкращою практикою.
Який шлях має надсилати події Meta або TikTok?
Ці запити призначення повинні бути створені тегами сервера в sGTM або іншої інтеграції сервера. Шлях сценарію Google GTG не є загальним маршрутом API перетворення, який не належить Google.