Server-Side GTM у Cloud Run: покрокове налаштування, вартість і підключення піддомену

Server-Side GTM — це вже не «тренд», а робочий інструмент, який дозволяє вам краще контролювати дані, зменшувати залежність від браузерних обмежень і покращувати швидкість завантаження ваших сайтів. Коли ми говоримо про перехід на Server-Side Google Tag Manager, важливо розуміти, що це не просто створення нового контейнера (як у випадку з браузерним GTM), а розгортання повноцінної серверної інфраструктури, яка має працювати стабільно, передбачувано й контрольовано.

У цій статті я детально покажу, як розгорнути Server-Side Google Tag Manager у Cloud Run, як правильно налаштувати піддомен через Load Balancer і DNS, а також розберу питання вартості та оптимізації. План буде такий:

• Розгортаємо Server-Side GTM у Cloud Run
  • Крок 1. Створюємо preview-сервіс
  • Крок 2. Створюємо основний серверний сервіс
  • Крок 3. Налаштовуємо піддомен
    • 3.1. Створюємо Load Balancer
    • 3.2. Додаємо DNS-запис
  • Крок 4. Перевіряємо, що все працює
  • Крок 5. Додаємо URL у Google Tag Manager
• Скільки це коштує і як оптимізувати витрати
  • Кількість запущених контейнерів
  • Трафік у Google Cloud
    • Трафік у Google Cloud (вихідний трафік)
    • Load Balancer та IP-адреса
  • Зберігання логів
• Замість висновку

Розгортаємо Server-Side GTM у Cloud Run

Крок 1. Створюємо preview-сервіс

У server-side GTM є два режими роботи: production (робочий режим) і preview (режим налагодження). У звичайному, клієнтському GTM ви просто натискаєте Preview і бачите debug-панель у браузері. У server-side архітектурі все працює інакше — серверу потрібна окрема точка входу для debug-сесій.

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

Рухатися ми будемо за цією інструкцією з документації. І починаємо ми, звісно, з переходу в Cloud Run. Далі ви:

1. Обираєте потрібний вам проєкт.
2. Відкриваєте розділ Services.
3. І натискаєте Deploy container.

4. Копіюєте посилання із документації по налаштуванню від Google. Для зручності залишаю його тут: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

5. Вставляєте посилання у блок Container image URL.

6. Далі в полі Service name ви даєте назву сервісу (оскільки ми налаштовуємо прев’ю сервіс, то давайте так і назвемо його “ssgtm-preview”)

7. І трохи нижче в полі Region обираєте регіон максимально близький до вашої основної аудиторії. Якщо більшість ваших користувачів в Україні — логічно обрати, наприклад, Варшаву.

8. У блоці Authentication обираємо Allow public access, бо авторизація нам не потрібна.

9. А для Billing ставимо Instance-based. Нам потрібно, щоб інстанс був запущений завжди, а не тільки коли є запит.

10. Autoscaling - у випадку з preview-сервісом, ми можемо поставити 0. Оскільки це сервіс лише для роботи в режимі preview, він не обслуговує реальний продакшн-трафік і не потребує постійно запущеного інстансу. Тому в налаштуваннях автоскейлінгу встановлюємо:

• Minimum number of instances — 0
• Maximum number of instances — 1

11. Для Ingress залишаємо All, щоб весь трафік міг потрапити на наші контейнери.

12. Далі відкриваємо блок Containers, Networking, Security, натиснувши на стрілочку і нижче обираємо вкладку Variables & Secrets.

13. Тепер дивимось у документації, які нам потрібні Environment variables:

• Перша змінна: RUN_AS_PREVIEW_SERVER зі значенням TRUE.
• Друга змінна: CONTAINER_CONFIG. Значення для неї - це ваш container configuration string, який ви берете з вашого Google Tag Manager. Щоб його знайти відкриваємо Admin -> Container settings -> Set up your tagging server -> Manually provision tagging server -> копіюємо Container config.

14. Тепер створюємо змінні і натискаємо Create.

Перший сервіс готовий, тепер давайте створювати наступний.

Крок 2. Створюємо основний серверний сервіс

Після того, як ми створили preview-сервіс, створюємо другий — основний сервіс, який оброблятиме запити від сайту. Налаштування майже повністю повторюють ті, що й для preview-сервісу, до етапу 10 — Auto Scaling. Тому виконайте ті самі дії, змінивши лише назву сервісу (наприклад, «ssgtm»), а далі продовжимо з налаштування масштабування:

• Auto Scaling - тут вибір залежить від кількості відвідувачів вашого сайту. Згідно з документацією Google, один контейнер може обробляти приблизно 35 запитів на секунду і коштує приблизно 45 доларів на місяць.
  • Minimum instances — В офіційній довідці Google рекомендує ставити мінімум 2. Це потрібно для того, щоб запити завжди мали куди потрапити — і щоб у вас був “запасний” сервіс на випадок, якщо кілька десятків запитів приходять одночасно. Для дуже малих проектів можна спробувати зменшити до 1, але обережно.
  • Maximum — в довідці Google рекомендує 10, що буде дозволяти оброблювати до близько 350 запитів в секунду. Але навряд чи сайту з трафіком в 50 тисяч користувачів потрібна така потужність (я розумію, що це мова про максимум, але це все одно занадто). Якщо відвідувачів небагато, то 3-4 інстанси буде достатньо.

• Environment variables - дивимось в документації, які змінні нам потрібні:

Перша змінна: PREVIEW_SERVER_URL. У значенні треба вказати посилання з нашого прев’ю-сервіса, який ми створили першим. Для цього заходимо в Services, обираємо тільки що створений прев’ю-сервіс та копіюємо посилання як на скріншоті нижче.

Друга змінна: CONTAINER_CONFIG. Для неї значення таке ж саме, як і для прев’ю - Container config з вашого GTM.

• Створюємо змінні та натискаємо Create.

Крок 3. Налаштовуємо піддомен / підкаталог

Після того як обидва сервіси в Cloud Run створені й налаштовані, переходимо до наступного етапу — підключення піддомену. Саме через нього наш server-side контейнер буде приймати запити з сайту.

Для цього потрібно:

1. Створити Load Balancer, який прийматиме HTTPS-запити та передаватиме їх у Cloud Run.
2. Додати DNS-запис, щоб піддомен вказував на створену IP-адресу.

3.1 Створюємо Load Balancer

Наші наступні кроки такі:

• отримати статичну IP-адресу;
• підключити власний піддомен;
• налаштувати HTTPS із керованим сертифікатом;
• почати стабільно передавати запити до Cloud Run.

Саме для цього і використовується Load Balancer.

Робити налаштування ми теж будемо згідно документації. Переходимо за посиланням і натискаємо Go to load balancing.

1. Перевіряємо, що обрано правильний проєкт — той самий, у якому розгорнуті сервіси Cloud Run. І натискаємо Create Load Balancer.

2. У пункті Type of load balancer залишаємо Application Load Balancer. Network Load Balancer — це більш низькорівневий механізм (TCP/UDP), який використовується для інших сценаріїв. Для server-side GTM він не потрібен.

3. У наступному пункті обираємо Public Facing, оскільки змає приймати запити з сайту користувачів, тобто з інтернету. А Internal підходить тільки якщо сервіс використовується лише всередині VPC.

4. Далі обираємо Best for global workloads. У регіональній конфігурації (Best for regional workloads) не підтримуються Google-managed SSL сертифікати. Це означає, що сертифікат довелося б створювати самостійно і надалі самостійно його оновлювати. Такий підхід ускладнює конфігурацію.

5. Далі - Global external Application Load Balancer.

6. І завершуємо, натиснувши Configure.

Тепер ми бачимо ще один блок frontend налаштувань нашого load balancer.

Frontend — це вхідна точка вашого сервісу. Саме тут визначається, як запити з інтернету потрапляють у систему: який використовується протокол, яка IP-адреса буде прив’язана до балансера, через який порт прийматиметься трафік і який SSL-сертифікат забезпечуватиме HTTPS-з’єднання.

Починаємо з того, що:

1. даємо йому назву, наприклад, ssgtm-lb;
2. даємо назву для Frontend IP and port, наприклад, ssgtm-frontend;
3. і міняємо Protocol на HTTPS (includes HTTP/2 and HTTP/3).

4. Далі нам треба створити нову IP-адресу.

Назвемо її ssgtmip.

5. Тепер створюємо Сертифікат.

У налаштуваннях сертифікату ми:

• Даємо йому назву.
• Обираємо Create Google-managed certificate.
• Вписуємо домен, який хочемо мати для серверного GTM. Наприклад, sg.proanalytics.academy
• Натискаємо Create.

6. Натискаємо Done і переходимо до розділу Backend Configuration. Backend визначає, куди саме Load Balancer передаватиме запити.

7. У полі Backend Services & backend buckets натискаємо Create a backend service.

8. У налаштуваннях обираємо:

• Назву сервісу.
• Тип Serverless network endpoint group.

Далі налаштовуємо групу:

• Даємо назву, наприклад, ssgtm-neg.
• Обираємо той самий регіон, що й при налаштуванні сервісу.
• У типі групи обираємо Cloud Run.
• І вказуємо саме наш основний сервіс (НЕ прев’ю).
• Натискаємо Create.

Далі прибираємо галочку з Enable Cloud CDN і натискаємо Create.

9. Натискаємо Create.

3.2 Додаємо DNS-запис

Поки Load Balancer створюється, переходимо до налаштувань домену.

Відкриваємо панель керування доменом або хостингом і переходимо до розділу DNS. Створюємо новий запис:

Додаємо A-запис:

• Тип — A
• Ім’я — піддомен (наприклад, sg)
• Значення — IP-адреса, створена для Load Balancer.
• І натикаємо Додати.

Щоб знайти IP-адресу, повертаємось до Load Balancer, переходимо на вкладку Frontends і копіюємо адресу. Адреса там зображена у вигляді ip:port, тому ми копієюмо все до знаку ":".

Після додавання запису потрібно дочекатися оновлення DNS.

Крок 4. Перевіряємо, що все працює

Повертаємося до Load Balancer. Відкриваємо його і перевіряємо статус сертифіката.

Спочатку він матиме статус Provisioning. Потрібно дочекатися, поки статус зміниться на Active. Це може зайняти до 30 хвилин. Тут треба просто почекати.

Коли з’являється статус Active ми можемо перевірити наш URL через health check endpoint. У браузері відкриваємо: https://ваш-піддомен/healthz. У нашому випадку це https://sg.proanalytics.academy/healthz

Якщо у відповідь отримуємо OK, як на скріні вище, це означає, що сервер налаштований коректно й готовий до роботи.

Крок 5. Додаємо URL у Google Tag Manager

Після того як піддомен працює, сертифікат активний і /healthz повертає OK, залишається фінальний технічний крок — повідомити Google Tag Manager, що саме цей URL потрібно використовувати як адресу серверного контейнера.

Переходимо до серверного контейнера в вашому Google Tag Manager і відкриваємо Admin -> Edit container -> додаємо піддомен, наприклад https://sg.proanalytics.academy -> Save.

Переходимо в Preview і перевіряємо, що все працює. Якщо все налаштовано правильно: preview-сесія відкриється без помилок, а якщо в сусідній вкладці відкрити свій сайт почнуть з’являтися запити.

Якщо preview не підключається, варто перевірити:

• чи активний SSL-сертифікат
• чи правильно додано DNS-запис
• чи вказано правильний Server Container URL в налаштуваннях GTM
• чи правильно вказані значення для змінної PREVIEW_SERVER_URL в налаштуваннях сервера

Скільки це коштує і як оптимізувати витрати

Вартість тут не є фіксованою сумою, вона складається з трьох компонентів. І важливо розуміти кожен із них окремо, щоб правильно оцінити бюджет.

Кількість запущених контейнерів

Перший і основний компонент вартості — це кількість контейнерів, які у вас запущені в Cloud Run. Один контейнер коштує приблизно 45 доларів на місяць. Тобто якщо ви встановили максимум 4 інстанси і всі 4 постійно працюють, то максимальна вартість за контейнери буде близько 200 доларів на місяць.

Але важливо розуміти, що ви платите саме за ті інстанси, які фактично працюють.

Наприклад, якщо у вас мінімум 2 інстанси і більшість часу система працює саме на цих двох, то реальна сума буде меншою, ніж умовні 200 доларів. Чотири інстанси можуть підніматися лише у моменти пікового навантаження, а не працювати постійно.

Тобто максимальна кількість інстансів — це ваша верхня межа витрат, але не обов’язкова щомісячна сума.

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

Трафік у Google Cloud

Трафік у Google Cloud (вихідний трафік)

Другий компонент вартості — це трафік. Але тут є дуже важливий нюанс: рахується не весь трафік, а тільки вихідний (у документації Google використовується термін Egress).

Вхідний трафік (коли користувач заходить на сайт і запит іде на ваш server-side контейнер) є абсолютно безкоштовним. Оплачується лише вихідний трафік — тобто те, що ваш сервер повертає у відповідь або відправляє далі назовні.

Тобто ви платите не за те, скільки даних «зайшло» на сервер, а за обсяг того, що він згенерував і віддав у відповідь.

У більшості середніх проєктів це не найбільша частина вартості, але її потрібно обов'язково враховувати. Вартість залежить від того, які саме теги налаштовані та який обсяг даних передається назовні, тому точну суму спрогнозувати складно. Детальніше про розрахунок можна прочитати в документації Google.

З нашого досвіду, при стандартних налаштуваннях у середніх проєктах витрати на Egress становлять у середньому близько 40–50 доларів на місяць, але цей показник варто регулярно відстежувати в Google Cloud Billing.

Load Balancer та IP-адреса

Окрім Cloud Run, окремо оплачується використання Load Balancer. За нього нараховується базова погодинна плата (за правила переспрямування). Детальніше про тарифи читайте тут.

Статична IP-адреса оплачується лише в тому випадку, якщо вона зарезервована, але не використовується. Якщо IP підв’язана до Load Balancer і реально обслуговує трафік, додаткової плати саме за IP немає. Детальніше за посиланням.

Зберігання логів

Останній компонент вартості — це зберігання логів. Cloud Run за замовчуванням зберігає логи роботи сервісу: інформацію про запити, відповіді, помилки та технічні події. Це корисно для дебагу та моніторингу, але важливо розуміти, що за зберігання цих логів також нараховується плата. Тобто, навіть якщо контейнери працюють стабільно, частина витрат може формуватися саме через накопичення логів.

Але важливо розуміти, що це керований параметр.

Якщо ви не плануєте регулярно аналізувати логи або використовувати їх для моніторингу, ви можете:

• повністю вимкнути зберігання логів (Детальніше про це читайте за посиланням)
• або скоротити термін їх зберігання

Таким чином можна зменшити витрати без впливу на роботу самого server-side контейнера.

Замість висновку

У результаті налаштування ви отримуєте повноцінну серверну інфраструктуру, яка працює через ваш піддомен, має кероване масштабування та прозору структуру витрат. Початок є - тепер вам потрібно як мінімум виконати наступні кроки:

• вирішити, які події передавати і в які системи;
• налаштувати first-party завантаження скриптів Google;
• налаштувати передачу даних до серверного GTM;
• налаштувати клієнт GA4 для прийому інформації;
• налаштувати коректну передачу даних до Google Analytics 4;
• налаштувати коректну передачу даних до рекламних систем, наприклад Meta та Google Ads.

Про все це, а також багато іншого важливого я детально розповідаю на курсі Server-side GTM Basics.

Якщо ж ви хочете системно та без технічних ризиків впровадити Server-Side GTM на своїх проектах надішліть заявку, заповнивши форму.