Атрибуція без cookie: що досі працює

Атрибуція без cookie працює, якщо перестати просити браузер пам'ятати клік. Записуйте клік на сервері, передавайте ідентифікатор в URL, зберігайте його у власному записі замовлення й надсилайте конверсію від сервера до сервера. Усе інше або деградоване, або юридично ризиковане в ЄС. Це стосується сторонніх cookie, cookie зі скриптів, що спливають за кілька днів, і фінґерпринтингу.

Стек, який більшість команд збудувала між 2012 і 2019 роками, залежав від стороннього cookie, залишеного на цільовій сторінці, і пікселя, що зіставляв його на сторінці конверсії. Основи терміна дивіться в матеріалі що таке маркетингова атрибуція. Ця стаття - мапа того, що вціліло, що Elido покриває сьогодні і де потрібен ваш власний бекенд.

Коротко

• Safari обмежує cookie та сховище, записані скриптами, 7 днями неактивності, а cookie, створені на цільовій сторінці з декорованим посиланням, - 24 годинами. Chrome досі дозволяє сторонні cookie з вибором користувача. У будь-якому разі вважайте їх ненадійними.
• Працюють два шляхи: ідентифікатор кліку чи посилання, переданий у ваш запис замовлення й надісланий від сервера до сервера, та first-party cookie, встановлені сервером.
• Без cookie не означає без згоди. Стаття 5(3) ePrivacy охоплює фінґерпринтинг і локальне сховище, а GDPR досі вимагає правової підстави для серверної обробки.
• Elido веде серверний журнал кліків і прив'язує виручку Stripe та Shopify до посилань. Він поки не генерує ідентифікатори кліків і не пересилає конверсії рекламним платформам.

Що змінилося в браузерах

Поточну картину дають три джерела, усі з датою звернення 2026-10-24.

На сторінці WebKit про запобігання відстеженню сказано, що Safari видаляє cookie, створені в JavaScript, та інше сховище, доступне для запису скриптами, через 7 днів без взаємодії користувача із сайтом. Там також сказано, що коли в URL цільової сторінки виявлено ідентифікатор кліку, строк дії cookie, створених у JavaScript на цій сторінці, обмежується 24 годинами. ITP 2.3, опублікований 23 вересня 2019 року, поширив подібні обмеження на інші дані, доступні для запису скриптами. Cookie, встановлені в заголовку HTTP-відповіді вашим власним first-party хостом, цими правилами не обмежуються. Виняток - замаскований сторонній хост, наприклад піддомен, замаскований через CNAME чи IP, для якого WebKit обмежує строк 7 днями.

Firefox розділяє сторонні cookie за сайтом верхнього рівня завдяки Total Cookie Protection. Cookie, встановлений трекером на вашій касі й на касі конкурента, стає двома окремими cookie.

Chrome так і не завершив відмову від них. 22 квітня 2025 року Google оголосив, що не запускатиме окремий запит про сторонні cookie, а користувачі й надалі обирають у налаштуваннях. Блог Privacy Sandbox додає, що деякі технології Privacy Sandbox згортаються. Тож практичне питання вже не "коли cookie помруть", а "яка частина моєї аудиторії їх блокує", і чесного відсотка по всьому ЄС я назвати не можу. Перевірте власну аналітику за браузерами.

Ще одне твердження, яке трапляється в презентаціях вендорів: нібито Link Tracking Protection у Safari вирізає ідентифікатори кліків, як-от fbclid чи gclid, у приватному перегляді та в Mail. На сторінці WebKit про запобігання відстеженню, коли я її завантажував, цього не було, тому перелік параметрів я тут не повторюю. Перевірте власні цільові сторінки в цих контекстах, перш ніж покладатися на те, що ідентифікатор кліку виживе.

Два шляхи, що досі працюють

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

Шлях 1: серверні ідентифікатори

Коли користувач клікає рекламу, платформа додає до URL цільової сторінки ідентифікатор кліку, наприклад fbclid для Meta чи gclid для Google. Ідентифікатор живе в URL, тож розділення cookie його не зачіпає. Ваша цільова сторінка читає його й зберігає в кошику чи замовленні. Коли замовлення оплачено, ваш бекенд бере його із замовлення й надсилає конверсію до серверного API платформи, як-от Conversions API від Meta чи GA4 Measurement Protocol.

Дедуплікація важлива, якщо ви залишаєте і браузерний піксель. У документації Meta сказано, що eventID пікселя має збігатися з event_id у Conversions API, з тією самою назвою події, а дублікати, отримані протягом 48 годин, відкидаються. Для покупок використовуйте ID замовлення. Які поля клієнта слід гешувати, читайте на сторінці Meta про параметри інформації про клієнта; ці правила я для цієї статті не перевіряв.

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

Шлях 2: редирект, який ви контролюєте

Редирект на вашому власному домені - це серверна подія. Коли хтось клікає брендоване коротке посилання, хост редиректу може записати клік у цю мить, із часовою міткою, реферером і user agent, а не чекати на спрацювання тегу при завантаженні сторінки. Якщо ви ще й встановлюєте cookie, робіть це в заголовку Set-Cookie на first-party хості. Так уникаєте згаданих вище 7-денного та 24-годинного обмежень для cookie, записаних скриптами.

Піксель цього відтворити не може. Саме тут закінчується і поточний обсяг можливостей Elido.

Що Elido робить сьогодні, звірено з кодом

Я перевірив за сервісами кожне твердження, яке ця стаття раніше містила. Ось результат.

Чесна версія тези "коротке посилання як поверхня атрибуції" вужча, ніж казала ця стаття раніше. Редирект дає запис кліку й звітність по кожному посиланню. Щоб замкнути цикл по виручці, покладіть ID посилання в замовлення: elido_link_id у метаданих Stripe або атрибут нотатки elido_link_id у кошику Shopify. Коли надходить вебхук замовлення, Elido відносить виручку на це посилання. Усе далі, наприклад гешування email і виклик API Meta, сьогодні - код у вашому бекенді. Як побудовано таке розгалуження, дивіться в серверному відстеженні конверсій через короткі посилання, а про кут Safari - у атрибуції кліків після Safari ITP. Сторінка функції відстеження конверсій описує сторону дашборда.

Зшивання ідентичності: що працює, а що ні

Серверні ID покривають типовий випадок: одна людина, один пристрій, одна сесія, жодних вирізаних параметрів. Решта потребує ідентифікатора, який людина дала вам сама.

Детерміноване зіставлення працює. Якщо людина десь входить в акаунт чи вводить email, ви можете надіслати геш email разом із конверсією як сигнал зіставлення. Гешування має відповідати правилам платформи щодо нормалізації, тож перед реалізацією прочитайте сторінку вендора.

Імовірнісний фінґерпринтинг - хибний запасний варіант у ЄС. Він поєднує розмір екрана, шрифти, часовий пояс, вивід canvas та подібні сигнали в ідентифікатор без cookie. Чи потрібна для цього згода - юридичне питання, а стаття 5(3) Директиви ePrivacy стосується доступу до інформації на пристрої користувача, а не лише до cookie. Сторінка EUR-Lex не завантажилася в мене 2026-10-24, тож я переказую загальновідомий обсяг Директиви, а не цитую її. Я також не називаю конкретних рішень регуляторів. Браузери, орієнтовані на приватність, і далі скорочують ентропію, на яку спираються ці методи. Точність падає саме там, де вона потрібна найбільше.

Міжпристрійність - прогалина, яку на сервері не закрити. Клік на телефоні й покупка на ноутбуці зв'язуються лише тоді, коли людина ідентифікує себе на обох.

Згода досі потрібна

"Немає cookie - немає згоди" - поширене хибне прочитання. Стаття 5(3) про пристрій, тому будь-яке зберігання чи доступ там потребує згоди, якщо воно не є суворо необхідним. Cookie для аналітики не є суворо необхідним лише тому, що він first-party.

Серверна обробка змінює те, куди йдуть дані. Блокувальники реклами й розділення її не зачіпають, а те, що залишає ваш бекенд, контролюєте ви. Їй усе одно потрібна правова підстава за GDPR згідно зі статтею 6, зазвичай законний інтерес для аналітики на рівні кампанії після оцінювання, і важче - для профілювання окремих осіб. Посібник GDPR для скорочувачів URL охоплює статті 6, 28 і 30, а згода на cookie для коротких посилань - питання банера.

Щодо обробки IP: Elido усікає IP відвідувача на edge (IPv4 до /24, IPv6 до /48), перш ніж клік буде збережено. Країна, регіон, місто та приблизні координати виводяться спершу й зберігаються разом із кліком, а також зберігається повний user agent, тож розглядайте рядок кліку як персональні дані. Якщо мінімізація важлива для вашого DPA, запросіть актуальні умови зберігання й обробки IP письмово.

Чим доводиться жертвувати

Серверна атрибуція повертає більшість втраченого сигналу, але не весь.

Міжпристрійна ідентичність. Втрачається, якщо людина не авторизується.

View-through атрибуція. Залежить від того, що рекламна платформа зіставляє показ із пізнішою конверсією через власний граф пристроїв. Очікуйте шумніших цифр, ніж у звітах на основі кліків.

Довгі вікна ретроспективи. Кожна платформа задає власні вікна атрибуції, і вони можуть бути коротшими за 28 чи 90 днів, які деякі команди мали з cookie. Перевіряйте поточне вікно для кожної платформи, по якій звітуєте. Найбільше втрачають підписки й B2B-цикли.

Multi-touch для анонімних користувачів. Без графа ідентичності ви за замовчуванням отримуєте останній клік. Геш email для авторизованих користувачів дозволяє відновити послідовності для цієї частини аудиторії за допомогою моделей на основі правил, що підходять вашим даним.

Практичний стек

Для команди, що веде платний трафік в ЄС, ось що я б будував із наявного сьогодні.

1. Брендовані короткі посилання для email, SMS, QR-кодів і органічних публікацій. Одразу отримуєте серверний запис кліку й звітність по кожному посиланню. Рекламу спрямовуйте на сам URL цільової сторінки: Elido відкидає параметри запиту, додані до короткого посилання, тож fbclid чи gclid з реклами не пережив би редирект (передача запланована, але поки недоступна).
2. Фіксуйте ідентифікатор кліку платформи на цільовій сторінці (fbclid, gclid) і записуйте його в кошик чи замовлення. Перевірте, що він виживає в iOS Mail і приватних вкладках, перш ніж йому довіряти.
3. Кладіть elido_link_id у метадані Stripe чи атрибути нотатки Shopify, щоб виручка звітувалася за посиланням без жодного cookie.
4. Надсилайте покупки від сервера до сервера з вашого бекенду в Meta і GA4, з ID замовлення як ключем дедуплікації.
5. Гешуйте email для авторизованих користувачів, щоб покрити міжпристрійність і заповнити прогалини там, де ідентифікатора кліку немає.
6. Імпортуйте офлайн-конверсії пакетами для довгих B2B- чи підписних циклів через офлайн-API платформи.

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

Читайте також у блозі

• Що таке маркетингова атрибуція
• Атрибуція кліків після Safari ITP
• Серверне відстеження конверсій через короткі посилання
• GDPR для скорочувачів URL