Атрибуция без куки-файлов: что все еще работает в 2026 году

Стек маркетинговой атрибуции, который большинство команд создавали между 2012 и 2019 годами, зависел от двух вещей: стороннего куки-файла, устанавливаемого рекламной платформой на целевой странице, и браузерного пикселя, который срабатывал на странице конверсии и сопоставлялся с этим куки-файлом. Обе половины этой пары теперь деградировали. Ни одна из них не восстановится.

Этот пост - не плач по куки-файлам. Это карта того, что на самом деле работает в 2026 году - какие пути атрибуции выжили, какие рекламировались как решения, не являясь ими на самом деле, и как на практике выглядит работающий стек для команд, запускающих платную рекламу на трафик из ЕС.

TL;DR#

• ITP 2.3 от Apple, Firefox Enhanced Tracking Protection и продолжающийся поэтапный отказ Chrome от сторонних куки-файлов вместе означают, что 60–70% веб-трафика в ЕС теперь блокируют или сильно ограничивают сторонние куки по умолчанию.
• Два пути атрибуции все еще функционируют: серверные идентификаторы, передаваемые через click ID, и установка куки-файлов от первого лица через цепочку редиректов, которую контролирует ваш домен.
• Отсутствие куки не означает отсутствие необходимости в согласии. Директива ePrivacy 2002/58/EC и GDPR по-прежнему требуют согласия для второстепенной аналитики, независимо от механизма хранения.
• Пробалистическая склейка по отпечатку браузера (fingerprinting) не является допустимым запасным вариантом в ЕС; детерминированное сопоставление хеша электронной почты в сочетании с серверным click ID - единственный подход, который выдерживает проверку как на точность, так и на соответствие регуляциям.

Что изменилось: краткая хронология#

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

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

График Chrome сдвигался несколько раз с тех пор, как Google анонсировала его в 2019 году. Текущая позиция, задокументированная на сайте Privacy Sandbox (доступ 2026-05-12), заключается в том, что прекращение поддержки продолжается для подмножества пользователей, а полное развертывание все еще находится в процессе. Независимо от окончательной даты Chrome, ситуация в ЕС уже определена: Safari и Firefox вместе составляют большинство мобильного и ориентированного на приватность десктопного трафика на рынках ЕС. Стратегии атрибуции, требующие сторонних куки, уже не работают для значительной части вашей европейской аудитории.

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

Два выживших пути атрибуции#

Путь 1: серверные идентификаторы#

Основной механизм прост. Когда пользователь нажимает на ваше объявление, рекламная платформа добавляет идентификатор клика к целевому URL - fbclid для Meta, gclid для Google и так далее. Этот идентификатор существует в URL, а не в куки, поэтому ITP и изоляция куки его не касаются.

Ваша целевая страница считывает click ID из URL и записывает его в куки-файл от первого лица на вашем собственном домене или передает его в корзину и далее в запись о заказе. Когда пользователь совершает конверсию, ваш бэкенд считывает click ID из заказа и отправляет конверсию с сервера на сервер в API конверсий рекламной платформы - Conversions API от Meta, GA4 Measurement Protocol, серверный эндпоинт событий Mixpanel.

Этот путь работает, потому что он никогда не касается сторонних куки. Click ID находится в строке запроса URL в момент приземления. Ваш куки-файл от первого лица на вашем собственном домене не ограничен ITP так же, как сторонние куки (хотя он подпадает под 7-дневный лимит для куки, установленных скриптом, если цепочка переходов подозрительна - подробнее об этом ниже). Событие конверсии передается сервер-сервер, полностью за пределами браузера.

Слабые места реальны. Если пользователь очистит куки между приземлением и конверсией, click ID будет потерян. Если конверсия происходит на другом устройстве, связь между устройствами отсутствует, если только у вас нет вошедшего в систему пользователя с известным адресом электронной почты. А в iOS 17 была введена защиту от отслеживания ссылок в режиме частного просмотра и в почте, которая удаляет известные параметры click ID из URL - fbclid, gclid, msclkid находятся в списке на удаление. Пользователь, пришедший через приложение почты с включенной защитой от отслеживания ссылок, не принесет click ID на ваш сайт вовсе.

Путь 2: цепочка редиректов от первого лица#

Второй выживший путь использует контролируемый вами редирект в качестве поверхности атрибуции. Вместо click ID рекламной платформы вы генерируете собственный постоянный идентификатор в момент редиректа на вашем собственном домене.

Когда пользователь нажимает на ссылку на вашем домене - будь то короткая ссылка, редирект кампании или брендированная диплинка - обработчик редиректа на вашем edge запускается до того, как вступят в силу ограничения приватности браузера. Он может:

1. Установить куки-файл от первого лица с созданным сервером click ID на вашем домене.
2. Добавить click ID как параметр URL к целевому URL.
3. Залогировать событие клика на стороне сервера с полным техническим контекстом (IP, user-agent, реферер, временная метка) в момент клика, а не в момент загрузки страницы.

Поскольку это ваш домен и ваш серверный куки, он находится вне ограничений для сторонних куки, на которые нацелена ITP. Куки устанавливается вашим сервером через заголовок ответа Set-Cookie в ответе на редирект - серверные куки не подпадают под 7-дневный лимит ITP, который применяется к записям document.cookie из JavaScript.

Это именно та поверхность атрибуции, которую обеспечивает сокращатель ссылок и которую не может дать браузерный пиксель. Редирект разрешается на домене сокращателя. Если этот домен является вашим собственным брендированным доменом, ваш click ID является собственным (first-party), серверным и архитектурно расположен до того, как сработают любые браузерные ограничения приватности.

Как короткая ссылка становится поверхностью атрибуции#

Поток редиректа работает следующим образом. Целевой URL вашего объявления - это брендированная короткая ссылка, например, go.acme.example/summer-sale. Пользователь нажимает на нее. Запрос редиректа достигает edge-обработчика Elido, который:

• Находит целевой URL.
• Генерирует идентификатор elido_click и логирует событие клика на стороне сервера.
• Устанавливает куки-файл от первого лица Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 в ответе на редирект.
• Добавляет ?elido_click=<id> к целевому URL перед пересылкой.

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

Click ID никогда не жил в стороннем куки. Он был установлен сервером, был собственным (first-party) и был залогирован до того, как слой приватности браузера успел вмешаться. Для понимания механики шага серверной пересылки в статье серверное отслеживание конверсий через короткие ссылки подробно описаны дедупликация, требования к хешированию и семантика повторных попыток.

Для более широкого понимания того, как именно ITP ухудшает атрибуцию кликов и что с этим делает цепочка редиректов коротких ссылок, операционным дополнением к этому посту служит статья атрибуция кликов после Safari ITP.

Склейка личностей: что работает, а что нет#

Серверные click ID решают проблему атрибуции для пользователей, которые нажимают на ссылку и совершают конверсию в той же сессии браузера на том же устройстве, не очищая куки и не используя защиту от отслеживания ссылок, удаляющую параметры. Это все еще покрывает большинство e-commerce конверсий. Но это покрывает не все, и подходы, которые команды используют для заполнения оставшегося пробела, значительно различаются как по точности, так и по юридическим рискам.

Детерминированное сопоставление работает. Если пользователь вошел в систему или предоставил свой адрес электронной почты в любой точке воронки (захват email, подписка на рассылку, оформление заказа), вы можете хешировать этот адрес с помощью SHA-256 и включить его в событие конверсии. Meta CAPI, GA4 и Mixpanel принимают хешированный email в качестве сигнала для сопоставления наряду с click ID или вместо него. Коэффициент сопоставления для трафика с известным email высок - Meta сообщает о коэффициенте сопоставления выше 90%, когда присутствует нормализованный хешированный email. Это основной механизм склейки, который выживает после отказа от куки без изменений.

Здесь важно сопряжение для дедупликации. Каждому событию конверсии нужен event_id (для Meta) или transaction_id (для GA4), который идентичен между браузерным пикселем и серверной отправкой. Без него оба события будут учтены, и конверсия будет посчитана дважды. ID заказа является стандартным ключом дедупликации для событий покупки.

Пробалистический фингерпринтинг не работает - и незаконен в ЕС. Браузерный фингерпринтинг собирает уникальный идентификатор из комбинации разрешения экрана, установленных шрифтов, часового пояса, user-agent, отрисовки canvas и подобных сигналов. Идентификатор является вероятностным - он присваивает высокую степень уверенности совпадению между двумя событиями без общего куки или логина. Некоторые вендоры атрибуции предлагают это как решение для «измерения без куки».

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

Даже за пределами юридических рисков, точность вероятностного фингерпринтинга снижается по мере уменьшения энтропии браузера. Современные браузеры, ориентированные на приватность, активно снижают энтропию, нормализуя вывод canvas и ограничивая разрешение таймингов API. Качество сигнала падает именно в той популяции - заботящейся о приватности, использующей iOS - где вам больше всего нужны точные измерения.

Склейка между устройствами через CRM - это оставшийся пробел. Для пользователей, которые совершают конверсию на устройстве, отличном от того, на котором они кликнули, детерминированное сопоставление по email - единственный работающий подход. Если пользователь вошел в систему на обоих устройствах, связующим звеном является user ID. Если они не вошли в систему, связать click ID на устройстве А и конверсию на устройстве Б невозможно без добровольного предоставления пользователем идентификатора (email, телефон), который вы можете хешировать и сопоставить. Этот пробел невозможно закрыть на стороне сервера. Это реальный предел атрибуции в мире без куки.

Слой комплаенса#

Формулировка «атрибуция без куки» может ввести людей в заблуждение, заставив думать, что раз куки не устанавливаются, то и согласие не требуется. Закон говорит не об этом.

Директива ePrivacy 2002/58/EC, Статья 5(3), применяется к любому хранению или доступу к информации на терминальном оборудовании пользователя - не только к куки. Куки-файл от первого лица, установленный для целей аналитики, требует такого же согласия, как и сторонний куки, установленный для целей отслеживания, если этот куки не является строго необходимым. Описанный выше серверный куки с click ID относится к аналитике; он может требовать или не требовать согласия в зависимости от оценки целей вашим контролером данных и применимой национальной имплементации Директивы.

Что действительно дает серверный подход - и в этом его реальное преимущество для комплаенса - так это перенос обработки с устройства пользователя на сервер. Логирование события клика, пересылка события конверсии, склейка личностей: все это происходит в вашем бэкенде и бэкенде Elido, а не в браузере. Это означает, что блокировщики рекламы не перехватывают их, функции приватности браузера не изолируют их, а степень минимизации данных контролируется вами, а не зависит от того, что решит отправить сторонний тег.

Вопрос законного основания по GDPR отделен от вопроса ePrivacy. Даже при серверной атрибуции вам нужно законное основание согласно Статье 6 GDPR для обработки данных о кликах идентифицируемых субъектов в ЕС. Для аналитики на уровне кампаний большинство контролеров основывают это на законном интересе согласно Статье 6(1)(f) после проведения оценки законного интереса (LIA). Для профилирования или ретаргетинга на индивидуальном уровне обоснование найти сложнее. Статья GDPR для сокращателей ссылок подробно освещает анализ Статей 6, 28 и 30; резюме здесь таково: отсутствие куки ≠ отсутствие необходимости в согласии, и слой комплаенса не исчезает из-за смены механизма хранения.

Настройки Elido по умолчанию для событий клика отражают позицию минимизации данных: IP-адреса усекаются до /24 (IPv4) перед сохранением, полные строки user-agent парсятся и удаляются. Данные в полном разрешении доступны для каждого воркспейса, если ваш кейс того требует, но по умолчанию установлена консервативная настройка. Это имеет значение для обсуждения DPA (соглашения об обработке данных) с вашими закупщиками. Подробнее об этом - в разделе решения для маркетологов, где описаны точки соприкосновения при закупках для маркетинговых команд.

От чего приходится отказываться#

Честный учет важен. Серверная атрибуция без куки восстанавливает большую часть сигнала, потерянного из-за деградации в браузере, но она не восстанавливает его полностью.

Идентификация между устройствами в реальном времени. Как отмечалось выше: если пользователь кликает на мобильном и конвертирует на десктопе без события логина, связывающего их, атрибуция теряется. Для этого нет соответствующего комплаенсу серверного решения. Пробел является структурным.

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

Длинные окна атрибуции. Большинство эндпоинтов серверных API конверсий накладывают ограничение на то, как далеко в прошлое может уходить клик, чтобы его можно было приписать конверсии. Стандартное окно Meta CAPI составляет 7 дней для кликов. У GA4 Measurement Protocol окно атрибуции варьируется в зависимости от канала. Эти ограничения короче, чем 28-дневные или 90-дневные окна, которые некоторые команды использовали в мире куки. Продукты по подписке и сложные покупки с длинным циклом исследования увидят больше конверсий, выпадающих за пределы атрибутируемого окна.

Доминирование последнего клика. Без мультитач-графа идентичности серверная атрибуция по умолчанию использует последний клик - кредит получает самый последний click ID в цепочке. Для кампаний по узнаваемости бренда, которые способствуют вспомогательным конверсиям в течение длительного периода, серверная атрибуция по последнему клику будет систематически недооценивать расходы на верхнюю часть воронки. Смягчением является склейка через CRM по хешированному email: если email каждого вошедшего пользователя присутствует в каждом событии конверсии, вы можете реконструировать последовательность мультитач для части вашей аудитории, вошедшей в систему. Для анонимных пользователей последний клик - это потолок.

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

Учитывая вышеуказанные ограничения, вот стек атрибуции, который работает для команды перформанс-маркетинга, работающей с трафиком из ЕС в 2026 году.

Click ID короткой ссылки как точка входа. Все целевые страницы объявлений - это брендированные короткие ссылки на вашем домене. Редирект устанавливает серверный куки-файл от первого лица и добавляет click ID к целевому URL. Это дает вам постоянный, установленный сервером идентификатор, который выживает в условиях ITP и изоляции куки в рамках сессии.

Настройка корзины и заказов. Click ID записывается в атрибут корзины при загрузке страницы (из параметра URL или куки-файла от первого лица). При создании заказа click ID находится в кастомных атрибутах заказа. Это надежная передача данных - как только click ID попадает в заказ, срок его действия не истекает.

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

Серверная передача Measurement Protocol в GA4. Одновременно отправляется событие GA4 на стороне сервера с transaction_id, равным ID заказа. client_id - это значение куки GA4 _ga, если оно доступно, или click ID в качестве запасного варианта. GA4 дедуплицирует по transaction_id в рамках окна сессии.

Склейка по хешу email из CRM. Для любой конверсии, где click ID отсутствует (органика, прямой заход, брендовый поиск), сигналом атрибуции является хешированный адрес электронной почты. Это наполняет сегмент «известных пользователей» вашей атрибуции и поддерживает базовую реконструкцию мультитач для вошедших в систему клиентов.

Импорт оффлайн-конверсий для длинных окон. Для продуктов по подписке или B2B-воронок, где конверсия происходит через несколько недель после клика, импорт оффлайн-конверсий через пакетный API платформы (оффлайн-события Meta Conversions API, оффлайн-конверсии Google Ads) позволяет отправлять события атрибуции за пределами окна реального времени. Ключом сопоставления по-прежнему является хешированный email или телефон; временное окно расширено. Это не решает проблему анонимной атрибуции с длинным циклом, но замыкает цикл для той части вашей аудитории, которая предоставила адрес электронной почты.

Вышеописанный стек не требует CDP. Ему нужен сокращатель ссылок, который генерирует и сохраняет серверные click ID, бэкенд, который передает click ID в заказ, и слой пересылки конверсий, который берет на себя хеширование и рассылку по API. Техническая реализация слоя рассылки, формы полезной нагрузки, механика дедупликации и семантика повторных попыток описаны в статье серверное отслеживание конверсий через короткие ссылки. О том, как это вписывается в полный рабочий процесс UTM-кампании, читайте в разделе решения для маркетологов.

Версия этого стека, которая не работает: та, что полагается на собственный кросс-девайсный граф рекламной платформы для разрешения идентичности, надеется, что у пользователей iOS включена функция App Tracking Transparency в пользу ваших измерений, или использует вероятностный фингерпринтинг для заполнения пробелов. Первое находится вне вашего контроля. Второе - из области желаемого. Третье - юридическая ловушка в ЕС.

Работайте с тем, что держится.