Sekimas prieš sutikimą: kas tai yra ir kodėl reguliuotojai tai vertina kaip pažeidimą

Sekimas prieš sutikimą yra mūsų skenerio radinių kategorija. Jis suveikia, kai tarp naujo puslapio įkėlimo pradžios ir momento, kai naudotojas atlieka bet kokį veiksmą sutikimo baneryje, naršyklė išsiunčia vieną ar daugiau tinklo užklausų, kurios neša identifikatorius, perduoda neesminius analitinius duomenis arba nustato neesminius slapukus.

Tai dažniausiai mūsų aptinkamas defektas. Mūsų atlikto 97 000 ES svetainių skenavimo metu didžioji dalis didelės rizikos klasifikacijų buvo sukelta sekimo prieš sutikimą, o ne trūkstamų banerių ar neveikiančių atmetimo mygtukų.

Į ką atkreipia dėmesį skeneris

Detektorius stebi tinklą nuo to momento, kai naršyklė išsiunčia dokumento užklausą, iki vieno iš trijų įvykių:

1. Naudotojas spusteli mygtuką sutikimo baneryje (sutikti, atmesti, nustatymai).
2. Užrašomas išmatuojamas sutikimo būsenos slapukas arba localStorage įrašas.
3. Pasibaigia laukimo laikas (pagal numatymą 8 sekundės) be jokio sutikimo signalo.

Kiekviena užklausa, suveikianti šiame lange, tikrinama pagal tris signalus:

• Žinomas sekimo įrankio pirštų atspaudas. Paskirties domenas, užklausos kelias arba naudingosios apkrovos modelis atitinka įrašą mūsų sekimo įrankių duomenų bazėje. Tai apima Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, X konversijų pikselius ir daugelį kitų.
• Identifikatorių nešanti naudingoji apkrova. Užklausoje yra stabilus kliento identifikatorius (slapukas, pirštų atspaudų maišos kodas arba užklausos parametras, kuris išlieka per kelis puslapius).
• Neesminio slapuko užrašymas. Atsakymas nustato slapuką, kuris pagal klasifikaciją nėra griežtai būtinas svetainės funkcionalumui.

Užtenka vieno iš šių požymių, kad būtų suveiktų radinys. Visi trys kartu yra tipiškas modelis Google Tag Manager konteinerio, kuris suveikia prieš sutikimo vartus.

Teisinis pagrindas, trumpai

Mes nesame jūsų advokatas. Plikos faktinės aplinkybės:

• GDPR Art. 6(1)(a) reikalauja galiojančio teisėto pagrindo asmens duomenų tvarkymui. Neesminiams sekimo įrankiams tai yra sutikimas.
• GDPR Art. 7 nustato galiojančio sutikimo standartą: laisvai duotas, konkretus, informuotas, nedviprasmiškas ir atšaukiamas.
• ePrivacy Directive Art. 5(3) aiškiai reikalauja sutikimo prieš saugant informaciją naudotojo galiniame įrenginyje arba prie jos prisijungiant — tai yra, prieš skaitant ar rašant slapukus ir panašius identifikatorius. Ar konkreti tinklo užklausa prieš sutikimą peržengia pažeidimo ribą, priklauso nuo to, ar ji skaito arba rašo informaciją įrenginyje, ar neša identifikatorius ir ar ją galima pateisinti kaip „griežtai būtiną" — tai klausimai, kuriuos svarsto reguliuotojai.

Nacionaliniai įgyvendinimai skiriasi detalėse. Vokietijos TTDSG (dabar TDDDG) ir Prancūzijos perkėlimas per Loi Informatique et Libertés, įgyvendinamas per CNIL, sukėlė matomiausią vykdymo praktiką. DPAs visoje ES įspėjo apie sekimo prieš sutikimą modelius; konkretūs vykdymo slenksčiai skiriasi pagal jurisdikciją. Pagrindinis principas visur tas pats: pirma sutikimas, paskui sekimo įrankis.

Ką iš tikrųjų padarė reguliuotojai

Trumpa, dalinė chronologija sprendimų, kuriuose sekimas prieš sutikimą buvo centrinis radinys:

• CNIL prieš Google (2020 m. gruodis): 100 mln. EUR už reklaminių slapukų talpinimą google.fr be išankstinio sutikimo.
• CNIL prieš Amazon Europe Core (2020 m. gruodis): 35 mln. EUR už tą patį modelį amazon.fr.

Tai ne vieninteliai atvejai — tai pagrindiniai. Modelis visur nuoseklus: reguliuotojas išmatavo tinklo elgseną ir techninę realybę traktavo kaip lemiamą, nepaisant privatumo politikos teksto.

Skriptai, kurie tai sukelia dažniausiai

Apytiksliai pagal tai, kaip dažnai juos matome kaip pagrindinę priežastį didelės rizikos skenavime:

• Google Tag Manager konteineriai, sukonfigūruoti be sutikimo režimo vartų, arba su sutikimo režimu, neteisingai sukonfigūruotu taip, kad numatytoji būsena yra „granted".
• Meta Pixel, įkeliamas tiesiogiai per <script src>, o ne už sutikimo atgalinio iškvietimo vartų.
• Hotjar sesijų įrašymas, pradėtas prieš uždarant banerį.
• LinkedIn Insight B2B pakartotiniam nukreipimui, ypač agentūrų ir SaaS svetainėse.
• TikTok Pixel vartotojų e. prekyboje.
• Pirmosios šalies analitikos diegimai, kurie skaito navigator savybes arba nustato pirštų atspaudų slapukus prieš bet kokį naudotojo veiksmą.

Bendras veiksnys beveik niekada nėra pats skriptas — tai diegimas. Kiekvienas iš šių tiekėjų skelbia dokumentuotą būdą susieti suveikimą su sutikimo signalu; numatytosios diegimo instrukcijos to dažnai nepamini.

Kaip atrodo švarus skenavimas

Svetainė, kuri išlaiko mūsų patikrą prieš sutikimą, daro vieną iš šių dalykų:

1. Visai neįkelia trečiųjų šalių sekimo, kol nebus duotas sutikimas. Funkciniai slapukai (sesijos, kalbos nuostata, CSRF) yra leidžiami.
2. Įkelia tag manager būsenoje „denied", su visais neesminiais žymekliais už aiškių sutikimo signalų vartų, ir atnaujina būseną per Google Consent Mode v2 arba lygiavertį mechanizmą po naudotojo veiksmo.
3. Įkelia sekimo įrankių trumpinius, kurie neperduoda identifikatorių, kol nebus nustatyta sutikimo žymė.

Mūsų 2026 m. I ketv. 97 000 ES svetainių rinkinyje 68 % turėjo aktyvią sekimo paslaugą prieš bet kokį sutikimo sprendimą. Mažuma svetainių, kurios išlaiko patikrą prieš sutikimą, paprastai turi bendrą profilį: tinklą lange prieš sutikimą dominuoja pats dokumentas, CSS ir šriftų failai bei favicon — niekas, kas neštų identifikatorių iš įrenginio.

Kaip tai pataisyti

Sąžininga versija: nėra jokio trumpesnio kelio. Kiekvieną žymeklį reikia patikrinti, ar jis suveikia prieš nustatant sutikimo signalą. Praktikoje pasitvirtinę žingsniai:

1. Atidarykite svetainę švariame naršyklės profilyje su atidarytomis kūrėjo priemonėmis.
2. Filtruokite tinklą į „third-party" ir perkraukite.
3. Viskas, kas suveikia prieš paspaudžiant banerio mygtuką, yra kandidatas.
4. Kiekvienam kandidatui raskite įkroviklį (paprastai skripto žymė, tag manager gaidukas arba įterptinis fragmentas) ir susiekite jį su sutikimo signalu.
5. Testuokite iš naujo. Kartokite, kol langas prieš sutikimą bus be sekimo įrankių.

Jeigu naudojate sutikimo valdymo platformą, jos „blokuoti iki sutikimo" režimas yra būtinas, bet nepakankamas — daugelis CMP blokuoja tik slapuko užrašymą, o ne užklausą. Article 5(3) iš ePrivacy Directive reikalauja sutikimo prieš saugant informaciją naudotojo įrenginyje arba prie jos prisijungiant (slapukai, local storage, panašūs identifikatoriai). Ar konkreti tinklo užklausa prieš sutikimą aktyvuoja šią pareigą, priklauso nuo to, ką užklausa skaito iš įrenginio arba į jį rašo — tai priklauso nuo faktų.

Pavyzdžiui savo domene paleiskite skenavimą ir pažvelkite į ataskaitos skydelį „tinklas prieš sutikimą". Kiekviena pažeidžianti užklausa išvardyta kartu su jos iniciatoriaus kamieniu, todėl galite ją atsekti iki šaltinio failo savo kodo bazėje.