Атрибуция кликов после Safari ITP: что все еще работает в 2026 году

Apple выпустила первую версию Intelligent Tracking Prevention в сентябре 2017 года. Она была представлена как функция обеспечения конфиденциальности, что соответствует действительности. Но это также был системный демонтаж каждой лазейки, которую индустрия рекламных технологий создавала с тех пор, как экосистема сторонних файлов cookie начала рушиться примерно в 2013 году. Каждая новая версия ITP закрывала запасной выход, найденный маркетологами в предыдущей. К моменту выхода ITP 2.3 в 2019 году последовательность ограничений стала настолько плотной, что единственными путями атрибуции, все еще надежно функционирующими в Safari, остались те, которые никогда не зависели от межсайтового отслеживания.

Этот пост рассматривает хронологию событий: что именно ломалось в каждой версии, для закрытия каких конкретно обходных путей она создавалась, и как обстоят дела с атрибуцией в 2026 году. В дополнение к этому, в статье Объяснение бескукисной атрибуции рассматривается общая ситуация в разных браузерах; здесь же мы сосредоточимся именно на Safari и паттерне цепочки редиректов, который пережил все изменения.

TL;DR#

• ITP 2.0 (2018) заблокировал доступ ко всем сторонним хранилищам (third-party storage) на межсайтовых доменах, убив стандартный путь атрибуции через рекламные пиксели в Safari.
• ITP 2.1 (2019) ограничил срок жизни основных файлов cookie (first-party), устанавливаемых через JavaScript, до 7 дней, положив конец годовым окнам атрибуции, настраиваемым через тег-менеджеры.
• ITP 2.2 и 2.3 начали вырезать параметры «декорирования ссылок» и понижать уровень заголовков referrer, закрыв последние лазейки через строку запроса.
• Короткая ссылка на вашем собственном домене устанавливает first-party cookie на стороне сервера в момент редиректа - это единственный паттерн, который выживает во всех версиях ITP и обеспечивает надежное 7-дневное окно атрибуции в Safari.

Хронология ITP: детальный разбор версий#

ITP не появился сразу в законченном виде. Он внедрялся постепенно, и каждая новая версия была нацелена на конкретный класс обходных путей, разработанных индустрией в ответ на предыдущие ограничения. Понимание этой последовательности важно, так как технический облик того, что работает сегодня, продиктован тем, что и как было закрыто.

ITP 1.0 - сентябрь 2017. Первый релиз классифицировал домены как «межсайтовые трекеры» на основе частоты откатов и сигналов взаимодействия с пользователем. Домены, классифицированные как трекеры, подвергались партиционированию файлов cookie - их можно было устанавливать, но считывать в межсайтовом контексте можно было только в том случае, если пользователь напрямую взаимодействовал с доменом трекера в течение последних 24 часов. Для доменов вроде стандартного аналитического пикселя, на которые пользователи никогда не переходят напрямую, это 24-часовое окно стало фактической блокировкой.

ITP 1.1 - март 2018. Рекламодатели ответили на версию 1.0, направив атрибуцию через цепочки редиректов, которые касались домена трекера как первой стороны (first-party) перед переходом к конечному пункту. Это давало пользователям «прямой визит» на домен трекера, что сбрасывало счетчик взаимодействия. ITP 1.1 распознал этот паттерн - известный как bounce tracker - и отменил кредит на взаимодействие, генерируемый такими цепочками. Домены, которые существовали исключительно для паттерна «отскок-и-редирект», потеряли статус взаимодействия.

Что сломал ITP 2.0#

ITP 2.0 вышел в сентябре 2018 года. Это был структурный разлом. Если версии 1.x партиционировали сторонние файлы cookie, то 2.0 пошла дальше: она полностью удалила доступ к сторонним хранилищам (third-party storage) для классифицированных доменов. Файлы 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) нацелился на обходной путь, который вырос в ответ на это: атрибуцию через внедрение собственных (first-party) cookie с помощью тег-менеджеров.

Логика была здравой. Если сторонний пиксель заблокирован, вы все равно можете сохранить атрибуцию, записав first-party cookie на собственном домене рекламодателя через JavaScript - обычно с помощью тег-менеджера вроде GTM. Этот файл cookie являлся собственным (first-party) и, следовательно, не подпадал под ограничения ITP на сторонние хранилища. Многие команды перешли на годовые окна атрибуции, установленные таким образом, полагая, что запись document.cookie через JavaScript безопасна.

ITP 2.1 ограничил все файлы cookie, установленные через document.cookie - независимо от их статуса (first-party или third-party) - максимальным сроком в 7 дней. Это ограничение применялось именно к файлам cookie, устанавливаемым скриптами; файлы cookie, устанавливаемые через HTTP-заголовок ответа Set-Cookie, не были затронуты версией 2.1. Различие точное и важное: document.cookie = "..." в JavaScript ограничено 7 днями. Set-Cookie: ...; Max-Age=31536000 в ответе сервера - нет.

Первой жертвой стала настройка атрибуции на базе GTM. GTM записывает файлы cookie через JavaScript на странице. Срок жизни таких cookie в Safari теперь истекал через 7 дней, независимо от указанного срока экспирации. Пользователь, который нажал на ссылку кампании во вторник и совершил конверсию в следующую среду, оказывался за пределами окна атрибуции. Годовые окна атрибуции через first-party cookie, на которые команды мигрировали после ITP 2.0, исчезли.

Что сломал ITP 2.2#

ITP 2.2 ужесточил правила в двух областях. Во-первых, он сократил лимит на JavaScript-cookie до 24 часов в тех случаях, когда ссылка на целевую страницу вела с домена, классифицированного ITP как межсайтовый трекер. Если пользователь кликал по ссылке на странице классифицированного домена, срок жизни first-party 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) закрыл две оставшиеся лазейки.

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

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

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

Что выжило#

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

First-party cookie, установленные сервером. Ограничение на cookie в ITP 2.1 применяется к записям через document.cookie в JavaScript. Файлы cookie, установленные сервером через HTTP-заголовок ответа Set-Cookie, сохраняют указанный срок действия. Ключевое условие: файл cookie должен быть установлен на домене, который контролирует сервер.

Серверная передача событий. Если идентификатор клика фиксируется в момент редиректа и сохраняется на стороне сервера, то поиск атрибуции в момент конверсии - это операция «сервер-сервер». Браузерному файлу cookie не нужно «выживать» 7 дней; идентификатор клика находится в вашей базе данных. Это архитектура, лежащая в основе серверного отслеживания конверсий, и подход, для поддержки которого разработаны Meta CAPI, GA4 Measurement Protocol и TikTok Events API.

Детерминированное сопоставление через хешированный email или телефон. Если пользователь авторизован или предоставил адрес электронной почты, конверсия может быть сопоставлена с исходным кликом по хешу email, а не по идентификатору cookie. Этот путь вообще не зависит от ITP - он никогда не полагался на хранилище браузера. Ограничение заключается в охвате: это работает только для пользователей, которые идентифицировали себя в окне атрибуции.

Полный технический контекст для этих паттернов приведен в статье Объяснение бескукисной атрибуции.

Паттерн редиректа коротких ссылок#

Короткие ссылки на вашем собственном домене (не на общем домене сервиса сокращения) предоставляют возможность установки cookie на стороне сервера в форме, которая естественно вписывается в трафик рекламных кампаний.

Механика проста. Когда пользователь нажимает на ссылку кампании, ведущую на go.acme.example/spring26, запрос попадает на edge-обработчик на go.acme.example. Обработчик фиксирует событие клика, генерирует идентификатор клика и устанавливает заголовок Set-Cookie в ответе редиректа - это собственный (first-party) cookie на домене acme.example. Затем он выдает 302-й ответ на целевой URL с идентификатором клика, добавленным в качестве параметра запроса.

Поскольку файл cookie устанавливается через Set-Cookie сервером в момент редиректа, 7-дневное ограничение ITP 2.1 для JavaScript не применяется. Файл cookie сохраняет срок экспирации, заданный сервером. В Safari с полностью активным ITP 2.3 серверный cookie на go.acme.example сохраняется в течение всего настроенного окна. В Elido мы устанавливаем 7-дневный срок по умолчанию, так как это все равно соответствует самому строгому ограничению ITP для JS-cookie, и серверный cookie сохраняется все эти 7 дней.

Целевая страница затем считывает идентификатор клика из cookie или из параметра запроса (в зависимости от того, что доступно), записывает его в атрибуты корзины или заказа, и событие конверсии передает его на сторону сервера в момент покупки. Межсайтовые домены не задействованы. Cookie находится на вашем домене. Поиск атрибуции - это серверная операция. У ITP нет поводов для блокировки.

Вот почему поддержка кастомных доменов для коротких ссылок важна для атрибуции: не только для брендинга, но и для классификации cookie как first-party. Общий домен сокращателя, такой как bit.ly или short.io, является для вашего сайта другим источником (origin). Cookie, установленный на bit.ly, является сторонним (third-party) для acme.example, и ITP 2.0 блокирует его. Cookie, установленный на go.acme.example, является собственным (first-party), и ничто в ITP его не трогает. Процесс атрибуции кампаний от начала до конца описан на странице решения для маркетологов.

Более глубокий контекст GDPR относительно того, какие данные кликов может законно обрабатывать сокращатель ссылок и как настроить минимизацию данных в схеме событий кликов, см. в статье GDPR для сокращателей URL.

Что все еще не работает#

Честность обходится дешевле, чем попытки продать частичное решение.

Междоменная атрибуция по показам (view-through). Если пользователь видит рекламу на publisher.example без клика, а позже совершает конверсию на advertiser.example, безопасного с точки зрения ITP пути для такой атрибуции не существует. Атрибуция по показам по своей природе требует межсайтового сигнала от впечатления до конверсии. Safari блокирует это, а подходы с серверной передачей, описанные выше, инициируются кликом - они требуют клика для установки first-party cookie или записи идентификатора клика.

Склейка данных в реальном времени для неавторизованных пользователей. Если пользователь совершает конверсию, не входя в систему и не оставляя адрес электронной почты, единственным доступным идентификатором является идентификатор клика из cookie или параметра запроса. Если срок действия cookie истек (более 7 дней после первого клика или 24 часа, если применяется более жесткое ограничение версии 2.2), связь теряется. Серверное хранение идентификаторов кликов решает эту проблему для конверсий внутри окна. Это не решает проблему для конверсий, которые происходят после закрытия окна.

Окна атрибуции длиннее 7 дней в Safari для первого касания. Если цикл покупки в вашем бизнесе измеряется неделями или месяцами - что часто бывает в B2B SaaS, дорогом e-commerce или финансовых услугах - 7-дневное окно для first-party cookie в Safari означает, что значительная часть конверсий не будет отнесена к их исходному клику. Для таких бизнес-моделей единственным вариантом остается путь детерминированного хеширования email; вероятностная атрибуция в Safari недостаточно надежна для принятия решений.

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

С чего начать на практике#

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

Технические подробности настройки передачи конверсий - Meta CAPI, GA4 Measurement Protocol, семантика повторных попыток и дедупликация - изложены в статье Серверное отслеживание конверсий. Описание возможностей продукта доступно на странице функции отслеживания конверсий.

ITP не убил атрибуцию. Он убил конкретную архитектуру атрибуции - ту, что была построена на межсайтовом постоянном хранилище и недифференцированном накоплении данных на доменах, которые вы не контролируете. Архитектура, пришедшая ей на смену, более устойчива, а не менее.