Якщо ви працюєте в маркетингу або покладаєтеся на такі інструменти відстеження, як GA4, для вимірювання ефективності веб-сайту, я впевнений, що ви знаєте, наскільки фрагментованим стало відстеження за останні роки. Особливо для відстеження Google Ads і платних соціальних мереж . У світі запрацювало кілька різних законів про конфіденційність. GDPR (Загальний регламент захисту даних) і CCPA (Каліфорнійський закон про конфіденційність прав споживачів) — це два, про які ви, напевно, чули найбільше, але насправді 71% усіх країн світу мають певне законодавство про захист даних і конфіденційність і ще 9% мають щось у чернетці на найближче майбутнє.
Це ускладнило відстеження точних даних вимірювання для маркетингових кампаній і ефективності веб-сайту. У вас хаотичне поєднання законів про конфіденційність, які відрізняються в різних країнах світу, різні веб-переглядачі розгортають власні засоби захисту від відстеження, що відрізняються за суворістю, встановлені користувачами блокувальники реклами та мережі VPN, деякі з яких мають вбудований захист від відстеження та блокувальник реклами.
З усіма цими змінними відстеження стало складним. Якщо ми розберемо це до самих основ, уявімо, що браузер із вбудованим захистом відстеження запобігає завантаженню Google Tag. Немає тегу Google = немає відстеження. Ці дані втрачено. І це незалежно від згоди користувача. Вони можуть охоче прийняти всі файли cookie на вашому веб-сайті, не знаючи, що браузер все одно відхиляє їх усі. Тут вступає в дію «режим першої сторони» Google.
Що таке режим підміни даних на first-party data?
Простіше кажучи, First-party data режим – це метод завантаження ваших тегів Google із домену вашого веб-сайту, тому він є основним і не залежить від підключення до зовнішнього ресурсу (домен googletagmanager.com).
У режимі першої сторони ваші запити на вимірювання надсилаються з вашого домену, що зменшує ймовірність їх блокування браузерами або блокувальниками реклами. Коли запити на вимірювання було надіслано з вашого домену та дані повернулися, вони потім пересилаються на відповідну платформу Google, зокрема GA4, Google Tag Manager або Google Ads, наприклад.
У Google є чудова діаграма, яка демонструє потік даних у режимі першої сторони:
Налаштування режиму first-party на вашому веб-сайті
Щоб налаштувати first-party по замовчуванню для для тегів Google, вам знадобляться дві речі:
- Тег Google або контейнер Google Tag Manager.
- CDN (мережа доставки вмісту) або балансувальник навантаження, який може пересилати запити на зовнішні кінцеві точки.
- Спеціальний шлях обслуговування тегів для вашого веб-сайту, який не повинен відповідати жодним поточним URL-адресам або URL-адресам, які ви можете використовувати в майбутньому. Я раджу випадковий рядок цифр і літер просто для безпеки.
Google надає три приклади налаштувань у своїх інструкціях, і вони охоплюють Google Cloud, Cloudflare та інше для індивідуальних налаштувань.
У цьому прикладі ми працюватимемо з Cloudflare, оскільки це CDN, що використовується найчастіше.
- У Cloudflare перейдіть до налаштувань DNS і додайте новий запис CNAME. Для цього прикладу ми використаємо adata. Отже, ім’я вашого запису CNAME буде adata .
- Для цілі вам потрібно використовувати свій тег Google (замініть своїм тегом), наприклад GTM-XXXXXX. Тому ми додамо GTM-XXXXXX.adata.goog
- Збережіть свій запис CNAME.
- Перейдіть на вкладку правил, виберіть правила походження та створіть нове правило.
- Введіть назву правила, наприклад, вимірювання маршруту.
- Зіставте вхідні запити за допомогою спеціального виразу фільтра та натисніть «Редагувати вираз».
- Ви можете вставити цей вираз у конструктор: (http.host eq “example.com” і starts_with(http.request.uri.path, “/adata”)). Не забудьте замінити example.com на свій домен.
- Тепер оновіть заголовок хосту, щоб він переписував ціль CNAME, яку ми додали до Cloudflare раніше. Отже, для цього прикладу це буде GTM-XXXXXX.adata.goog.
- Далі оновіть свій запис DNS, щоб він перевизначав субдомен, доданий раніше в Cloudflare, тому для цього прикладу це буде adata.example.com.
- Збережіть своє правило перетворення.
- Якщо ви використовуєте інші правила перетворення, Google рекомендує збільшити позицію щойно створеного, щоб воно працювало після будь-яких правил підстановки.
- Якщо ви зараз перейдете на сторінку https://example.com/adata/healthy , відповідь має звучати як «ок». Якщо це так, ваші налаштування наразі правильні. Якщо ні, поверніться до кроків назад і перевірте налаштування.
Якщо ви хочете включити інформацію про геолокацію, вам потрібно трохи змінити налаштування.
- Поверніться на вкладку правил і відкрийте правила перетворення.
- Створіть нове правило запиту на зміну.
- Застосуйте правило до всіх вхідних запитів.
- Змініть заголовок запиту, встановивши для оператора динамічний, назву заголовка — X-CfIpCountryRegion і значення ip.src.subdivision_1_iso_code .
- Розгорніть правило трансформації, а потім вам потрібно буде зачекати кілька хвилин, поки воно пошириться.
- Щоб перевірити правило, перейдіть до https://example.com/adata/?validate_geo=healthy (замінивши домен на свій власний). Відповідь знову має бути «ОК».
Якщо ви хочете видалити IP-адреси із запитів, ви можете зробити це, дотримуючись інструкцій, наведених у документації Cloudflare тут .
Все ще у здоровому глузді та бажаєте продовжувати? Настав час останнього кроку. Оновлення URL-адрес запиту тегів на вашому веб-сайті.
Давайте розглянемо стандартний gtag як перший приклад.
Ось як виглядатиме ваш поточний тег:
<!-- Google tag (gtag.js) --> <script async src=”https://www.googletagmanager.com/gtag/js?id=GTM-XXXXXX”></script>
Ваше нове налаштування має виглядати так (з використанням прикладів вище):
<!-- Google tag (gtag.js) --> <script async src=”/adata/”></script>
По-друге, давайте подивимося на стандартний код GTM:
Ось як має виглядати ваш новий тег після заміни за допомогою наведених вище прикладів:
<!-- Google Tag Manager -->
<script>
(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push(
{‘gtm.start’:new Date().getTime(),event:’gtm.js’});
var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!=’dataLayer’?’&l=’+l:”;
j.async=true;j.src=‘/adata/?id=’+i+dl;
f.parentNode.insertBefore(j,f);
})(window,document,’script’,’dataLayer’,”);
</script>
<!-- End Google Tag Manager -->Тепер перевірте свої налаштування!
Можливо, найважливішою частиною цієї зміни є тестування ваших налаштувань. Не вірте, що все працює так, як має бути, тому що якщо щось піде не так, ви зрештою порушите відстеження.
Хороша новина полягає в тому, що ви можете перевірити налаштування так само, як зараз, за допомогою інструмента Google Tag Assistant. У розділі «Вивід» у підсумку ви побачите, що в цьому прикладі запити надсилаються до /adata.
First-party не замінює згоду
First-party міцно займає золоту середину стандартних налаштувань відстеження до яких ви звикли, і більш просунутих налаштувань відстеження на стороні сервера (GTM server side), які надсилають вимірювання безпосередньо з вашого сервера до інструментів Google.
Як серверний формат налаштувань, так і формат підміни можуть допомогти проблемою втрати даних і відновити частину втрачених даних відстеження, які виникли через обмеження браузера та блокувальники реклами тощо. Однак, і я не можу це не підкреслити, ці налаштування не замінюють режим згоди. Ви не повинні стежити за користувачами без явної згоди, оскільки якщо вас спіймають, штрафи відповідно до GDPR тощо будуть дуже значними. Ризик значно переважує винагороду.
Про налаштування режиму згоди безкоштовно ви можете прочитати у мене на сайті
Потрібна допомога з впровадженням підміни ресурсу відстеження який дає статус вашим даним first-party?
Якщо з будь-якої причини ви не бажаєте впроваджувати відстеження в режимі першої сторони, я, звичайно, готови допомогти. Ви можете зв’язатися зі мною в коментарях вже сьогодні!