Click ID, который раньше спокойно жил 30 дней в сторонней куке, теперь слетает за 24 часа в Safari — и за 7 дней на любом устройстве Apple с включённым Intelligent Tracking Prevention. Отказ Chrome от сторонних кук откладывали, отменяли и переанонсировали уже не раз, но практический урон уже нанесён: Safari и Firefox вместе занимают достаточно большую долю мобильного трафика в гемблинге, нутре, дейтинге и крипте, чтобы чисто «куковая» схема тихо теряла часть конверсий в каждой кампании, каждый день. Это не проблема будущего, к которой стоит готовиться заранее. Это причина, почему ваш дашборд в Facebook и ваша CRM расходятся между собой уже последние два года.
Что на самом деле сломалось в трекинге на куках
Кука браузера никогда не проектировалась как долговечный реестр атрибуции — она создавалась, чтобы запоминать сессию логина. Adtech начал использовать её для click ID просто потому, что это было бесплатно, повсеместно и неплохо работало целое десятилетие. Изменили это три вещи:
- Intelligent Tracking Prevention (ITP) в Safari ограничивает время жизни кук, установленных на клиенте, и — это критично — различает first-party куки, установленные вашим собственным JavaScript, и куки, установленные через HTTP-заголовки ответа. В зависимости от механизма и версии Safari, этот лимит может составлять 7 дней или всего 24 часа.
- Enhanced Tracking Protection (ETP) в Firefox по умолчанию блокирует куки с известных трекинговых доменов и разделяет хранилище отдельно для каждого топ-уровневого сайта, поэтому кука, установленная на одном домене, не читается с другого — это убивает кросс-доменную атрибуцию ещё до того, как она началась.
- Consent-фреймворки (баннеры в стиле GDPR, CMP) означают, что заметная доля пользователей из ЕС и Великобритании отказывается от необязательных кук на уровне браузера, и этот отказ тихо обнуляет любой связанный с куками пиксель для этой сессии — без ошибки, без предупреждения, событие просто никогда не срабатывает.
Добавьте сюда блокировщики рекламы — обычно оценивают в диапазоне 15-30% в зависимости от ГЕО и вертикали, а на десктопном технически подкованном трафике показатель бывает существенно выше — и получается, что чисто клиентский пиксель отчитывается об урезанной, неравномерной выборке вашего реального трафика. Неравномерность здесь важнее самой цифры: пользователи, которые чаще всего блокируют трекеры или сидят в «прожатом» по приватности Safari, распределены по вашим креативам, ГЕО и офферам неравномерно. Ваш дашборд не просто недосчитывает объём — он смещён так, что это трудно увидеть изнутри инструмента.
Почему ваш дашборд разошёлся с реальностью
Вот конкретный механизм. Допустим, пользователь кликает по вашей рекламе, попадает на прелендинг, и click ID записывается в куку клиентским JavaScript на этой первой странице. Через два дня в Safari эта кука уже исчезла — под лимитом ITP для кук, установленных скриптом. Пользователь конвертится — регистрируется, делает депозит, или что там реальное событие в вашей воронке — но страница, которая запускает конверсионный пиксель, уже не может прочитать click ID, потому что читать нечего. Конверсия всё равно происходит. Выручка всё равно приходит в бэк-офис оффера. Просто ваш трекер об этом так никогда и не узнаёт.
Умножьте это на недели трафика — и получите ровно тот паттерн, с которым живёт большинство байеров в гемблинге и нутре: отчётный CPA выглядит хуже реального, креативы, которые «не тянут», убивают, хотя на самом деле с ними всё в порядке, а алгоритм на стороне рекламной платформы оптимизируется под тот тонкий срез конверсий, который реально поймал пиксель — а он, как мы уже говорили, смещён в сторону пользователей, которые не блокируют трекеры и не сидят под ITP. В итоге вы обучаете оптимизацию Facebook на отфильтрованном, нерепрезентативном подмножестве ваших победителей.
Уровень кук против серверного уровня
Решение — не лучшая кука. Решение — полностью убрать источник правды из браузера.
| Кука / клиентский пиксель | Серверный уровень (S2S постбек + CAPI) | |
|---|---|---|
| Переживает Safari ITP | Нет — лимит 24 ч – 7 дней | Да — куки вообще нет |
| Переживает Firefox ETP / разделение хранилища | Нет | Да |
| Переживает блокировщики рекламы | Нет | Да |
| Зависит от открытой вкладки | Да | Нет |
| Обрабатывает отложенные конверсии (депозит спустя дни) | Плохо | Надёжно — срабатывает на реальном изменении статуса на вашем бэкенде |
| Идентификация атрибуции | Только click ID на основе куки | Click ID (first-party) + хешированный PII-матчинг как фолбек |
| Кто контролирует данные | Разделено между клиентскими скриптами и политикой браузера | Полностью под контролем сервера, в вашем трекере |
Ни пиксель, ни CAPI, ни постбек не являются полной заменой двух остальных — смотрите наш разбор в статье Пиксель против Conversions API против S2S-постбека, где показано, как они работают вместе. Но направление одно и то же независимо от вертикали: воспринимайте браузер как подсказку, а сервер — как запись в реестре.
Три опоры трекинга без кук
Серверная доставка событий (CAPI). Вместо того чтобы событие отправлял браузер, ваш бэкенд отправляет его напрямую в Facebook Conversions API — без куки, без блокировщиков рекламы на пути, без зависимости от открытой вкладки. Сегодня это базовая гигиена, а не продвинутая настройка.
S2S-постбек для событий, которые действительно важны. Регистрация или депозит, случающиеся спустя минуты или дни после клика, не должны зависеть от вкладки браузера, которую давно закрыли. Ваша партнёрская сеть или CRM напрямую обращается к серверу вашего трекера в момент изменения статуса — смотрите что такое S2S-постбек на самом деле, если ещё не настроили это.
Устойчивые first-party click ID. Вместо куки, установленной клиентским JavaScript (именно такую ITP уничтожает в первую очередь), click ID путешествует как URL-параметр через каждый шаг воронки — прелендинг, страницу оффера, колбек постбека — и матчится на сервере. Куки вообще не нужно, чтобы ID пережил весь этот путь.
Сквозная передача first-party click ID на практике
Паттерн простой: генерируете click ID в первой точке контакта и передаёте его как query-параметр через каждый редирект и каждую отправку формы в воронке, вместо того чтобы полагаться на куку, которая должна была бы его «запомнить».
https://track.yourdomain.com/click?campaign_id=8841&source=fb&sub1={{ad.id}}&sub2={{adset.id}}Ваш трекер отвечает редиректом на оффер, добавляя собственный сгенерированный click_id:
https://offer.example.com/lp?click_id=a93f7c21e4&sub1=fb-adset-8841Страница оффера переносит click_id дальше — в собственный конверсионный пиксель и, что важнее, в постбек, который она отправляет обратно:
https://track.yourdomain.com/postback?click_id=a93f7c21e4&status=deposit&payout=42.00¤cy=USDВ этой цепочке нет ни одной куки. ID едет в URL весь путь, и ваш трекер сопоставляет постбек с исходным кликом исключительно по этому параметру. Это тот же механизм, против которого ITP и ETP бессильны — это не кука, поэтому нечему истекать или разделяться.
Матчинг по идентификации как резервный уровень
Передача click ID закрывает типовой случай, но ломается, когда пользователь кликает с одного устройства, а конвертится с другого — мобильная реклама, десктопный депозит — или когда цепочка редиректов теряет параметр из-за криво сделанного лендинга. Вот тут пробел и закрывает хешированный PII-матчинг: email, номер телефона и другие идентификаторы хешируются через SHA-256 на клиенте или сервере и отправляются вместе с событием, а движок матчинга Facebook использует это, чтобы сшить конверсию с показом рекламы, который он видел, — даже без click ID или куки в цепочке.
Минимальный payload события CAPI с обоими уровнями выглядит так:
{
"event_name": "Purchase",
"event_time": 1751875200,
"event_id": "a93f7c21e4-deposit",
"action_source": "website",
"user_data": {
"em": ["9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"],
"client_ip_address": "203.0.113.14",
"client_user_agent": "Mozilla/5.0 ..."
},
"custom_data": {
"currency": "USD",
"value": 42.00
}
}Поле event_id важно не меньше, чем данные идентификации: если вы одновременно гоняете браузерный пиксель и серверный CAPI для одной и той же конверсии (а во время миграции так и стоит делать), именно общий event_id позволяет Facebook дедуплицировать эти два события вместо того, чтобы посчитать один депозит как две конверсии.
Типичные ошибки
- Запускать CAPI без дедупликации. Если отправлять одно и то же событие и из браузерного пикселя, и с сервера без совпадающего
event_id, конверсии считаются дважды — это раздувает отчётный объём и тихо искажает математику CPA в сторону, которая выглядит хорошо, пока финансы не спросят, почему не сходится выручка. - Передавать click ID только на первом шаге. Воронка с прелендингом, потом редиректом, потом страницей оффера требует, чтобы параметр
click_idпроносился через каждый без исключения шаг. Потеряйте его один раз — обычно на редиректе, который никто не тестировал, — и каждому следующему постбеку будет не с чем сопоставлять. - Считать хешированный PII-матчинг полной заменой click ID. Матчинг по идентификации вероятностный, а не точный. Он возвращает часть кросс-девайсных конверсий, но не является 1:1 заменой click ID, который пережил весь путь — используйте его как резервный уровень, а не основной механизм.
- Думать, что срок Chrome даёт вам время в запасе. Safari и Firefox уже годами враждебны к сторонним кукам, и в зависимости от вашего микса ГЕО это часто треть трафика или больше уже сейчас — ждать Chrome значит игнорировать браузеры, которые уже вызывают расхождение в цифрах.
- Автооптимизироваться только по сигналу пикселя. Если автоматические правила рекламной платформы читают только загрузку страницы или пиксельные события вместо реальных депозитов ниже по воронке, вы оптимизируетесь под самый тонкий, самый смещённый срез своей воронки — решение в том, чтобы проводить реальный статус конверсии обратно в движок правил, а не только в отчётность.
Миграция с чисто «куковой» схемы
- Проаудируйте, что на самом деле зависит от кук сегодня. Проверьте, хранится ли ваш click ID в куке, установленной на клиенте, или передаётся как URL-параметр. Если первое — это первое, что стоит поменять.
- Перейдите на передачу click ID через URL. Каждый редирект в воронке — от прелендинга к офферу, от оффера к любому промежуточному шагу — должен явно проносить параметр дальше.
- Разверните CAPI параллельно с существующим пикселем, с общим
event_id. Не выдёргивайте пиксель сразу — гоняйте оба в переходный период, чтобы сравнивать количество заматченных событий, прежде чем довериться исключительно серверным цифрам. - Проводите реальные статусы конверсий через S2S-постбек, а не только начальный клик или загрузку страницы — регистрация и депозит (или какое там конечное событие в вашей вертикали) должны каждая вызывать свой постбек.
- Добавьте хешированные PII-поля в payload CAPI как резервный уровень для кросс-девайсных случаев и случаев с потерей параметра.
- Перенаправьте правила автооптимизации на серверно-верифицированные события, а не на нативный пиксельный сигнал, чтобы алгоритм рекламной платформы обучался на том, что действительно произошло дальше по воронке.
FAQ
Значит ли это, что куки теперь полностью бесполезны?
Нет — аккуратно настроенные first-party куки по-прежнему отлично работают для коротких сессий на том же домене. Умерло именно полагание на куку для передачи click ID через домены, дни или устройства. Теперь эту работу выполняют click ID на основе URL и серверный матчинг.
Нужен ли мне браузерный пиксель, если есть CAPI и постбек?
Да, по крайней мере на время миграции. Гоняйте пиксель и CAPI параллельно с общим event_id, чтобы измерять разрыв и дедуплицировать, вместо того чтобы переключиться резко и потерять возможность сравнения.
Соответствует ли хешированный PII-матчинг требованиям GDPR?
Хеширование (обычно SHA-256) — это стандартный механизм, который рекламные платформы требуют именно по этой причине, но само по себе хеширование не делает обработку данных законной — вам всё равно нужно валидное правовое основание и consent-флоу для сбора исходных PII-данных. Проверьте настройки своего CMP — это не технический обход требований о согласии.
Как быстро ждать разницы после миграции?
Серверные конверсии обычно начинают появляться в отчётности платформы в течение дня-двух после корректной настройки, но качество заматченных событий (сколько атрибутируется против скольких логируется как «unmatched») обычно улучшается постепенно, по мере накопления сигнала идентификации — не оценивайте миграцию только по первому дню.
Трекинг на куках деградирует не где-то в далёком будущем — он уже сейчас причина того, что ваш CPA выглядит хуже, чем есть на самом деле, а ваши креативы оценивают по отфильтрованным данным. Трекер DarkCore построен server-side по умолчанию: постбеки маршрутизируются по статусу конверсии напрямую из конфига стрима, пиксели срабатывают только на реальных верифицированных конверсиях вместо загрузок страницы, а контроль качества трафика вместе с аналитикой работают на тех же серверно зафиксированных событиях, которые реально сработали в ваших пикселях и постбеках — а не на том, что случайно пропустил браузер. Если цифры Facebook и цифры вашей CRM расходятся — этот разрыв можно измерить. Пишите нам в https://t.me/DarkCore_service.