Izsekošana pirms piekrišanas: kas tā ir un kāpēc regulatori to uzskata par pārkāpumu

Izsekošana pirms piekrišanas ir atklājumu klase mūsu skenerī. Tā aktivizējas, kad laikā starp jaunas lapas ielādes sākumu un brīdi, kad lietotājs veic jebkādu darbību piekrišanas banerī, pārlūks nosūta vienu vai vairākus tīkla pieprasījumus, kas pārnes identifikatorus, satur nebūtiskas analītikas slodzes vai iestata nebūtiskus sīkdatnes.

Tas ir visbiežāk atklājamais defekts. Mūsu 97 000 ES tīmekļvietņu skenēšanā lielākā daļa augsta riska klasifikāciju tika izraisītas ar izsekošanu pirms piekrišanas, nevis ar trūkstošiem baneriem vai nestrādājošām noraidīšanas pogām.

Ko skeneris meklē

Detektors vēro tīklu no brīža, kad pārlūks izdod dokumenta pieprasījumu, līdz vienam no trim notikumiem:

1. Lietotājs noklikšķina uz pogas piekrišanas banerī (piekrist, noraidīt, iestatījumi).
2. Tiek rakstīta izmērāma piekrišanas stāvokļa sīkdatne vai localStorage ieraksts.
3. Iestājas taimauts (pēc noklusējuma 8 sekundes) bez jebkāda piekrišanas signāla.

Katrs pieprasījums, kas šajā logā tiek aktivizēts, tiek pārbaudīts pēc trim signāliem:

• Zināms izsekotāja pirkstu nospiedums. Mērķa domēns, pieprasījuma ceļš vai slodzes raksts atbilst ierakstam mūsu izsekotāju datubāzē. Tas ietver Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, X konversijas pikseļus un daudzus citus.
• Identifikatoru nesoša slodze. Pieprasījums satur stabilu klienta identifikatoru (sīkdatni, pirkstu nospiedumu hash vai vaicājuma parametru, kas saglabājas starp lapām).
• Nebūtiskas sīkdatnes rakstīšana. Atbilde iestata sīkdatni, kas pēc klasifikācijas nav stingri nepieciešama vietnes funkcionalitātei.

Pietiek ar vienu no šiem, lai aktivizētu atklājumu. Visi trīs kopā ir tipisks raksts Google Tag Manager konteineram, kas aktivizējas pirms piekrišanas vārtiem.

Juridiskais ietvars, īsi

Mēs neesam jūsu jurists. Kailie fakti:

• GDPR Art. 6(1)(a) pieprasa spēkā esošu tiesisku pamatu personas datu apstrādei. Nebūtiskiem izsekotājiem tā ir piekrišana.
• GDPR Art. 7 nosaka standartu derīgai piekrišanai: brīvi sniegta, konkrēta, informēta, nepārprotama un atsaucama.
• ePrivacy Directive Art. 5(3) īpaši pieprasa piekrišanu pirms informācijas glabāšanas vai piekļuves tai lietotāja gala iekārtā — tas ir, pirms sīkdatņu un līdzīgu identifikatoru lasīšanas vai rakstīšanas. Tas, vai konkrēts tīkla pieprasījums pirms piekrišanas šķērso pārkāpuma robežu, ir atkarīgs no tā, vai tas lasa vai raksta informāciju ierīcē, vai tas pārnes identifikatorus un vai to var attaisnot kā „stingri nepieciešamu" — šos jautājumus ir izvērtējuši regulatori.

Nacionālās īstenošanas atšķiras detaļās. Vācijas TTDSG (tagad TDDDG) un Francijas transpozīcija ar Loi Informatique et Libertés, ko īsteno CNIL, ir radījušas visredzamāko izpildes praksi. DPAs visā ES ir brīdinājušas par izsekošanas pirms piekrišanas rakstiem; konkrēti izpildes sliekšņi atšķiras atkarībā no jurisdikcijas. Pamatprincips visur ir vienāds: vispirms piekrišana, tad izsekotājs.

Ko regulatori faktiski ir izdarījuši

Īsa, daļēja laika skala lēmumiem, kuros izsekošana pirms piekrišanas bija galvenais atklājums:

• CNIL pret Google (2020. gada decembris): 100 miljoni EUR par reklāmas sīkdatņu ievietošanu google.fr bez iepriekšējas piekrišanas.
• CNIL pret Amazon Europe Core (2020. gada decembris): 35 miljoni EUR par to pašu rakstu amazon.fr.

Tie nav vienīgie gadījumi — tie ir galvenie. Raksts tajos ir konsekvents: regulators izmērīja tīkla uzvedību un tehnisko realitāti uzskatīja par izšķirošu, neatkarīgi no politikas teksta.

Skripti, kas to visbiežāk izraisa

Aptuveni tādā secībā, cik bieži mēs tos redzam kā galveno cēloni augsta riska skenējumā:

• Google Tag Manager konteineri, kas konfigurēti bez piekrišanas režīma vārtiem vai ar nepareizi konfigurētu piekrišanas režīmu, kur noklusējuma stāvoklis ir „granted".
• Meta Pixel, kas tiek ielādēts tieši caur <script src>, nevis aiz piekrišanas atzvanīšanas vārtiem.
• Hotjar sesiju ierakstīšana, kas sākta pirms banera aizvēršanas.
• LinkedIn Insight B2B retargetingam, īpaši aģentūru un SaaS vietnēs.
• TikTok Pixel patērētāju e-komercijā.
• Pirmās puses analītikas ieviešanas, kas lasa navigator īpašības vai iestata pirkstu nospiedumu sīkdatnes pirms jebkādas lietotāja darbības.

Kopīgais faktors gandrīz nekad nav pats skripts — tā ir izvietošana. Katrs no šiem piegādātājiem publicē dokumentētu veidu, kā aktivizēšanu saistīt ar piekrišanas signālu; taču noklusējuma instalēšanas instrukcijas to bieži nepiemin.

Kā izskatās tīrs skenējums

Vietne, kas iztur mūsu pirms piekrišanas pārbaudi, veic vienu no šīm darbībām:

1. Neielādē nekādu trešo pušu izsekošanu, kamēr nav saņemta piekrišana. Funkcionālas sīkdatnes (sesija, valodas preference, CSRF) ir pieņemamas.
2. Ielādē tag manager stāvoklī „denied", ar visām nebūtiskām birkām aiz skaidriem piekrišanas signāliem, un pēc lietotāja darbības atjaunina stāvokli caur Google Consent Mode v2 vai līdzvērtīgu mehānismu.
3. Ielādē izsekotāju saīsinājumus, kas nepārnes identifikatorus, kamēr nav iestatīts piekrišanas karodziņš.

Mūsu 2026. gada 1. ceturkšņa 97 000 ES vietņu korpusā 68 % bija aktīvs izsekošanas pakalpojums pirms jebkāda piekrišanas lēmuma. Mazākums vietņu, kas iztur pirms piekrišanas pārbaudi, parasti ir ar kopīgu profilu: tīklu pirms piekrišanas logā dominē pats dokuments, CSS un fontu faili un favicon — nekas, kas pārnes identifikatoru no ierīces.

Kā to labot

Godīgā versija: nav īsceļa. Katra birka ir jāpārbauda attiecībā uz to, vai tā aktivizējas pirms piekrišanas signāla iestatīšanas. Praksē efektīvi soļi:

1. Atveriet vietni tīrā pārlūka profilā ar atvērtiem izstrādātāja rīkiem.
2. Filtrējiet tīklu uz „third-party" un pārlādējiet.
3. Viss, kas aktivizējas pirms jūs noklikšķināt banera pogu, ir kandidāts.
4. Katram kandidātam atrodiet ielādētāju (parasti skripta birka, tag manager palaidējs vai inline fragments) un sasaistiet to ar piekrišanas signālu.
5. Pārtestējiet. Atkārtojiet, līdz logs pirms piekrišanas ir tukšs no izsekotājiem.

Ja izmantojat piekrišanas pārvaldības platformu, tās „bloķēt līdz piekrišanai" režīms ir nepieciešams, bet nav pietiekams — daudzi CMP bloķē tikai sīkdatnes rakstīšanu, nevis pieprasījumu. Article 5(3) no ePrivacy Directive pieprasa piekrišanu pirms informācijas glabāšanas vai piekļuves tai lietotāja ierīcē (sīkdatnes, local storage, līdzīgi identifikatori). Tas, vai konkrēts tīkla pieprasījums pirms piekrišanas aktivizē šo pienākumu, ir atkarīgs no tā, ko pieprasījums lasa no ierīces vai raksta tajā — tas ir no faktiem atkarīgs jautājums.

Lai redzētu piemēru savā domēnā, palaidiet skenēšanu un apskatiet atskaites paneli „tīkls pirms piekrišanas". Katrs pārkāpjošais pieprasījums ir uzskaitīts ar tā iniciatora kaudzi, lai jūs varētu to izsekot līdz pirmkoda failam savā kodu bāzē.