Теги «на стороні сервера»: я йду туди чи ні?

Із зростанням проблем, пов’язаних із даними, конфіденційністю та «первою стороною» в цифровому маркетингу, тема тегування «на стороні сервера» часто постає на стіл. Питання, що лежить в основі пілотування, таке: «Чи мені туди йти чи ні?» або «Мені йти зараз чи пізніше?» У цій статті ми спробуємо застосувати синтетичний підхід, щоб допомогти в прийнятті рішень.

Соммер: 

Корисні визначення: 

  • Власний файл cookie: файл cookie, пов’язаний з тим самим доменним іменем, що й веб-сайт, який відвідуєте. 
  • Сторонні файли cookie (або сторонні файли cookie): файл cookie, пов’язаний з доменом, відмінним від відвідуваного веб-сайту (часто це домен рекламної платформи).
  • ITP (Інтелектуальне запобігання відстеженню) : функція конфіденційності, представлена ​​Apple у Safari у 2017 році.
  • TMS (Tag Management System): система управління тегами

3 основні питання

По-перше, давайте розглянемо три основні проблеми, які часто піднімаються в контексті стратегії «серверної сторони». Для кожної з цих проблем ми розглянемо їхній вплив і те, що може принести серверна технологія.

Проблема 1: Довіра до даних (якість даних)

Важливі рішення приймаються на основі результатів звітів Web Analytics. Рекламні кампанії також коригуються та оптимізуються на основі зібраних даних. La достовірність даних так і є головне питання.

В останні роки різноманітні технічні або нормативні події вплинули на збір даних:

  1. RGPD (нормативний) : ми втрачаємо частину даних.
  2. Блокувальники реклами (технічний) : ми втрачаємо іншу частину даних.
  3. Safari / iOS / Firefox(технічний) : ми все ще втрачаємо дані (з ITP, системою запобігання відстеженню, яка значно обмежує використання файлів cookie)
  4. Chrome сторонні файли cookie (технічний): на даний момент у режимі очікування, але ми очікуємо подальших подій, які, безумовно, призведуть до подальшої втрати даних 

Давайте розглянемо ці різні моменти трохи докладніше: 

1 – GDPR

З точки зору регулювання, деякі відвідувачі не дають своєї згоди. Це нормально, це зроблено. І ми могли б так само зрозуміти з самого початку, ідея сторони сервера полягає не в тому, щоб перевизначати згоди !

</ S> </ s>  У Франції, за оцінками, близько 35% користувачів Інтернету не дають своєї згоди.
(джерело: Credoc Digital Barometer – 2022)

⚠️ Вплив: частина даних не збирається. Об’ємні ключові показники ефективності у звітах веб-аналітики втрачають своє значення (пропорції та зміни залишаються доступними для використання).

2 – Блокувальники реклами

Значна частина користувачів оснащує свої браузери доповнення, які називаються блокувальниками реклами (блокувальники реклами). Роль цих інструментів полягає головним чином у перешкоджанні функціонуванню маркетингових/рекламних процесів на відвідуваних сайтах. Іноді ці інструменти можуть навіть виходити за межі цієї мети, доходячи до того, що взагалі перешкоджають завантаженню Менеджера тегів.

Як ми вже сказали, в основному це, звичайно, питання поваги до вибору користувача з точки зору GDPR. Для цього ваш веб-сайт, ймовірно, уже обладнано менеджером згоди (Axeptio, Cookiebot, Didomi тощо). 

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

</ S> </ s>  У Франції приблизно від 30 до 40% користувачів Інтернету (десктоп) використовують блокувальники реклами

⚠️ Вплив: додаткова частина даних не збирається. Вплив попереднього пункту (GDPR) посилюється.

3 – ITP (Safari / Firefox…)

Система ITP (Intelligent Tracking Prevention), запущена в 2017 році, призначена для обмеження використання файлів cookie. Він присутній, зокрема, у браузерах Safari та Firefox.

Зокрема, він блокує сторонні файли cookie та видаляє власні файли cookie через 1 днів.

</ S> </ s>  У Франції близько 32% користувачів Інтернету використовують Safari (джерело Statista)

⚠️ Вплив: тут це в основному стосується можливостей націлювання або моделей атрибуції сторонніх рекламних систем (заблоковано сторонні файли cookie). З боку веб-аналітики вони більше не можуть ефективно розпізнавати регулярного користувача (власні файли cookie видаляються протягом 1–1 днів).

4 – Блокування сторонніх файлів cookie в Chrome

Така сама ідея тут: після першої згадки a перенесення амортизації сторонніх файлів cookie на 2025 рік, Google нещодавно оголосив про це сторонні файли cookie в Chrome остаточно не будуть застарілими (22). Незважаючи на все, це блокування сторонніх файлів cookie залишається проблемою, яку потрібно вирішити. Навіть якщо майбутні розробки Chrome не складатимуться з прямого блокування, ми можемо очікувати, що вони залишать більше контролю користувачам із, як наслідок, зміною поточного функціонування.

Зокрема, галас навколо цього моменту викликає останнім часом зростання інтересу до серверних технологій.

</ S> </ s>  У Франції близько 57% користувачів Інтернету використовують Chrome (джерело Statista)

⚠️ Вплив: це посилить вплив попереднього пункту (ITP) на файли cookie третіх сторін. Особливо це стосується таргетингу рекламних кампаній і моделей атрибуції (падіння прибутку від інвестицій у рекламу або ROAS).

коротко, через зменшення кількості зібраних даних статистична маса природним чином послаблюється. Довіра до даних похитується, а маркетингові стратегії втрачають частину своєї точності та ефективності. 

Внески на стороні сервера щодо довіри до даних: 

Що стосується цієї першої проблеми, впровадження на стороні сервера зменшить вплив технічних обмежень:

  • Зменшити вплив блокувальників реклами (в залежності від використовуваного технічного рішення).
  • Зменште вплив обмежень на Safari / Firefox (ITP).
  • Зменште вплив стороннього блокування на Chrome.

⚠️ Зверніть увагу, що існують різні способи впровадження на стороні сервера, що забезпечує більшу чи меншу ефективність. Наші рекомендації в цьому напрямку ми обговоримо в кінці статті.

👍 З боку сервера збір даних буде ширшим і якіснішим, що сприятиме оптимізації стратегій маркетингових кампаній і покращенню якості аналізу аудиторії.

 

Проблема 2: контролювати зібрані дані (управління даними)

На стороні клієнта сценарії тегів можуть збирати певні дані, не будучи повністю прозорими та контрольованими. Насправді досить важко перевірити, що насправді зафіксовано та відправлено тегом.

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

Внески на стороні сервера щодо управління даними: 

У цьому другому питанні сторона сервера надає: 

  • Повна видимість даних, які передаються тегами
  • Повний контроль цих даних, що передаються за допомогою тегів (анонімізація / модифікація персональних даних)
  • «Постачальники» (Meta, Google тощо) мають доступ лише до даних, налаштованих у тегах у Менеджері тегів.

👍 На стороні сервера можна відновити контроль над даними, залученими до процесів веб-аналітики та цифрового маркетингу.

 

Питання 3: Збереження продуктивності веб-сайту

У системі тегування на стороні клієнта теги завантажуються та виконуються браузером користувача.

Деякі теги, взяті окремо, вже досить важкі (наприклад, Facebook Pixel). Але разом узяті ми інколи маємо значні та впливові сукупні збори для відвідувачів.

© Посміхніться

Внесок сервера в продуктивність веб-сайту: 

Що стосується продуктивності, на стороні сервера надається: 

  • Оптимізація/обмеження кількості елементів, що обробляються на стороні клієнта.
  • Сприятливий для користувацького досвіду (UX).
  • Сприятливий для SEO.

👍 Серверна сторона сприяє продуктивності веб-сайту та SEO.

 

«Серверна сторона», як?

Але Джеймі, що таке тег на стороні сервера?

Зазвичай тег відстеження виконується в браузері клієнта. Обмін даними відбувається безпосередньо між браузером відвідувача та маркетинговою або аналітичною платформою. Тоді ми говоримо про тег «на стороні клієнта».

На стороні клієнта: 

  • Кожен тег завантажується/виконується браузером.
  • Кожен тег збирає свої дані (часто ті самі, що й інші теги).

У випадку тегу на стороні сервера інформація передається зі сторони клієнта в інший контейнер, розміщений на сервері в хмарі, за допомогою єдиного тега, який діє як «транспортер». Потім теги виконуються з цими даними з сервера на маркетингову або аналітичну платформу.

На стороні сервера: 

  • Браузер завантажує лише один тег колекції.
  • Єдиний тег колекції бере дані та робить їх доступними для тегів на стороні сервера.

© Посміхніться

Гаразд, але який сенс?

Завдяки тому, що теги виконуються з сервера, а не з браузера/клієнта, ми отримуємо такі характеристики: 

  • Тег на стороні сервера не розміщує файли cookie третіх сторін у браузерах відвідувачів. Однак файли cookie, розміщені сервером, стають першими. 
  • Тег на стороні сервера може надсилати лише дані, отримані єдиною точкою входу від клієнта.
  • Серверний тег не працює у браузерах відвідувачів. 

Тоді це надає такі основні переваги: 

  • Покращена якість даних
    Обмежуючи вплив блокувальників реклами або обмеження, пов’язані зі сторонніми файлами cookie, ми збираємо більше даних.
  • Контроль зібраних даних
    Керуючи каналом даних до тегів на стороні сервера, ви відновлюєте контроль над тим, що надсилається, а отже, збирається.
  • Оптимізація часу зарядки
    Запускаючи теги на стороні сервера, ми зменшуємо роботу браузера. Це йде в напрямку покращення взаємодії з користувачем та SEO-оптимізації.
  • Більш стійкий спосіб
    Розвиток правил і технологій має тенденцію до підвищення інтересу серверної сторони. Приступивши до роботи досить рано, ми можемо сподіватися на стабільність, на відміну від усього, що обертається навколо файлів cookie та клієнтської сторони

 

Деякі упереджені ідеї

  • На стороні сервера можна обійти блокувальники реклами

На мою думку, це трохи правда і трохи неправда :cЦе не є основною метою серверної частини. Однак це правда

Це не є основною метою серверної частини. Однак насправді, логічно надсилаючи теги на стороні сервера, вони більше не будуть перешкоджати.

Але щоб тегування на стороні сервера працювало, ваш сайт має продовжувати використовувати контейнер менеджера тегів на стороні клієнта з тегами, які посилаються на сторону сервера. Ці теги мосту можуть залишатися заблокованими блокувальником реклами. У цьому випадку ми не можемо сказати, що сторона сервера обходить блокувальник реклами. Те саме, якщо блокувальник реклами повністю блокує Менеджер тегів.

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

Трохи пізніше в цій статті ми згадаємо, що передові методи впровадження дозволяють обмежити вплив блокувальників реклами.

  • На стороні сервера можна нічого не завантажувати на стороні клієнта

Тут також слід уточнити і сз тієї ж причини: Фактично, більшість часу, коли ми говоримо про тегування на стороні сервера, ми насправді говоримо про «від клієнта до сервера до сервера». Зауважте, що існує тип розширеної реалізації, що дозволяє сервер між серверами (з протоколом вимірювання, зарезервованим для експертів).

Щоб «класичне» тегування на стороні сервера працювало, ваш сайт має продовжувати використовувати контейнер диспетчера тегів на стороні клієнта з тегами, які створюють «міст» на стороні сервера. Таким чином, у всіх випадках все ще є процеси на стороні браузера/клієнта.

Але насправді певні теги будуть передані на сторону сервера. 

Таким чином, на стороні сервера (класичний) можна зменшити навантаження на стороні клієнта, але не повністю їх усунути.

  • На стороні сервера це добре, але це дорого

Отже, щодо вартості все відносно (знову!?): якщо ми просто подивимося на прямі витрати на рішення та експертний час, необхідний для реалізації, це може охолонути (інакше ми нічого не робимо і ми не витрачайте нічого зайвого).

Але, очевидно, я збираюся запропонувати тут трохи розширити рефлексію: я провів швидкий розрахунок на кутку скатертини (добре… я використав електронну таблицю), яким я хотів би поділитися з вами: 

Почнемо з гіпотези електронного продавця, який проводить кампанії SEA за допомогою ретаргетингу. У нас є кілька доступних KPI:

  • Він витрачає 5 євро на місяць на SEA.
  • Його середня CPC становить 1,5 євро за клік.
  • Його середній кошик становить 140 євро з валовою прибутковістю 40%.
  • Він спостерігає середній коефіцієнт конверсії з SEA 3%.

Все йде добре в найкращому з усіх можливих світів, і все йде на плаву, приблизно 100 конверсій на місяць і загальна валова прибутковість 7 євро на місяць. Прямий вплив SEA є позитивним і становить + 000 євро на місяць (валовий прибуток – витрати CPC). А потім одного «прекрасного дня» ми зменшили його можливості націлювання через оновлення Chrome, яке блокувало сторонні файли cookie… З цього моменту, оскільки його кампанії були трохи менш ефективними, його коефіцієнт конверсії впав до 2%. Тоді він втрачає 2 євро маржі на місяць, лише за -1% коефіцієнт конверсії… 

Я дозволю вам спланувати наперед і уявити інші сценарії. Але підсумовуючи, розглядаючи витрати на стороні сервера в перспективі, це загалом досить обнадійливо. Те, що може бути дорогим, - це нічого не робити.

Як ми це робимо?

Отже, питання досить широке. Оскільки я вже витратив багато вашого дорогоцінного часу (а експерти, набагато обізнаніші з цього питання, уже пропонують чудові ресурси), я спробую коротко та спрощено викласти свій погляд на речі:

  • Спосіб 1: «стара школа»

Клієнт відкриває для нас екземпляр сервера в хмарі (часто на Google Cloud Platform, оскільки його пропонує безпосередньо Менеджер тегів Google), ми встановлюємо все для передачі даних із сторони клієнта на сторону сервера… Ми робимо тести, ми бачимо, що теги на стороні сервера залишаються... все добре. Ми працюємо на стороні сервера!

Але... не усвідомлюючи цього відразу, у нас є теги «мост» на стороні клієнта, заблоковані блокувальниками реклами... у нас є менеджери контейнерних тегів на стороні клієнта, заблоковані блокувальниками реклами... у нас може виникнути проблема з примірником Google Cloud для проблема з виставленням рахунків, яку клієнт не впорався… у нас можуть виникнути проблеми з погано зібраними даними… тощо.

Ми швидко опиняємося перед великим ризиком, пов’язаним із відсутністю моніторингу та ефектом «чорної скриньки». Коротше кажучи, ми досягаємо результатів, але привіт, це сповнено невеликих клопотів, часто досить підступних і впливових на продуктивність ваших операцій на стороні сервера.

  • Спосіб 2. Покладіться на експертне рішення/партнера

І ось одного чудового дня ми виявляємо на форумі даних/маркетингу або в статті в блозі, що французька компанія пропонує платформу та послуги, які відповідають на ці проблеми.

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

Коротше кажучи, все це значно перевершує метод «старої школи».

Цим технологічним партнером є Addingwell. І ні, у мене немає жодних дій з ними (шкода). Розрив дійсно є (що, до речі, не є нелогічним). Ми швидко бачимо, що вони дуже добре знають свій предмет і що все, що вони створюють, безпосередньо відповідає конкретним питанням. Ми значно виграємо в часі монтажу, можливостях і надійності.

Висновок

Йти туди чи ні?

  • Вперед! Враховуючи наявні та майбутні проблеми з даними та продуктивністю, вам потрібно позиціонувати себе на цю технологію (за винятком випадків, коли ви взагалі не займаєтеся збором трафіку/рекламою).

Мені йти зараз чи пізніше?

  • Ви бачите це, але не чекайте надто довго: до того часу, коли наступні зміни в Chrome, пов’язані зі сторонніми файлами cookie, з’являться (2025?), існуватиме ризик затору запитів на впровадження на стороні сервера.

І як мені це зробити?

  • Ви дзвоните в UX-Republic (випадково).
    • Ми вивчимо потреби та, можливо, запропонуємо нашому партнеру Addingwell приєднатися до нас, щоб створити для вас відповідний проект.

    У будь-якому випадку не рекомендуємо йти туди без супроводу. Складність налаштування тегів на стороні сервера є кроком вище, ніж реалізація на стороні клієнта (яка вже може бути досить складною).

 

 


Лоран Невіль, старший консультант з веб-аналітики Smile