Усунення несправностей із тегами на стороні сервера за допомогою логів севрерного GTM

Налаштування тегування на стороні сервера може бути важкою задачею. За винятком налаштування сервера тегування для вашого sGTM, існує дуже багато різних клієнтів, тегів, змінних і тригерів, які потрібно налаштувати для безперебійної роботи.

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

Server GTM logsСкопіюйте посилання на цей розділ

Логи – це важливий інструмент для налаштування тегів на стороні сервера. Вони можуть допомогти вам усунути будь-які проблеми із запитами, відсутніми даними або навіть визначити, як постачальник обробив запит.

Stape пропонує кілька типів логів користувачам:

- Access Logs

- Request Logs

- Response Logs

- Та інші логи

Користувачі планів Pro та Pro+ отримують доступ до логів за останні 3 дні. А для планів Business і вище - логи доступні за останні 10 днів. Кожен тип лога має свої власні параметри фільтрації, як-от діапазон дат або ім’я клієнта, які допоможуть гарантувати, що певні події не загубляться серед інших – це ідеально підходить, коли вам потрібно швидко усунути неполадки. Також можна завантажити ці запити в CVS.

Ми розглянемо кожен тип логів і побачимо, як вони можуть допомогти налаштувати тегування на стороні сервера. Я також збираюся показати кілька прикладів проблем відстеження ss, з якими логи можуть допомогти, щоб усе було зрозуміло відразу.

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

Щоб переглянути логи, увійдіть у свій обліковий запис stape.io, відкрийте контейнер sGTM та перейдіть на вкладку Logs.

Access Logs - показують запити, отримані серверним GTM. Можна фільтрувати логи доступу за датою, назвою клієнта, назвою події, кодом стану та URL-адресою запиту.

На скріншоті нижче я відфільтрував запити, заявлені клієнтом UA. Щоб переглянути більш детальний опис цього лога, клацніть праворуч від запиту.

Якщо розгорнути деталі запиту та прокрутити вниз, ви побачите пов’язані запити. Наприклад, під час використання клієнта UA для запуску FB CAPI та натискання лога доступу UA, ви побачите пов’язані логи запитів і відповідей від FB CAPI. Логи запитів і відповідей доступні лише для тегів від stape, якщо ввімкнути цю опцію в налаштуваннях тегів.

Request Logs – показують запити, надіслані серверним GTM на платформи Facebook, TikTok тощо. Це працює, лише якщо ви використовуєте теги Stape. Щоб увімкнути цей тип лога, перейдіть на серверний GTM, відкрийте тег, прокрутіть униз до Налаштування логів і виберіть Always log to console.

Response Logs – показують відповіді, отримані від сторонніх платформ, таких як Facebook, TikTok тощо, і працюють лише за умови використання тегів Stape.

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

Та інші логи – це логи, які ми не можемо класифікувати як access, request, чи response.. Використовуйте їх, щоб переглянути запити, надіслані logger тегом. Тег Logger доступний у галереї шаблонів server Google Tag Manager і надзвичайно корисний для тестування запитів POST у sGTM. Я покажу, як використовувати тег Logger, у цьому блозі.

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

Існує незліченна кількість ситуацій, коли логи server 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. Ви можете додати власну назву до цієї події, а потім перевірити її в розділі логів.

4. Logging  POST requests body. 

Логи GTM на стороні сервера мають два типи запитів POST і GET. Тіло запиту POST за замовчуванням недоступне в логах Google Cloud або Stape. Якщо вам потрібно переглянути докладнішу інформацію про POST-запити, скористайтеся тегом Logger і увімкніть тіло запиту лога в налаштуваннях тегу.

Налаштування тегу Logger в sGTMСкопіюйте посилання на цей розділ

1. Завантажте тег Logger з GitHub -> Відкрийте розділи шаблонів у server Google Tag Manager -> Натисніть Створити.

2. Натисніть три крапки у верхньому правому куті -> Натисніть Імпорт -> Виберіть шаблон тегу Logger, який ви нещодавно завантажили з GitHub -> Натисніть зберегти.

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

4. Запустіть налагоджувач sGTM та перевірте тег Logger. Після того, як тег активується, перейдіть до свого контейнера sGTM -> натисніть логи -> інші логи -> додайте назву події -> застосувати фільтр.

Ви побачите інформацію про запити та зможете усунути будь-які проблеми.

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

Server GTM Logs — це потужний інструмент для налаштування, тестування та налагодження тегів на стороні сервера. Найкраще в логах від stape – це те, що вони безкоштовні для користувачів платного плану. На відміну від Google Cloud, де вам потрібно сплачувати додаткову плату за логи.

Якщо ви використовуєте теги stape, ви також можете перевірити response logs і чітко зрозуміти, чи успішно платформа отримувала та обробляла запити чи спонукала до деяких помилок.

Якщо ви хочете перевірити конкретну ситуацію, logger tag для sGTM може бути корисним.