Ограничения Safari ITP на куки: как сохранить атрибуцию через server-side трекинг
Три правила ITP, которые урезают браузерные куки
Intelligent Tracking Prevention (ITP) в Safari документирован серией постов WebKit, и для конверсионного трекинга важны три правила. Первое: Safari стал первым мейнстрим-браузером с полным блоком third-party cookies по умолчанию - куки трекинг-домена внутри чужой страницы просто не существуют. Второе: ITP капит script-writable хранилище - куки через document.cookie и JS-хранилища - семью днями, и формулировка WebKit точна: удаление происходит после семи дней использования Safari без взаимодействия с сайтом. Третье - самое жёсткое для платного трафика: ITP 2.2 капит persistent-куки через document.cookie до одного дня хранения при двух условиях: на страницу привёл домен, классифицированный с cross-site tracking capabilities, и финальный URL несёт query string или fragment.
И это прямое описание платного клика. Рекламная платформа - ровно тот классифицированный домен, который уводит пользователей на чужие страницы, а URL рекламных лендингов - ровно те декорированные линки - fbclid, ttclid, rdt_cid, gclid - которые правило называет. Сам клик-ID в URL выживает нормально, поэтому потери клик-идентификаторов - отдельная проблема; умирает кук, который должен был запомнить пользователя после клика.
Почему пиксель теряет атрибуцию на iOS
Браузерный пиксель идентифицирует посетителя first-party куком, записанным JavaScript, - это ровно тот класс хранилища, который ITP капит. На лендинге с платного клика такой кук стартует с потолком в один день. Пользователь, конвертнувшийся на третий день, не опознан: пиксель стреляет новое событие о незнакомце. Частотные капы, ретаргет-пулы и view-through атрибуция деградируют так же, а фон по трекингу - в pixel warming.
Здесь нет бага вашей настройки - это документированное поведение браузера на большой доле мобильного трафика. Практическое следствие - системный зазор между конверсиями трекера и платформы на iOS Safari, поверх эффектов задержки из Meta CAPI event delay. Лечить зазор подкруткой пикселя бесполезно: капится именно то хранилище, на котором пиксель держится.
Серверный ответ: кук ставит ваш собственный домен
Капы ITP 2.1-2.3 целятся в script-writable хранилище. Кук, доставленный в HTTP-заголовке ответа - Set-Cookie от сервера, на котором стоит ваш трекер, на домене, который реально ваш, - не записан JavaScript, и таблица совместимости из поста WebKit о CNAME-защите различает именно это: first-party субдомен без cloaking не получает капа срока куки. Отсюда структурный фикс воронки: поймайте клик-ID в трекер первым же запросом и пусть серверный ответ трекера ставит идентифицирующий кук на будущее.
Практическая настройка воронки с трекером следует из этого напрямую. Держите трекер на своём субдомене, чтобы идентифицирующий кук был честно first-party. Сохраняйте клик-ID из URL и привязку к этому куку на сервере, а не в поле, доступном клиентскому JavaScript. Состояние конверсий храните на сервере, куда семидневное удаление не дотягивается. Браузерный маркер сессии становится расходником: в худшем случае Safari его снесёт, а клик-ID в ваших логах всё ещё связывает визит с рекламой. Общий контекст атрибуции без опоры на браузерное хранилище - в cookieless-атрибуции для аффилей.
CNAME cloaking больше не лазейка
Когда ITP закапил JS-куки, появилась обходная схема: навести субдомен вашего сайта на внешний трекер через DNS CNAME-запись, чтобы куки трекера писались от имени вашего домена. Ответ WebKit прямой - ITP детектит third-party CNAME cloaking, определяемый как first-party субресурс, чей CNAME отличается от first-party домена, и капит срок любых куки из таких ответов семью днями. Таблица WebKit рисует границу ясно: ваш субдомен, резолвящийся в ваш трекер, капа не получает; субдомен, резолвящийся во внешний трекер, получает 7-дневный кап.
Вывод для воронки с iOS-трафиком: честное first-party развёртывание - единственный вариант, который браузер считает first-party. Ставьте трекер на инфраструктуру под вашим контролем на вашем домене - и серверное хранилище следует само собой; архитектурная рамка выбора - сравнение server-side трекинга и браузерного пикселя.
Что выживает, а что нет
Компактная карта для планирования:
- Выживает: клик-ID в URL лендингов (
fbclid,ttclid,rdt_cid) - это query-параметры, а не хранилище. Серверные записи сессий и конверсий на вашем домене. Серверная доставка событий - канал conversions API не зависит от памяти браузера. - Деградирует до 1 дня: пиксельные куки на лендингах с классифицированных рекламных кликов с декорированными линками.
- Деградирует до 7 дней в остальных случаях: script-writable куки в целом (после семи дней Safari без взаимодействия) и куки из third-party CNAME-клокнутых ответов.
- Не существовало вовсе: third-party куки встроенных трекеров - полностью заблокированы по умолчанию.
Следствие для воронки: мерить и оптимизировать через каналы, не опирающиеся на деградирующие строки. Серверная доставка в платформу работает на полную - дедупликация пикселя и API поглощает слабеющую копию пикселя, а собственные записи трекера держат цифры честными. MOST ведёт такую серверную доставку в Meta, TikTok, Reddit, Pinterest, Snapchat и OpenAI из постбеков трекера, а бесплатный Pixel Activator закрывает ту же доставку для одного лендинга.