Атрибуція кліків після Safari ITP: що все ще працює у 2026 році

Apple випустила першу версію Intelligent Tracking Prevention у вересні 2017 року. Це позиціонувалося як функція приватності, що відповідає дійсності. Але це також був систематичний демонтаж усіх обхідних шляхів, які індустрія рекламних технологій вибудувала з того часу, як екосистема сторонніх файлів cookie почала давати тріщини приблизно у 2013 році. Кожна нова версія ITP закривала чергову лазівку, яку маркетологи знаходили в попередній. До моменту виходу ITP 2.3 у 2019 році послідовність обмежень стала настільки ретельною, що єдиними шляхами атрибуції, які все ще надійно працювали в Safari, були ті, що ніколи не залежали від крос-сайтового відстеження.

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

TL;DR#

• ITP 2.0 (2018) заблокувала доступ до сторонніх сховищ на крос-сайтових доменах, знищивши стандартний шлях атрибуції через рекламні пікселі в Safari.
• ITP 2.1 (2019) обмежила термін дії першосторонніх файлів cookie, встановлених через JavaScript, до 7 днів, поклавши край річним вікнам атрибуції через менеджери тегів.
• ITP 2.2 та 2.3 почали вирізати параметри декорування посилань і понижувати заголовки referrer, закривши останні лазівки через рядки запитів.
• Коротке посилання на вашому власному домені встановлює першосторонній файл cookie на стороні сервера під час редиректу - це єдиний паттерн, який витримує всі версії ITP і забезпечує надійне 7-денне вікно атрибуції у Safari.

Хронологія ITP: розбір кожної версії#

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

ITP 1.0 - вересень 2017. Перший реліз класифікував домени як «крос-сайтові трекери» на основі частоти баунсів та сигналів взаємодії з користувачем. Для доменів, класифікованих як трекери, файли cookie були ізольовані (partitioned): їх можна було встановлювати, але зчитувати в крос-сайтовому контексті дозволялося лише за умови, що користувач безпосередньо взаємодіяв з доменом трекера протягом останніх 24 годин. Для таких доменів, як стандартний аналітичний піксель, на які користувачі ніколи не заходять прямо, 24-годинне вікно стало фактичним блокуванням.

ITP 1.1 - березень 2018. Рекламодавці відповіли на версію 1.0, спрямувавши атрибуцію через ланцюжки редиректів, які торкалися домену трекера як першосторонньої сторінки перед переходом до пункту призначення. Це давало користувачам «прямий візит» на домен трекера, що скидало лічильник взаємодії. ITP 1.1 ідентифікувала цей паттерн - відомий як bounce tracker - і скасувала зарахування взаємодії, яку генерували такі ланцюжки. Домени, які, очевидно, існували лише для паттерну «перехід-і-редирект», втратили статус взаємодії.

Що зламала ITP 2.0#

ITP 2.0 вийшла у вересні 2018 року. Вона стала структурним переломом. Якщо версії 1.x ізолювали сторонні файли cookie, то 2.0 пішла далі: вона повністю закрила доступ до сторонніх сховищ для доменів, класифікованих як трекери. Файли cookie, localStorage, IndexedDB, кешовані дані - все це було заблоковано для будь-якого домену, який ITP визначила як крос-сайтовий трекер.

Практичний вплив на рекламні технології був колосальним. Facebook Pixel, тег конверсії Google Ads та більшість пікселів ретаргетингу залежать від зчитування крос-сайтового файлу cookie, щоб пов’язати клік із конверсією. У Safari після ITP 2.0 це зчитування перестало працювати. Власна звітність Meta на той час вказувала на 15-25% прогалини в покритті подій для трафіку з Safari - кліки та конверсії, які піксель бачив у Chrome або Firefox, просто не з’являлися у користувачів Safari.

Блокування сховища не обмежувалося лише файлами cookie. Скрипти, які намагалися зберегти ідентифікатори в localStorage під доменом, класифікованим як трекер, або використовувати для цього Service Workers, так само блокувалися. Метою 2.0 було зробити рівень стороннього сховища структурно недоступним для цілей відстеження, а не просто зламати якусь конкретну техніку.

Що зламала ITP 2.1#

Якщо 2.0 вбила сторонню атрибуцію, то ITP 2.1 (березень 2019) націлилася на обхідний шлях, який з’явився у відповідь на неї: атрибуцію через першосторонні файли cookie за допомогою ін’єкції менеджера тегів.

Логіка була слушною. Якщо сторонній піксель заблоковано, ви все одно можете зберегти атрибуцію, записавши першосторонній файл cookie на власному домені рекламодавця через JavaScript - зазвичай за допомогою менеджера тегів, як-от GTM. Файл cookie був першостороннім, а отже, не підпадав під обмеження ITP щодо сторонніх сховищ. Багато команд перейшли на річні вікна атрибуції, встановлені таким чином, вважаючи, що запис document.cookie у JavaScript є безпечним.

ITP 2.1 обмежила термін дії всіх файлів cookie, встановлених через document.cookie - незалежно від того, першосторонні вони чи сторонні - максимумом у 7 днів. Це обмеження стосувалося саме файлів cookie, встановлених скриптами; на файли cookie, встановлені через HTTP-заголовок відповіді Set-Cookie, версія 2.1 не впливала. Ця різниця є точною і важливою: document.cookie = "..." у JavaScript обмежено 7 днями. Set-Cookie: ...; Max-Age=31536000 у відповіді сервера - ні.

Першою жертвою стала атрибуція на базі GTM. GTM записує файли cookie через JavaScript на сторінці. Ці файли, незалежно від заявленого терміну дії, тепер зникали через 7 днів у Safari. Користувач, який натиснув на посилання кампанії у вівторок і здійснив конверсію наступної середи, опинявся поза межами вікна атрибуції. Річне вікно атрибуції через першосторонні файли cookie, на яке команди перейшли після ITP 2.0, зникло.

Що зламала ITP 2.2#

ITP 2.2 посилила обмеження у двох сферах. По-перше, вона скоротила ліміт для JavaScript-cookie до 24 годин у конкретному випадку, коли на цільову сторінку перейшли з домену, класифікованого ITP як крос-сайтовий трекер. Якщо користувач натиснув на посилання зі сторінки класифікованого домену, першосторонні файли cookie на сайті призначення, встановлені через JavaScript, обмежувалися 24 годинами, а не 7 днями. 7-денний ліміт залишався для шляхів реферера, що не відстежуються, але 24-годинний ліміт застосовувався, коли ланцюжок кліків включав класифікований домен.

По-друге, що було помічено значно ширше, ITP 2.2 ввела обмеження на декорування посилань. Рекламні платформи та інструменти аналітики розробили паттерн додавання ідентифікаторів атрибуції як параметрів запиту до цільових URL - gclid для Google Ads, fbclid для Meta, msclkid для Microsoft Advertising. За певних умов, якщо домен, з якого здійснювався перехід, був класифікований як трекер, ITP починала вирізати ці параметри перед завантаженням сторінки або обмежувати файли cookie, які могли бути встановлені у відповідь на їхню наявність.

Це була пряма атака на шлях атрибуції на основі gclid, на який команди перейшли після версій 2.0 та 2.1. Логіка була чіткою: Apple вважала відстеження користувачів за параметрами запиту еквівалентним за впливом на приватність відстеженню за файлами cookie, і до нього мають застосовуватися ті самі обмеження.

Що зламала ITP 2.3#

ITP 2.3 (вересень 2019) закрила дві лазівки, що залишилися.

Першою було пониження реферера (referrer downgrading) під час крос-сайтової навігації. Якщо попередні версії фокусувалися на сховищі та параметрах посилань, то 2.3 взялася за заголовок Referer - значення, яке сторінка отримує, коли користувач переходить на неї з іншого сайту. Для крос-сайтових переходів із класифікованих доменів ITP 2.3 понижувала реферер до рівня origin-only: https://classified-domain.com/ замість повного https://classified-domain.com/path?campaign=spring&source=email. Шлях (path) та рядок запиту, які часто містили контекст атрибуції, видалялися.

Друга зміна розширила логіку обмеження сховища. На додачу до 7-денного ліміту для JavaScript-cookie, ITP 2.3 почала застосовувати обмеження сховища після одного крос-сайтового кліку з класифікованого домену: все клієнтське сховище на цільовому сайті - файли cookie, localStorage, IndexedDB - підлягало обмеженню. Метою було закрити клас паттернів атрибуції зі збереженням стану, де сам факт переходу з класифікованого домену запускав зворотний відлік можливості сайту призначення зберігати дані.

Разом версії 2.2 та 2.3 закрили три основні маршрути, які команди використовували після 2.0 та 2.1: параметри декорування посилань, атрибуцію на основі реферера та накопичення даних у сховищі через ланцюжки крос-сайтових кліків.

Що вижило#

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

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

Передача подій на стороні сервера. Якщо ідентифікатор кліку фіксується під час редиректу і зберігається на стороні сервера, пошук атрибуції в момент конверсії стає операцією «сервер-сервер». Ніякому браузерному файлу cookie не потрібно виживати 7 днів; ідентифікатор кліку знаходиться у вашій базі даних. Це архітектура, що стоїть за відстеженням конверсій на стороні сервера, і саме цей підхід розроблені підтримувати Meta CAPI, GA4 Measurement Protocol та TikTok Events API.

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

Повний технічний контекст цих паттернів наведено в дописі Пояснення атрибуції без файлів cookie.

Паттерн редиректу через короткі посилання#

Короткі посилання на вашому власному домені - не на спільному домені сервісу скорочення - дають вам шлях через встановлений сервером файл cookie у формі, яка природно працює з трафіком кампаній.

Механіка проста. Коли користувач натискає на посилання кампанії, що вказує на go.acme.example/spring26, запит потрапляє на edge handler на go.acme.example. Він фіксує подію кліку, генерує ідентифікатор кліку та встановлює заголовок Set-Cookie у відповіді редиректу - це першосторонній файл cookie, встановлений сервером на acme.example. Потім він видає 302 редирект на цільовий URL з ідентифікатором кліку, доданим як параметр запиту.

Оскільки файл cookie встановлюється сервером через Set-Cookie під час редиректу, 7-денне обмеження JavaScript в ITP 2.1 не застосовується. Файл cookie зберігає термін дії, встановлений сервером. У Safari з активованою ITP 2.3 встановлений сервером файл cookie на go.acme.example виживає протягом усього налаштованого вікна. В Elido ми за замовчуванням встановлюємо 7-денний термін дії, оскільки це відповідає найсуворішому обмеженню ITP для JS-cookie, і встановлений сервером файл cookie тримається всі ці 7 днів.

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

Ось чому підтримка власних доменів для коротких посилань важлива для атрибуції: не лише для брендингу, але й для класифікації cookie як першосторонніх. Спільний домен сервісу скорочення, як-от bit.ly або short.io, є іншим походженням (origin) відносно вашого сайту. Файл cookie, встановлений на bit.ly, є стороннім для acme.example; ITP 2.0 блокує його. Файл cookie, встановлений на go.acme.example, є першостороннім; ITP його не чіпає. Сторінка рішення для маркетологів детально описує наскрізний потік атрибуції кампаній.

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

Що досі не працює#

Чесність коштує дешевше, ніж продаж часткового рішення.

Міждоменна атрибуція за показами (view-through). Якщо користувач бачить рекламу на publisher.example, не натискаючи на неї, а згодом здійснює конверсію на advertiser.example, безпечного для ITP шляху для такої атрибуції не існує. View-through за своєю суттю потребує крос-сайтового сигналу від показу до конверсії. Safari блокує це, а описані вище підходи на стороні сервера ініціюються кліком - вони потребують кліку для встановлення першостороннього файлу cookie або запису ідентифікатора.

Склеювання (stitching) у реальному часі для неавторизованих користувачів. Якщо користувач здійснює конверсію, ніколи не входячи в систему і не надаючи адресу електронної пошти, єдиним доступним ідентифікатором є ID кліку з файлу cookie або параметра запиту. Якщо термін дії файлу cookie закінчився (після 7 днів після першого кліку або 24 годин, якщо застосовується суворіший ліміт 2.2), зв’язок втрачається. Зберігання ID кліку на стороні сервера вирішує це для конверсій у межах вікна, але не для тих, що відбуваються після його закриття.

Вікна атрибуції довші за 7 днів у Safari для першого дотику (first-touch). Якщо ваш бізнес має цикл покупки, що вимірюється тижнями або місяцями - як це часто буває в B2B SaaS, дорогому e-commerce чи фінансових послугах - 7-денне вікно для першосторонніх cookie у Safari означає, що значна частина конверсій не буде пов’язана з початковим кліком. Для таких бізнес-моделей єдиним варіантом є детермінований шлях через хеш електронної пошти; імовірнісна (probabilistic) атрибуція в Safari недостатньо надійна для прийняття рішень.

Фінгерпринтинг як заміна. Canvas fingerprinting, аудіо-фінгерпринтинг та перерахування шрифтів - це обхідні шляхи, які намагаються повторно ідентифікувати користувачів між сесіями без файлів cookie. Apple чітко заявила про намір зменшити поверхню для фінгерпринтингу в Safari. У примітках до релізу ITP 2.3 згадується «додатковий захист від інших форм крос-сайтового відстеження», і цей напрямок зберігається в кожному наступному випуску Safari. Фінгерпринтинг також несе суттєві юридичні ризики згідно зі статтею 6 GDPR, як зазначено в GDPR для сервісів скорочення посилань. Це не є життєздатною заміною для описаних вище паттернів.

З чого почати на практиці#

Паттерн редиректу працює. Налаштуйте власний домен у своєму робочому просторі для коротких посилань (go.yourdomain.example), спрямуйте через нього трафік кампаній та налаштуйте свою цільову сторінку на зчитування параметра запиту elido_click або першостороннього файлу cookie і запис його в атрибути замовлення чи кошика до того, як користувач здійснить конверсію. Потім передавайте конверсії на рекламні платформи на стороні сервера через Conversions API. 7-денне вікно охоплює більшість шляхів від кліку до конверсії для більшості типів кампаній.

Щодо налаштування передачі конверсій - Meta CAPI, GA4 Measurement Protocol, семантики повторних спроб та форми дедуплікації - технічним доповненням до цього допису є відстеження конверсій на стороні сервера. Опис продуктової частини можна знайти на сторінці функції відстеження конверсій.

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