Проследяване преди съгласие: какво представлява и защо регулаторите го третират като нарушение

Проследяване преди съгласие е клас констатация в нашия скенер. Тя се задейства, когато между началото на ново зареждане на страницата и момента, в който потребителят предприеме каквото и да е действие върху банера за съгласие, браузърът изпраща една или повече мрежови заявки, които носят идентификатори, съдържат несъществени аналитични данни или задават несъществени бисквитки.

Това е най-разпространеният дефект, който откриваме. В нашето сканиране на 97 000 уебсайта в ЕС, мнозинството от класификациите с висок риск бяха предизвикани от проследяване преди съгласие, а не от липсващи банери или неработещи бутони за отказ.

Какво търси скенерът

Детекторът наблюдава мрежата от момента, в който браузърът изпрати заявката за документ, до едно от три събития:

Потребителят натиска бутон на банера за съгласие (приемам, отказвам, настройки).
Записва се измерима бисквитка или запис в localStorage за състоянието на съгласието.
Изтича таймаут (по подразбиране 8 секунди) без какъвто и да е сигнал за съгласие.

Всяка заявка, която се задейства в този прозорец, се проверява за три сигнала:

Известен отпечатък на тракер. Целевият домейн, пътят на заявката или моделът на полезния товар съответстват на запис в нашата база данни за тракери. Това включва Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, X конверсионни пиксели и много други.
Полезен товар, носещ идентификатор. Заявката носи стабилен клиентски идентификатор (бисквитка, отпечатък хеш или query параметър, който оцелява между страниците).
Запис на несъществена бисквитка. Отговорът задава бисквитка, която по класификация не е строго необходима за функционалността на сайта.

Всеки един от тези сигнали е достатъчен, за да задейства констатацията. И трите заедно са типичният модел за контейнер на Google Tag Manager, който се задейства преди портата за съгласие.

Правната рамка, накратко

Ние не сме вашият адвокат. Голите факти:

GDPR Art. 6(1)(a) изисква валидно правно основание за обработка на лични данни. За несъществени тракери това е съгласието.
GDPR Art. 7 определя стандарта за това как изглежда валидното съгласие: свободно дадено, конкретно, информирано, недвусмислено и оттегляемо.
ePrivacy Directive Art. 5(3) изрично изисква съгласие преди съхраняване или достъп до информация на крайното оборудване на потребителя — тоест преди четене или записване на бисквитки и подобни идентификатори. Дали определена мрежова заявка преди съгласие представлява нарушение зависи от това дали тя чете или записва информация на устройството, дали носи идентификатори и дали може да бъде оправдана като „строго необходима“ — това са въпросите, които регулаторите преценяват.

Националните транспозиции се различават в детайли. Германският TTDSG (сега TDDDG) и френската транспозиция чрез Loi Informatique et Libertés, прилагана от CNIL, са произвели най-видимите случаи на правоприлагане. DPAs в ЕС са предупреждавали относно модели на проследяване преди съгласие; конкретните прагове на правоприлагане варират по юрисдикции. Основният принцип е един и същ навсякъде: първо съгласие, после тракер.

Какво всъщност са направили регулаторите

Кратък, частичен преглед на решения, при които проследяването преди съгласие беше централната констатация:

CNIL срещу Google (декември 2020 г.): 100 милиона евро за поставяне на рекламни бисквитки на google.fr без предварително съгласие.
CNIL срещу Amazon Europe Core (декември 2020 г.): 35 милиона евро за същия модел на amazon.fr.

Това не са единствените случаи — те са носещите. Моделът във всички тях е последователен: регулаторът измери поведението на мрежата и третира техническата реалност като определяща, независимо от текста на политиката.

Скриптовете, които най-често го причиняват

В груб ред на това колко често ги виждаме като основна причина при сканиране с висок риск:

Google Tag Manager контейнери, конфигурирани без consent-mode gating, или с неправилно конфигуриран consent-mode, така че състоянието по подразбиране е „предоставено“.
Meta Pixel, зареден директно чрез <script src>, вместо да е зад консент callback.
Hotjar запис на сесия, започнат преди банерът да е затворен.
LinkedIn Insight за B2B ретаргетиране, особено на агенции и SaaS сайтове.
TikTok Pixel на потребителска електронна търговия.
Имплементации на първоличева аналитика, които четат свойства на navigator или задават fingerprinting бисквитки преди каквото и да е действие на потребителя.

Общият фактор почти никога не е самият скрипт — а внедряването. Всеки от тези доставчици публикува документиран начин за gating на задействането при сигнал за съгласие; инструкциите за инсталация по подразбиране обаче често не го споменават.

Как изглежда чисто сканиране

Сайт, който преминава нашата проверка преди съгласие, прави едно от следните неща:

Не зарежда никакво проследяване от трети страни до даване на съгласие. Функционални бисквитки (сесия, езикова настройка, CSRF) са приемливи.
Зарежда tag manager в състояние „отказано“, с всички несъществени тагове зад изрични сигнали за съгласие, и обновява състоянието чрез Google Consent Mode v2 или еквивалентен механизъм след действие на потребителя.
Зарежда стъбове на тракери, които не предават идентификатори до задаване на флага за съгласие.

В нашия корпус от Q1 2026 от 97 000 сайта в ЕС, 68% имаха активна услуга за проследяване преди каквото и да е решение за съгласие. Малцинството сайтове, които преминават проверката преди съгласие, обикновено имат общ профил: мрежата в прозореца преди съгласие е доминирана от самия документ, CSS и шрифтови файлове, и favicon — нищо, което да носи идентификатор от устройството.

Sample scan

78 / 100

High Risk · 23 trackers · pre-consent tracking: yes

See sample report →

Как да го поправите

Честната версия: няма пряк път. Всеки таг трябва да се одитира за това дали се задейства преди задаването на сигнала за съгласие. Стъпки, които работят на практика:

Отворете сайта в чист профил на браузъра с отворени dev tools.
Филтрирайте мрежата към „трети страни“ и презаредете.
Всичко, което се задейства преди да натиснете бутон на банера, е кандидат.
За всеки кандидат намерете loader-а (обикновено script таг, тригер на tag manager или вграден сниппет) и go gate-нете при сигнала за съгласие.
Тествайте отново. Повторете, докато прозорецът преди съгласие не е празен от тракери.

Ако използвате платформа за управление на съгласие, режимът „блокирай до съгласие“ на платформата е необходим, но не достатъчен — много CMP блокират само записа на бисквитката, не и заявката. Article 5(3) от ePrivacy Directive изисква съгласие преди съхраняване или достъп до информация на устройство на потребителя (бисквитки, локално съхранение, подобни идентификатори). Дали конкретна мрежова заявка преди съгласие задейства това задължение зависи от това какво заявката чете от или записва на устройството — въпрос, специфичен за всеки факт.

За работен пример на собствения ви домейн, стартирайте сканиране и погледнете панела „мрежа преди съгласие“ на доклада. Всяка нарушаваща заявка е изброена с нейния initiator stack, така че можете да я проследите до изходния файл във вашата кодова база.