Sīkdatņu banera audits: vai tas tiešām bloķē neobligātos skriptus? 7 tipiskās kļūdas

Poga “Noraidīt” vēl nepierāda, ka izsekošana apstājas. Praktisks ceļvedis banera pārbaudei ar Network, Application, Consent Mode un atkārtotiem testiem.

Jūs atverat vietni jaunā pārlūka profilā, nospiežat “Noraidīt” un redzat, ka sīkdatņu paziņojums pazūd; no malas viss šķiet kārtībā, taču sīkdatņu banera audits sākas tieši šajā brīdī: vai pirms klikšķa jau notika pieprasījums uz reklāmas platformu, vai atbildē bija mēģinājums iestatīt identifikatoru, kas palika pārlūka krātuvē, un vai tagi pēc atteikuma saņēma pareizo piekrišanas stāvokli? Poga ir tikai vadības panelis, un auditam jāpārbauda, vai zem tā tiešām savienoti vadi, jo CMP var vēl nebūt iestatījis noklusējumu brīdī, kad tagu pārvaldnieks jau izpilda pirmo noteikumu.

Banera vizuāla apskate vai automātiska skenera zaļš ķeksītis nepasaka, kas noticis ielādes pirmajās sekundēs, un arī neatklāj, kurš skripts darbību izraisīja, kāds piekrišanas stāvoklis tam tajā brīdī bija pieejams un vai redzamais gala stāvoklis atbilst visai iepriekšējai notikumu secībai. Tāpēc vienā laika līnijā salīdzinām vietnes uzvedību pirms izvēles, pēc visu neobligāto kategoriju noraidīšanas, pēc atļaušanas un pēc vēlākas piekrišanas atsaukšanas, katrā stāvoklī vērtējot tīkla pieprasījumus, atbilžu galvenes, sīkdatnes, localStorage un citas krātuves, piekrišanas signālu secību un konkrētās darbības iniciatoru. Tikai šāds salīdzinājums atšķir korektu konfigurāciju no banera, kas vienkārši aizveras.

Šis ir tehnisks raksts, nevis individuāls juridisks atzinums: tas rāda, kā savākt pārbaudāmus faktus un neizdarīt secinājumus, kurus pierādījumi neattaisno. Ja vietne izmanto Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, iegultus video, čata logu vai citus trešo pušu rīkus, vienā ekrānā redzamais sīkdatņu saraksts būs tikai daļa no kopainas, tādēļ būtiskais jautājums nav “vai baneris ir uzstādīts?”, bet gan “ko vietne izdara katrā lietotāja izvēles brīdī?”.

Ko sīkdatņu banera audits pārbauda — un ko tas neapliecina

Audits pārbauda tehnisko piekrišanas ķēdi no pirmā lapas pieprasījuma līdz stāvokļa maiņai pēc lietotāja izvēles, taču to nevar novērtēt tikai pēc gala stāvokļa, jo sākotnējā ielādes secība var jau būt palaidusi darbību, kuru vēlāk aizvērts baneris vairs neatceļ. Tvērumā ietilpst skriptu ielādes secība, tīkla savienojumi, sīkdatnes un citas krātuves, CMP jeb piekrišanas pārvaldības platformas signāli, Google Consent Mode konfigurācija, kategoriju darbība un iespēja vēlāk mainīt izvēli; rezultāts ir pierādījumu kopums par sīkdatņu un izsekošanas slāni, nevis sertifikāts, ka visa organizācijas personas datu apstrāde ir juridiski nevainojama.

Juridiski jānošķir divi savstarpēji saistīti līmeņi: ePrivacy direktīvas 5. panta 3. punkts attiecas uz informācijas glabāšanu lietotāja galaiekārtā un piekļuvi tajā jau esošai informācijai, un šis tehniskais tvērums nav ierobežots ar failiem, kuru nosaukumā ir “cookie”. VDAR kļūst būtisks, ja tiek apstrādāti personas dati, turklāt tas nosaka arī derīgas piekrišanas kvalitāti un atsaukšanas principus, tāpēc viena režīma tehniska pārbaude neaizstāj otra režīma juridisku izvērtējumu. Audita atskaitē abus līmeņus nosaucam atsevišķi, lai novērots tehniskais fakts netiktu pasniegts kā plašāks juridisks secinājums.

Datu valsts inspekcija skaidro, ka neobligāto rīku aktivizēšana pirms izvēles un nefunkcionāla atteikšanās nav brīva piekrišana, tomēr arī kategorijas nosaukums “necessary” pats par sevi neko nepierāda. Obligāti nepieciešamais izņēmums jāvērtē šauri: konkrētajai darbībai jābūt vajadzīgai lietotāja nepārprotami pieprasīta pakalpojuma vai sakaru nodrošināšanai, nevis vienkārši ērtai analītikai, mārketingam vai vietnes īpašnieka iekšējām vajadzībām, un auditoram šī darbība jāsasaista ar funkciju, kuras dēļ tā nepieciešama, vienlaikus pārbaudot, vai tajā pašā kategorijā nav paslēpts pavisam cits nolūks, kuru lietotāja pieprasītā funkcija neattaisno.

Meklējumos lietotā frāze “GDPR mājaslapas audits” šajā pakalpojumā nozīmē tikai sīkdatņu, izsekošanas un piekrišanas pārvaldības tvērumu, jo ārpus tā paliek citu procesu tiesiskie pamati, datu subjektu pieprasījumi, līgumi un iekšējā pārvaldība. Mūsu sīkdatņu un izsekošanas audita pakalpojums dod tehniskos faktus, ar kuriem jurists vai datu aizsardzības speciālists var pamatoti novērtēt tieši šo vietnes daļu, taču VDAR atbilstība nav viens slēdzis, ko tehnisks skeneris var ieslēgt visai organizācijai. Šāda robeža nav atruna no atbildības; tā skaidri pasaka, ko atskaite pierāda un kuri jautājumi vēl jāizlemj ārpus tehniskā audita.

Kā audits iegūst pierādījumus, nevis tikai skenera rezultātu

Labs tests sākas tīrā pārlūka profilā, kurā nav iepriekš saglabātas piekrišanas, vietnes sīkdatņu vai paplašinājumu radītu pieprasījumu, un pirms jebkura klikšķa tiek ieslēgts Network žurnāls, pārbaudīta Application sadaļa un fiksēts sākotnējais stāvoklis. Pēc tam to pašu darbību secību atkārto pēc noraidīšanas, pēc piekrišanas un pēc atsaukšanas, katru scenāriju sākot no dokumentēta stāvokļa un saglabājot visu žurnālu, jo citādi vakardienas izvēle var izskatīties pēc šodienas banera kļūdas vai, gluži pretēji, īsto kļūdu noslēpt.

Network ieraksts pierāda, ka pārlūks mēģināja sazināties ar konkrētu adresi, un ļauj apskatīt iniciatoru, statusu, pieprasījuma un atbildes galvenes un nosūtīto informāciju, taču tas vēl nepierāda, ka sīkdatne ir saglabāta. Atbildes galvene Set-Cookie rāda servera mēģinājumu to iestatīt, taču pārlūks šo mēģinājumu var bloķēt, savukārt JavaScript var ierakstīt document.cookie vai localStorage bez šādas galvenes; tādēļ faktiskais rezultāts jāpārbauda Application skatā un neviena pazīme nedrīkst aizstāt pārējās. Redzams pieprasījums uz analītikas domēnu ir pierādījums datu plūsmas mēģinājumam, nevis automātisks pierādījums par veiksmīgi iestatītu analītikas sīkdatni vai konkrēta personas datu kopuma saņemšanu serverī.

Katram atradumam pierakstām pārbaudīto URL un lietotāja ceļu, laiku, ierīces un pārlūka kontekstu, izvēlēto piekrišanas stāvokli, pieprasījuma iniciatoru, galamērķi, nosūtīšanas rezultātu un krātuves izmaiņas, lai pēc labojuma varētu atkārtot tieši to pašu testu. Automātiska skenēšana dod plašu sākuma inventāru, bet tā neiziet visas izvēlnes, pirkuma soļus, ielogošanās zonas, valodu versijas un dinamiski atvērtas integrācijas un nevar droši noteikt nolūku pēc faila nosaukuma vai domēna vien, tāpēc tai seko manuāli scenāriji un saruna ar rīku īpašniekiem. Tajā noskaidrojam, kas rīku ieviesa, kādam nolūkam, kurā tagu konteinerā tas dzīvo un kādam piekrišanas signālam tam jāpakļaujas, lai tehnisko atradumu varētu sasaistīt ar paredzēto konfigurāciju. Pierādījums bez konteksta ir tikai ekrānuzņēmums; konteksts bez pierādījuma ir tikai solījums.

1. Neobligātie skripti tiek palaisti pirms lietotāja izvēles

Kritiska secības kļūda rodas tad, ja CMP baneris vizuāli parādās ātri, bet analītikas vai reklāmas tags jau ir palaists: lietotājs vēl lasa pogu tekstu, kamēr pārlūks ir sazinājies ar trešo pusi vai ierakstījis identifikatoru. Datu valsts inspekcijas skaidrojums šajā punktā ir nepārprotams: neobligātās sīkdatnes pirms izvēles aktivizēt nedrīkst, tādēļ tehniskā pārbaude sākas no pirmās dokumenta ielādes, nevis no brīža, kad auditoram izdevies atrast un nospiest “Noraidīt”.

Google Tag Manager vidē biežs cēlonis ir nepareiza notikumu secība, jo piekrišanas noklusējuma stāvoklis jāiestata pirms tagiem, izmantojot Consent Initialization posmu vai citu risinājumu, kas garantē tādu pašu kārtību, un tikai pēc lietotāja darbības tiek sūtīts atjauninājums. Ja noklusējums pienāk par vēlu, tags īsu brīdi var redzēt nenoteiktu vai iepriekš saglabātu stāvokli un palaisties, bet ātri aizverošs baneris šo sacensību neizlabo, jo problēma ir izpildes secībā, nevis animācijā.

Frāze “sīkdatnes ielādējas pirms piekrišanas” auditā jāsadala precīzāk: var būt ielādēts pats skripts, veikts tīkla pieprasījums, nosūtīts signāls bez sīkdatnēm, mēģināts iestatīt Set-Cookie vai faktiski saglabāts identifikators, un katrai darbībai ir cita pierādījumu nozīme. Advanced Consent Mode gadījumā daži Google tagi ar liegtu glabāšanu var ielādēties un sūtīt signālus bez sīkdatnēm, tāpēc ar skripta klātbūtni vien nepietiek ne pārkāpuma, ne atbilstības secinājumam.

Labojums sākas ar rīku karti un vienu skaidru stāvokļu modeli: kuri tagi drīkst darboties bez izvēles, kuriem nepieciešama konkrēta kategorija un kurš notikums maina noklusējumu. Pēc konfigurācijas maiņas pārbaudi atkārto tīrā profilā ar saglabātu Network žurnālu, īpaši vērojot pirmos pieprasījumus un to iniciatorus; ja kļūda parādās tikai dažreiz, tas parasti norāda uz sacensību starp CMP, tagu konteineru un vietnes kodu, kura jānovērš pašā ielādes kārtībā, nevis jāpaslēpj ar vizuāli ātrāku baneri.

2. “Noraidīt” maina interfeisu, bet ne datu plūsmu

Poga var aizvērt baneri, iekrāsot izvēli pelēku un pat saglabāt vērtību “denied”, kamēr trešo pušu tagi turpina darboties kā iepriekš, tādēļ atteikuma tests nav jautājums par pazudušu uzrakstu, bet gan divu stāvokļu salīdzinājums. Pirms un pēc visu neobligāto kategoriju noraidīšanas fiksējam pieprasījumus un krātuvi, pēc tam skatāmies, vai attiecīgie tagi nesaņem aktivizējošu notikumu, vai neparādās jauni identifikatori un vai turpmākie lapu skatījumi saglabā atteikumu. Iepriekšēja sesija šo testu viegli sabojā: ja vakar dota piekrišana, šodienas poga “Noraidīt” var vispirms ielādēt lapu ar vakardienas stāvokli un tikai tad to mainīt, atstājot pirmo pieprasījumu jau nosūtītu. Arī manuāla sīkdatņu dzēšana starp soļiem rada neīstu tīrību un nepārbauda īsto atsaukšanas mehānismu, tāpēc sākotnējā noraidīšana un vēlākā atsaukšana ir atsevišķi scenāriji: pirmais sākas bez lēmuma, otrais — ar apzināti dotu piekrišanu, un abu rezultātus nedrīkst sajaukt vienā ekrānuzņēmumā.

Arī pēc atteikuma vietne drīkst veikt darbības, kas tiešām vajadzīgas lietotāja skaidri pieprasītai drošības, groza vai citai funkcijai, tāpēc apgalvojums “jebkurš pieprasījums pēc noraidīšanas ir slikts” būtu tikpat neprecīzs kā banera zaļais ķeksītis. Jānoskaidro katra palikušā savienojuma nolūks, iniciators un glabāšanas darbība, pēc tam CMP jākonfigurē tā, lai noraidījums vispirms atjauninātu piekrišanas stāvokli un tagi izmantotu iebūvētās vai skaidri norādītās piekrišanas pārbaudes; funkcionāla poga ir tā, kas vairākās lapās paredzami maina zem tās pieslēgto datu plūsmu. Ja atteikums aptur reklāmas tagu, bet atstāj pirmās puses sesijas sīkdatni, tas var būt gaidītais rezultāts; ja viena kategorija klusām aktivizē otru, konfigurācija nav uzticama, un pēc labojuma atteikums jāspēj atkārtot vairākās lapās bez manuālas krātuves tīrīšanas un ikreiz iegūt vienādu, atkārtojamu un pierādāmu stāvokli.

3. Kategorijas un sīkdatņu politika neatbilst faktiskajam inventāram

Baneris var būt tehniski disciplinēts un tomēr maldināt, ja kategorijas vai politika apraksta citu vietni, kā tas mēdz notikt pēc veidnes kopēšanas, tagu konteinera pārņemšanas vai jauna rīka pievienošanas bez dokumentācijas atjaunošanas. Politikā tad paliek sen nelietota sīkdatne, kamēr video atskaņotājs, čata logs vai reklāmas konversijas tags nav pieminēts, un lietotājs izdara izvēli pēc nepilnīgas informācijas. Uzņēmums šādā situācijā nevar pamatot, kurš saņēmējs datus saņem, kādam nolūkam tas notiek un cik ilgi identifikators dzīvo.

Datu valsts inspekcija sīkdatņu politiku saista ar faktisko inventāru, kurā norādīts nolūks, pakalpojuma sniedzējs vai saņēmējs un glabāšanas termiņš, nevis tikai tas, ko automātiski atpazinis CMP katalogs. Viena nosaukuma sīkdatnei dažādās konfigurācijās var būt atšķirīgs lietojums, bet pielāgotam pirmās puses identifikatoram publiskajā datubāzē apraksta var nebūt vispār, tāpēc audits tehnisko objektu sasaista ar vietnes īpašnieka patieso nolūku un atbildīgo rīku. Audita uzdevums nav pārrakstīt kataloga minējumu, bet pārbaudīt, vai konfigurācija, saņēmējs un termiņš atbilst tam, ko uzņēmums faktiski izmanto un spēj izskaidrot.

Inventārs nebeidzas Cookies cilnē: jāpārbauda localStorage, sessionStorage, IndexedDB, pikseļu un servera pieprasījumi, kā arī URL vai veidlapu plūsmās izmantoti identifikatori, ja tie iesaistīti izsekošanā. EDPB tehniskās vadlīnijas skaidro, ka ePrivacy tvērums nav piesiets vienai glabāšanas tehnoloģijai, tāpēc politika, kura sola “mēs nelietojam sīkdatnes”, vēl neatbild, vai vietne ar citu metodi piekļūst galaiekārtas informācijai vai sūta mērījumu signālus. Sīkdatņu nosaukumu saraksts tādēļ ir inventarizācijas sākums, nevis pilns pārskats par tehnoloģijām, kas var glabāt, nolasīt vai nosūtīt identifikatorus.

Praktisks labojums ir vienots avota reģistrs, no kura uztur gan CMP klasifikāciju, gan politikas tehnisko tabulu, gan audita scenārijus un kurā katram ierakstam norādīts rīka īpašnieks uzņēmumā, piegādātājs, nolūks, aktivizējošais piekrišanas stāvoklis, izmantotā krātuve, saņēmējs un termiņš. Tad jauna taga pievienošana vairs nav tikai darbs Google Tag Manager konteinerā, bet kontrolēta izmaiņa, kurai pirms publicēšanas jāatjauno lietotājam dotā informācija un pārbaudes gadījumi. Tas pats reģistrs pēc izmaiņas dod atkārtojamam testam sākuma punktu un parāda, kurš uzņēmumā atbild par neatbilstības novēršanu.

4. Vienu Network pieprasījumu sajauc ar pierādījumu par sīkdatni

Network panelī redzams analītikas domēns ir svarīgs atradums, tomēr no tā vien neizriet secinājums “sīkdatne tika iestatīta”: ieraksts pierāda savienojuma mēģinājumu un rāda, ko pārlūks pievienoja URL, galvenēm vai pieprasījuma saturam, bet neveiksmīgs, bloķēts vai atcelts pieprasījums nav tas pats, kas servera veiksmīgi saņemti dati. Sīkdatņu daļai jāpārbauda, vai pieprasījuma galvenē bija Cookie, vai atbildē parādījās Set-Cookie, vai pārlūks to nebloķēja un vai ieraksts tiešām nonāca krātuvē. Pieprasījums var būt bloķēts vai atcelts, pirms serveris saņem datus, un šī pierādījuma robeža jāatspoguļo arī atraduma formulējumā, neapvienojot savienojuma mēģinājumu, nosūtīšanas rezultātu un glabāšanu vienā apgalvojumā.

Arī pretējais secinājums nav drošs, jo pieprasījums bez sīkdatnes var saturēt piekrišanas stāvokli un citus parametrus, bet vietne var izmantot localStorage identifikatoru, URL parametru vai citu tehnisku metodi; sīkdatnes neesamība savienojumu automātiski nepadara anonīmu vai tukšu. Savukārt Set-Cookie ir servera norādījums pārlūkam, nevis garantija, ka ieraksts saglabāts, jo pārlūks to var noraidīt domēna, drošības atribūtu, trešo pušu ierobežojumu vai citas politikas dēļ, bet JavaScript iestatīta pirmās puses sīkdatne var parādīties bez šīs atbildes galvenes. DevTools rāda arī bloķēšanas iemeslus, tāpēc Set-Cookie klātbūtne jālasa kopā ar pārlūka lēmumu un faktisko Application stāvokli. Ja Cookies tabulā nav jaunas rindas, signālu nepārkrāsojam par “bez datiem”, bet pārbaudām URL, galvenes, parametrus un citas krātuves.

Drošākā metode savieno trīs skatus vienā laika līnijā — kas izraisīja pieprasījumu, ko serveris lūdza izdarīt un kas pēc tam faktiski saglabājās konkrētajā pārlūka profilā —, un audita atskaite apzināti nosauc tikai pierādīto. Tajā rakstām “pirms izvēles nosūtīts pieprasījums uz domēnu X”, “atbildē konstatēts sīkdatnes iestatīšanas mēģinājums” vai “Application skatā pēc noraidīšanas saglabājies identifikators Y”, jo šādu soli izstrādātājs var atkārtot, jurists redz tehniskā fakta robežas un pēc labojuma rezultātu iespējams objektīvi salīdzināt. No viena ekrānuzņēmuma neizsecinām visu datu apstrādes ķēdi, jo tas var pierādīt tikai konkrēto darbību, stāvokli un laiku, kurā attēls uzņemts.

5. Piekrišanas atsaukšana ir paslēpta vai tehniski nepilnīga

Piekrišana nav vienreizējs klikšķis, kuru vietne drīkst aizmirst: VDAR 7. panta 3. punkts paredz iespēju to atsaukt jebkurā laikā un prasa, lai atsaukšana būtu tikpat vienkārša kā došana, ko praktiski skaidro arī Datu valsts inspekcija. Ja piekrišanu var dot sākumlapas pirmajā ekrānā, bet atsaukšanai jāmeklē privātuma politikas apakšsadaļa, jāraksta e-pasts vai jātīra pārlūka iestatījumi, mehānisms nav līdzvērtīgi pieejams; parasts risinājums ir pastāvīga izvēļu pārvaldības saite vietnes kājenē. Tās atrodamību pārbaudām no katras lapas un arī tad, kad baneris vairs nav redzams, jo tieši šādā stāvoklī lietotājs mēģina mainīt agrāko lēmumu.

Tehniskais tests sākas ar apzināti dotu piekrišanu un reāli aktivizētiem tagiem, pēc tam auditors atver izvēļu pārvaldību, atsauc neobligātās kategorijas un turpina pārvietoties pa vietni, neradot mākslīgu sākumu ar manuālu krātuves dzēšanu. Jāpārbauda, vai CMP nosūta atjaunināto stāvokli un tagi to saņem, vai vairs nesākas jaunas uz piekrišanu balstītas datu plūsmas un kas notiek ar vietēji glabātajiem identifikatoriem, jo tieši šādi atklājas poga, kura saglabā jauno izvēli, bet par to nepaziņo jau ielādētajiem tagiem. Vienlaikus fiksējam izmaiņas notikuma secību, lai atšķirtu pareizi saglabātu izvēli no situācijas, kurā atkarīgais tags atjauninājumu saņem pārāk vēlu vai nesaņem vispār.

Atsaukšana darbojas uz priekšu un pati par sevi nepārraksta pagātni vai neizdzēš visus iepriekš likumīgi apstrādātos datus, tāpēc pēc tās ir jāpārtrauc turpmāka apstrāde, kas balstīta uz šo piekrišanu, bet agrāk serverī saņemto datu glabāšana vai dzēšana var prasīt atsevišķu izvērtējumu. Audita atskaitē tāpēc nošķiram turpmākās datu plūsmas apturēšanu no agrāko datu glabāšanas jautājuma, neapsolot, ka tehniska izvēles maiņa atrisina abus. Labojumam jāsavieno interfeiss ar integrāciju: saitei jābūt atrodamai no katras lapas, CMP jārāda pašreizējais stāvoklis, izmaiņai jānonāk līdz katram atkarīgajam tagam un tests jāatkārto ar vairākām kategoriju kombinācijām, jo “atteikt visu” var darboties, kamēr atsevišķa mārketinga slēdža izslēgšana paliek bez efekta. Arī pārlūka identifikatoru dzēšana jāvērtē pēc to funkcijas, nevis jāsola, ka viens CMP klikšķis automātiski iztīrīs katras trešās puses sistēmu.

6. Basic un Advanced Consent Mode tiek sajaukti vai apsolīti modelēti dati

Basic un Advanced Consent Mode nav divi viena slēdža dizaini: Basic režīmā Google tagi pirms piekrišanas netiek ielādēti un līdz tam Google nesaņem šo tagu mērījumu datus, bet pēc piekrišanas tagi var sākt ierasto mērīšanu. Advanced režīmā tie ielādējas ar sākotnēji liegtu glabāšanu un, kamēr piekrišana nav dota, var nosūtīt signālus bez sīkdatnēm, tāpēc šo režīmu nedrīkst aprakstīt kā stāvokli, kurā “nekas netiek nosūtīts”, un Basic nav automātiski sliktāka analītikas konfigurācija. Atšķirība ir faktiskajā tagu uzvedībā pirms izvēles, nevis banera izskatā vai viena iestatījuma nosaukumā.

Izvēle jābalsta uzņēmuma juridiskajā izvērtējumā un analītikas vajadzībās, nevis pieņēmumā, ka Google produkta nosaukums pats atrisina ePrivacy vai VDAR prasības. Google Consent Mode dokumentācija nošķir tagu bloķēšanu Basic režīmā no signāliem bez sīkdatnēm Advanced režīmā, bet auditā pārbaudām faktisko konfigurāciju: vai noklusējumi stājas spēkā pirms tagiem, kāds atjauninājums tiek nosūtīts pēc klikšķa un kādi pieprasījumi katrā stāvoklī tiešām parādās. Produkta režīma nosaukums nav juridisks secinājums, tādēļ atskaitē aprakstām pārbaudīto plūsmu un uzņēmuma izvēlēto konfigurāciju, nevis piešķiram tai automātisku atbilstības marķējumu.

“Bez sīkdatnēm” nenozīmē “bez informācijas”, tādēļ signāla nosaukums atskaitē nedrīkst aizstāt tā satura un nolūka izvērtējumu. Network panelī jāapskata galamērķis, parametri, piekrišanas stāvoklis un iniciators, savukārt Google Tag Assistant vai Consent Mode atkļūdošanas rīki palīdz pārbaudīt noklusējuma un atjauninātos stāvokļus; šie skati viens otru papildina, jo pirmais atklāj konkrētā mēģinājuma datu plūsmu, bet otrais — konfigurācijas loģiku. Ja abi skati nesakrīt, priekšroka nav jādod glītākajam ekrānam: jāatrod, kur noklusējuma vai atjauninājuma notikums nav nonācis līdz tagam paredzētajā secībā.

Arī modelētie dati nav garantēta balva par Advanced režīma ieslēgšanu, jo Google Analytics 4 uzvedības modelēšanas pieejamība ir atkarīga no Google noteiktajiem īpašuma, datu apjoma un kvalitātes nosacījumiem un funkcija var nebūt pieejama vai var zust, ja tie vairs neizpildās. Modelēšana neatjauno atsevišķu noraidījušo lietotāju sesijas, tādēļ piedāvājumā apsolām korektu konfigurāciju un pārbaudāmu signālu secību, nevis konkrētu modelēto datu apjomu, ko nosaka Google sistēma un attiecīgā īpašuma atbilstība. Tādējādi audita rezultāts ir reproducējama konfigurācija un signālu pārbaude, nevis solījums par datu apjomu, kuru pakalpojuma sniedzējs nekontrolē.

7. Tests beidzas pirmajā lapā un pirmajā dienā

Sākumlapa reti aptver visu izsekošanas inventāru: video tags var ielādēties tikai pēc atskaņošanas, kartes integrācija — kontaktu lapā, reklāmas konversija — pēc veidlapas nosūtīšanas, maksājumu rīks — groza pēdējā solī, bet čata vai personalizācijas skripts — pēc noteikta laika. Auditors, kurš atver vienu URL, pagaida dažas sekundes un aizver skeneri, var uzrakstīt tehniski pareizu atskaiti par šo vienu skatu un vienlaikus bīstami nepilnīgu atskaiti par vietni kopumā. Katrs no šiem stāvokļiem jāatver ar darbību, kas to reāli aktivizē, nevis jāpieņem, ka sākumlapas inventārs automātiski pārstāv visas veidnes un lietotāju ceļus.

Scenārijus veidojam pēc reāliem lietotāju ceļiem un vietnes veidnēm, aptverot publisko lapu, rakstu, kontaktu formu, konta zonu, pirkuma procesu, iegultu saturu un katru būtisko valodas vai reģiona versiju; jāpārbauda arī mobilais izkārtojums, kurā CMP pogas var pārklāties vai izvēļu saite kļūt nesasniedzama, lai gan darbvirsmā viss strādā. Automatizēts rāpojums dod plašumu, savukārt manuāls scenārijs atver stāvokļus, kurus robots bez konta, klikšķa vai ievades nekad neieraudzīs. Valodu un reģionu versijas, tāpat kā mobilais izkārtojums, nav dekoratīvi dublikāti, ja tajos mainās integrāciju ielāde vai lietotājam pieejamās izvēles.

Vienreizējs audits nenosedz izmaiņas laikā, jo jauns mārketinga tags, nomainīta CMP veidne vai importēts Google Tag Manager konteiners var izjaukt iepriekš pareizu secību bez redzamas izmaiņas banerī, tāpēc katram jaunam rīkam vajadzīgs tests pirms publicēšanas un atkārtots salīdzinājums. Tā ir disciplīna, kuru vērts ieplānot jau vietnes izstrādes līgumā, kā skaidrojām rakstā par 10 kļūdām, pasūtot mājaslapas izstrādi; mūsu audita procesā pēc ieviešanas paredzēta atkārtota skenēšana pēc 30 un 180 dienām, izmantojot tos pašus scenārijus un pierādījumu laukus, lai redzētu, vai labojums turas reālā publicēšanas ritmā un vai vēlāk nav parādījušies jauni rīki vai konfigurācijas novirzes. Pirmais termiņš parāda, vai ieviešana izturējusi ikdienas publicēšanu, bet otrais atklāj vēlākas izmaiņas; atkārtotajā testā salīdzinām konkrētu pieprasījumu, krātuvi un piekrišanas stāvokli ar sākotnējo atradumu, nevis aprobežojamies ar iespaidu, ka “tagad izskatās labāk”.

Ko saņemat tehniskā sīkdatņu un izsekošanas auditā

Audita pirmais rezultāts ir pārbaudīts sīkdatņu, krātuvju, tagu un trešo pušu pieprasījumu inventārs, kurā katrs atradums sasaistīts ar lapu, lietotāja darbību un piekrišanas stāvokli, bet blakus norādīts pierādījums un tā robeža: Network ieraksts, Set-Cookie mēģinājums, faktiska sīkdatne Application skatā, localStorage ieraksts vai CMP notikums. Izstrādātājs tā saņem reproducējamu kļūdu, nevis neskaidru piezīmi “salabojiet GDPR”, savukārt atbildīgais par privātumu redz, kuri fakti vēl prasa juridisku lēmumu. Katram atradumam paliek arī atkārtošanas ceļš, lai pēc ieviešanas varētu pārbaudīt tieši to pašu lapu, izvēli, pieprasījumu un krātuves rezultātu.

Otra daļa ir ieviešana: sakārtojam CMP kategorijas un Google Tag Manager noklusējumu un atjauninājumu secību, konfigurējam Google Analytics 4, Google Ads, Meta Pixel un citu rīku piekrišanas pārbaudes, kā arī sagatavojam sīkdatņu un privātuma politikas tekstu latviešu valodā. Basic vai Advanced Consent Mode izvēlamies pēc jūsu juridiskā izvērtējuma un analītikas vajadzībām, nepasniedzot Advanced kā universāli pareizu variantu un neapsolot modelētos datus, ja konkrētais Google īpašums neatbilst Google nosacījumiem. Ieviešanas rezultātu pārbaudām tajos pašos piekrišanas stāvokļos, kuros tika fiksēts sākotnējais atradums, lai konfigurācijas izmaiņu varētu pamatot ar salīdzināmiem pierādījumiem.

Pakalpojuma cena ir sākot no €800, bet izpildes laiks — 1–4 nedēļas, atkarībā no vietnes apjoma, valodu un veidņu skaita, CMP un tagu konteineru sarežģītības, kā arī no nepieciešamo integrāciju skaita. Cenā un grafikā pirms darba skaidri nošķiram audita pierādījumus, tehniskos labojumus un jautājumus, kuri jāizlemj uzņēmuma juristam vai datu aizsardzības speciālistam, bet pēc 30 un 180 dienām veicam atkārtotu skenēšanu pret fiksētajiem scenārijiem. Tādējādi cena un termiņš attiecas uz skaidri nosauktu tehnisko tvērumu, nevis uz nenoteiktu solījumu sakārtot visu uzņēmuma datu aizsardzību.

Ja jums vajadzīgs “GDPR mājaslapas audits”, vispirms vienojamies, ka šeit tas nozīmē sīkdatņu, izsekošanas, CMP un Consent Mode tvērumu, nevis visas organizācijas pilnu VDAR atbilstības pārbaudi, un tādēļ apsolām tikai to, ko tehniski varam pierādīt: vietnes uzvedību pirms izvēles, pēc noraidīšanas, pēc piekrišanas un pēc tās atsaukšanas, rīkiem nosūtītos signālus un vietas, kur pierādījuma vēl nepietiek juridiskam secinājumam. Šis nošķīrums ļauj tehnisko darbu pabeigt ar pārbaudāmu rezultātu un juridiskos jautājumus nodot cilvēkam, kurš atbild par plašāko personas datu apstrādi. Pieteikt sīkdatņu un izsekošanas auditu varat, nosūtot vietnes adresi un izmantoto CMP vai tagu pārvaldnieku.