Серверний Google Tag Manager обріс обіцянками: поверне втрачені конверсії, обійде блокувальники, полагодить атрибуцію. Частина цього правда, частина — ні, і різницю видно тільки після того, як поставиш його сам.
Ми поставили. Нижче — рішення, які довелося ухвалити, і що з них вийшло.
Що взагалі змінюється
У класичній схемі браузер відправляє дані на домени Google. У серверній він відправляє їх на ваш власний ендпоінт, а вже той передає їх далі — в аналітику, у рекламні системи, куди потрібно.
Змінюється не те, що ви вимірюєте. Змінюється, чиїм доменом підписаний запит і хто контролює дані дорогою.
Головне рішення: шлях, а не піддомен
Стандартна порада — виділити піддомен на кшталт t.вашсайт.com. Ми починали саме так і потім переробили на директорію на домені самого сайту. Причина того варта.
Піддомен t.сайт.com
- блокується списками — це ім'я хоста
- потребує окремого запису в CSP
- новий DNS-запис і новий сертифікат
- працює навіть якщо сайт на чужому хостингу
Єдина реальна перевага піддомена — він не вимагає контролю над вебсервером сайту.
Шлях /збірник
- не блокується без блокування сайту
- уже покритий правилом self у CSP
- жодного DNS і жодного сертифіката
- потрібен контроль над вебсервером
Той самий origin означає, що для суворої політики безпеки це просто ваш сайт.
Блокування — вирішальний пункт. Піддомен це ім'я хоста, а імена хостів потрапляють у списки. Обирати t. замість gtm. означає лише обійти найпростіші з них. Директорія на домені сайту не блокується інакше, ніж разом із сайтом.
Друга перевага виявилася дуже конкретною. Наш сайт віддається зі суворою політикою безпеки без підстановок, і кожен новий домен для тегів там довелося б додавати окремо — тобто змінювати код і передеплоювати. Той самий origin не потребує жодного рядка.
Ціна цього рішення теж конкретна: потрібен контроль над вебсервером, який віддає домен. Поки сайт стояв на чужому шаред-хостингу, зробити так було неможливо — маршрут до директорії налаштовується там, де живе домен. Саме тому робота чекала переїзду сайту, а не навпаки.
Пастка з піддоменом, у яку ми потрапили
Один випадок варто розповісти, бо він не гуглиться.
Прев'ю-сервер спершу підняли теж на піддомені. Виявилося, що загальний символьний запис *.домен резолвив його на проксі старого хостера, чий сертифікат виписаний на зовсім інше ім'я. Сервер тегів пішов туди по HTTPS, отримав невідповідність імені в сертифікаті — і режим прев'ю віддавав HTTP 500 без жодної підказки, що справа в DNS.
Перенесення прев'ю на директорію прибрало з рівняння і DNS, і сертифікат одразу. Мораль вужча, ніж «шлях кращий»: кожен піддомен, який ви додаєте, успадковує чужі записи, про які ви забули.
Що це справді лагодить, а що ні
| Що кажуть | Що насправді | Масштаб |
|---|---|---|
| «Поверне втрачені конверсії» | частину — ті, що губилися на блокуванні запитів до чужих доменів | відсотки, не половина |
| «Обійде блокувальники» | запит до свого домену не блокується; сама подія все одно потребує згоди | залежить від частки згод |
| «Подовжить життя куків» | так — кука ставиться вашим сервером, а не сторонньою стороною | реальний ефект, особливо в Safari |
| «Прискорить сайт» | тільки якщо винести на свій домен ще й завантаження скриптів | окремий крок, не з коробки |
Головне, чого воно не робить: не бачить людей, які не дали згоди, і не відновлює даних, яких не було. Серверна схема покращує доставку — вона не створює подій.
Пункт про швидкість варто розкрити, бо він контрінтуїтивний. Базовий серверний контейнер уміє приймати виміри аналітики — і повертає помилку на спроби віддати з нього самі скрипти. Це не поломка: щоб віддавати ще й JavaScript зі свого домену, у контейнер додається окремий клієнт. Саме той крок дає виграш у швидкості; сама по собі серверна схема його не дає.
Скільки це коштує
Три варіанти, і різниця між ними не в грошах, а в тому, чия це відповідальність.
Готовий сервіс. Щомісячна плата, нуль налаштувань, дані проходять через посередника.
Хмара великого провайдера. Плата за використання, автоматичне масштабування, стандартний шлях із документації.
Свій сервер. Якщо коробка вже є — фактично безкоштовно: образ важить близько 110 МБ, однієї віртуальної машини достатньо, більше одного ядра на екземпляр не використовується взагалі.
І тут потрібна чесність, якої в описах цієї технології зазвичай бракує. Рекомендація вендора для продакшену — не менше трьох екземплярів. Ми свідомо працюємо на одному. Це означає, що перезапуск контейнера — це пропуск у зборі даних, а не сповільнена відповідь. Для агенційного сайту прийнятно; для магазину з мільйонними оборотами — ні.
Ще одна деталь із власних граблів: контейнери не варто публікувати портами назовні. Docker пише власні правила фаєрвола в обхід звичайного, тож опублікований порт доступний зі світу, що б не показував статус фаєрвола.
Кому це потрібно, а кому ні
Не потрібно, якщо у вас ще не налаштоване звичайне відстеження конверсій. Серверна схема покращує доставку події — вона не робить подію правильною. Спершу ланцюжок від форми до звіту, потім усе інше.
Потрібно, якщо ви впираєтеся в стелю: значна частка трафіку з браузерів, що обмежують сторонні куки, довгий цикл угоди, де важливо не втратити зв'язок між візитами, або вимога тримати дані у себе.
Проміжний варіант — почати з вимірювання втрат. Порівняйте кількість заявок у своїй CRM із кількістю конверсій в аналітиці за той самий місяць. Розрив і є верхньою межею того, що серверна схема здатна відіграти.
З чого почати
Перевірте базове: чи збігаються цифри конверсій із реальними заявками. Чекліст аналітики проходить це за шість блоків, і його варто закрити до будь-яких серверних робіт.
Якщо базове в порядку і питання в тому, чи варта серверна схема заходу саме у вас, — подивіться, як ми працюємо з аналітикою й відстеженням.