Cookie scanner не знаходить половину трекерів: де ламається
Cookie scanner обходить сторінку як робот: завантажує розмітку, чекає відмальовування, збирає запити до сторонніх доменів.
Проблема в тому, що реальний користувач проходить сторінкою інакше — відкриває модальні вікна, погоджується з банером, гортає стрічку, і лише тоді підтягуються скрипти аналітики, ретаргетингу та чатів.
Сканування cookie за замовчуванням бачить статичний зріз і пропускає все, що підвантажується за дією.
Найчастіша причина — динамічне підвантаження. Скрипт вставляється в DOM після кліку, скролу або таймауту, і на момент обходу його в розмітці ще немає.
Друга — сторонні скрипти, які запускаються не напряму, а через менеджер тегів: сканер бачить один контейнер, а всередині нього десяток тегів, кожен зі своїми cookie. Третя — приховані пікселі та трекери в iframe: вони не віддають себе в основний документ, і обхід їх не фіксує.
Окремо ламають картину кеш і CDN. Сканер отримує закешовану версію сторінки, де частину тегів уже вирізано або, навпаки, залишено від попереднього складання.
Якщо банер згоди підвантажується асинхронно, сканування cookie може взагалі не побачити його на момент перевірки — і у звіті з'явиться «чиста» сторінка, хоча на проді трекери працюють.
Підсумок: сканер показує не реальний набір трекерів, а те, що встигло виконатися за відведений йому час.
Тому коректне налаштування починається не з кнопки «Scan», а з відтворення користувацьких сценаріїв — розбираємо, як це закривається на рівні конфігурації обходу та менеджера тегів.
Що дає коректне налаштування сканера cookie
Налаштування сканера cookie — це не «поставити банер і забути». Сканер обходить сайт за картою сторінок, перехоплює запити до та після взаємодії з інтерфейсом і збирає все, що надходить у браузер: власні скрипти, сторонні пікселі, вбудовані віджети, теги аналітики та реклами.
На виході формується реєстр трекерів, де кожен елемент має джерело, призначення, термін життя та категорію cookie. Якщо карта обходу неповна, частина трекерів залишається поза реєстром — і саме вони стають джерелом претензій під час перевірки відповідності.
Практика показує: на типовому сайті з формами, чатом і вбудованою аналітикою первинний обхід знаходить помітно менше трекерів, ніж їх є насправді. Причина в тому, що частина скриптів підвантажується лише після дії користувача — надсилання форми, відкриття карти, кліку по відео.
Тому сканер налаштовують у режимі сценаріїв: він проходить ключові користувацькі шляхи, фіксує зміни та додає знайдене до реєстру.
Після цього категорії cookie перестають бути формальними — маркетингові, аналітичні та строго необхідні трекери розносяться по своїх групах, а не звалюються в одну.
Окрема робота — зв'язка сканера з механізмом згоди. Поки банер не отримав явну дію користувача, жоден необов'язковий трекер не повинен стартувати; після відмови — не повинен запускатися взагалі.
Це перевіряється не на око, а прогоном: сканер фіксує, які запити надходять до згоди, які після, і чи збігається фактична поведінка із заявленою в політиці. Розбіжність тут — найчастіша причина, через яку перевірка відповідності закінчується приписом.
Вимірюваний ефект від наведеного порядку складається з кількох речей. Повнота реєстру трекерів виходить на рівень, за якого нові скрипти ловляться на етапі додавання, а не через пів року.
Частка коректних згод зростає, бо банер перестає блокувати інтерфейс і водночас не пропускає трекери раніше часу. Швидкість проходження перевірок і аудит cookie займають години замість тижнів — реєстр, категорії та логи згод вивантажуються одним звітом.
Клас претензій знижується: замість спору про факт утечі даних обговорюється процедура, яка вже працює.
Способи розгорнути сканер cookie: порівняння варіантів
Розгортати сканер можна трьома способами, і вибір визначає не «модність» інструмента, а те, хто відповідає за актуальність бази трекерів і як швидко правка потрапляє на прод.
Нижче — порівняння за реальними критеріями: швидкість підключення, контроль над даними, трудовитрати на підтримку та клас обмежень, який ви отримуєте разом із кожним варіантом.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарний сканер | Потрібен швидкий старт і регулярне пересканування без власної інфраструктури | Дані сканування йдуть на бік вендора; глибина обходу обмежена тарифом і лімітом сторінок; кастомні віджети та скрипти, що підвантажуються за дією, ловляться не завжди |
| Власний збирач на стороні сайту | Суворі вимоги до того, де зберігаються дані, або нестандартний стек | Потрібно самим підтримувати обхідник, оновлювати сигнатури трекерів і стежити за оновленнями браузерних політик; вищий поріг входу |
| Гібридна схема | Потрібен контроль над даними плюс готова база трекерів | Складніше в налагодженні: розбіжність між тим, що бачить хмара і що бачить локальний збирач, доводиться розбирати вручну |
Ключове обмеження будь-якого сканера — він бачить тільки те, що встиг завантажити за час обходу.
Скрипти, які підключаються після згоди, при скролі або в модальних вікнах, у базовий звіт не потрапляють, тому підключення скрипта майже завжди доповнюють ручною перевіркою ключових сценаріїв.
Гібридну схему обирають, коли хмарна база закриває 80% типових трекерів, а решта 20% — свої інтеграції, які потрібно контролювати локально. Тоді хмара відповідає за широту охоплення, а власний збирач — за глибину за вашими сценаріями.
Як ми впроваджуємо сканер cookie: етапи робіт
Впровадження починаємо не з банера, а з інвентаризації: сканер обходить сайт за картою розділів і фіксує, які скрипти ставлять cookie, до якого домену звертаються і чи завантажуються вони до надсилання згоди чи після.
На цьому кроці випливають «забуті» лічильники, вбудовані віджети та пікселі, які ставлять сторонні підрядники — саме вони найчастіше ламають коректність банера.
Далі розкладаємо знайдене за категоріями (суворо необхідні, аналітичні, маркетингові, функціональні) і налаштовуємо поведінку платформи: блокування до згоди, повторний запит при оновленні політики, термін зберігання вибору, гео-правила для різних регіонів.
Категорії звіряємо з текстом політики cookie та переліком у ній — розбіжність між банером і документом це перше, що знаходять перевіряльники.
- Аудит сторінок та інвентаризація скриптів: обхід розділів, фіксація джерел cookie та їхнього призначення.
- Звірка з політикою конфіденційності: приводимо перелік cookie та категорії до єдиного вигляду.
- Налаштування категорій і тригерів: що блокується до згоди, що завантажується одразу, як працює відмова.
- Підключення платформи управління згодою та прив'язка до тегів і систем аналітики.
- Перевірка на живому трафіку: тестові сесії, відмова та повторна згода, мобільні браузери, оновлення сторінки.
- Усунення розбіжностей: скрипти, які ставлять cookie в обхід банера, переносимо під управління згодою.
- Передача документації та регламенту супроводу: як додавати нові скрипти і коли переглядати категорії.
Після запуску залишаємо регламент: будь-який новий лічильник або віджет проходить через той самий контроль, а перелік cookie оновлюється при зміні політики.
Так сканер не перетворюється на разове налаштування — він залишається робочим інструментом, який тримає згоди в актуальному стані.
Політики згоди та правила блокування трекерів
Політика згоди — це не текст на сторінці, а виконувана конфігурація: категорії cookie, умови спрацювання банера та правила, за якими скрипти або завантажуються одразу, або чекають на явну дію користувача. Нижче — що замовник отримує на руки і за якими пунктами ми разом проходимо під час приймання.
- Карта трекерів. Повний перелік скриптів, пікселів і тегів на всіх шаблонах: ім'я, призначення, категорія, момент завантаження. Звіряємо з фактичним трафіком, а не з документацією підрядників — розбіжності спливають майже завжди.
- Категорії cookie. Строго необхідні, аналітичні, функціональні, маркетингові. Межі прописані так, щоб спірний тег не можна було віднести до «необхідних» за замовчуванням.
- Правила спрацювання банера. Географія, мова, повторний візит, відкликання згоди. Банер не перекриває контент і не блокує інтерфейс до згоди там, де це ламає сценарій.
- Список винятків. Теги, які завантажуються до згоди: захист від ботів, антифрод, балансування. Кожен виняток обґрунтовано й зафіксовано письмово.
- Журнал згод. Що і коли вибрав користувач, з якою версією політики, з можливістю вивантаження. Це доказ під час перевірки та основа для повторного запиту при зміні політики.
- Регламент оновлення. Хто і як додає новий трекер, як він потрапляє в карту та категорію до викочування в продакшн.
Окремо фіксуємо поведінку при відмові: які скрипти не стартують, що видаляється зі сховища браузера, як відкликання згоди відкочує вже завантажені теги. Без цього політика залишається декларацією, а блокування трекерів — неповним.
Кейс: сканер cookie на сайті з десятками сторонніх скриптів
Що було до
Клієнт прийшов з типовою картиною: на сайті більше десятка сторонніх скриптів — аналітика, рекламні пікселі, чат підтримки, карти, віджети відгуків, — а банер згод показував користувачеві три категорії та збирав позначки «на око».
Автоматичний сканер, запущений у базовому режимі, знаходив 6-7 трекерів: він бачив лише ті, що завантажуються одразу при відкритті сторінки.
Решта підключалися пізніше — після прокрутки, кліку по кнопці або через ланцюжок: один скрипт підтягував другий, той — третій. Такі трекери сканер не фіксував, і в реєстрі їх просто не було.
При цьому частина з них ставила cookie до того, як користувач взагалі щось натиснув у банері, — тобто згода формально не збиралася, а дані вже йшли.
Що змінили
Ми перевели сканер у режим обходу сценаріїв: він проходив сторінками як реальний користувач — відкривав меню, доскролював, надсилав форми, — і на кожному кроці фіксував нові запити та сховища.
Налаштували періодичний перезапуск, щоб ловити скрипти, які підключаються не щоразу, і звели знахідки в єдиний реєстр трекерів із зазначенням категорії, призначення та моменту спрацювання.
Далі перезібрали логіку банера: категорії згод прив'язали до реальних груп трекерів з реєстру, а завантаження кожного скрипта поставили в залежність від отриманої згоди.
Технічно це блокування до явного дозволу — жоден трекер не стартує раніше, ніж користувач підтвердив відповідну категорію. Інструмент — CookieBot, але підхід переноситься на будь-який сканер із підтримкою блокування до згоди.
Що стало
| Метрика | До | Після |
|---|---|---|
| Трекерів у реєстрі | 6-7 | 19 |
| Трекерів до згоди | 4 | 0 |
| Частка сесій із валідною згодою | ~60% | 94% |
| Ручні правки реєстру на місяць | регулярні | за фактом нових скриптів |
Реєстр перестав бути неповним: нові скрипти, які додають маркетологи, тепер потрапляють до нього під час наступного обходу, а не після скарги. Перевірка відповідності звелася до звірки реєстру з фактичними запитами — розбіжностей немає.
Чим відрізняється сканер cookie від менеджера згоди?
Сканер cookie — це інструмент виявлення. Він обходить сторінки сайту як звичайний відвідувач, фіксує, які трекери встигають запуститися до та після взаємодії з банером, і розкладає їх за категоріями: строго необхідні, аналітичні, маркетингові.
На виході виходить інвентар — перелік скриптів із зазначенням джерела, домену, терміну життя та призначення. Далі цей перелік потрібно підтримувати: варто додати нову форму, вбудувати чат або підключити рекламний піксель — і інвентар застаріває, поки сканування не пройде заново.
Менеджер згоди вирішує інше завдання — він керує банером і зберіганням виборів. Саме він показує відвідувачу вікно з категоріями, блокує трекери до отримання згоди, записує, що і коли людина дозволила або відкликала, і передає ці дані далі — в аналітику та в журнал доказів.
Сканер сам по собі банер не малює і згоду не зберігає; менеджер без сканера не знає повного списку того, що повинен блокувати. Це і є різниця інструментів: один відповідає на питання «що у нас стоїть на сайті», другий — «що відвідувач дозволив і як ми це доведемо».
На практиці вони працюють у зв'язці, і порядок важливий. Спочатку сканування дає повну карту трекерів, потім ці дані переносяться в налаштування менеджера згоди — категорії, правила блокування, тексти банера.
Після цього сканування запускається повторно, вже з активним банером: так перевіряють, що до згоди не витікає нічого зайвого, а після — підключається рівно те, що дозволено. Регулярний прогін за розкладом ловить трекери, які додали в обхід процесу.
Для замовника це означає простий розподіл відповідальності: сканер закриває повноту та актуальність інвентарю, менеджер — коректність керування банером і збереження виборів.
Коли обидва налаштовані та пов'язані, перевірка показує, що жоден трекер не стартує раніше згоди, а журнал виборів готовий до запиту в будь-який момент.
Часті технічні сумніви щодо налаштування сканера
Сканер cookie поводиться передбачувано лише на статичних сторінках із серверним рендерингом.
Щойно з'являються односторінкові застосунки, відкладене підвантаження скриптів і агресивний кеш на CDN, картина змінюється: частина скриптів встановлюється вже після першого проходу, і сканер їх не бачить. Нижче — розбір ситуацій, з якими стикаємося найчастіше.
Вже розгорнуто інший сканер — переписувати все заново?
Ні. Спочатку знімаємо поточну конфігурацію: які категорії заведено, за якими селекторами розмічаються скрипти, як влаштовано банер згоди і куди надходить журнал. Якщо розмітка коректна, переносимо її на нову платформу і змінюємо лише те, що не покриває вимоги. Повна заміна потрібна, коли категорії не розділені або згода не блокує скрипти до її отримання.
Односторінковий застосунок — сканер бачить не всі скрипти. Що робити?
Проблема в тому, що сканер обходить URL, а застосунок підвантажує модулі в міру навігації. Налаштовуємо обхід за реальними маршрутами, а не за однією точкою входу, і додаємо ручну розмітку для скриптів, які встановлюються за дією користувача.
Після цього проганяємо сценарії: перехід за розділами, відкриття форм, авторизація — і звіряємо, що кожен знайдений скрипт потрапив у потрібну категорію.
CDN і кеш віддають стару версію банера. Як синхронізувати?
Сканер і банер мають оновлюватися однією хвилею. Скидаємо кеш на CDN після публікації конфігурації, версіонуємо сам скрипт банера і перевіряємо, що на всіх вузлах віддається актуальна збірка.
Інакше виникає розрив: сканер уже знає про новий скрипт, а відвідувачу надходить стара розмітка без потрібної категорії.
Як часто запускати повторне сканування?
Постійно, а не разово. Ставимо регулярний обхід за розкладом і додатково — після кожного релізу, бо новий код майже завжди тягне за собою новий скрипт.
Результат кожного проходу порівнюємо з попереднім: з'явилися нерозмічені cookie — одразу в роботу, а не через місяць, коли це спливе на перевірці.
Обговоримо ваше завдання зі сканером cookie
Розмову починаємо не з презентації, а з вашого сайту: скільки доменів і піддоменів, на чому зібраний фронтенд, як влаштована видача згод і що вже налаштовано в поточному сканері. Цього достатньо, щоб зрозуміти обсяг і не гадати за скриншотами.
Далі робота йде етапами, і на кожному ви бачите результат, а не звіт про зайнятість:
- Розбір поточного стану — які скрипти та трекери реально завантажуються, що з них до згоди користувача, де сканер пропускає сторонні вставки.
- Звірка з вимогами — які категорії згод потрібні за вашою юрисдикцією та моделлю роботи з даними, що вже покрито, а що ні.
- Оцінка робіт — обсяг правок у розмітці та тегах, точки інтеграції зі сканером, трудовитрати за кожним блоком.
- План впровадження — послідовність кроків, що робимо на тестовому контурі, що викочуємо на прод і в якому порядку.
- Налаштування та підключення — банер, категорії, правила блокування до згоди, синхронізація із системами аналітики та реклами.
- Перевірка — прогін сканером, ручна перевірка ключових сценаріїв, звірка журналу згод із фактичною поведінкою скриптів.
- Передача та супровід — доступи, документація з налаштувань, регламент оновлення при додаванні нових сервісів.
Підтримка сканера — окрема частина роботи: правила та категорії застарівають, коли на сайт додають новий сервіс або змінюється розмітка. Ми фіксуємо, хто і як вносить зміни, щоб банер не розходився з реальним набором скриптів.
Опишіть завдання: адреса сайту, поточний сканер і що турбує — пропущені скрипти, застарілий банер, відсутність журналу згод. Повернемося з оцінкою та планом робіт.
