Google Tag Manager був спочатку розроблений для того, щоб полегшити життя маркетологам. Якщо ви використовуєте веб-контейнер Google Tag Manager, вам більше не потрібно просити розробників додати пікселі відстеження та чекати наступного оновлення, щоб побачити ваше відстеження в робочій версії.
Server-side Google Tag Manager tagging є складнішим, ніж налаштований веб-контейнер, принаймні наразі, оскільки ідея та технологія тегів на стороні сервера повністю відрізняються від того, що ми раніше мали в Інтернеті. Але тегування на стороні сервера дасть вашому сайту величезні переваги. Тегування на стороні сервера стає все більш популярним завдяки його можливості відстежувати людей навіть з AdBlockers, браузерами з ITP та іншими обмеженнями відстеження.
Мета цієї статті — не переконати вас почати використовувати теги на стороні сервера (є ще одна публікація в блозі, яка описує основні переваги відстеження на стороні сервера). Я припускаю, що ви вже вирішили застосувати тегування на стороні сервера на своєму сайті. Ця публікація в блозі покаже вам, як перевірити, чи правильно налаштовано відстеження на стороні сервера для GA4 та Facebook Conversion API.
Ми розглянемо такі методи: перевірка тегів на стороні сервера в режимі налагодження серверного контейнера Tag Manager, інструмент тестування подій Facebook і інструмент розробників у вашому браузері. Давайте розпочнемо.
У цьому відео показано, як тестувати серверний Google Analytics👇
Я пропоную почати з режиму попереднього перегляду та налагодження Tag Manager, щоб переконатися, що ваші теги запускаються, коли вони повинні. Інструмент налагодження GTM покаже вам, які теги та події були додані на сайт і чи запускалися вони на певних сторінках/тригерах.
Tag manager server container debug mode працює аналогічно веб-налагоджувачу. Просто натисніть кнопку попереднього перегляду у верхньому правому куті. Потім після різних сторінок натисніть кнопку або виконайте події, налаштовані в серверному контейнері.
Поверніться до налагоджувача Tag Manager і перевірте, які теги та події були запущені, а також чи всі необхідні параметри були надіслані на рівень даних. Якщо все працює правильно, можна переходити до наступного кроку.
GA4 має власне подання налагодження, яке показує вам усі події, параметри подій і дані користувача, які ми обробили GA4. Щоб знайти налагоджувач GA4, натисніть Налаштувати -> Debug view.
Щоб переконатися, що запити надсилаються із кастомної URL-адреси тегів, вам потрібно зануритися глибше в зону розробника. Тут нам знадобляться інструменти розробника Chrome або Safari (ви також можете використовувати інші браузери).
На Mac ви можете отримати доступ до інструмента розробника, натиснувши command+option+I або клацніть правою кнопкою миші, а потім inspect.
Відкривши інструмент розробника, перейдіть на вкладку Мережа та оновіть сторінку. Усередині фільтра введіть collect. Ви повинні побачити запити GA4. Натисніть на запит GA4, і праворуч ви побачите додаткові параметри.
Майте на увазі, що вам потрібно ще раз перевірити, чи всередині URL-адреси запиту ви можете побачити URL-адресу сервера тегів; Це той, який ви додали до севрерного контейнера та всередині змінної чи тегу GA4.
Примітка: файли cookie будуть розширені, лише якщо ви використовуєте кастомний субдомен всередині URL-адреси тегів. Наприклад, URL-адреса вашого веб-сайту – example.com. Тоді кастомний домен для тегування URL-адреси має виглядати як gtm.example.com.
Перейдіть на вкладку програми всередині інструмента розробника, який ви використовували на другому кроці. Натисніть Зберігання-> Файли cookie. З правого боку ви знайдете файли cookie з назвою FPID; перевірте дату в графі «закінчується». Таким чином, cookie має бути продовжено до 2 років. Я пишу цю публікацію в лютому 2021 року, а термін дії мого файлу cookie закінчиться в лютому 2023 року. Якщо ви не використовуєте відстеження на стороні сервера та не використовуєте кастомну URL-адресу тегів, розташовану під вашим основним доменом, Safari скоротить термін служби файлів cookie до 1 або 7 днів. Якщо ви бачите, що файли cookie не були розширені, перейдіть до клієнта GA4 всередині серверного контейнера, натисніть додаткові налаштування та перевірте, як виглядають налаштування файлів cookie сервера на знімку екрана нижче. Або переконайтеся, що ви використовуєте кастомну URL-адресу тегів, яка виглядає як gtm.youdomain.com.
У цьому відео показано, як протестувати Facebook conversion API👇
Перший крок тестування серверного відстеження Facebook такий самий, як і для Google Analytics. Ви повинні переконатися, що події запускаються на правильні тригери. Відкрийте інструмент налагодження GTM, клацайте сторінками свого сайту та виконуйте події, які потрібно перевірити. Зробивши це, перейдіть на вкладку Tag Manager debugger і перевірте результати.
Спочатку переконайтеся, що базовий піксель FB спрацьовує при перегляді сторінки. Якщо ви бачите статус тегу Fail, перевірте вихідні запити. Він повинен показати причину, чому тег не вдалося виконати.
Якщо ви використовуєте наш тег відстеження на стороні сервера FB, у вас є два варіанти надсилання подій у FB:
- Успадкувати від клієнта GA. У цьому випадку ми автоматично порівнюємо події GA зі стандартними подіями FB. Якщо ви використовуєте параметр успадкування, ви побачите лише базовий тег FB у режимі налагодження GTM.
- Override. Вибір параметра заміни вимагає вручну налаштувати події сервера FB всередині серверного контейнера. Таким чином, він буде видимий у режимі налагодження сервера.
Відкрийте менеджер подій у своєму бізнес-менеджері Facebook і натисніть на тестові події. Ви побачите тестовий код події, який слід додати до нашого тегу Facebook у Google Tag Manager. За допомогою цього коду ви зможете тестувати події сервера Facebook у режимі реального часу.
Додавши тестовий ідентифікатор, відкрийте свій сайт і виконайте дії, які запускають події у FB. Потім поверніться до інструменту тестування Facebook і перевірте події, які він вам показує. У стовпці «Отримано від» ви повинні побачити «Сервер». Ви можете натиснути на подію та побачити записані параметри.
Зауважте, що допоміжний плагін Chrome для пікселів Facebook, який ви використовували для перевірки подій браузера FB, не працюватиме для conversion API. Ось чому вам потрібно перевірити все всередині інструмента тестування.
Примітка: файли cookie будуть розширені, лише якщо ви використовуєте кастомний субдомен всередині URL-адреси тегів. Наприклад, URL-адреса вашого сайту – example.com, тоді кастомний домен для тегування URL-адреси має виглядати як gtm.example.com.
Третій крок знову подібний до того, що ми робили, але має кілька відмінностей. Щоб перевірити термін дії файлів cookie Facebook, вам спочатку потрібно його згенерувати. Для цього відкрийте свій сайт і додайте fbclid.
Після того, як ви відкриєте інструменти розробників, перейдіть до сховища та натисніть файли cookie. Перевірка _fbc і _fbp була розширена.
Сподіваюся, у вас все спрацювало, і вам вдалося успішно налаштувати відстеження на стороні сервера для GA4 або Facebook conversion API . Якщо ні, ця стаття допоможе вам усунути неполадки та виправити налаштування. Якщо у вас виникли запитання, можете надіслати нам електронного листа на адресу support@stape.io.
Ми допоможемо вам у будь-якій справі! Натисніть Отримати допомогу, заповніть форму, і ми надішлемо вам розцінку.
