Автоматично блокиране на скриптове: как работи блокирането преди съгласие
Автоматичното блокиране на скриптове (наричано още блокиране преди съгласие или авто-блокиране) предотвратява изпълнението на несъществени скриптове, докато потребителят не даде съгласие. Това е правно изискване съгласно член 5(3) от Директивата за електронна поверителност (ePrivacy): върху устройството на потребителя не могат да се поставят бисквитки или технологии за проследяване без предварително информирано съгласие, освен ако не са строго необходими за поисканата от потребителя услуга.
Без автоматично блокиране уебсайт, който зарежда Google Analytics, Facebook Pixel или какъвто и да е маркетингов скрипт на трета страна, ще зададе бисквитки и ще събере данни, преди потребителят изобщо да е имал възможност да направи избор относно съгласието. Това е нарушение на съответствието, независимо дали се показва банер за съгласие.
Защо ръчното маркиране на скриптове не е достатъчно
Традиционният подход към зареждането на скриптове въз основа на съгласие изисква разработчиците да маркират ръчно всеки скрипт на сайта. Всеки скрипт трябва да бъде модифициран така, че да не се зарежда по подразбиране, а след това да се активира условно, когато потребителят даде съгласие за съответната категория. Това обикновено включва промяна на type="text/javascript" на type="text/plain" и добавяне на data атрибут, указващ категорията на съгласие.
Този подход има сериозни проблеми:
- Всеки нов скрипт, добавен към сайта, трябва да бъде маркиран ръчно. Ако маркетингов екип добави нов пиксел за проследяване чрез мениджър на тагове, той се задейства без съгласие, освен ако някой не се сети да конфигурира правилото за блокиране.
- Скриптовете на трети страни често зареждат допълнителни скриптове динамично. Блокирането на родителския скрипт не блокира непременно дъщерните скриптове, които той би заредил.
- Вградените в HTML на страницата inline скриптове не могат лесно да бъдат прихванати.
- Подходът е нестабилен. Един-единствен пропуснат скрипт означава несъответстващо на изискванията събиране на данни.
Как работи автоматичното блокиране
Платформа за управление на съгласието с автоматично блокиране прилага различен подход. Вместо да изисква от разработчиците да маркират отделните скриптове, CMP прихваща цялото зареждане на скриптове на ниво браузър и блокира всичко, което не е строго необходимо.
Процесът протича по следния начин:
- CMP се зарежда като първи скрипт в секцията
<head>на страницата, преди всякакви други скриптове. - Той прихваща механизмите за зареждане на скриптове на браузъра, включително
document.createElement('script'), изпълнението на inline скриптове и динамично инжектираните скриптове. - Всеки скрипт се проверява спрямо база данни за класификация. Скриптовете от известни домейни за анализ, реклама и социални медии се идентифицират и категоризират.
- Скриптовете, класифицирани като несъществени, се задържат в опашка. Те не се изпълняват, не задават бисквитки и не правят мрежови заявки.
- Когато потребителят даде съгласие за конкретна категория, задържаните скриптове в тази категория се освобождават и им се позволява да се изпълнят нормално.
- Ако потребителят откаже дадена категория, скриптовете в нея остават блокирани за времетраенето на сесията.
Какво се блокира
Автоматичното блокиране обикновено класифицира скриптовете в четири категории, съответстващи на стандартните категории за съгласие за бисквитки:
| Категория | Примери | Блокирани преди съгласие |
|---|---|---|
| Строго необходими | Платежни процесори, удостоверяване, управление на сесии, самият CMP | Не (винаги разрешени) |
| Анализ | Google Analytics, Hotjar, Matomo, Plausible | Да |
| Маркетинг | Google Ads, Facebook Pixel, LinkedIn Insight, TikTok Pixel | Да |
| Предпочитания | Езикови предпочитания, персонализиране на потребителския интерфейс, инструменти за A/B тестване | Да |
Проблемът с времето на зареждане
За да работи правилно автоматичното блокиране, CMP трябва да е първият скрипт, който се зарежда на страницата. Ако някакъв несъществен скрипт се зареди преди CMP, той ще се изпълни без съгласие. Ето защо тагът на CMP скрипта не трябва да използва атрибутите defer или async и трябва да се появи преди всеки друг скрипт в секцията <head>.
Това е същата архитектура, използвана от всяка съответстваща на изискванията CMP: Cookiebot, OneTrust, CookieYes и Passiro изискват синхронно зареждане като първи скрипт в главата на документа.
Взаимодействие с Google Consent Mode
Автоматичното блокиране на скриптове работи заедно с Google Consent Mode v2. Докато Consent Mode коригира поведението на собствените тагове на Google при отказано съгласие (превключвайки към измерване без бисквитки), автоматичното блокиране изцяло предотвратява изпълнението на всички несъществени скриптове.
Двата механизма се допълват: Consent Mode се справя елегантно с таговете на Google (позволявайки моделирани реализации), докато авто-блокирането се справя с всичко останало (пиксели на трети страни, социални джаджи, рекламни скриптове от доставчици извън Google).
Автоматично блокиране и Passiro
Passiro включва автоматично блокиране на скриптове в своя безплатен джаджа за съгласие. Когато скриптът на Passiro се зареди, той идентифицира и блокира несъществените скриптове, преди те да могат да се изпълнят. Не се изисква ръчно маркиране на скриптове.
Базата данни за класификация е изградена върху общностния блокиращ списък EasyPrivacy (GPL-3.0), който обхваща ~4900 домейна за проследяване, анализ и реклама и се обновява ежедневно. Това е значително по-обширно от собствените курирани списъци, използвани от повечето търговски CMP — Cookiebot, OneTrust и други обикновено разчитат на бази данни с порядък по-малки.
В комбинация с IAB TCF v2.3 и Google Consent Mode v2, автоматичното блокиране гарантира, че не се събират данни преди даване на съгласие, отговаряйки на изискванията на член 5(3) от ePrivacy и член 6 от GDPR.
Вашият уебсайт съответства ли на правилата за бисквитки?
Сканирайте уебсайта си безплатно и намерете всички бисквитки за минути.
Сканирайте бисквитките си безплатно