Чи замінює Google Tag Gateway GTM на стороні сервера?

Коротка відповідь: доставка не є обробкою

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

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

Що Google Tag Gateway може, а що ні

GTG може зменшити взаємодію сторонніх розробників у веб-переглядачі та відновити деякі сигнали, які не вдаються лише тому, що відоме ім’я хосту Google заблоковано. Це також дозволяє Google використовувати вибрані основні файли cookie Google у пересланому запиті; Google каже, що основні файли cookie, які не належать Google, видаляються.

Він не створює відсутні події електронної комерції, не відновлює слабкий рівень даних, не перевіряє дохід, не збагачує події з вашої CRM і не надсилає запити Meta CAPI і TikTok Events API. Це також не скасовує обов’язки згоди. Тег Google усе ще працює у веб-переглядачі, а збої на стороні веб-переглядача, стан згоди та помилки впровадження все ще мають значення.

Що додає server-side GTM

sGTM корисний, коли сервер повинен виконати роботу до того, як постачальник отримає подію. Приклади включають видалення несхвалених параметрів, нормалізацію назв подій, отримання корисних даних, що стосуються місця призначення, встановлення файлів cookie сервера, застосування логіки згоди та запис вихідних відповідей для усунення несправностей.

Компромісом є право власності. Серверному контейнеру потрібен хостинг, робоче налаштування та налаштування попереднього перегляду, моніторинг, контроль доступу, перегляд шаблону та хтось, хто може діагностувати повний шлях. sGTM створює контроль, а не автоматичну коректність.

Чому існує міф про заміну

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

Корисним тестом є запитати, що відбувається після того, як запит досягає вашого домену. Якщо шлях просто пересилає підтримуваний запит Google до Google, це є поведінкою шлюзу. Якщо ваш контейнер приймає запит, створює подію та вирішує, які теги та призначення запускаються, це server-side GTM.

Який вибрати?

Виберіть окремо GTG, якщо ваш діапазон в основному підтримує вимірювання Google, ви вже використовуєте сумісний CDN або балансувальник навантаження та вам не потрібен спільний рівень даних на стороні сервера. Це менші операційні зобов'язання.

Виберіть sGTM, якщо вам потрібні не-Google API перетворення, перетворення, мінімізація даних, керування подіями або серверні введення. Якщо ви вже використовуєте sGTM, Google запропонує вам увімкнути поведінку шлюзу в налаштуваннях на стороні сервера. Таким чином, продукти можуть доповнювати один одного, не стаючи двома конкуруючими потоками подій.

Виберіть правильну архітектуру за шість перевірок

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

1. 01

   Перерахуйте кожне місце призначення

   Включно GA4, Google Ads, Floodlight, Meta, TikTok, LinkedIn, CRM системи та склади. GTG не є загальним маршрутизатором для цього списку.

2. 02

   Перелічіть необхідну обробку

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

3. 03

   Намалюйте фактичні шляхи запиту

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

4. 04

   Призначте одного власника для кожної події

   Для кожного призначення визначте, чи надсилає подію браузер, шлях GTG або тег sGTM. Два власники створюють дублікати.

5. 05

   Перевірте стан згоди та невдачі

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

6. 06

   Примиритися з джерельною правдою

   Порівняйте прийнятні конверсії та дохід із записами електронної комерції чи CRM. Успішний мережевий запит не є доказом того, що цифри правильні.

GTG — це сфокусований рівень доставки, а не sGTM lite

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

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

Google Tag Gateway проти sGTM: типові запитання

Першоджерела та подальше читання

• Google: огляд Google Tag Gateway
• Google: Вступ до тегування на стороні сервера
• Google: процес впровадження GTG

Схожі статті