Інтелектуальне запобігання відстеження та інші механізми запобігання відстеження значно змінили світ відстеження. Він ввів обмеження на файли cookie, які кидають виклик компаніям, які сильно покладаються на онлайн-маркетинг, особливо на збір даних третіх сторін для націлювання реклами.
У цьому блозі розповідатиметься про обмеження відстеження, які впливають на файли cookie, про те, як вони впливають на маркетинг, а також про те, як використовувати серверний Google Tag Manager, щоб продовжити термін служби файлів cookie.
Сьогодні багато браузерів блокують сторонні файли cookie (3rd party cookies). Двома найпопулярнішими браузерами, які обмежують сторонні файли cookie, є Safari та Firefox. Chrome оголосив, що до кінця 2023 року вони почнуть відмовлятися від сторонніх файлів cookie. Це означає, що до кінця 2023 року близько 80% веб-переглядачів перестануть підтримувати сторонні файли cookie. Це не вплине на власні файли cookie.
Давайте поговоримо про різницю між файлами cookie першої та сторонньої сторони. Щоб спростити, основна відмінність полягає в тому, що основні файли cookie встановлюються з вашого сайту на ваш домен, а сторонні файли cookie встановлюються з вашого сайту на інші домени.
Немає жодних обмежень щодо використання сторонніх файлів cookie. Сторонні файли cookie отримали погану репутацію через міжсайтове відстеження. Рекламодавці використовують цей тип файлів cookie для відстеження користувачів у різних доменах і для профілювання користувачів. За допомогою сторонніх файлів cookie великі платформи можуть стежити за вами в Інтернеті та бачити, які сайти ви відвідуєте. І зрештою, використовують цю інформацію, щоб показувати вам персоналізовану рекламу.
Алгоритми інтелектуального відстеження, що використовуються у Firefox і Safari, обмежують тривалість життя файлів cookie 7 днями (якщо файли cookie встановлені за допомогою JavaScript) або 24 годинами (якщо файли cookie встановлені за допомогою JavaScript, використовується оформлення посилань, а посилання на веб-сайт є «відомим трекером» ).
Більшість маркетологів використовують UTM-теги для відстеження параметрів кампанії. Коли ITP виявляє теги UTM в URL-адресі, це зменшує тривалість життя файлів cookie до 1 дня. Це сильно впливає на атрибуцію, оскільки якщо користувач відвідує ваш веб-сайт, натиснувши оголошення з тегами UTM, і здійснить конверсію через кілька днів, конверсію не буде віднесено до рекламної кампанії.
Оскільки файли cookie видаляються через 1 або 7 днів, користувач, який відвідав ваш сайт 7 днів тому, буде вважатися новим. Це матиме величезний вплив на шлях клієнта по сайту. Ви не зможете побачити повну картину того, які джерела трафіку вплинули на рішення клієнта зробити покупку.
Персоналізація часто використовується, щоб забезпечити клієнтам безперебійну роботу, показуючи релевантні пропозиції, вміст, продукти тощо. Зі зменшенням терміну служби файлів cookie персоналізація може мати негативний вплив. Оскільки користувач буде призначатися до нового пулу аудиторій щоразу, коли закінчується термін дії файлу cookie.
Кожна партнерська пропозиція має свій термін дії файлів cookie. Коли користувач відвідує ваш сайт у Safari за реферальним посиланням сьогодні та приховано через 10 днів, ця конверсія не буде зарахована на рахунок філії. В результаті афілійована особа не отримає комісію.
Коли файли cookie скидаються кожні 7 днів або 1 день, це негативно впливає на розмір аудиторії ремаркетингу та частоту оголошень. Платформи також матимуть менше даних для створення схожих або схожих аудиторій.
Встановлення або розширення файлів cookie – це складне питання, і його слід розглядати окремо для кожної платформи та браузера. Підводячи підсумок, ви можете використовувати серверний контейнер Google Tag Manager із кастомним доменом, щоб установити власні файли cookie та продовжити термін їх служби. Перегляньте цей сайт, щоб побачити, як працюють файли cookie в кожному браузері cookiestatus.com.
Стандартні клієнти Universal Analytics або Google Analytics 4 для серверного Google Tag Manager встановлюють FPID файлів cookie сервера з прапорцем HttpOnly. Це робить файли cookie Google Analytics стійкими до ITP, оскільки ITP в основному впливає на сторонні файли cookie, встановлені JavaScript. Це означає, що файл cookie Google Analytics на стороні сервера триватиме 2 роки, як і раніше.
Google Analytics 4 був випущений рік тому, і не так багато компаній встигли перейти на GA4, і більшість досі використовує Universal Analytics. Якщо ви хочете перемістити наявний ресурс UA з веб-відстеження на сервер, обов’язково ввімкніть «Перейти з ідентифікатора клієнта, керованого JavaScript» у шаблоні клієнта Universal Analytics. Це не дозволить створювати нових користувачів для тих, хто вже відвідував ваш сайт. GA продовжуватиме використовувати ідентифікатор клієнта, керованого JavaScript, доки файл cookie _ga не буде скинуто. Після закінчення терміну дії _ga буде використовуватися FPID.
Наш тег Facebook conversion API для серверного GTM автоматично подовжує термін служби файлів cookie _fbp і _fbc до 2 років. Усі інші теги stape.io для серверного Google Tag Manager розширюють файли cookie. Термін служби файлів cookie залежить від платформи.
Stape створив тег Cookie extender для sGTM, спеціально розроблений для розширення файлів cookie. Може виникнути кілька ситуацій, коли вам потрібно використовувати цей тег для розширення файлів cookie, деякі найпопулярніші сценарії з мого досвіду:
Неодноразово нам потрібно було розширити файли cookie для платформ, чиї рідні теги не можуть цього зробити, як-от партнерські мережі та служби електронної пошти. Або, можливо, вам потрібно розширити веб-файли cookie, оскільки файли cookie сервера, ті з Httponly, не можуть бути доступні за допомогою JavaScript. І ви не можете використовувати ці файли cookie у веб-GTM. Або, можливо, вам потрібно використовувати формат ідентифікатора клієнта, згенерованого веб-GA, на інших платформах. У всіх цих ситуаціях може допомогти Cookie extender.
Іншим поширеним сценарієм є використання веб-відстеження та серверне відстеження, наприклад, для таких платформ, як Facebook, TikTok або Snap. Навіть якщо ви розширюєте файли cookie fb за допомогою серверного тегу, можуть виникнути сценарії, коли веб-куки встановлюються першими. Це означає, що файли cookie сервера та кейс Safari все одно зменшаться.
Тож як використовувати тег Cookie extender?
1. Завантажте тег Cookie extender з GitHub.
2. Імпортуйте тег Cookie extender у свої шаблони тегів sGTM. Перейдіть до розділів шаблонів у sGTM -> натисніть створити новий тег -> Імпортуйте тег розширення Cookie, який ви завантажили з GitHub.
3. Створіть тег Cookie extender в sGTM. У цьому прикладі я розширю файли cookie Facebook (fbc, fbp) і Google Analytics (gid і ga). У налаштуваннях тегів я встановив назви файлів cookie та тривалість їхнього існування.
Я також увімкнув прапорець Створювати резервні файли cookie та відновлювати їх, якщо основні файли cookie не знайдено. Цей параметр створює резервні файли cookie, наприклад, для _ga, він створить _ga_backup і зберігатиме там те саме значення, що й _ga. Якщо ви встановили тег Cookie extender та ввімкнули резервні файли cookie, він відновить файл cookie _ga із резервного файлу cookie _ga_backup. Це означає, що цей користувач все одно матиме ті самі файли cookie, як і під час перших відвідувань, навіть якщо файл cookie _ga вже було стерто.
З файлами cookie Facebook (fbc, fbp) діє інша логіка. Тег FB CAPI на стороні сервера встановлює для файлів cookie 3 місяці. Якщо ви використовуєте відстеження як браузера, так і сервера для FB, можуть бути випадки, коли тег пікселя FB запускається першим і встановлює файл cookie браузера, термін служби якого в Safari (та інших браузерах з ITP) становить максимум 7 днів. У цьому випадку файли cookie не розширюються. Щоб усунути цю проблему, ми запускатимемо піксельні теги FB лише після того, як тег FB на стороні сервера встановить файли cookie.
4. Усередині веб-контейнера GTM я хочу змінити тригер для подій пікселів FB, оскільки мені спочатку потрібно встановити файли cookie на стороні сервера. Для цього я буду використовувати Data Tag/Data Client, оскільки ці два мають можливість відправити dataLayer push до веб-GTM після завершення запитів сервера. Моя ідея полягає в тому, щоб активувати піксель FB тільки після того, як спрацював тег FB CAPI на стороні сервера, що означає, що файли cookie сервера були встановлені.
Для цього я використовую Data Tag/Data Client для надсилання рівня даних до веб-GTM, коли сервер отримає відповідь.
Мій тригер для тегу перегляду сторінки FB виглядає так. Він запускається на кастомні події server_reponse, що означає, що запити сервера були надіслані.
5. Тепер ви можете перевірити тег Cookie extender за допомогою попереднього перегляду веб- та серверних GTM. Після того, як ви переконаєтеся, що вони працюють правильно, я пропоную відкрити Safari (або будь-який веб-переглядач, який обмежує тривалість життя файлів cookie) і протестувати файли cookie. Ось як файли cookie виглядають для моїх налаштувань.
Завдяки обмеженням ITP щодо файлів cookie та інших зборів даних, Safari очолив хрестовий похід щодо конфіденційності. Однак інші браузери також почали впроваджувати механізми проти відстеження, включаючи Chrome, який займає понад 50% ринку браузерів.
Файли cookie мають значний вплив на ефективність кампанії, атрибуцію, відстеження конверсій тощо. Ось чому ви можете застосувати відстеження на стороні сервера, щоб продовжити термін служби файлів cookie. Якщо вам потрібна допомога, просто надішліть електронного листа на адресу agency@stape.io.
Все, що потрібно, це кілька простих запитань. Натисніть Отримати допомогу, заповніть форму, і ми надішлемо вам пропозицію.
