tools · 4 min read

First-party tracking без cookies: как сохранить управляемую атрибуцию

First-party tracking часто продают как «новый cookie-хакинг». Это неверная постановка задачи. Смысл подхода не в том, чтобы спрятать идентификатор от браузера или обойти согласие пользователя, а в том, чтобы собирать разрешённые события на вашем домене и передавать их партнёру понятным, проверяемым способом.

Для арбитражника это особенно важно в связке с несколькими переходами: объявление, прелендинг, форма, подтверждение заявки и финальный постбек могут проходить через разные системы. Если каждая система считает конверсию по-своему, отчёт выглядит точным только на экране.

Начните не с cookies, а с карты событий

До выбора трекера выпишите путь пользователя. Например: рекламное объявление → статья-сравнение на вашем домене → переход в оффер → заявка → подтверждение рекламодателем. Для каждого шага зафиксируйте:

событие и его источник;
домен, на котором оно происходит;
идентификатор клика или сессии;
момент, когда требуется согласие;
систему, которая считается источником правды.

Такой список сразу показывает, что нужно измерять. Просмотр страницы и клик можно записать в аналитике сайта, а подтверждённую выплату — принять из партнёрской сети через postback. Не называйте оба события «конверсией»: это разные этапы воронки.

Удобный стартовый формат — таблица event_name, event_time, click_id, order_id, value, currency, consent_state. Не передавайте в неё лишние персональные данные. Хеширование поля не отменяет обязанностей по правовому основанию, цели обработки и сроку хранения.

Что именно даёт first-party слой

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

Third-party cookie — лишь один из способов связать пользователя с рекламной системой, и его доступность зависит от браузера, настроек и контекста. First-party cookie тоже имеет срок жизни, область действия и ограничения. Поэтому полезнее строить систему вокруг событий и серверных подтверждений, а cookie использовать только там, где это законно и действительно нужно.

Практическая схема для партнёрской воронки

1. Дайте клику собственный идентификатор

Создайте click_id на входе в воронку и храните его в разрешённом first-party контексте. Передавайте его в ссылку на оффер только в том виде, который согласован с партнёрской сетью. Не кладите в URL имя, email или телефон.

2. Отделите браузерное событие от серверного

Браузер может сообщить о просмотре или клике, но итоговую заявку лучше подтверждать на сервере. Сервер получает ответ от формы или сети, проверяет order_id, сумму и статус, а затем отправляет событие в рекламную платформу через её официальный API. Это не «обход блокировки»: событие всё равно должно соответствовать настройкам согласия и правилам платформы.

Google описывает Enhanced Conversions как передачу хешированных пользовательских данных при соблюдении требований, а Meta и TikTok документируют собственные серверные события. Используйте официальные схемы полей, дедупликацию и тестовые события, а не универсальный самодельный payload.

3. Введите единый журнал событий

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

4. Проверьте расхождения до запуска бюджета

Сделайте небольшую тестовую воронку с несколькими искусственными событиями. Сравните клики в трекере, заявки в CRM, подтверждённые конверсии сети и принятые события рекламной платформы. Цель проверки — не добиться одинаковых чисел, а понять каждое расхождение.

Атрибуция: не обещайте себе невозможную точность

Если пользователь увидел объявление, вернулся из письма и оформил заявку напрямую, у вас есть несколько сигналов, а не «истинный» ответ, какой канал заслуживает всю выплату. Выберите модель заранее: last non-direct click, позиционная модель или правило, согласованное с рекламодателем. Храните первичный click ID и не перезаписывайте его молча при каждом новом визите.

Для повторных покупок особенно важно различать первичную атрибуцию и статус клиента. Email или номер телефона могут помочь сопоставить запись только при законном основании и в допустимом формате. First-party tracking не отменяет требования к согласию, уведомлению, удалению данных и региональным правилам.

Практические материалы о структуре партнёрских воронок можно найти в блоге Affiliate Business Club на русском. Если вы сравниваете инструменты, сначала описывайте события и ограничения, а уже потом выбирайте трекер.

Часто задаваемые вопросы

Чем first-party tracking отличается от server-side tracking?

First-party описывает контекст данных: событие связано с доменом, который посещает пользователь. Server-side описывает способ передачи: сервер отправляет событие напрямую в другую систему. Они могут использоваться вместе, но не являются синонимами.

Можно ли использовать first-party tracking без согласия пользователя?

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

Что проверять, если в трекере больше конверсий, чем в рекламном кабинете?

Сверьте окно атрибуции, часовой пояс, дедупликацию, статус события, обязательные параметры и согласие пользователя. Затем сопоставьте несколько конкретных click_id, а не только общие суммы. Так вы увидите, где именно расходятся определения конверсии.

Sources

Материал подготовлен редакцией Affiliate Business Club.