Устранение неполадок тегов на стороне сервера с помощью логов серверного GTM

Установка тегов на стороне сервера может оказаться нелегкой задачей. Кроме настройки сервера тегов для вашего sGTM, существует так много различных клиентов, тегов, переменных и триггеров, которые необходимо настроить для бесперебойной работы.

В этой статье я хочу поговорить о логах серверного GTM и о том, как логи помогают диагностировать проблемы с тегами на стороне сервера

Server GTM logsСкопировать ссылку на этот раздел

Логи - это важный инструмент, который необходимо использовать при настройке тегов на стороне сервера. Он может помочь вам устранить любые проблемы с запросами, недостающие данные или даже определить, как поставщик обработал запрос.

Stape предлагает пользователям несколько типов логов:

- Access Logs

- Request Logs

- Response Logs

- И другие логи

Пользователи планов Stape Pro и Pro+ получают доступ к логам за последние 3 дня. А для планов Business и выше - логи доступны за последние 10 дней. Каждый тип лога имеет свои собственные опции фильтрации, такие как диапазон дат или имя клиента, что поможет конкретным событиям не затеряться среди других - идеально, когда вам нужно быстро устранить неполадки. Также возможна загрузка этих запросов в CVS.

Мы рассмотрим каждый тип лога и увидим, как они могут помочь в настройке тегов на стороне сервера. Я также покажу несколько примеров проблем отслеживания ss, с которыми могут помочь логи, чтобы все было понятно в мгновение ока.

Типы server GTM логовСкопировать ссылку на этот раздел

Чтобы посмотреть логи, войдите в свою учетную запись stape.io, откройте контейнер sGTM и перейдите на вкладку "Логи".

Access Logs - показывает запросы, полученные сервером GTM. Можно фильтровать логи доступа по дате, имени клиента, имени события, коду статуса и URL запроса.

На скриншоте ниже я отфильтровал запросы, заявленные клиентом UA. Чтобы увидеть более подробное описание этого лога, нажмите на правую часть запроса.

Если вы развернете детали запроса и прокрутите вниз, вы увидите связанные запросы. Например, при использовании клиента UA для запуска FB CAPI и нажатии на лог доступа UA, вы увидите связанные логи запросов и ответов от FB CAPI. Логи запросов и ответов доступны только для тегов stape, если вы включите эту опцию в настройках тега.

Request Logs - показывают запросы, которые были отправлены сервером GTM на платформы Facebook, TikTok и др. Это работает только в том случае, если вы используете теги Stape. Чтобы включить этот тип лога, перейдите на сервер GTM, откройте тег, прокрутите вниз до Настройки логов и выберите Всегда записывать в консоль.

Response Logs - показывают ответы, полученные от сторонних платформ, таких как Facebook, TikTok и т.д., и работают только при использовании тегов Stape.

Response logs полезны при устранении неполадок с тегами ss. Например, вы можете отфильтровать все ответы, полученные от Facebook, и посмотреть, все ли из них имеют код ответа 200, что означает, что они были обработаны правильно. Если событие не было успешно обработано, можно проверить детали запроса и устранить причину ошибки.

И другие логи - логи, которые мы не можем классифицировать как access, request, или response. Используйте его для просмотра запросов, отправленных тегом logger. Тег logger доступен в галерее шаблонов серверного Google Tag Manager и чрезвычайно полезен для тестирования POST-запросов в sGTM. Я покажу, как использовать тег logger в этой статье блога. 

Случаи использования логов серверного GTMСкопировать ссылку на этот раздел

Существует бесчисленное множество ситуаций, когда серверные логи Google Tag Manager могут помочь в устранении неполадок при настройке тегов на стороне сервера. Вот лишь четыре из многих способов, которые могут вам помочь.

1. Меньше покупок в аналитической платформе, чем в CRM.

Допустим, вы настроили FB CAPI, но видите меньше покупок в менеджере событий Facebook, чем в CRM. Чтобы устранить эту проблему, вы можете перейти в логи и отфильтровать все логи ответов Facebook и посмотреть, все ли события покупки были обработаны успешно (статус 200). Если вы видите какой-либо запрос с другим кодом ответа, откройте данные запроса и проверьте, что вызвало эту проблему; например, проверьте, все ли необходимые параметры были отправлены.

2. Предположительно, неправильно работает атрибуция Facebook ads manager.

Facebook приписывает события кампаниям, проверяя параметр fbc (идентификатор клика). Если вы думаете, что атрибуция FB работает некорректно, первое, что вы захотите проверить, отправляет ли Facebook CAPI параметры fbc и fbp. Просто проверьте детали запроса и посмотрите количество покупок с параметрами fbc.

3. Событию не хватает параметра.

Вы заметили, что в некоторых покупках в Google Analytics отсутствует параметр покупки. В этом случае тег Logger может помочь устранить эту ошибку. Я покажу, как использовать тег Logger позже в этой статье блога. Но основная идея заключается в том, что вы устанавливаете тег в sGTM, который запускает событие покупки, когда значение покупки равно 0. Вы можете добавить пользовательское имя к этому событию и позже проверить его в разделе stape logs.

4. Logging POST requests body.

Логи серверного GTM имеют два типа запросов POST и GET. Тело запроса POST по умолчанию недоступно в логах Google Cloud или Stape. Если вам нужно увидеть более подробную информацию о POST-запросах, используйте Logger Tag и включите Log Request Body в настройках тега.

Настройка Logger Tag в sGTMСкопировать ссылку на этот раздел

1. Скачайте тег Logger с GitHub -> Откройте разделы шаблонов в серверном контейнере Google Tag Manager -> Нажмите New.

2. Нажмите три точки в правом верхнем углу -> Нажмите Импорт -> Выберите шаблон тега Logger, который вы недавно скачали с GitHub -> Нажмите сохранить.

3. Создайте новый тег в sGTM -> Тип тега Logger Tag -> Выберите, хотите ли вы регистрировать события только во время отладки или всегда -> Выберите, какую информацию вы хотите добавить в логи -> добавьте имя события. Вы можете использовать статическое или динамическое имя -> добавьте пользовательские данные, если необходимо -> добавьте триггер. 

4. Запустите отладчик sGTM и протестируйте тег Logger. Когда тег сработает, перейдите в ваш sGTM Container -> нажмите logs -> other logs -> добавьте имя события -> примените фильтр.

Вы увидите информацию о запросах и сможете устранить любые неполадки.

Заключение:Скопировать ссылку на этот раздел

Server GTM Logs - это мощный инструмент при настройке, тестировании и отладке серверных тегов. Самое лучшее в логах stape - это то, что они бесплатны для пользователей платных тарифных планов. В отличие от Google Cloud, где за логи нужно платить дополнительно.

Если вы используете теги stape, вы также можете проверить response logs и четко понять, успешно ли платформа получила и обработала запросы или же допустила какие-то ошибки.

Если вы хотите протестировать конкретную ситуацию, тег logger для sGTM может быть полезен.