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.