Атрибуция без cookie в арбитраже: что реально работает

Почему браузерные cookie перестали работать

Safari первым внедрил Intelligent Tracking Prevention ещё в 2017 году, Firefox подхватил с Enhanced Tracking Protection. Google планировал убрать сторонние cookie из Chrome через инициативу Privacy Sandbox, но в 2025 году развернулся: сторонние cookie в Chrome работают до сих пор, а Sandbox-API-замены сворачиваются. Ограничений Safari и Firefox уже достаточно, чтобы сокращать окно, в котором браузерный пиксель успевает зафиксировать конверсию.

Регуляторы добавили давления с другой стороны. GDPR в Евросоюзе и законы штатов в США требуют явного согласия до выполнения любого трекинг-скрипта. Если посетитель отклоняет баннер, пиксель не загружается и конверсия уходит в «неатрибутированные».

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

Трекинг на стороне сервера как основа

Классический пиксель зависит от цепочки: браузер выполняет JavaScript, сохраняет cookie, отправляет запрос на сервер платформы. Любое звено рвётся - адблок, отключённые cookie, таймаут сети - и конверсия пропадает.

Серверный трекинг убирает браузер из критического пути. Бэкенд приложения записывает событие и передаёт его напрямую в endpoint платформы через server-to-server соединение. Посетителю не нужно загружать скрипт или принимать cookie, чтобы событие зарегистрировалось.

Схематично поток выглядит так:

Пользователь оформляет заказ
  -> Бэкенд фиксирует покупку
  -> Бэкенд отправляет payload в API платформы
  -> Платформа матчит конверсию с кликом

В payload обычно входят хешированный email или телефон, ID транзакции, таймстемп и сумма. Матчинг происходит на стороне платформы по этим идентификаторам, а не по браузерному cookie. Подробнее о предотвращении дублей - в статье event_id и дедупликация.

Серверный трекинг фиксирует конверсионные данные на вашей инфраструктуре и передаёт их в рекламные платформы через API, минуя браузерные ограничения.

API рекламных платформ вместо пикселей

Meta Conversions API (CAPI)

Отправка событий напрямую с бэкенда в Meta исключает зависимость от JavaScript-тега пикселя. API принимает стандартные события (Purchase, Lead, CompleteRegistration) и кастомные, каждое с параметрами user_data, хешированными SHA-256 для матчинга.

Дедупликация работает через общий event_id. Если и браузерный пиксель, и CAPI срабатывают для одной транзакции, Meta оставляет одну запись. Команды, переходящие на схему без cookie, могут отключить браузерный пиксель и работать только через CAPI.

{
  "event_name": "Purchase",
  "event_time": 1719312000,
  "event_id": "order-8842",
  "user_data": {
    "em": ["hashed_email_sha256"],
    "ph": ["hashed_phone_sha256"]
  },
  "custom_data": {
    "currency": "USD",
    "value": 49.99
  }
}

Полная спецификация - в официальной документации Conversions API. Если льёте платный трафик через Meta, прогоните текущую настройку по чек-листу аудита Facebook Pixel, чтобы браузерный фолбэк продолжал работать там, где согласие получено.

TikTok Events API

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

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

Google Consent Mode v2

Подход Google не заменяет cookie, а регулирует объём собираемых сигналов в зависимости от выбора посетителя. При отказе от согласия теги срабатывают, но без идентификаторов; Google досчитывает конверсии статистически на агрегированных данных согласившихся пользователей.

Арбитражники выигрывают за счёт модельных конверсий, которые заполняют пробел без сбора first-party данных. Компромисс - гранулярность: вместо пользовательских путей вы получаете оценки на уровне кампании. Для трафика из EEA включённый Consent Mode v2 стал обязательным условием конверсионного трекинга в Google Ads.

Практическая сборка стека атрибуции

Начните с единой точки сбора. Все конверсионные события - покупки, лиды, регистрации - должны проходить через один бэкенд-endpoint или контейнер серверного GTM. Это даёт единую схему данных и одно место для добавления новых платформ.

Далее подключайте API платформ по приоритету:

1. Meta CAPI для трафика из Facebook и Instagram.
2. Events API для кампаний в TikTok.
3. Импорт офлайн-конверсий Google Ads для поиска и YouTube.
4. Постбэк-URL партнёрских сетей для расчётов с аффилиатами.

Затем наслоите обработку согласия. Для трафика из EEA и UK проверяйте строку согласия до прикрепления идентификаторов к payload. При отсутствии согласия отправляйте событие с ID транзакции и суммой, чтобы платформа применила модельную атрибуцию.

Наконец, настройте сверку. Еженедельно сравнивайте конверсии из кабинетов платформ с базой заказов на бэкенде. Расхождение шире 5% обычно указывает на ошибку схемы, хеширования или потерянный event_id.

Командам, которым нужна автоматическая маршрутизация между платформами без поддержки отдельных интеграций, подойдёт MOST - он берёт на себя доставку, ретраи и дедупликацию. Для лёгкой настройки на одной платформе используйте Pixel Activator: ручная активация пикселя без полноценного серверного пайплайна.

Sources