Küpsisebänneri kontroll: kas see tõesti blokeerib mittehädavajalikud skriptid? 7 levinud viga

Nupp „Keeldu” ei tõenda veel, et jälgimine lõpeb. Praktiline juhend bänneri kontrollimiseks Networki, Applicationi, nõusolekurežiimi ja kordustestidega.

Te avate veebilehe uues brauseriprofiilis, klõpsate „Keeldu” ja näete, et küpsiseteade kaob. Pealtnäha on kõik korras, kuid küpsisebänneri kontroll algab just nüüd: kas juba enne klõpsu saadeti päring reklaamiplatvormile, kas vastus püüdis salvestada identifikaatorit, mis jäi brauseri salvestusruumi, ning kas märgendid said pärast keeldumist õige nõustumisoleku? Nupp on kõigest juhtpaneel ja kontroll peab näitama, kas selle all on juhtmed päriselt ühendatud. CMP ei pruugi olla vaikeolekut veel määranud, kui märgendihaldur juba esimese märgendi käivitab.

Bänneri visuaalne ülevaatus ega automaatse skanneri roheline linnuke ei näita, mis juhtus laadimise esimestel sekunditel. Samuti ei selgu neist, milline skript toimingu põhjustas, milline nõustumisolek oli sel hetkel skriptile kättesaadav ega kas nähtav lõppolek vastab kogu eelnenud sündmuste jadale. Seepärast võrdleme ühel ajajoonel veebilehe käitumist enne valikut, pärast kõigi mittehädavajalike kategooriate tagasilükkamist, pärast lubamist ja pärast hilisemat nõusoleku tagasivõtmist. Igas olekus hindame võrgupäringuid, vastusepäiseid, küpsiseid, localStorage’i ja muid salvestusruume, nõusolekusignaalide järjekorda ning konkreetse toimingu algatajat. Ainult selline võrdlus eristab korrektset seadistust bännerist, mis lihtsalt sulgub.

See on tehniline artikkel, mitte individuaalne õigusnõuanne. Siin näitame, kuidas koguda kontrollitavaid fakte ja vältida järeldusi, mida tõendid ei toeta. Kui veebileht kasutab Google Tag Manageri, Google Analytics 4, Google Adsi, Meta Pixelit, manustatud videoid, vestlusakent või muid kolmandate osapoolte tööriistu, on ühel ekraanil nähtav küpsiste loend ainult osa tervikust. Seetõttu ei ole põhiküsimus, kas bänner on paigaldatud, vaid see, mida veebileht kasutaja valiku igas etapis teeb.

Mida küpsisebänneri kontroll hõlmab — ja mida see ei tõenda

Kontroll hõlmab tehnilist nõusolekuahelat lehe esimesest päringust kuni oleku muutumiseni pärast kasutaja valikut. Seda ei saa hinnata üksnes lõppoleku järgi, sest algne laadimisjärjekord võib olla juba käivitanud toimingu, mida hiljem suletud bänner enam tagasi ei võta. Kontrollime skriptide laadimisjärjekorda, võrguühendusi, küpsiseid ja muid salvestusruume, CMP ehk nõusolekuhalduse platvormi signaale, Google’i nõusolekurežiimi seadistust, kategooriate toimimist ning võimalust valikut hiljem muuta. Tulemuseks on tõendikogum küpsiste ja jälgimise kihi kohta, mitte tunnistus, et kogu organisatsiooni isikuandmete töötlemine on õiguslikult veatu.

Õiguslikult tuleb lahus hoida kaks omavahel seotud tasandit. E-privaatsusdirektiivi artikli 5 lõige 3 käsitleb teabe salvestamist kasutaja lõppseadmesse ja juba salvestatud teabele juurdepääsu; selle tehniline ulatus ei piirdu failidega, mille nimes on „cookie”. Isikuandmete kaitse üldmäärust (IKÜM) kohaldatakse siis, kui töödeldakse isikuandmeid; määrus sätestab ka kehtiva nõusoleku tingimused ja tagasivõtmise põhimõtted. Seetõttu ei asenda ühe õigusraamistiku tehniline kontroll teise õigusraamistiku õiguslikku hindamist. Auditiaruandes nimetame mõlemad tasandid eraldi, et vaadeldud tehnilist fakti ei esitataks sellest laiema õigusliku järeldusena.

Andmekaitse Inspektsioon selgitab, et mittehädavajalikud küpsised ei tohi enne nõusolekut rakenduda ning kasutaja peab saama neist keelduda. Ka kategooria nimi „necessary” ei tõenda iseenesest midagi. Hädavajalike küpsiste erandit tuleb hinnata kitsalt: konkreetne toiming peab olema vajalik kasutaja sõnaselgelt soovitud teenuse või side võimaldamiseks, mitte lihtsalt kasulik analüütikale, turundusele või veebilehe omaniku sisemistele vajadustele. Audiitor peab toimingu siduma funktsiooniga, mille jaoks see on vajalik, ning kontrollima samal ajal, ega samasse kategooriasse ole peidetud hoopis teist eesmärki, mida kasutaja soovitud funktsioon ei õigusta.

Otsingufraas „veebilehe GDPR-i audit” tähendab selle teenuse puhul ainult küpsiste, jälgimise ja nõusolekuhalduse ulatust. Välja jäävad muude protsesside õiguslikud alused, andmesubjektide taotlused, lepingud ja sisejuhtimine. Meie küpsiste ja jälgimise audit annab tehnilised faktid, mille alusel jurist või andmekaitsespetsialist saab just seda veebilehe osa põhjendatult hinnata. GDPR-i nõuetele vastavus ei ole üks lüliti, mille tehniline skanner saaks kogu organisatsiooni jaoks sisse lülitada. Selline piir ei ole vastutusest loobumine, vaid selge kirjeldus sellest, mida aruanne tõendab ja millised küsimused tuleb lahendada väljaspool tehnilist auditit.

Kuidas kontroll kogub tõendeid, mitte ainult skanneri tulemust

Hea küpsisebänneri test algab puhtas brauseriprofiilis, kus pole varem salvestatud nõusolekut, veebilehe küpsiseid ega laienduste tekitatud päringuid. Enne esimest klõpsu lülitatakse sisse Networki logi, vaadatakse üle Applicationi jaotis ja talletatakse algolek. Seejärel korratakse sama toimingute jada pärast keeldumist, pärast nõusoleku andmist ja pärast selle tagasivõtmist. Iga stsenaarium algab dokumenteeritud olekust ja kogu logi säilitatakse, sest muidu võib eilne valik näida tänase bänneriveana või tegelikku viga hoopis varjata.

Networki kirje tõendab, et brauser püüdis konkreetse aadressiga ühendust võtta, ning võimaldab vaadata algatajat, olekut, päringu- ja vastusepäiseid ning saadetud teavet. See ei tõenda veel, et küpsis salvestati. Vastusepäis Set-Cookie näitab serveri katset küpsist määrata, kuid brauser võib katse blokeerida; JavaScript saab samal ajal kirjutada document.cookie või localStorage’i ilma sellise päiseta. Seetõttu tuleb tegelikku tulemust kontrollida Applicationi vaates; ükski neist tõenditest ei asenda teisi. Analüütikadomeenile suunatud nähtav päring tõendab andmevoo katset, mitte automaatselt analüütikaküpsise edukat salvestamist ega konkreetse isikuandmete kogumi serverisse jõudmist.

Iga leiu juurde märgime kontrollitud URL-i ja kasutajateekonna, aja, seadme- ja brauserikonteksti, valitud nõustumisoleku, päringu algataja, sihtkoha, päringu tulemuse ning salvestusruumi muutused. Nii saab pärast parandust korrata täpselt sama testi. Automaatne skannimine annab laia alginventuuri, kuid ei läbi kõiki menüüsid, ostuetappe, sisselogitud alasid, keeleversioone ega dünaamiliselt laaditavaid integratsioone ning ei suuda tööriista eesmärki kindlalt tuvastada üksnes failinime või domeeni järgi. Seetõttu järgnevad sellele käsitsi läbitavad stsenaariumid ja vestlus tööriistade eest vastutajatega. Selgitame välja, kes tööriista lisas, mis eesmärgil, millises märgendikonteineris see asub ja millisele nõusolekusignaalile peab alluma, et tehnilise leiu saaks siduda kavandatud seadistusega. Tõend ilma kontekstita on ainult kuvatõmmis; kontekst ilma tõendita ainult lubadus.

1. Mittevajalikud skriptid käivituvad enne kasutaja valikut

Kriitiline järjestusviga tekib siis, kui CMP-bänner ilmub kiiresti, kuid analüütika- või reklaamimärgend on juba käivitunud. Kasutaja alles loeb nuppude teksti, kui brauser on kolmanda osapoolega ühenduse võtnud või identifikaatori salvestanud. Andmekaitse Inspektsiooni seisukoht on siin üheselt mõistetav: mittehädavajalikke küpsiseid ei tohi enne nõusoleku andmist rakendada. Seega algab tehniline kontroll dokumendi esimesest laadimisest, mitte hetkest, mil audiitor leidis ja klõpsas nupul „Keeldu”.

Google Tag Manageris põhjustab seda sageli vale sündmuste järjekord. Nõusoleku vaikeolek tuleb määrata enne märgendeid, kasutades nõusoleku algatamise käivitajat või muud lahendust, mis tagab sama järjekorra; alles pärast kasutaja toimingut saadetakse värskendus. Kui vaikeolek jõuab kohale liiga hilja, võib märgend näha lühikest aega määramata või varem salvestatud olekut ja käivituda. Kiiresti sulguv bänner seda võidujooksu ei paranda, sest viga on täitmisjärjekorras, mitte animatsioonis.

Väide „küpsised laaditakse enne nõusolekut” tuleb auditisse kirjutades täpsemalt osadeks võtta. Laaditud võib olla skript ise, tehtud võrgupäring, saadetud küpsisteta signaal, üritatud määrata Set-Cookie või tegelikult salvestatud identifikaator; igal toimingul on erinev tõendusjõud. Täiustatud (Advanced) nõusolekurežiimis võivad mõned Google’i märgendid laadituda ka siis, kui salvestamine on keelatud, ja saata küpsisteta signaale. Seetõttu ei piisa skripti olemasolust ei rikkumise ega vastavuse järeldamiseks.

Parandus algab tööriistade kaardist ja ühest selgest olekumudelist: millised märgendid võivad töötada ilma valikuta, millised vajavad kindlat kategooriat ning milline sündmus seda olekut uuendab. Pärast seadistuse muutmist korratakse kontrolli puhtas profiilis ja salvestatud Networki logiga, pöörates erilist tähelepanu esimestele päringutele ning nende algatajatele. Kui viga ilmub ainult mõnikord, viitab see tavaliselt CMP, märgendikonteineri ja veebilehe koodi võidujooksule. See tuleb parandada laadimisjärjekorras, mitte peita visuaalselt kiirema bänneriga.

2. „Keeldu” muudab liidest, kuid mitte andmevoogu

Nupp võib bänneri sulgeda, kuvada valiku hallina ja isegi väärtuse „denied” salvestada, samal ajal kui kolmandate osapoolte märgendid töötavad edasi nagu varem. Seetõttu ei piirdu keeldumise test kontrolliga, kas tekst kadus, vaid võrdleb kahte olekut. Talletame päringud ja salvestusruumi enne ning pärast kõigi mittehädavajalike kategooriate tagasilükkamist. Seejärel kontrollime, kas asjaomased märgendid ei saa käivitavat sündmust, kas uusi identifikaatoreid ei teki ning kas järgmistel lehevaatamistel jääb keeldumine kehtima. Varasem seanss rikub testi kergesti: kui eile anti nõusolek, võib leht tänase „Keeldu” valiku puhul laadida esmalt eilse olekuga ja alles siis seda muuta, nii et esimene päring on juba saadetud. Ka küpsiste käsitsi kustutamine sammude vahel loob kunstliku puhtuse ega kontrolli tegelikku tagasivõtmise mehhanismi. Esmane keeldumine ja hilisem tagasivõtmine on seetõttu eri stsenaariumid: esimene algab otsuseta, teine teadlikult antud nõusolekuga, ning nende tulemusi ei tohi ühte kuvatõmmisesse segada.

Veebileht võib ka pärast keeldumist teha toiminguid, mis on tõesti vajalikud kasutaja sõnaselgelt soovitud turbe-, ostukorvi- või muu funktsiooni jaoks. Seega oleks väide „iga päring pärast keeldumist on halb” sama ebatäpne kui bänneri roheline linnuke. Iga allesjäänud ühenduse puhul tuleb kindlaks teha eesmärk, algataja ja salvestustoiming. Seejärel seadistatakse CMP nii, et keeldumine uuendaks esmalt nõustumisolekut ning märgendid kasutaksid sisseehitatud või selgelt määratud nõusolekukontrolle. Toimiv nupp muudab selle alla ühendatud andmevoogu mitmel lehel etteaimatavalt. Kui keeldumine peatab reklaamimärgendi, kuid jätab alles esimese osapoole seansiküpsise, võib see olla oodatud tulemus. Kui üks kategooria käivitab märkamatult teise, ei ole seadistus usaldusväärne. Pärast parandust peab keeldumist saama mitmel lehel ilma salvestusruumi käsitsi puhastamata korrata ning tulemus peab iga kord olema sama, korratav ja tõendatav.

3. Kategooriad ja küpsisepoliitika ei vasta tegelikule inventuurile

Bänner võib olla tehniliselt korrektne ja ikkagi eksitada, kui kategooriad või poliitika kirjeldavad teist veebilehte. Seda juhtub pärast malli kopeerimist, märgendikonteineri ülevõtmist või uue tööriista lisamist ilma dokumentatsiooni uuendamata. Poliitikasse jääb ammu kasutusest kõrvaldatud küpsis, samal ajal kui videopleierit, vestlusakent või reklaamikonversiooni märgendit ei mainita. Kasutaja teeb siis valiku puuduliku teabe põhjal. Sellises olukorras ei suuda ettevõte põhjendada, milline vastuvõtja andmeid saab, mis eesmärgil see toimub ja kui kaua identifikaator säilib.

Andmekaitse Inspektsioon seob küpsisepoliitika tegeliku inventuuriga, kus on kirjas eesmärk, teenusepakkuja või vastuvõtja ning säilitustähtaeg, mitte ainult CMP-kataloogi automaatselt tuvastatu. Sama nimega küpsisel võib eri seadistustes olla erinev kasutus, kuid kohandatud esimese osapoole identifikaatoril ei pruugi avalikus andmebaasis üldse kirjeldust olla. Seetõttu seob audit tehnilise objekti veebilehe omaniku tegeliku eesmärgi ja seda haldava tööriistaga. Auditi ülesanne ei ole kataloogi oletust ümber kirjutada, vaid kontrollida, kas seadistus, vastuvõtja ja tähtaeg vastavad sellele, mida ettevõte päriselt kasutab ning oskab selgitada.

Inventuur ei lõpe vahekaardil Cookies. Kontrollida tuleb localStorage’i, sessionStorage’i, IndexedDB-d, piksli- ja serveripäringuid ning URL-ides või vormivoogudes kasutatavaid identifikaatoreid, kui neid rakendatakse jälgimiseks. EDPB tehnilised suunised selgitavad, et e-privaatsuse ulatus ei ole seotud ühe salvestustehnoloogiaga. Seetõttu ei vasta poliitika lubadus „me ei kasuta küpsiseid” veel küsimusele, kas veebileht pääseb muu meetodiga ligi lõppseadme teabele või saadab mõõtmissignaale. Küpsisenimede loend on seega inventuuri algus, mitte täielik ülevaade tehnoloogiatest, mis võivad identifikaatoreid salvestada, lugeda või saata.

Praktiline parandus on üks keskne register, mille põhjal hallatakse CMP-liigitust, poliitika tehnilist tabelit ja auditistsenaariume. Iga kirje juures on tööriista eest vastutav inimene, tarnija, eesmärk, käivitav nõustumisolek, kasutatav salvestusruum, vastuvõtja ja tähtaeg. Nii ei ole uue märgendi lisamine enam ainult töö Google Tag Manageri konteineris, vaid kontrollitud muudatus, mille puhul tuleb enne avaldamist uuendada kasutajale antavat teavet ja testjuhtumeid. Sama register annab pärast muudatust kordustestile lähtepunkti ja näitab, kes ettevõttes vastutab mittevastavuse kõrvaldamise eest.

4. Üht Networki päringut peetakse ekslikult küpsise tõendiks

Networki paneelil nähtav analüütikadomeen on oluline leid, kuid sellest üksi ei järeldu, et „küpsis määrati”. Kirje tõendab ühenduskatset ja näitab, mida brauser lisas URL-ile, päistele või päringu sisule. Ebaõnnestunud, blokeeritud või tühistatud päring ei ole sama mis serverisse edukalt jõudnud andmed. Küpsise puhul tuleb kontrollida, kas päringupäises oli Cookie, kas vastuses ilmus Set-Cookie, kas brauser seda ei blokeerinud ja kas kirje jõudis tegelikult salvestusruumi. Päring võidakse blokeerida või tühistada enne, kui server andmed saab, ning leiu sõnastus peab kajastama ka tõendi sellist piiratust. Ühenduskatset, saatmise tulemust ja salvestamist ei tohi üheks väiteks kokku sulatada.

Ka vastupidine järeldus ei ole kindel. Küpsiseta päring võib sisaldada nõustumisolekut ja muid parameetreid ning veebileht võib kasutada localStorage’i identifikaatorit, URL-i parameetrit või muud tehnilist meetodit; küpsise puudumine ei muuda ühendust automaatselt anonüümseks ega tühjaks. Set-Cookie on serveri juhis brauserile, mitte garantii, et kirje salvestati. Brauser võib selle domeeni, turbeatribuutide, kolmandate osapoolte piirangute või muu reegli tõttu tagasi lükata, samal ajal kui JavaScriptiga määratud esimese osapoole küpsis võib ilmuda ilma selle vastusepäiseta. DevTools näitab ka blokeerimise põhjuseid, mistõttu tuleb Set-Cookie olemasolu lugeda koos brauseri otsuse ja tegeliku Applicationi olekuga. Kui Cookiesi vaates uut rida ei teki, ei järelda me sellest, et signaal oli „andmeteta”, vaid kontrollime URL-i, päiseid, parameetreid ja muid salvestusruume.

Kõige kindlam meetod ühendab ühel ajajoonel kolm vaadet: mis päringu põhjustas, mida server käskis teha ja mis jäi seejärel konkreetsesse brauseriprofiili tegelikult alles. Auditiaruanne nimetab teadlikult ainult tõendatut. Kirjutame näiteks „enne valikut saadeti päring domeenile X”, „vastuses tuvastati küpsise määramise katse” või „Applicationi vaates säilis pärast keeldumist identifikaator Y”. Arendaja saab sellist sammu korrata, jurist näeb tehnilise fakti piire ja pärast parandust saab tulemust objektiivselt võrrelda. Ühest kuvatõmmisest ei järelda me kogu andmetöötlusahelat, sest see võib tõendada ainult kindlat toimingut, olekut ja pildi tegemise aega.

5. Nõusoleku tagasivõtmine on peidetud või tehniliselt poolik

Nõusolek ei ole ühekordne klõps, mille veebileht võib unustada. IKÜM-i artikli 7 lõige 3 annab andmesubjektile õiguse nõusolek igal ajal tagasi võtta ja nõuab, et tagasivõtmine oleks sama lihtne kui nõusoleku andmine; sama põhimõtet selgitab praktiliselt ka Andmekaitse Inspektsioon. Kui nõusoleku saab anda avalehe esimesel vaatel, kuid selle tagasivõtmiseks tuleb otsida privaatsuspoliitika alamjaotist, kirjutada e-kiri või puhastada brauseri seadeid, ei ole mehhanism võrdselt kättesaadav. Tavaline lahendus on püsiv valikute haldamise link veebilehe jaluses. Kontrollime, kas see on leitav igalt lehelt ja ka siis, kui bännerit enam ei näe, sest just selles olekus püüab kasutaja varasemat otsust muuta.

Tehniline test algab teadlikult antud nõusoleku ja päriselt käivitunud märgenditega. Seejärel avab audiitor valikute haldamise, võtab mittehädavajalike kategooriate nõusoleku tagasi ja jätkab veebilehel liikumist, ilma et salvestusruumi käsitsi kustutades loodaks kunstlik algseis. Kontrollida tuleb, kas CMP saadab uuendatud oleku ja märgendid saavad selle kätte, kas uusi nõusolekul põhinevaid andmevooge enam ei käivitata ning mis juhtub kohapeal salvestatud identifikaatoritega. Nii tuleb ilmsiks nupp, mis salvestab uue valiku, kuid ei teavita sellest juba laaditud märgendeid. Samal ajal talletame värskendussündmuste järjekorra, et eristada õigesti salvestatud valikut olukorrast, kus sellest sõltuv märgend saab värskenduse liiga hilja või ei saa seda üldse.

Tagasivõtmine kehtib edaspidi ega kirjuta iseenesest minevikku ümber ega kustuta kõiki varem õiguspäraselt töödeldud andmeid. Pärast tagasivõtmist tuleb peatada edasine sellel nõusolekul põhinev töötlemine, kuid serverisse varem jõudnud andmete säilitamine või kustutamine võib vajada eraldi hindamist. Seetõttu eristame auditiaruandes tulevase andmevoo peatamist varasemate andmete säilitamise küsimusest ega luba, et tehniline valikumuudatus lahendab mõlemad. Paranduse järel peavad kasutajaliides ja integratsioon koos toimima: link peab olema leitav igalt lehelt, CMP peab näitama praegust olekut, muudatus peab jõudma iga sellest sõltuva märgendini ja testi tuleb korrata mitme kategooriakombinatsiooniga. „Keeldu kõigist” võib töötada ka siis, kui eraldi turunduslüliti väljalülitamine ei muuda midagi. Ka brauseri identifikaatorite kustutamist tuleb hinnata nende funktsiooni järgi, mitte lubada, et üks CMP-klõps puhastab automaatselt iga kolmanda osapoole süsteemi.

6. Tavaline ja täiustatud nõusolekurežiim aetakse segi või lubatakse modelleeritud andmeid

Tavaline (Basic) ja täiustatud (Advanced) nõusolekurežiim ei ole ühe lüliti kaks kujundust. Tavalises režiimis ei laadita Google’i märgendeid enne nõusolekut ning Google ei saa seni nende märgendite mõõtmisandmeid; pärast nõusolekut võivad märgendid alustada tavapärast mõõtmist. Täiustatud režiimis laaditakse märgendid algul olekuga, kus salvestamine on keelatud, ja enne nõusolekut võivad need saata küpsisteta signaale. Seetõttu ei tohi seda režiimi kirjeldada olekuna, kus „midagi ei saadeta”, ning tavaline režiim ei ole automaatselt halvem analüütikaseadistus. Erinevus seisneb märgendite tegelikus käitumises enne valikut, mitte bänneri välimuses või ühe seade nimes.

Valik peab põhinema ettevõtte õiguslikul hinnangul ja analüütikavajadustel, mitte eeldusel, et Google’i tootenimi lahendab iseenesest e-privaatsuse või IKÜM-i nõuded. Google’i nõusolekurežiimi dokumentatsioon eristab märgendite blokeerimist tavalises režiimis küpsisteta signaalidest täiustatud režiimis. Auditi käigus kontrollime siiski tegelikku seadistust: kas vaikeolekud jõustuvad enne märgendeid, milline värskendus saadetakse pärast klõpsu ja millised päringud igas olekus päriselt ilmuvad. Tooterežiimi nimi ei ole õiguslik järeldus, seega kirjeldame aruandes kontrollitud voogu ja ettevõtte valitud seadistust, mitte ei anna sellele automaatselt vastavusmärgist.

„Küpsisteta” ei tähenda „teabeta”, mistõttu ei saa signaali nimi aruandes asendada selle sisu ja eesmärgi hindamist. Networki paneelil tuleb vaadata sihtkohta, parameetreid, nõustumisolekut ja algatajat. Google Tag Assistant või nõusolekurežiimi silumistööriistad aitavad kontrollida vaike- ja värskendatud olekuid. Need vaated täiendavad teineteist: esimene näitab konkreetse katse andmevoogu, teine seadistuse loogikat. Kui vaated ei ühti, ei eelistata ilusamat ekraani. Tuleb leida koht, kus vaikeoleku või värskenduse sündmus ei jõudnud märgendini ettenähtud järjekorras.

Ka modelleeritud andmed ei ole täiustatud režiimi sisselülitamise garanteeritud tulemus. Google Analytics 4 käitumispõhise modelleerimise kättesaadavus sõltub Google’i konkreetsele varale seatud andmemahu- ja kvaliteeditingimustest ning funktsioon võib puududa või kaduda, kui tingimused ei ole enam täidetud. Modelleerimine ei taasta üksikute keeldunud kasutajate seansse. Seetõttu lubame pakkumises korrektset seadistust ja kontrollitavat signaalijärjekorda, mitte kindlat modelleeritud andmete mahtu, mille määravad Google’i süsteem ning konkreetse vara sobivus. Auditi tulemus on seega korratav seadistus ja signaalide kontroll, mitte lubadus andmemahu kohta, mida teenusepakkuja ei kontrolli.

7. Test lõpeb esimesel lehel ja esimesel päeval

Avaleht hõlmab harva kogu jälgimisinventuuri. Videomärgend võib laadida alles pärast video käivitamist, kaardiintegratsioon kontaktilehel, reklaamikonversioon pärast vormi saatmist, maksevahend ostukorvi viimases etapis ning vestlus- või isikupärastamisskript alles teatud aja järel. Audiitor, kes avab ühe URL-i, ootab mõne sekundi ja sulgeb skanneri, võib koostada selle ühe vaate kohta tehniliselt õige aruande ning samal ajal veebilehe kohta tervikuna ohtlikult puuduliku aruande. Kõik need olekud tuleb esile kutsuda toiminguga, mis need päriselt käivitab, mitte eeldada, et avalehe inventuur esindab automaatselt kõiki malle ja kasutajateekondi.

Stsenaariumid koostame tegelike kasutajateekondade ja veebilehemallide järgi. Need hõlmavad avalikku lehte, artiklit, kontaktivormi, kontoala, ostuprotsessi, manustatud sisu ning kõiki olulisi keele- või piirkonnaversioone. Kontrollida tuleb ka mobiilivaadet, kus CMP-nupud võivad kattuda või valikute link muutuda kättesaamatuks, kuigi arvutivaates töötab kõik. Automaatne veebilehe läbivaatus katab rohkem lehti, käsitsi stsenaarium aga avab olekud, mida robot ilma kontole ligipääsu, klõpsu või sisendita kunagi ei näe. Keele- ja piirkonnaversioonid, nagu ka mobiilivaade, ei ole dekoratiivsed koopiad, kui neis erineb integratsioonide laadimine või kasutajale antud valikute kättesaadavus.

Ühekordne audit ei kata aja jooksul tekkivaid muudatusi. Uus turundusmärgend, muudetud CMP-mall või imporditud Google Tag Manageri konteiner võib varem õige järjekorra lõhkuda ilma bänneri nähtava muutuseta. Seetõttu tuleb iga uut tööriista testida enne avaldamist ja hiljem sama testi korrata. Seda distsipliini tasub kavandada juba veebiarenduslepingus, nagu selgitasime artiklis 10 viga veebilehe tellimisel. Meie auditiprotsessis tehakse pärast juurutamist kordusskannimine 30 ja 180 päeva pärast, kasutades samu stsenaariume ja tõendivälju. Nii näeme, kas parandus peab tavapärase sisuhalduse käigus vastu ning kas hiljem on lisandunud uusi tööriistu või seadistusnihkeid. Esimene tähtaeg näitab, kas juurutus pidas vastu igapäevases sisuhalduses, teine paljastab hilisemad muudatused. Kordustestis võrdleme kindlat päringut, salvestusruumi ja nõustumisolekut algse leiuga, mitte ei piirdu muljega, et „nüüd paistab parem”.

Mida saate küpsiste ja jälgimise tehnilisest auditist

Auditi esimene tulemus on kontrollitud küpsiste, salvestusruumide, märgendite ja kolmandate osapoolte päringute inventuur. Iga leid seotakse lehe, kasutaja toimingu ja nõustumisolekuga ning selle kõrval märgitakse tõend ja selle ulatus: Networki kirje, Set-Cookie katse, Applicationi vaates tegelikult salvestatud küpsis, localStorage’i kirje või CMP-sündmus. Nii saab arendaja korratava vea, mitte ebamäärase märkuse „tehke GDPR korda”, ning privaatsuse eest vastutav inimene näeb, millised faktid vajavad veel õiguslikku otsust. Iga leiu juures on ka kordamisjuhis, et pärast juurutamist saaks kontrollida sama lehte, valikut, päringut ja salvestustulemust.

Teine osa on juurutamine. Seadistame CMP-kategooriad ning Google Tag Manageri vaikeolekute ja värskenduste järjekorra, konfigureerime Google Analytics 4, Google Adsi, Meta Pixeli ja teiste tööriistade nõusolekukontrollid ning koostame küpsiste deklaratsiooni ja privaatsuspoliitika teksti. Tavalise (Basic) või täiustatud (Advanced) nõusolekurežiimi valime teie õigusliku hinnangu ja analüütikavajaduste järgi. Me ei esitle täiustatud režiimi universaalselt õige valikuna ega luba modelleeritud andmeid, kui konkreetne Google Analyticsi vara ei vasta Google’i tingimustele. Juurutuse tulemust kontrollime samades nõustumisolekutes, milles algne leid talletati, et seadistusmuutust saaks põhjendada võrreldavate tõenditega.

Teenuse hind on alates 800 € ja töö kestab 1–4 nädalat, olenevalt veebilehe mahust, keelte ja mallide arvust, CMP ning märgendikonteinerite keerukusest ja vajalike integratsioonide hulgast. Enne töö algust eristame hinnas ja ajakavas selgelt auditi tõendid, tehnilised parandused ning küsimused, mille peab lahendama ettevõtte jurist või andmekaitsespetsialist. 30 ja 180 päeva pärast teeme talletatud stsenaariumide põhjal kordusskannimise. Nii kehtivad hind ja tähtaeg selgelt nimetatud tehnilisele ulatusele, mitte ebamäärasele lubadusele korrastada kogu ettevõtte andmekaitse.

Kui vajate „veebilehe GDPR-i auditit”, lepime esmalt kokku, et siin tähendab see küpsiste, jälgimise, CMP ja nõusolekurežiimi ulatust, mitte kogu organisatsiooni IKÜM-i vastavuskontrolli. Lubame ainult seda, mida saame tehniliselt tõendada: veebilehe käitumist enne valikut, pärast keeldumist, pärast nõusolekut ja pärast selle tagasivõtmist, tööriistadele saadetud signaale ning kohti, kus tõendist veel õiguslikuks järelduseks ei piisa. Selline eristus võimaldab tehnilise töö lõpetada kontrollitava tulemusega ja suunata õiguslikud küsimused inimesele, kes vastutab isikuandmete laiema töötlemise eest. Küpsiste ja jälgimise auditi tellimiseks saatke meile veebilehe aadress ning kasutatava CMP või märgendihalduri nimi.