Пояснення атрибуції без файлів cookie: що все ще працює у 2026 році

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

Цей допис не є плачем за cookie. Це карта того, що насправді працює у 2026 році - які шляхи атрибуції вижили, які просувалися як рішення, не будучи такими насправді, і як виглядає робочий стек на практиці для команд, що запускають платне залучення трафіку в ЄС.

TL;DR#

• Apple's ITP 2.3, Firefox Enhanced Tracking Protection, та поточний Chrome third-party cookie phase-out разом означають, що 60–70% веб-трафіку в ЄС тепер блокує або суворо обмежує сторонні файли cookie за замовчуванням.
• Два шляхи атрибуції все ще функціонують: серверні ідентифікатори, що передаються через ідентифікатор кліку, та встановлення першосторонніх файлів cookie через ланцюжок редиректів, який контролює ваш домен.
• Відсутність файлів cookie не означає відсутність згоди. ePrivacy Directive 2002/58/EC та GDPR все ще вимагають згоди для несуттєвої аналітики, незалежно від механізму зберігання.
• Імовірнісне зшивання відбитків (fingerprint stitching) не є відповідною альтернативою в ЄС; детерміноване зіставлення хешів електронної пошти у поєднанні з серверним ідентифікатором кліку - це єдиний підхід, який витримує перевірку як на точність, так і на відповідність регуляторним нормам.

Що змінилося: коротка хронологія#

Safari почав обмежувати сторонні файли cookie у 2017 році з ITP 1.0. Обмеження швидко посилювалися. ITP 2.3, ви--- title: "Пояснення атрибуції без файлів cookie: що все ще працює у 2026 році" description: "Два шляхи атрибуції пережили відмову від сторонніх файлів cookie - серверні ідентифікатори та перенаправлення від першої особи. Прагматичний стек для маркетологів, яким потрібні реальні цифри" publishedAt: "2026-05-12" author: "Sasha Ehrlich" authorSlug: "sasha" authorRole: "Compliance · EU residency" cluster: "compliance" cornerstone: false tags:

• "cookieless attribution"
• "cookieless tracking"
• "server side attribution"
• "itp 2.3"
• "third party cookie phase out"
• "marketing attribution" coverImage: "/blog/covers/cookieless-attribution-explained.svg" coverAlt: "Diagram showing a strikethrough browser cookie jar on the left and a server-side click-ID flowing to Meta CAPI and GA4 Measurement Protocol on the right"

Маркетинговий стек атрибуції, який більшість команд створювали між 2012 та 2019 роками, залежав від двох речей: стороннього файлу cookie, що розміщувався рекламною платформою на цільовій сторінці, та пікселя в браузері, який спрацьовував на сторінці конверсії та зіставлявся з цим файлом cookie. Обидві частини цієї пари зараз деградували. Жодна з них не відновиться.

Цей допис - не плач за файлами cookie. Це карта того, що насправді працює у 2026 році - які шляхи атрибуції вижили, які були розрекламовані як рішення, не будучи такими насправді, і як виглядає робочий стек на практиці для команд, що запускають платне залучення трафіку з ЄС.

Стисло (TL;DR)#

• ITP 2.3 від Apple, Firefox Enhanced Tracking Protection та тривала поетапна відмова від сторонніх файлів cookie в Chrome разом означають, що 60–70% веб-трафіку в ЄС тепер блокують або суворо обмежують сторонні файли cookie за замовчуванням.
• Два шляхи атрибуції все ще функціонують: серверні ідентифікатори, що передаються через ідентифікатор кліку, та встановлення власних файлів cookie (first-party cookie) через ланцюжок перенаправлень, який контролює ваш домен.
• Відсутність файлів cookie не означає відсутність згоди. Директива ePrivacy 2002/58/EC та GDPR все ще вимагають згоди для необов’язкової аналітики, незалежно від механізму зберігання.
• Імовірнісне зшивання відбитків пальців (probabilistic fingerprint stitching) не є відповідним нормам варіантом в ЄС; детерміноване зіставлення хешів електронної пошти у поєднанні з серверним ідентифікатором кліку - це єдиний підхід, який витримує перевірку як на точність, так і на відповідність регуляторним вимогам.

Що змінилося: коротка хронологія#

Safari почав обмежувати сторонні файли cookie у 2017 році з ITP 1.0. Обмеження швидко посилювалися. ITP 2.3, випущений у вересні 2019 року, обмежив час життя встановлених скриптами власних файлів cookie до семи днів, а до двадцяти чотирьох годин, якщо ланцюжок переходів містив відомий міжсайтовий трекер. Тільки ця зміна порушила стандартну передачу ідентифікатора кліку у файл cookie, на яку покладалася більшість постачальників послуг атрибуції.

Firefox Enhanced Tracking Protection впровадив Total Cookie Protection для всіх користувачів у 2022 році, розділивши кожен сторонній файл cookie за доменом верхнього рівня. Файл cookie, встановлений pixel.example.com на вашій сторінці оформлення замовлення та на сторінці оформлення замовлення вашого конкурента, тепер є двома абсолютно окремими файлами cookie - міжсайтова кореляція зникла за конструкцією.

Графік Chrome змінювався кілька разів відтоді, як Google оголосив про це у 2019 році. Поточна позиція, задокументована на сайті Privacy Sandbox (доступ 12.05.2026), полягає в тому, що відмова триває для підмножини користувачів, а повне розгортання все ще в процесі. Незалежно від остаточної дати Chrome, ситуація в ЄС вже вирішена: Safari та Firefox разом складають більшість мобільного та орієнтованого на приватність десктопного трафіку на ринках ЄС. Стратегії атрибуції, які вимагають сторонніх файлів cookie, вже не працюють для великої частки вашої європейської аудиторії.

Комбінований ефект, виміряний на типових акаунтах перфоманс-маркетингу в ЄС: атрибуція за пікселем з боку браузера недораховує конверсії на 25–45% залежно від складу трафіку, причому вертикалі з великою часткою iOS (мода, краса, застосунки, підписки) знаходяться на верхній межі цього діапазону.

Два шляхи атрибуції, що вижили#

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

Основна механіка проста. Коли користувач натискає на вашу рекламу, рекламна платформа додає ідентифікатор кліку до цільової URL-адреси - fbclid для Meta, gclid для Google і так далі. Цей ідентифікатор існує в URL-адресі, а не у файлі cookie, тому ITP та розділення файлів cookie його не чіпають.

Ваша цільова сторінка зчитує ідентифікатор кліку з URL-адреси та записує його у власний файл cookie на вашому власному домені або передає його у кошик і, врешті-решт, у запис про замовлення. Коли користувач здійснює конверсію, ваш бекенд зчитує ідентифікатор кліку із замовлення та надсилає конверсію за схемою «сервер-сервер» до API конверсій рекламної платформи - Meta CAPI, GA4 Measurement Protocol, серверна кінцева точка Mixpanel.

Цей шлях працює, тому що він ніколи не торкається сторонніх файлів cookie. Ідентифікатор кліку знаходиться в рядку запиту URL у момент приземлення. Ваш власний файл cookie на вашому власному домені не підпадає під обмеження сторонніх файлів cookie так само як і ITP (хоча на нього поширюється 7-денне обмеження на файли cookie, встановлені скриптом, якщо ланцюжок рефералів є підозрілим - детальніше про це нижче). Подія конверсії передається від сервера до сервера, повністю поза межами браузера.

Слабкі місця реальні. Якщо користувач очистить файли cookie між приземленням та конверсією, ідентифікатор кліку зникне. Якщо конверсія відбувається на іншому пристрої, зв'язок між пристроями відсутній, якщо у вас немає авторизованого користувача з відомою адресою електронної пошти. Крім того, в iOS 17 було впроваджено Link Tracking Protection у режимі приватного перегляду та в пошті (Mail), яка видаляє відомі параметри ідентифікаторів кліків з URL-адрес - fbclid, gclid, msclkid знаходяться у списку на видалення. Користувач, який перейшов через застосунок Mail з увімкненим захистом від відстеження посилань, взагалі не принесе ідентифікатор кліку на ваш сайт.

Шлях 2: ланцюжок перенаправлень від першої особи#

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

Коли користувач натискає на посилання на вашому домені - будь то коротке посилання, перенаправлення цільової кампанії або брендоване глибоке посилання - обробник перенаправлення на вашому краї (edge) спрацьовує до того, як застосовуються обмеження приватності браузера. Він може:

1. Встановити власний файл cookie з ідентифікатором кліку, згенерованим сервером на вашому домені.
2. Додати ідентифікатор кліку як параметр URL до цільової URL-адреси.
3. Записати подію кліку на стороні сервера з повним технічним контекстом (IP, user-agent, реферер, мітка часу) у момент кліку, а не у момент завантаження сторінки.

Оскільки це ваш домен і ваш серверний файл cookie, він знаходиться поза межами обмежень сторонніх файлів cookie, на які спрямована ITP. Файл cookie встановлюється вашим сервером через заголовок відповіді Set-Cookie у відповіді на перенаправлення - на файли cookie, встановлені сервером, не поширюється 7-денне обмеження ITP, яке застосовується до записів document.cookie з JavaScript.

Це поверхня атрибуції, яку забезпечує скорочувач URL-адрес і яку не може забезпечити піксель браузера. Перенаправлення виконується на домені скорочувача. Якщо цей домен є вашим власним брендованим доменом, ваш ідентифікатор кліку є власним (first-party), встановленим сервером і архітектурно розміщеним до того, як спрацює будь-яке обмеження приватності з боку браузера.

Як коротке посилання стає поверхнею атрибуції#

Потік перенаправлення працює так. Цільова URL-адреса вашої реклами - це брендоване коротке посилання, наприклад, go.acme.example/summer-sale. Користувач натискає. Запит на перенаправлення потрапляє до обробника Elido, який:

• Знаходить цільову URL-адресу.
• Генерує ідентифікатор elido_click і реєструє подію кліку на стороні сервера.
• Встановлює власний файл cookie Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 у відповіді на перенаправлення.
• Додає ?elido_click=<id> до цільової URL-адреси перед пересиланням.

Цільова сторінка отримує ідентифікатор кліку в рядку запиту. Ваш диспетчер тегів або код теми зчитує його і зберігає у кошику або записі про замовлення. Коли відбувається конверсія, ви надсилаєте POST /v1/conversions з ідентифікатором кліку та деталями замовлення - Elido бере на себе хешування ідентифікаторів клієнтів за допомогою SHA-256 та розсилку на стороні сервера до Meta CAPI, GA4 Measurement Protocol та Mixpanel.

Ідентифікатор кліку ніколи не зберігався у сторонньому файлі cookie. Він був встановлений сервером, був власним (first-party) та зареєстрованим до того, як рівень приватності браузера отримав можливість втрутитися. Щодо повної механіки кроку пересилання на стороні сервера, стаття відстеження конверсій на стороні сервера за допомогою коротких посилань детально описує дедуплікацію, вимоги до хешування та семантику повторних спроб.

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

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

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

Детерміноване зіставлення працює. Якщо користувач авторизований або надає свою адресу електронної пошти на будь-якому етапі воронки (захоплення імейла, підписка на розсилку, оформлення замовлення), ви можете хешувати цю адресу електронної пошти за допомогою SHA-256 і включити її в подію конверсії. Meta CAPI, GA4 та Mixpanel приймають хешовану електронну пошту як сигнал для зіставлення разом із ідентифікатором кліку або замість нього. Рівень відповідності для трафіку з відомою електронною поштою високий - Meta внутрішньо повідомляє про рівень відповідності понад 90%, коли присутня нормалізована хешована електронна пошта. Це основний механізм зшивання, який пережив відмову від файлів cookie без змін.

Тут важливою є пара для дедуплікації. Кожна подія конверсії потребує event_id (для Meta) або transaction_id (для GA4), який є ідентичним між пікселем з боку браузера та відправленням з боку сервера. Без нього обидві події будуть враховані, і конверсія буде подвоєна. Ідентифікатор замовлення є стандартним ключем дедуплікації для подій покупки.

Імовірнісний фінгерпринтинг (fingerprinting) не працює - і є незаконним в ЄС. Фінгерпринтинг браузера збирає унікальний ідентифікатор із комбінації роздільної здатності екрана, встановлених шрифтів, часового поясу, user-agent, відбитка рендерингу canvas та подібних сигналів. Ідентифікатор є імовірнісним - він призначає високу впевненість збігу між двома подіями без спільного файлу cookie або входу в систему. Деякі постачальники атрибуції пропонують це як рішення для «вимірювання без файлів cookie».

В ЄС цей підхід має конкретну юридичну проблему. Директива ePrivacy 2002/58/EC, Стаття 5(3), вимагає згоди на доступ або зберігання інформації на термінальному обладнанні користувача. Позиція EDPB (Європейського комітету з питань захисту даних), повторена у кількох рішеннях наглядових органів з 2022 року, полягає в тому, що фінгерпринтинг підпадає під дію Статті 5(3) незалежно від того, чи є ідентифікатор технічно «файлом cookie». Австрійська DSB, французька CNIL та італійська Garante видали приписи про примусове виконання щодо фінгерпринтингу без згоди. Твердження «ми не використовуємо файли cookie, ми використовуємо фінгерпринтинг» не є аргументом на користь відповідності нормам; це аргумент, який запрошує до пильнішої перевірки.

Навіть поза межами юридичних ризиків, точність імовірнісного фінгерпринтингу знижується в міру того, як зменшується ентропія браузера. Сучасні браузери, орієнтовані на приватність, активно знижують ентропію шляхом нормалізації виводу canvas та обмеження точності API часу. Якість сигналу падає саме в тій частині аудиторії - орієнтованій на приватність, з великою часткою iOS - де вам найбільше потрібне точне вимірювання.

Зшивання між пристроями через CRM - це прогалина, що залишилася. Для користувачів, які здійснюють конверсію на іншому пристрої, ніж той, на якому вони клікнули, детерміноване зіставлення електронної пошти є єдиним підходом, що працює. Якщо користувач авторизований на обох пристроях, ідентифікатор користувача є зв'язком. Якщо він не авторизований, ідентифікатор кліку на пристрої А та конверсію на пристрої Б неможливо пов'язати без добровільного надання користувачем ідентифікатора (email, телефон), який ви можете хешувати та зіставити. Цю прогалину неможливо закрити на стороні сервера. Це реальне обмеження атрибуції у світі без файлів cookie.

Відповідність нормативним вимогам#

Формулювання «атрибуція без файлів cookie» може ввести в оману, змусивши думати, що оскільки файли cookie не встановлюються, згода не потрібна. Це не те, що каже закон.

Директива ePrivacy 2002/58/EC, Стаття 5(3), застосовується до будь-якого зберігання або доступу до інформації на термінальному обладнанні користувача - не тільки до файлів cookie. Власний файл cookie, встановлений для аналітичних цілей, вимагає такої ж згоди, як і сторонній файл cookie, встановлений для цілей відстеження, якщо цей файл cookie не є обов’язковим. Серверний файл cookie з ідентифікатором кліку, описаний вище, є суміжним з аналітикою; він може вимагати або не вимагати згоди залежно від оцінки мети вашим контролером та застосовного національного законодавства, що впроваджує Директиву.

Що насправді робить серверний підхід - і це його справжня перевага щодо відповідності - так це перенесення обробки з пристрою користувача на сервер. Реєстрація події кліку, пересилання події конверсії, зшивання ідентичності: ці процеси відбуваються у вашому бекенді та бекенді Elido, а не в браузерному скрипті. Це означає, що блокувальники реклами не перехоплюють їх, функції приватності браузера не розділяють їх, а стан мінімізації даних контролюєте ви, а не залежите від того, що вирішить надіслати сторонній тег.

Питання законної підстави за GDPR стоїть окремо від питання ePrivacy. Навіть із серверною атрибуцією вам потрібна законна підстава згідно зі Статтею 6 GDPR для обробки даних про кліки ідентифікованих суб’єктів з ЄС. Для аналітики на рівні кампанії більшість контролерів обґрунтовують це законним інтересом згідно зі Статтею 6(1)(f) після оцінки законного інтересу (LIA). Для профілювання на індивідуальному рівні або ретаргетингу обґрунтування знайти складніше. Стаття GDPR для скорочувачів URL-адрес детально охоплює аналіз Статей 6, 28 та 30; підсумок тут полягає в тому, що відсутність файлів cookie ≠ відсутність згоди, і необхідність відповідності не зникає через зміну механізму зберігання.

Налаштування Elido для подій кліків за замовчуванням відображають позицію мінімізації даних: IP-адреси скорочуються до /24 (IPv4) перед збереженням, повні рядки user-agent аналізуються і видаляються. Дані повної роздільної здатності доступні для кожного робочого простору, якщо ваш сценарій використання цього вимагає, але за замовчуванням встановлено консервативне налаштування. Це має значення для обговорення додатка про обробку даних (DPA) з вашими баєрами. Більше про це - у розділі solutions/marketers, який охоплює точки контакту при закупівлі для маркетингових команд.

Від чого доводиться відмовитися#

Чесний звіт має значення. Серверна атрибуція без файлів cookie відновлює більшу частину сигналу, втраченого через деградацію на стороні браузера, але вона не відновлює його повністю.

Ідентифікація між пристроями в реальному часі. Як зазначалося вище: якщо користувач клікає на мобільному пристрої та конвертує на десктопі без події входу в систему, що пов'язує ці два пристрої, атрибуція втрачається. Для цього не існує відповідного нормам серверного рішення. Це структурна прогалина.

Точна атрибуція за показами (view-through). Атрибуція за показами - зарахування кампанії конверсії, яка відбулася після показу реклами, а не кліку - вимагає від рекламної платформи зіставлення користувача в обох подіях. Серверні API конверсій добре справляються з атрибуцією на основі кліків; атрибуція за показами залежить від власного графа пристроїв платформи, який сам деградує пропорційно до втрати сигналу. Очікуйте, що звітність за показами буде більш «шумною» та менш надійною, ніж цифри на основі кліків.

Довгі вікна ретроспективного аналізу (lookback windows). Більшість кінцевих точок серверних API конверсій встановлюють обмеження на те, наскільки далеко в минулому клік може бути пов'язаний з конверсією. Стандартне вікно для Meta CAPI становить 7 днів для переходів. У GA4 Measurement Protocol вікно атрибуції варіюється залежно від каналу. Ці обмеження коротші за 28-денні або 90-денні вікна, які деякі команди використовували у світі файлів cookie. Продукти за підпискою та покупки з довгим циклом прийняття рішення побачать більше конверсій, що випадають за межі атрибутованого вікна.

Домінування останнього кліку (last-click). Без багатоканального графа ідентичності серверна атрибуція за замовчуванням використовує останній клік - кредит отримує останній ідентифікатор кліку в ланцюжку. Для кампаній із підвищення впізнаваності бренду, які сприяють асистованим конверсіям протягом тривалого періоду, серверна атрибуція за останнім кліком буде систематично недооцінювати витрати на верхню частину воронки. Пом'якшенням є зшивання через CRM за допомогою хешованої електронної пошти: якщо хеш пошти кожного авторизованого користувача присутній у кожній події конверсії, ви можете реконструювати багатоканальну послідовність для авторизованої частини вашої аудиторії. Для анонімних користувачів останній клік - це стеля.

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

Враховуючи вищезазначені обмеження, ось стек атрибуції, який працює для команди перфоманс-маркетингу, що працює з трафіком ЄС у 2026 році.

Ідентифікатор кліку короткого посилання як точка входу. Усі рекламні цілі - це брендовані короткі посилання на вашому домені. Перенаправлення встановлює серверний власний файл cookie та додає ідентифікатор кліку до цільової URL-адреси. Це дає вам постійний, встановлений сервером ідентифікатор, який переживає ITP та розділення файлів cookie протягом сесії.

Налаштування кошика та замовлення. Ідентифікатор кліку записується в атрибут кошика під час завантаження сторінки (з параметра URL або власного файлу cookie). При створенні замовлення ідентифікатор кліку знаходиться в кастомних атрибутах замовлення. Це надійна передача - як тільки ідентифікатор кліку опиняється в замовленні, термін його дії не закінчується.

Серверний CAPI для Meta. Після оплати замовлення ваш бекенд (або функція пересилання конверсій) надсилає POST до Meta CAPI з ідентифікатором кліку, хешованою за допомогою SHA-256 електронною поштою та ідентифікаторами fbc/fbp із власних файлів cookie. event_id - це ідентифікатор замовлення, що збігається з пікселем з боку браузера. Meta виконує дедуплікацію протягом 48-годинного вікна зіставлення.

Серверний Measurement Protocol для GA4. Одночасно надсилається серверна подія GA4 з transaction_id, що дорівнює ідентифікатору замовлення. client_id - це значення файлу cookie GA4 _ga, якщо воно доступне, або ідентифікатор кліку як резервний варіант. GA4 виконує дедуплікацію за transaction_id у межах вікна сесії.

Зшивання пошти через CRM. Для будь-якої конверсії, де ідентифікатор кліку відсутній (органічний пошук, прямий захід, брендовий пошук), сигналом атрибуції є хешована адреса електронної пошти. Це заповнює сегмент «відомих користувачів» вашої атрибуції та підтримує базову реконструкцію багатоканальної атрибуції для авторизованих клієнтів.

Імпорт офлайн-конверсій для довгого ретроспективного аналізу. Для продуктів за підпискою або B2B-воронок, де конверсія відбувається через кілька тижнів після кліку, імпорт офлайн-конверсій через пакетний API платформи (офлайн-події Meta CAPI, офлайн-конверсії Google Ads) дозволяє надсилати події атрибуції поза межами вікна ретроспективного аналізу в реальному часі. Ключем зіставлення все ще є хешована електронна пошта або телефон; часове вікно розширено. Це не вирішує проблему анонімної атрибуції з довгим циклом, але закриває цикл для тієї частини вашої аудиторії, яка надала адресу електронної пошти.

Наведений вище стек не потребує CDP. Він потребує скорочувача URL-адрес, який генерує та зберігає серверні ідентифікатори кліків, бекенда, який передає ідентифікатор кліку до замовлення, і рівня пересилання конверсій, який обробляє хешування та розсилку по API. Технічна реалізація рівня розсилки з описами корисного навантаження, механікою дедуплікації та семантикою повторних спроб наведена у статті відстеження конверсій на стороні сервера за допомогою коротких посилань. Про те, як це вписується в повний робочий процес UTM-кампанії, дивіться у розділі solutions/marketers.

Версія цього стека, яка не працює: та, що покладається на власний міжпристроєвий граф рекламної платформи для ідентифікації, сподівається, що користувачі iOS увімкнули App Tracking Transparency таким чином, щоб це сприяло вашому вимірюванню, або використовує імовірнісний фінгерпринтинг для заповнення прогалин. Перше - поза вашим контролем. Друге - лише сподівання. Третє - юридичний ризик в ЄЄ.

Працюйте з тим, що тримається.