Интернет-магазин бытовой техники в Алматы переводит трекинг на серверный GTM. У него около 150 000 визитов в месяц, и маркетолог считает просто: один визит - один запрос. Младший платный тариф Stape рассчитан на 500 000 запросов в месяц, так что запас выглядит тройным (лимиты тарифов собраны в статье о том, во сколько обходится server-side GTM). На пятнадцатый день Stape ставит контейнер на паузу, и события перестают доходить до GA4 и рекламных кабинетов. Сервер работал исправно, ошибка была в первой строке расчёта. Цифры магазина в уроке условные.
Один визит даёт пять запросов
| Что приходит на сервер | Что сделал покупатель |
|---|---|
| page_view | Открыл каталог |
| view_item | Посмотрел холодильник |
| add_to_cart | Положил его в корзину |
| begin_checkout | Начал оформлять заказ |
| gtm.js | Ничего: сайт загрузил скрипт через свой сервер |
Загрузка gtm.js входит в счёт, если скрипт грузится через этот сервер. Запросы измеряют на своём сайте.
Один визит - несколько запросов
В таблице покупатель открыл каталог, посмотрел холодильник, положил его в корзину и начал оформлять заказ. Это четыре события: page_view, view_item, add_to_cart и begin_checkout, и в примере каждое уходит на сервер отдельным запросом. Пятый запрос - загрузка gtm.js. Если сайт берёт скрипт GTM через ваш сервер, чтобы скрипт грузился с вашего домена, это тоже обращение к серверу. Один визит дал пять запросов, и 150 000 таких визитов дали бы уже 750 000.
Stape считает запросом каждое входящее обращение к серверному контейнеру, в том числе загрузку скриптов вроде gtm.js и gtag.js и запросы к Stape Store, его встроенному хранилищу (что Stape считает запросом). Там же Stape предлагает грубую оценку: число событий в GA4 за последние 30 дней плюс 30%. У магазина за месяц 150 000 сеансов и 870 000 событий, значит, запросов будет около 1,1 млн, в семь с половиной раз больше, чем насчитал маркетолог.
Визиты бывают разные: кто-то уходит с первой страницы, кто-то листает двадцать товаров. Поэтому число запросов на визит не угадывают по примеру, а меряют на своём сайте, как в задании в конце урока.
Теперь понятно, откуда пауза. 1,1 млн запросов в месяц - это около 37 700 в день. Лимит в 500 000 магазин израсходовал за 14 дней, а на пятнадцатый перевалил за 550 000. Если расход превысил лимит на 10%, Stape ставит контейнер на паузу, и тот не обрабатывает ни одного запроса, пока вы не перейдёте на тариф выше или не начнётся следующий расчётный период. На младших платных тарифах пауза наступает сразу, на старших первое превышение получает разовую отсрочку на 30 дней. Паузы не будет, если в настройках подписки включить автоматический переход на следующий тариф (лимиты и пауза у Stape).
У другого провайдера единица счёта может быть другой, так что перед сравнением тарифов найдите на его сайте, что именно он считает. А на Cloud Run за запросы не платят вовсе. В руководстве Google экземпляры запускают с постоянно выделенным процессором (флаг --no-cpu-throttling), и при такой модели экземпляр оплачивается всё время, пока запущен, даже без запросов (модели оплаты Cloud Run). Там, как и на своём сервере, число запросов отвечает на другой вопрос: сколько мощности держать.
Считайте по пику, а не по месяцу
1,1 млн запросов в месяц - это в среднем 26 запросов в минуту. С такой нагрузкой справится что угодно, только трафик не приходит равномерно. В пятницу в 20:00 магазин делает рассылку в WhatsApp и выкладывает сторис о распродаже, и за час приходит 12 000 визитов. При тех же 7,5 запроса на визит это 90 000 запросов за час, или 1 500 в минуту. А в первые минуты после рассылки, когда люди открывают ссылку разом, запросов в разы больше.
Месячный объём подсказывает, какой тариф брать. Выдержит ли сервер, решает пик. Его берут из прошлого: самый нагруженный час прошлой распродажи или запуска кампании в GA4 или в выгрузке GA4 в BigQuery.
Для ориентира у Google есть одна оценка: от 2 до 10 экземпляров Cloud Run обрабатывают от 35 до 350 запросов в секунду, а точнее зависит от того, сколько тегов в контейнере и что они делают (руководство по Cloud Run). 1 500 запросов в минуту - 25 в секунду, это в пределах двух экземпляров. Пик первых минут считают отдельно, как при выборе того, где хостить sGTM.
Кто за что отвечает
У серверного контейнера три зоны ответственности, и в каждой нужен человек с именем:
- Сервер. Работает, обновлён, выдерживает пик, счёт оплачен.
- Схема событий. Какие события уходят, с какими полями и что считается покупкой.
- Доставка. События доходят до GA4, Meta и Google Ads, и получатели их принимают.
Выбор хостинга меняет только первую зону:
| Cloud Run | Stape | Свой сервер | |
|---|---|---|---|
| Где работает сервер | В проекте Google Cloud клиента | У Stape, в аккаунте клиента | На VPS или в облаке клиента, например в AWS |
| Кто ведёт сервер | Вы или админ клиента: экземпляры, обновления, логи, бюджет | Stape поднимает и обслуживает сервер, вы настраиваете контейнер, домен и логи в его панели | Админ клиента: машина, сертификат, перезапуски, мониторинг |
| Кто ведёт схему событий и доставку | Тот, кто настраивает трекинг | Тот, кто настраивает трекинг | Тот, кто настраивает трекинг |
Хостинг не знает, что purchase должен уходить после оплаты, а не при открытии страницы «Спасибо». Ни Google, ни Stape не заметят, что из события пропала сумма заказа. Поэтому последняя строка таблицы одинаковая во всех столбцах.
Аккаунты оформляйте на клиента: проект и платёжный аккаунт Google Cloud, аккаунт Stape. Себе берите доступ. В Stape для этого есть общий доступ к рабочему пространству, а доступ к оплате выдаётся отдельной галочкой (общий доступ в Stape). Когда проект закончится, сервер останется у клиента, и никому не придётся переносить контейнер с вашей карты.
Из чего складывается счёт
Цен в уроке нет, они меняются. Тарифы и арифметика собраны в статье о стоимости sGTM. Здесь строки сметы, которые легко пропустить.
Экземпляры. Чтобы сбой одного экземпляра не стоил потерянных событий, Google советует держать запущенными несколько (--min-instances), но пишет об этом по-разному: в руководстве по Cloud Run не меньше двух, в обзоре серверного тегирования не меньше трёх. Верхняя граница --max-instances - это худший случай по оплате: столько экземпляров Cloud Run запустит, только если они понадобятся.
Preview-сервер. Отдельный сервис, без которого не работает предварительный просмотр контейнера. Рабочий трафик обрабатывают серверы тегов, а запросы предварительного просмотра они пересылают на preview-сервер. Ему нужен ровно один экземпляр, без масштабирования (ручная настройка). В смете это отдельная строка.
Логи. По умолчанию Cloud Run записывает каждый запрос вместе с путём и параметрами, а сервер и теги могут писать в консоль свои сообщения. Google предупреждает, что при большом потоке, например больше миллиона запросов в месяц, это заметно увеличивает счёт, и рекомендует запись запросов отключить фильтром в Logs Router. Поток магазина из примера, 1,1 млн запросов в месяц, как раз на этой границе. Отключать всё целиком не обязательно: фильтр может исключить успешные ответы и оставить записи с кодами 4xx и 5xx. По ним потом видно, когда и на чём сервер ошибался, а за каждый успешный запрос платить не придётся.
Исходящий трафик. Сервер пересылает каждое событие дальше, в GA4, Meta и другие системы. AWS в своём руководстве по sGTM прямо предупреждает о плате за передачу данных в Google Analytics и каждому стороннему получателю (sGTM на AWS).
Обновления. Google советует периодически перезапускать серверы, чтобы они получали обновления кода, и обновлять сервер хотя бы с каждой мажорной версией (ручная настройка). На Cloud Run это новая ревизия с теми же настройками. За этой строкой стоят часы людей, о них ниже.
В Google Cloud сразу заведите бюджет с оповещениями на почту клиента и на вашу. Только учтите: бюджет с одними оповещениями трату не останавливает. Google прямо пишет, что такой бюджет не ограничивает ни использование сервисов, ни расходы, а первое письмо может прийти через несколько часов после создания бюджета (бюджеты и оповещения). Есть и бюджет с потолком расходов (spend cap), Cloud Run его поддерживает. Но когда потолок достигнут, сервис встаёт на паузу до конца периода или пока потолок не снимут (потолок расходов). Для сервера тегов пауза означает, что события перестали собираться. Ставить ли потолок, решает клиент, и решает, зная эту цену.
Время людей тоже в смете
Положим, час инженера стоит 12 000 ₸. На Cloud Run в проекте клиента уходит день на запуск: домен, экземпляры, фильтры логов, бюджет. Это 96 000 ₸. Потом пара часов в месяц на обновления и разбор оповещений, ещё 24 000 ₸ ежемесячно. На Stape сервер поднимает провайдер, и подключение занимает пару часов. В статье о стоимости sGTM дешевле всех по железу выходит VPS, на котором рядом работают другие сервисы. Но машину, сертификат, перезапуски и мониторинг кто-то должен вести. Если админа у клиента нет, этим человеком станете вы, и часы нужно вписать в договор.
Положите эти суммы рядом с ценами из статьи о стоимости sGTM и посмотрите, что больше: разница в тарифах или разница в часах.
Сервер отвечает - это ещё не доставка
Сервер тегов отвечает ok, если открыть его адрес с /healthy на конце (руководство по Cloud Run). Google советует использовать этот адрес как проверку живости: если ответ не ok, сервер перезапускают. На Cloud Run и на своём сервере поставьте на него внешнюю проверку доступности с первого дня.
Но ok говорит только о том, что сервер жив. Тег Meta мог не сработать, Meta могла отклонить событие с неверным полем, и /healthy об этом не узнает. Доставку смотрят отдельно: по исходящим запросам и кодам ответа получателей в логах и по сверке покупок в рекламных кабинетах с заказами в CRM. У Stape для этого есть логи входящих и исходящих запросов, исходящие включаются отдельным переключателем (логи Stape). Такой контроль строят по правилам мониторинга S2S.
Задание: смета и владельцы для своего проекта
Возьмите сайт клиента или свой тестовый сайт с серверным контейнером из урока про server-side GTM.
Выполнено 0 из 6
В итоге у вас должен получиться абзац, который можно отправить клиенту. Для магазина из урока он звучал бы так: «Ждём около 1,1 млн запросов в месяц. В час рассылки в среднем 1 500 запросов в минуту, в первую минуту в разы больше. Сервер на Stape в вашем аккаунте, автоматический переход на следующий тариф включён, за события и доставку отвечаю я». Первую минуту считают отдельно, как в уроке о том, где хостить sGTM.
Если число запросов из предварительного просмотра, умноженное на визиты, сильно расходится с оценкой по правилу Stape, найдите причину. Возможно, часть событий уходит на сервер мимо GA4, например только для Meta, или через сервер грузится gtm.js, которого нет среди событий GA4. Правило Stape даёт грубую оценку, а замер на вашем сайте точнее, и в смету идёт он.
Видео: сравнение подходов к размещению
Видео на английском. Цены в нём могли устареть, актуальные собраны в статье о стоимости sGTM.