Google tag manager на стороні сервера: як налаштувати Tag Manager, Universal Analytics, GA4 і Facebook conversion API на стороні сервера

Server-side tagging є однією з основних тенденцій веб-аналітики протягом останніх кількох років. Блокувальники реклами, інтелектуальний захист від відстеження, обмеження сторонніх файлів cookie, правила, такі як GDPR, змушують аналітичні та рекламні компанії хвилюватися про те, як і яку інформацію вони збирають про відвідувачів сайту. Додавання тегів на стороні сервера дозволяє перемістити сторонні теги з вашого сайту на хмарний сервер. У цьому випадку пікселі сторонніх розробників завантажуються безпосередньо з сервера could, а не з вашого сайту.

У цій статті я поясню й продемонструю основи налаштування серверного контейнера Google Tag Manager, серверні Universal Analytics, GA4 та Facebook Conversion API.

Навіщо використовувати server-side tagging?Скопіюйте посилання на цей розділ

Однією з перших компаній, які почали говорити про теги на стороні сервера, був Facebook. Вони анонсували новий метод відстеження користувачів у 2018 році. А в 2021 році вони перейменували його на Facebook Conversion API і сказали, що всі рекламодавці FB повинні впровадити FB CAPI, зробивши його майже обов’язковим.

Логіка Facebook conversion API дуже схожа на офлайнові події: ви надсилаєте інформацію про користувача (електронну пошту, ім’я, номер телефону тощо) і дані про події (наприклад, ідентифікатор кліку, назву події, ідентифікатор події тощо). Facebook і вони намагаються зіставити користувача з вашого сайту з користувачем у своїй базі даних і призначити подію цьому конкретному користувачеві. Чим більше інформації про користувача та подію ви надсилаєте на Facebook, тим більша ймовірність, що користувач, який здійснив конверсію на вашому сайті, зіставить користувача в їхній базі даних. У менеджері подій у FB ви можете побачити якість відповідності ваших подій. Якість відповідності подій (Event Match Quality) має найвищий показник 10 і показує ефективність інформації користувача, надісланої з вашого сервера, у збігу подій з обліковим записом Facebook. Висока якість відповідності подій може позитивно вплинути на ефективність оголошення та атрибуцію.

Хоча Facebook Conversion API настійно усіма рекомендується (через обмеження iOS 14, ITP і блокувальники реклами), ви все одно можете використовувати теги у браузері. Існує кілька методів налаштування відстеження Facebook:

1) Браузер. Якщо ви використовуєте лише методи браузера, швидше за все, Facebook буде занижувати дані про події. Деякі дослідження показують, що близько 80% людей використовують Facebook лише на мобільних пристроях. Частка ринку iOS становить приблизно 30%. За внутрішніми оцінками FB, менше 20% користувачів Facebook iOS дозволять відстеження. Зрештою, ваш піксель Facebook буде пропускати дані про події приблизно для 16% користувачів вашого сайту. Але, звичайно, ця цифра буде відрізнятися залежно від вашої країни, цільової аудиторії та продукту.

2) Комбінований спосіб типу браузер + сервер. Цей метод має два підметоди.

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

2.2) Відстеження деяких подій у браузері та інших подій на сервері. Якщо ви використовували рідну програму Facebook Shopify для відстеження конверсій і перейшли на максимальний обмін даними, Facebook відстежуватиме подію Purchase із сервера та інші події у браузері.

3) Сервер. У цьому випадку всі події будуть відстежуватися з сервера. Це допоможе зібрати дані про всіх користувачів і збільшити швидкість сторінки. За допомогою відстеження сервера важливо надсилати якомога більше даних користувача та параметрів подій. Вся особиста інформація про вашого користувача, яку ви надсилаєте на Facebook, має хешуватися.

У 2020 році Google випустила нову версію Google Tag Manager – серверний контейнер. Логіка серверних контейнерів суттєво відрізняється від того, що ми раніше мали всередині веб-контейнера. Крім того, Google додав новий об’єкт до серверного контейнера – він називається Client.

Ще одна велика відмінність між веб- та серверними контейнерами полягає в тому, що серверний контейнер не є безкоштовним. Якщо ви використовуєте Google Cloud Platform, швидше за все, ви будете платити мінімум 120 доларів США на місяць. Є можливість безкоштовно налаштувати тестовий контейнер за допомогою одного сервера. Але Google рекомендує використовувати мінімум 3 сервери, щоб зменшити ризик втрати даних (кожен сервер коштує близько 40 доларів США), але, звичайно, ви можете запустити менше (або більше) серверів.

Майте на увазі, що ви не можете перемістити всі пікселі відстеження на стороні сервера. Наприклад, LinkedIn і Twitter поки не підтримують тегування на стороні сервера. У той же час ви можете перемістити Facebook, Universal analytics, GA4, Snapchat, Bing, Reddit, Pinterest, Yandex, Klaviyo (та деякі інші платформи електронної пошти) до тегування на стороні сервера.

Усі ці зміни в інфраструктурі відстеження Google і Facebook доводять, що світ відстеження зміниться за пару років, і тегування на стороні сервера може стати новим стандартом відстеження поведінки користувачів.

Але як щодо переваг тегування на стороні сервера? Чому слід перейти з веб- на серверне тегування?Скопіюйте посилання на цей розділ

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

Основні переваги тегів на стороні сервера:Скопіюйте посилання на цей розділ

1. По-перше, найважливішою причиною впровадження тегів SS є більш точне відстеження користувачів. Завдяки SS Facebook і Google Analytics ви матимете точніші дані, оскільки пікселі відстеження не будуть блокуватися блокувальниками реклами ITP та іншими обмеженнями відстеження.

2. Подовження терміну дії файлів cookie в Safari (та інших браузерах, які використовують інтелектуальне запобігання відстеження). Ми всі використовували термін служби файлів cookie Google Analytics – два роки. Але починаючи з 2020 року Safari скоротив термін життя файлів cookie до 7 днів (а в деяких випадках і лише 24 годин). Це означає, що якщо користувач не переходить на ваш сайт кожні сім днів, він вважатиметься новим. Зменшений термін життя файлів cookie може мати значний вплив на ваші аналітичні дані. Скажімо, користувач Safari побачив ваше оголошення в Google AdWords, натиснув на нього, а потім повернувся на сайт через сім днів і зробив покупку. У цьому випадку Analytics віднесе конверсію до джерела прямого/немає трафіку. Це означає, що ви не зможете правильно розрахувати рентабельність інвестицій у рекламу для своїх PPC-кампаній і приймати правильні рішення під час оптимізації облікового запису AdWords.

3. Краща швидкість сторінки. Швидкість роботи сайту буде покращена, оскільки скрипти відстеження не завантажуватимуться у браузер користувача. З мого досвіду, один із найважчих скриптів – це Facebook. Якщо сайт співпрацює з рекламним агентством, на його сайті може бути кілька скриптів Facebook. Добре те, що ви можете повністю перенести Facebook на сторону сервера

4. Збільште дані про своїх користувачів. За допомогою тегування на стороні сервера ви можете передавати дані зі своєї CRM (наприклад, замовлення по телефону, продажі тощо) в Google Analytics або будь-який інший аналітичний інструмент, який підтримує тегування SS.

Як налаштувати теги на стороні сервера на вашому сайті?Скопіюйте посилання на цей розділ

Я розділю цей гайд на чотири частини:

• Створення серверного контейнера Google Tag Manager

• Додавання кастомного домену

• Налаштування Universal Analytics або Google Analytics 4 на стороні сервера

• Налаштування Facebook Conversion API.

1. Налаштуйте серверний контейнер Google Tag ManagerСкопіюйте посилання на цей розділ

1.1 Увійдіть у свій обліковий запис Google Tag Manager і створіть серверний контейнер. Для цього перейдіть до налаштувань адміна -> натисніть + під контейнерами -> додати ім'я контейнера -> виберіть сервер -> натисніть створити -> виберіть «Manually provision tagging server» -> скопіюйте конфігурацію контейнера, яку ви побачите у спливаючому вікні.

1.2 Створіть або увійдіть у свій обліковий запис у нашому сервісі -> натисніть «створити контейнер» -> вставте конфігурацію контейнера, яку ви скопіювали з Google Tag Manager -> натисніть «Створити контейнер». Налаштування контейнера займе до 10 хвилин. Оновіть сторінку за пару хвилин. Якщо налаштування пройшло успішно, статус контейнера буде «Запущений».

2. Створіть та додайте кастомну URL-адресу тегів.Скопіюйте посилання на цей розділ

2.1 Виберіть субдомен, який ви хочете використовувати як URL-адресу сервера тегів. Я рекомендую вам використовувати те, що не пов’язане з відстеженням, аналітикою, gtm тощо. Причиною цього є те, що деякі блокатори реклами почали блокувати всі запити, які надходять з URL-адреси, яка містить будь-яке ключове слово, що стосується відстеження користувачів. Наприклад, якщо ви будете використовувати gtm.yoursite.com, запити можуть бути заблоковані, оскільки вони бачитимуть gtm у вашій URL-адресі. Отже, ви можете зробити щось на кшталт tgurl.yoursite.com або ss.yoursite.com або все, що вам спадає на думку.

2.2 Щоб налаштувати кастомну URL-адресу для серверного контейнера Google Tag Manager, вам потрібно оновити запис A для свого субдомену. У цьому гайді я розповім, як це зробити всередині Cloudflare. Увійдіть у свій обліковий запис Cloudflare -> виберіть домен -> натисніть DNS -> Додати запис. Налаштування мають виглядати так:

Тип: А

Ім'я: ss (або будь-який інший субдомен, який ви бажаєте)

IPv4-адреса: IP-адреса залежить від розташування серверів. Ви можете знайти кастомну IP-адресу домену в обліковому записі stape.io.

TTL: статус автопроксі: вимкнено

Після завершення натисніть Зберегти.

2.3 Оновіть URL-адреси тегів у нашому сервісі. Натисніть налаштування та додайте створений вами кастомний домен. Зауважте, що деяким реєстраторам може знадобитися до 72 годин, щоб налаштувати субдомен. Щойно домен буде налаштовано та запущено, статус контейнера в нашій службі буде запущеним.

2.4 Перейдіть до налаштувань адміна серверного контейнера керування тегами Google і оновіть URL-адресу сервера тегів. Оновіть код Google Tag Manager на своєму сайті. Змініть виділене доменне ім’я на субдомен вашої URL-адреси тегів як для скріпту gtm.js, так і для файлу ns.html:

2.5. Додайте транспортну URL-адресу до тегу Universal Analytics або Google Analytics 4 у WEB-контейнері Google Tag Manager. Ви можете зробити це, додавши транспортну URL-адресу до змінної Universal Analytics, яку ви використовуєте всередині WEB-контейнера, або додавши її до тегу UA в розширеній конфігурації.

2.6 Щоб оновити URL-адресу тегів у Google Analytics 4, вам потрібно додати ці записи до полів, які потрібно встановити.

назва поля: transport_url

значення: ваша URL-адреса тегів

3. Налаштування Universal Analytics або GA4 на стороні сервера.Скопіюйте посилання на цей розділ

3.1 Перейдіть до серверного контейнера Google Tag Manager. Натисніть Клієнти та додайте клієнта Universal Analytics або Google Analytics 4.

3.2 Створіть теги Universal Analytics або GA4 всередині серверного контейнера. Перейдіть до тегів -> натисніть додати новий -> виберіть UA або GA4.

3.3 Створіть тригери для тегів, які ви створили на попередньому кроці. Для тегу UA тригером має бути ім’я клієнта, що дорівнює Universal Analytics. А для тригера GA4 має бути ім’я клієнта, що дорівнює GA4.

3.4 Відкрийте режим налагодження серверного контейнера Google Tag Manager і переконайтеся, що UA або GA4 працює на сервері. Зауважте, що налагоджувач сервера оновлюється довше, ніж веб. Щоб ще раз перевірити налаштування, відкрийте консоль і перевірте запити Google Analytics. Коли все налаштовано, не забудьте опублікувати зміни.

4. Налаштування Facebook conversion APIСкопіюйте посилання на цей розділ

4.1 Додайте шаблон тега Facebook із галереї шаблонів.

4.2 Створіть тег Facebook у серверному контейнері Google Tag Manager -> Додайте свій ідентифікатор пікселя Facebook і Facebook API access token. (ось тут можна знайти свій FB API access token).

4.3 Наш кастомний тег має два варіанти налаштування Facebook CAPI: успадкувати від клієнта GA та override. Успадкування від клієнта GA буде відповідати подіям UA та подіям Facebook (якщо можливо, стандартним подіям, якщо ні, то запис як кастомні події). Для успадкування налаштування тригером має бути ім’я клієнта, що дорівнює Universal Analytics. Другий варіант — замінити події FB. У цьому випадку вам потрібно буде вибрати назви подій і створити тригер для кожної події FB, яку ви хочете відстежувати. У цьому випадку подія перегляду сторінки у FB має викликати назву події, що дорівнює перегляду сторінки.

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

Висновки:Скопіюйте посилання на цей розділ

Server-Side tagging є стійкою заміною тегів на стороні клієнта, оскільки воно охоплює всі поточні та майбутні обмеження відстеження на стороні клієнта. Але оскільки ця технологія знаходиться на початковій стадії, ви не можете повністю замінити відстеження на стороні клієнта серверною. Проте, здається, що тегування на стороні сервера стає новим стандартом веб-аналітики. Ось чому я пропоную почати поступово відмовлятися від відстеження зі сторони клієнта і перейти на сторону сервера.