Slapukų banerio auditas: ar jis tikrai blokuoja nebūtinus skriptus? 7 dažnos klaidos
Mygtukas „Atmesti“ dar neįrodo, kad sekimas sustoja. Praktinis slapukų banerio tikrinimo vadovas su Network, Application, sutikimo režimu ir kartotiniais testais.
Mygtukas „Atmesti“ dar neįrodo, kad sekimas sustoja. Praktinis slapukų banerio tikrinimo vadovas su Network, Application, sutikimo režimu ir kartotiniais testais.
Jūs atidarote svetainę naujame naršyklės profilyje, paspaudžiate „Atmesti“ ir matote, kad pranešimas apie slapukus dingsta; iš šalies viskas atrodo tvarkinga, tačiau slapukų banerio auditas prasideda būtent šią akimirką: ar dar prieš spustelėjimą jau buvo išsiųsta užklausa reklamos platformai, ar atsakyme mėginta nustatyti identifikatorių, kuris liko naršyklės saugykloje, ir ar po atsisakymo žymos gavo tinkamą sutikimo būseną? Mygtukas tėra valdymo skydelis, todėl per auditą reikia patikrinti, ar po juo iš tiesų sujungti laidai, nes sutikimų valdymo platforma (CMP) gali dar nespėti nustatyti numatytosios būsenos, kai žymų tvarkytuvė jau vykdo pirmąją taisyklę.
Vizuali banerio apžiūra arba žalia automatinio skenerio varnelė nepasako, kas įvyko per pirmąsias įkėlimo sekundes, taip pat neatskleidžia, kuris skriptas pradėjo veiksmą, kokia sutikimo būsena tuo metu jam buvo prieinama ir ar matoma galutinė būsena atitinka visą ankstesnę įvykių seką. Todėl vienoje laiko juostoje lyginame svetainės elgseną prieš pasirinkimą, atmetus visas nebūtinas kategorijas, davus sutikimą ir vėliau jį atšaukus; kiekvienu atveju vertiname tinklo užklausas, atsakymų antraštes, slapukus, localStorage bei kitas saugyklas, sutikimo signalų seką ir konkretaus veiksmo iniciatorių. Tik toks palyginimas leidžia atskirti tinkamą konfigūraciją nuo banerio, kuris paprasčiausiai užsidaro.
Tai techninis straipsnis, o ne individuali teisinė išvada: jame parodoma, kaip surinkti patikrinamus faktus ir nedaryti išvadų, kurių įrodymai nepagrindžia. Jei svetainėje naudojami Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, įterpti vaizdo įrašai, pokalbių langas ar kitos trečiųjų šalių priemonės, viename ekrane matomas slapukų sąrašas tebus dalis viso vaizdo, todėl svarbiausias klausimas yra ne „ar baneris įdiegtas?“, o „ką svetainė daro kiekvieną naudotojo pasirinkimo akimirką?“.
Ką tikrina slapukų banerio auditas — ir ko jis nepatvirtina
Auditas tikrina techninę sutikimo grandinę nuo pirmosios puslapio užklausos iki būsenos pasikeitimo po naudotojo pasirinkimo, tačiau jos negalima vertinti vien pagal galutinę būseną, nes pradinė įkėlimo seka jau galėjo paleisti veiksmą, kurio vėliau užvertas baneris nebeatšauks. Auditas apima skriptų įkėlimo seką, tinklo ryšius, slapukus ir kitas saugyklas, CMP signalus, Google Consent Mode konfigūraciją, kategorijų veikimą ir galimybę vėliau pakeisti pasirinkimą; jo rezultatas yra slapukų ir sekimo sluoksnio įrodymų visuma, o ne pažymėjimas, kad visas organizacijoje atliekamas asmens duomenų tvarkymas teisiškai nepriekaištingas.
Teisiniu požiūriu reikia atskirti du tarpusavyje susijusius lygmenis: Lietuvoje Elektroninių ryšių įstatymo 73 straipsnio 4 dalis reglamentuoja informacijos saugojimą abonento ar faktinio viešųjų elektroninių ryšių paslaugų gavėjo galiniame įrenginyje ir prieigą prie jame jau saugomos informacijos, taip nacionalinėje teisėje įgyvendindama ePrivacy direktyvos 5 straipsnio 3 dalį; ši techninė taikymo sritis neapsiriboja failais, kurių pavadinime yra žodis „cookie“. BDAR tampa aktualus, kai tvarkomi asmens duomenys, be to, jis nustato galiojančio sutikimo kokybės ir jo atšaukimo principus, todėl vieno lygmens techninė patikra nepakeičia kito lygmens teisinio vertinimo. Audito ataskaitoje abu lygmenis įvardijame atskirai, kad pastebėtas techninis faktas nebūtų pateiktas kaip platesnė teisinė išvada.
Valstybinė duomenų apsaugos inspekcija primena, kad nebūtinos sekimo priemonės negali būti aktyvinamos negavus lankytojo sutikimo, o neveikiantis atsisakymas nesukuria laisva valia duoto sutikimo, tačiau ir kategorijos pavadinimas „būtini“ pats savaime nieko neįrodo. Būtinosios išimties taikymo sąlygas reikia vertinti siaurai: konkretus veiksmas turi būti būtinas naudotojo aiškiai paprašytai informacinės visuomenės paslaugai teikti arba informacijai elektroninių ryšių tinklu perduoti, o ne vien patogus analitikai, rinkodarai ar svetainės savininko vidaus poreikiams; auditorius šį veiksmą turi susieti su funkcija, dėl kurios jis būtinas, ir kartu patikrinti, ar toje pačioje kategorijoje nepaslėptas visai kitas tikslas, kurio naudotojo paprašyta funkcija nepateisina.
Paieškoje vartojama frazė „svetainės BDAR auditas“ šioje paslaugoje reiškia tik slapukų, sekimo ir sutikimų valdymo apimtį, nes už jos ribų lieka kitų procesų teisiniai pagrindai, duomenų subjektų prašymai, sutartys ir vidaus valdymas. Mūsų slapukų ir sekimo audito paslauga suteikia techninius faktus, kuriais remdamasis teisininkas ar duomenų apsaugos specialistas gali pagrįstai įvertinti būtent šią svetainės dalį, tačiau BDAR atitiktis nėra vienas jungiklis, kurį techninis skeneris galėtų įjungti visai organizacijai. Tokia riba nėra atsakomybės išlyga; ji aiškiai pasako, ką ataskaita įrodo ir kuriuos klausimus dar reikia spręsti už techninio audito ribų.
Kaip auditas surenka įrodymus, o ne vien skenerio rezultatą
Geras testas prasideda švariame naršyklės profilyje, kuriame nėra anksčiau išsaugoto sutikimo, svetainės slapukų ar plėtinių sukurtų užklausų; dar prieš bet kurį spustelėjimą įjungiamas Network žurnalas, patikrinama Application skiltis ir užfiksuojama pradinė būsena. Tada ta pati veiksmų seka kartojama po atsisakymo, po sutikimo ir po jo atšaukimo, kiekvieną scenarijų pradedant nuo dokumentuotos būsenos ir išsaugant visą žurnalą, nes priešingu atveju vakarykštis pasirinkimas gali atrodyti kaip šiandienos banerio klaida arba, atvirkščiai, paslėpti tikrąjį trūkumą.
Network įrašas įrodo, kad naršyklė bandė susisiekti su konkrečiu adresu, ir leidžia peržiūrėti iniciatorių, būseną, užklausos bei atsakymo antraštes ir siunčiamą informaciją, tačiau dar neįrodo, kad slapukas buvo išsaugotas. Atsakymo antraštė Set-Cookie rodo serverio bandymą jį nustatyti, bet naršyklė gali šį bandymą blokuoti, o JavaScript gali įrašyti document.cookie arba localStorage ir be tokios antraštės; todėl faktinį rezultatą būtina patikrinti Application rodinyje, ir nė vienas požymis negali pakeisti kitų. Matoma užklausa analitikos domenui yra duomenų srauto bandymo įrodymas, o ne automatinis įrodymas, kad analitikos slapukas sėkmingai nustatytas ar kad serveris gavo konkretų asmens duomenų rinkinį.
Prie kiekvieno radinio užrašome patikrintą URL ir naudotojo kelią, laiką, įrenginio bei naršyklės aplinką, pasirinktą sutikimo būseną, užklausos iniciatorių, paskirties vietą, siuntimo rezultatą ir saugyklų pokyčius, kad po pataisymo būtų galima tiksliai pakartoti tą patį testą. Automatinis skenavimas pateikia platų pradinį inventorių, tačiau nepereina visų meniu, pirkimo etapų, prisijungimo sričių, kalbinių versijų ir dinamiškai atveriamų integracijų, taip pat negali patikimai nustatyti tikslo vien iš failo pavadinimo ar domeno, todėl po jo atliekami rankiniai scenarijai ir kalbamasi su priemonių valdytojais. Taip išsiaiškiname, kas priemonę įdiegė, kokiu tikslu, kuriame žymų konteineryje ji veikia ir kokiam sutikimo signalui turi paklusti, kad techninį radinį būtų galima susieti su numatyta konfigūracija. Įrodymas be konteksto tėra ekrano kopija; kontekstas be įrodymo tėra pažadas.
1. Nebūtini skriptai paleidžiami prieš naudotojo pasirinkimą
Kritinė sekos klaida atsiranda tada, kai CMP baneris vizualiai pasirodo greitai, bet analitikos ar reklamos žyma jau paleista: naudotojas dar skaito mygtukų tekstą, o naršyklė jau susisiekė su trečiąja šalimi arba įrašė identifikatorių. Valstybinės duomenų apsaugos inspekcijos išaiškinimas šiuo klausimu nedviprasmiškas: nebūtini slapukai negali būti aktyvinami prieš pasirinkimą, todėl techninė patikra prasideda nuo pirmojo dokumento įkėlimo, o ne nuo akimirkos, kai auditoriui pavyksta rasti ir paspausti „Atmesti“.
Google Tag Manager aplinkoje dažna priežastis yra netinkama įvykių seka, nes numatytoji sutikimo būsena turi būti nustatyta prieš žymas, naudojant sutikimo inicijavimo aktyviklį („Sutikimo inicijavimas – visi puslapiai“) arba kitą sprendimą, kuris užtikrina tokią pačią tvarką, o tik po naudotojo veiksmo siunčiamas būsenos atnaujinimas. Jei numatytoji būsena gaunama per vėlai, žyma trumpą akimirką gali matyti neapibrėžtą ar anksčiau išsaugotą būseną ir būti paleista, tačiau greitai užsiveriantis baneris šių lenktynių neištaiso, nes problema slypi vykdymo sekoje, o ne animacijoje.
Frazę „slapukai įkeliami prieš sutikimą“ audito ataskaitoje reikia išskaidyti tiksliau: gali būti įkeltas pats skriptas, išsiųsta tinklo užklausa ar signalas be slapukų, pamėginta nustatyti Set-Cookie arba faktiškai išsaugotas identifikatorius, o kiekvienas iš šių veiksmų turi kitokią įrodomąją reikšmę. Advanced Consent Mode atveju kai kurios Google žymos, esant uždraustai saugyklai, gali būti įkeltos ir siųsti signalus be slapukų, todėl vien skripto buvimo nepakanka nei pažeidimui, nei atitikčiai konstatuoti.
Taisymas prasideda nuo priemonių žemėlapio ir vieno aiškaus būsenų modelio: kurios žymos gali veikti be pasirinkimo, kurioms reikia konkrečios kategorijos ir kuris įvykis pakeičia numatytąją būseną. Pakeitus konfigūraciją, patikra kartojama švariame profilyje su išsaugotu Network žurnalu, ypač stebint pirmąsias užklausas ir jų iniciatorius; jei klaida pasirodo tik kartais, tai paprastai rodo CMP, žymų konteinerio ir svetainės kodo lenktyniavimo sąlygą, kurią reikia pašalinti pačioje įkėlimo sekoje, o ne paslėpti vizualiai greitesniu baneriu.
2. „Atmesti“ pakeičia sąsają, bet ne duomenų srautą
Mygtukas gali užverti banerį, papilkinti pasirinkimą ir net išsaugoti reikšmę „denied“, o trečiųjų šalių žymos tebeveiks kaip anksčiau, todėl atsisakymo testas nėra klausimas apie dingusį užrašą — tai dviejų būsenų palyginimas. Prieš atmetant visas nebūtinas kategorijas ir po to fiksuojame užklausas bei saugyklas, paskui tikriname, ar atitinkamos žymos negauna jas paleidžiančio įvykio, ar neatsiranda naujų identifikatorių ir ar atsisakymas išlieka per vėlesnes puslapių peržiūras. Ankstesnis seansas lengvai sugadina šį testą: jei vakar sutikimas buvo duotas, šiandien paspaudus „Atmesti“ puslapis iš pradžių gali būti įkeltas su vakarykšte būsena ir tik paskui ją pakeisti, kai pirmoji užklausa jau išsiųsta. Rankinis slapukų trynimas tarp žingsnių taip pat sukuria dirbtinę švarą ir nepatikrina tikrojo atšaukimo mechanizmo, todėl pradinis atsisakymas ir vėlesnis atšaukimas yra atskiri scenarijai: pirmasis prasideda be sprendimo, antrasis — sąmoningai davus sutikimą, o jų rezultatų negalima suplakti vienoje ekrano kopijoje.
Net ir po atsisakymo svetainė gali atlikti veiksmus, kurie iš tiesų būtini naudotojo aiškiai paprašytai saugumo, krepšelio ar kitai funkcijai, todėl teiginys „bet kuri užklausa po atmetimo yra bloga“ būtų toks pat netikslus kaip žalia banerio varnelė. Reikia nustatyti kiekvieno likusio ryšio tikslą, iniciatorių ir saugojimo veiksmą, tada sukonfigūruoti CMP taip, kad atmetimas pirmiausia atnaujintų sutikimo būseną, o žymos naudotų integruotas arba aiškiai nurodytas sutikimo patikras; veikiantis mygtukas yra tas, kuris keliuose puslapiuose nuspėjamai pakeičia prie jo prijungtą duomenų srautą. Jei atsisakymas sustabdo reklamos žymą, bet palieka pirmosios šalies seanso slapuką, tai gali būti laukiamas rezultatas; jei viena kategorija nepastebimai aktyvina kitą, konfigūracija nėra patikima, o po pataisymo atsisakymą turi būti galima kartoti keliuose puslapiuose nevalant saugyklos rankiniu būdu ir kaskart gauti vienodą, pakartojamą bei įrodomą būseną.
3. Kategorijos ir slapukų politika neatitinka faktinio inventoriaus
Baneris gali veikti techniškai drausmingai ir vis tiek klaidinti, jei kategorijos ar politika aprašo kitą svetainę, kaip neretai nutinka nukopijavus šabloną, perėmus žymų konteinerį arba pridėjus naują priemonę, bet neatnaujinus dokumentų. Politikoje tuomet lieka seniai nebenaudojamas slapukas, o vaizdo įrašų leistuvas, pokalbių langas ar reklamos konversijų žyma apskritai nepaminėti, tad naudotojas renkasi remdamasis neišsamia informacija. Tokioje situacijoje įmonė negali pagrįsti, kuris gavėjas gauna duomenis, kokiu tikslu tai vyksta ir kiek laiko identifikatorius išlieka.
Valstybinė duomenų apsaugos inspekcija slapukų politiką sieja su faktiniu inventoriumi, kuriame nurodytas tikslas, paslaugų teikėjas arba gavėjas ir saugojimo terminas, o ne vien tai, ką automatiškai atpažino CMP katalogas. To paties pavadinimo slapukas skirtingose konfigūracijose gali būti naudojamas kitaip, o individualiai sukurtam pirmosios šalies identifikatoriui viešoje duomenų bazėje aprašo gali apskritai nebūti, todėl per auditą techninis objektas susiejamas su tikruoju svetainės savininko tikslu ir atsakinga priemone. Audito paskirtis nėra perrašyti katalogo spėjimą, o patikrinti, ar konfigūracija, gavėjas ir terminas atitinka tai, ką įmonė iš tikrųjų naudoja ir geba paaiškinti.
Inventorius nesibaigia ties Cookies skirtuku: reikia patikrinti localStorage, sessionStorage, IndexedDB, pikselių ir serverio užklausas, taip pat URL ar formų srautuose naudojamus identifikatorius, jei jie pasitelkiami sekimui. Europos duomenų apsaugos valdybos (EDAV) techninėse gairėse paaiškinta, kad ePrivacy taikymo sritis nėra susieta su viena saugojimo technologija, todėl politika, kurioje žadama „mes nenaudojame slapukų“, dar neatsako, ar svetainė kitu būdu pasiekia galiniame įrenginyje esančią informaciją arba siunčia matavimo signalus. Taigi slapukų pavadinimų sąrašas yra inventorizacijos pradžia, o ne išsami technologijų, galinčių saugoti, nuskaityti ar siųsti identifikatorius, apžvalga.
Praktiškas sprendimas yra vienas bendras registras, pagal kurį prižiūrima CMP klasifikacija, techninė politikos lentelė ir audito scenarijai; kiekviename jo įraše nurodomas priemonės savininkas įmonėje, tiekėjas, tikslas, aktyvinanti sutikimo būsena, naudojama saugykla, gavėjas ir terminas. Tada naujos žymos pridėjimas nebėra tik darbas Google Tag Manager konteineryje — tai kontroliuojamas pakeitimas, dėl kurio prieš paskelbiant reikia atnaujinti naudotojui pateikiamą informaciją ir testavimo atvejus. Tas pats registras po pakeitimo suteikia kartotiniam testui atskaitos tašką ir parodo, kas įmonėje atsako už neatitikties pašalinimą.
4. Viena Network užklausa supainiojama su slapuko įrodymu
Network skydelyje matomas analitikos domenas yra svarbus radinys, tačiau vien iš jo negalima daryti išvados „slapukas buvo nustatytas“: įrašas įrodo bandymą užmegzti ryšį ir rodo, ką naršyklė pridėjo prie URL, antraščių ar užklausos turinio, bet nesėkminga, užblokuota ar atšaukta užklausa nėra tas pats, kas sėkmingai serverio gauti duomenys. Tikrinant slapuką reikia nustatyti, ar užklausos antraštėje buvo Cookie, ar atsakyme pasirodė Set-Cookie, ar naršyklė jo neužblokavo ir ar įrašas iš tiesų pateko į saugyklą. Užklausa gali būti užblokuota ar atšaukta dar prieš serveriui gaunant duomenis, ir ši įrodymo riba turi atsispindėti radinio formuluotėje, nesuplakant ryšio bandymo, siuntimo rezultato ir saugojimo į vieną teiginį.
Priešinga išvada taip pat nėra saugi, nes užklausoje be slapuko gali būti sutikimo būsena ir kiti parametrai, o svetainė gali naudoti localStorage identifikatorių, URL parametrą ar kitą techninį būdą; vien slapuko nebuvimas ryšio automatiškai nepaverčia anoniminiu ar tuščiu. Savo ruožtu Set-Cookie yra serverio nurodymas naršyklei, o ne garantija, kad įrašas išsaugotas, nes naršyklė gali jį atmesti dėl domeno, saugumo atributų, trečiųjų šalių apribojimų ar kitos politikos, o JavaScript nustatytas pirmosios šalies slapukas gali atsirasti be šios atsakymo antraštės. DevTools taip pat rodo blokavimo priežastis, todėl Set-Cookie buvimą reikia vertinti kartu su naršyklės sprendimu ir faktine Application būsena. Jei Cookies lentelėje nėra naujos eilutės, signalo nepervadiname „duomenų nebuvimu“, bet patikriname URL, antraštes, parametrus ir kitas saugyklas.
Patikimiausias metodas vienoje laiko juostoje sujungia tris vaizdus: kas inicijavo užklausą, ką serveris nurodė padaryti ir kas paskui faktiškai išliko konkrečiame naršyklės profilyje, o audito ataskaitoje sąmoningai įvardijama tik tai, kas įrodyta. Joje rašome „prieš pasirinkimą domenui X išsiųsta užklausa“, „atsakyme nustatytas bandymas įrašyti slapuką“ arba „Application rodinyje po atmetimo liko identifikatorius Y“, nes kūrėjas gali pakartoti tokį veiksmą, teisininkas mato techninio fakto ribas, o po pataisymo rezultatą galima objektyviai palyginti. Iš vienos ekrano kopijos nedarome išvadų apie visą duomenų tvarkymo grandinę, nes ji gali įrodyti tik konkretų veiksmą, būseną ir laiką, kuriuo buvo padaryta.
5. Sutikimo atšaukimas paslėptas arba techniškai neužbaigtas
Sutikimas nėra vienkartinis spustelėjimas, kurį svetainė gali pamiršti: BDAR 7 straipsnio 3 dalyje numatyta galimybė bet kada jį atšaukti ir reikalaujama, kad atšaukti būtų taip pat lengva kaip duoti, o šį principą praktiškai aiškina ir Valstybinė duomenų apsaugos inspekcija. Jei sutikimą galima duoti pirmajame pradžios puslapio ekrane, bet norint jį atšaukti reikia ieškoti privatumo politikos poskyrio, rašyti el. laišką arba valyti naršyklės nustatymus, mechanizmas nėra vienodai prieinamas; įprastas sprendimas yra nuolatinė pasirinkimų valdymo nuoroda svetainės poraštėje. Tikriname, ar ji randama iš kiekvieno puslapio ir tada, kai banerio nebematyti, nes būtent tokioje būsenoje naudotojas mėgina pakeisti ankstesnį sprendimą.
Techninis testas pradedamas sąmoningai davus sutikimą ir iš tikrųjų aktyvinus žymas, tada auditorius atveria pasirinkimų valdymą, atšaukia nebūtinas kategorijas ir toliau naršo svetainėje, nesukurdamas dirbtinės pradžios rankiniu būdu išvalyta saugykla. Reikia patikrinti, ar CMP išsiunčia atnaujintą būseną ir žymos ją gauna, ar nebeprasideda nauji sutikimu grindžiami duomenų srautai ir kas nutinka vietoje saugomiems identifikatoriams, nes būtent taip aptinkamas mygtukas, kuris išsaugo naują pasirinkimą, tačiau nepraneša apie jį jau įkeltoms žymoms. Kartu fiksuojame pakeitimo įvykių seką, kad tinkamai išsaugotą pasirinkimą atskirtume nuo situacijos, kai nuo jo priklausanti žyma atnaujinimą gauna per vėlai arba jo visai negauna.
Atšaukimas galioja į ateitį ir pats savaime nepakeičia praeities ar neištrina visų anksčiau teisėtai tvarkytų duomenų, todėl po jo turi būti sustabdytas tolesnis šiuo sutikimu grindžiamas tvarkymas, o anksčiau serverio gautų duomenų saugojimui ar ištrynimui gali reikėti atskiro vertinimo. Dėl to audito ataskaitoje atskiriame tolesnio duomenų srauto sustabdymą nuo ankstesnių duomenų saugojimo klausimo ir nežadame, kad techninis pasirinkimo pakeitimas išspręs abu. Taisymas turi sujungti sąsają su integracija: nuoroda turi būti randama kiekviename puslapyje, CMP turi rodyti esamą būseną, pakeitimas turi pasiekti kiekvieną nuo jo priklausomą žymą, o testas turi būti pakartotas su keliomis kategorijų kombinacijomis, nes „atmesti viską“ gali veikti, nors atskiro rinkodaros jungiklio išjungimas nieko nekeičia. Naršyklės identifikatorių trynimą irgi reikia vertinti pagal jų funkciją, o ne žadėti, kad vienas CMP spustelėjimas automatiškai išvalys kiekvienos trečiosios šalies sistemą.
6. Painiojami Basic ir Advanced Consent Mode arba žadami sumodeliuoti duomenys
Basic ir Advanced Consent Mode nėra du to paties jungiklio dizainai: Basic režimu Google žymos iki sutikimo neįkeliamos ir Google iki tol negauna šių žymų matavimo duomenų, o davus sutikimą jos gali pradėti įprastą matavimą. Advanced režimu žymos įkeliamos su iš pradžių uždrausta saugykla ir, kol sutikimas neduotas, gali siųsti signalus be slapukų, todėl šio režimo negalima apibūdinti kaip būsenos, kai „niekas nesiunčiama“, o Basic nėra automatiškai prastesnė analitikos konfigūracija. Skirtumas yra faktinė žymų elgsena prieš pasirinkimą, o ne banerio išvaizda ar vieno nustatymo pavadinimas.
Pasirinkimas turi būti grindžiamas įmonės teisiniu vertinimu ir analitikos poreikiais, o ne prielaida, kad Google produkto pavadinimas savaime išsprendžia ePrivacy arba BDAR reikalavimus. Google sutikimo režimo dokumentacijoje Basic režimo žymų blokavimas atskiriamas nuo Advanced režimo signalų be slapukų, tačiau per auditą tikriname faktinę konfigūraciją: ar numatytosios būsenos įsigalioja prieš žymas, koks atnaujinimas išsiunčiamas po spustelėjimo ir kokios užklausos iš tiesų pasirodo kiekvienoje būsenoje. Produkto režimo pavadinimas nėra teisinė išvada, todėl ataskaitoje aprašome patikrintą srautą ir įmonės pasirinktą konfigūraciją, o ne automatiškai suteikiame jai atitikties žymą.
„Be slapukų“ nereiškia „be informacijos“, todėl signalo pavadinimas ataskaitoje negali pakeisti jo turinio ir tikslo vertinimo. Network skydelyje reikia peržiūrėti paskirties vietą, parametrus, sutikimo būseną ir iniciatorių, o Google Tag Assistant arba Consent Mode derinimo priemonės padeda patikrinti numatytąsias ir atnaujintas būsenas; šie vaizdai papildo vienas kitą, nes pirmasis atskleidžia konkretaus bandymo duomenų srautą, o antrasis — konfigūracijos logiką. Jei abu vaizdai nesutampa, pirmenybė neteikiama gražiau atrodančiam ekranui: reikia rasti vietą, kur numatytosios būsenos ar atnaujinimo įvykis nepasiekė žymos numatyta seka.
Sumodeliuoti duomenys taip pat nėra garantuotas Advanced režimo įjungimo rezultatas, nes Google Analytics 4 elgsenos modeliavimo prieinamumas priklauso nuo Google nustatytų nuosavybės, duomenų kiekio ir kokybės sąlygų, o funkcija gali būti nepasiekiama arba dingti, kai šios sąlygos nebetenkinamos. Modeliavimas neatkuria atskirų nesutikusių naudotojų seansų, todėl pasiūlyme žadame tinkamą konfigūraciją ir patikrinamą signalų seką, o ne konkretų sumodeliuotų duomenų kiekį, kurį lemia Google sistema ir atitinkamos nuosavybės tinkamumas. Taigi audito rezultatas yra atkuriama konfigūracija ir signalų patikra, o ne pažadas dėl duomenų kiekio, kurio paslaugos teikėjas nekontroliuoja.
7. Testas baigiasi pirmame puslapyje ir pirmą dieną
Pradžios puslapis retai apima visą sekimo inventorių: vaizdo įrašo žyma gali būti įkelta tik paleidus įrašą, žemėlapio integracija — kontaktų puslapyje, reklamos konversija — pateikus formą, mokėjimo priemonė — paskutiniame krepšelio etape, o pokalbių ar suasmeninimo skriptas — praėjus tam tikram laikui. Auditorius, kuris atveria vieną URL, kelias sekundes palaukia ir uždaro skenerį, gali parengti techniškai teisingą ataskaitą apie tą vieną vaizdą ir kartu pavojingai neišsamią ataskaitą apie visą svetainę. Kiekvieną iš šių būsenų reikia atverti veiksmu, kuris ją iš tikrųjų aktyvina, o ne daryti prielaidą, kad pradžios puslapio inventorius automatiškai atspindi visus šablonus ir naudotojų kelius.
Scenarijus sudarome pagal tikrus naudotojų kelius ir svetainės šablonus, įtraukdami viešą puslapį, straipsnį, kontaktų formą, paskyros sritį, pirkimo procesą, įterptą turinį ir kiekvieną svarbią kalbos ar regiono versiją; taip pat reikia patikrinti mobilųjį išdėstymą, kuriame CMP mygtukai gali persidengti arba pasirinkimų nuoroda tapti nepasiekiama, nors kompiuteryje viskas veikia. Automatinis svetainės nuskaitymas suteikia aprėptį, o rankinis scenarijus atveria būsenas, kurių robotas be paskyros, spustelėjimo ar įvesties niekada nepamatys. Kalbų ir regionų versijos, kaip ir mobilusis išdėstymas, nėra dekoratyvios kopijos, jei jose skiriasi integracijų įkėlimas ar naudotojui prieinami pasirinkimai.
Vienkartinis auditas neapima laikui bėgant atsirandančių pokyčių, nes nauja rinkodaros žyma, pakeistas CMP šablonas arba importuotas Google Tag Manager konteineris gali suardyti anksčiau tinkamą seką be jokio matomo banerio pakeitimo, todėl kiekvieną naują priemonę reikia išbandyti prieš paskelbiant ir vėliau palyginti pakartotinai. Šią drausmę verta numatyti jau svetainės kūrimo sutartyje, kaip aiškinome straipsnyje apie 10 klaidų užsakant svetainės kūrimą; mūsų audito procese po diegimo numatytas pakartotinis skenavimas po 30 ir 180 dienų, naudojant tuos pačius scenarijus ir įrodymų laukus, kad matytume, ar pataisymas išlieka veiksmingas realiame svetainės atnaujinimo cikle ir ar vėliau neatsirado naujų priemonių arba konfigūracijos nuokrypių. Pirmoji pakartotinė patikra parodo, ar diegimas atlaikė kasdienius svetainės atnaujinimus, o antroji atskleidžia vėlesnius pakeitimus; per kartotinį testą konkrečią užklausą, saugyklą ir sutikimo būseną lyginame su pradiniu radiniu, o ne pasitenkiname įspūdžiu, kad „dabar atrodo geriau“.
Ką gaunate atlikus techninį slapukų ir sekimo auditą
Pirmasis audito rezultatas yra patikrintas slapukų, saugyklų, žymų ir trečiųjų šalių užklausų inventorius, kuriame kiekvienas radinys susietas su puslapiu, naudotojo veiksmu ir sutikimo būsena, o šalia nurodytas įrodymas bei jo riba: Network įrašas, Set-Cookie bandymas, faktinis slapukas Application rodinyje, localStorage įrašas arba CMP įvykis. Taip kūrėjas gauna pakartojamą klaidą, o ne miglotą pastabą „sutvarkykite BDAR“, o už privatumą atsakingas asmuo mato, dėl kurių faktų dar reikia teisinio sprendimo. Kiekvienam radiniui taip pat išlieka pakartojimo kelias, kad po diegimo būtų galima patikrinti tą patį puslapį, pasirinkimą, užklausą ir saugyklos rezultatą.
Antroji dalis yra diegimas: sutvarkome CMP kategorijas ir Google Tag Manager numatytųjų būsenų bei atnaujinimų seką, sukonfigūruojame Google Analytics 4, Google Ads, Meta Pixel ir kitų priemonių sutikimo patikras, taip pat parengiame slapukų deklaracijos bei privatumo politikos tekstą. Basic arba Advanced Consent Mode pasirenkame pagal Jūsų teisinį vertinimą ir analitikos poreikius, nepateikdami Advanced kaip visuotinai tinkamo varianto ir nežadėdami sumodeliuotų duomenų, jei konkreti Google Analytics nuosavybė neatitinka Google sąlygų. Diegimo rezultatą tikriname tomis pačiomis sutikimo būsenomis, kuriomis buvo užfiksuotas pradinis radinys, kad konfigūracijos pakeitimą būtų galima pagrįsti palyginamais įrodymais.
Paslaugos kaina yra nuo 800 €, o darbai trunka 1–4 savaites, priklausomai nuo svetainės apimties, kalbų ir šablonų skaičiaus, CMP bei žymų konteinerių sudėtingumo ir reikalingų integracijų skaičiaus. Dar prieš pradėdami kainoje ir grafike aiškiai atskiriame audito įrodymus, techninius taisymus ir klausimus, kuriuos turi išspręsti įmonės teisininkas arba duomenų apsaugos specialistas, o po 30 ir 180 dienų atliekame pakartotinį skenavimą pagal užfiksuotus scenarijus. Taigi kaina ir terminas taikomi aiškiai įvardytai techninei apimčiai, o ne neapibrėžtam pažadui sutvarkyti visą įmonės duomenų apsaugą.
Jei Jums reikia „svetainės BDAR audito“, pirmiausia susitariame, kad čia ši frazė reiškia slapukų, sekimo, CMP ir Consent Mode apimtį, o ne visos organizacijos išsamią BDAR atitikties patikrą, todėl žadame tik tai, ką galime techniškai įrodyti: svetainės elgseną prieš pasirinkimą, po atmetimo, po sutikimo ir po jo atšaukimo, priemonėms išsiųstus signalus ir vietas, kuriose įrodymų dar nepakanka teisinei išvadai. Toks atskyrimas leidžia techninį darbą užbaigti patikrinamu rezultatu, o teisinius klausimus perduoti asmeniui, atsakingam už platesnį asmens duomenų tvarkymą. Užsisakyti slapukų ir sekimo auditą galite atsiuntę svetainės adresą ir nurodę naudojamą CMP arba žymų tvarkytuvę.
Dažniausiai užduodami klausimai.
Ką tikrina slapukų banerio auditas?
Jis tikrina, ką svetainė techniškai daro prieš naudotojo pasirinkimą ir po jo. Auditorius lygina skriptų įkėlimo seką, Network užklausas, Set-Cookie antraštes, naršyklėje faktiškai išsaugotus slapukus ir kitas saugyklas, CMP signalus bei Consent Mode būsenas po atmetimo, sutikimo ir jo atšaukimo. Rezultatas yra slapukų ir sekimo apimties įrodymų visuma, o ne automatinis visos organizacijos BDAR atitikties patvirtinimas.
Ar Network užklausa įrodo, kad naršyklėje išsaugotas slapukas?
Ne, viena Network užklausa to neįrodo. Ji rodo bandymą užmegzti ryšį, paskirties vietą, iniciatorių, antraštes ir kitus siuntimo faktus; tikrinant slapuką dar reikia peržiūrėti Cookie arba Set-Cookie antraštes, galimą blokavimo priežastį ir faktinį įrašą Application rodinyje. Priešinga išvada taip pat nėra saugi: jei naujo slapuko nėra, vis tiek gali būti siunčiamas signalas be slapukų, naudojamas localStorage įrašas ar taikomas kitas sekimo būdas.
Ar Advanced Consent Mode yra saugesnis pasirinkimas už Basic?
Ne, Advanced nėra automatiškai saugesnis ar teisiškai tinkamesnis pasirinkimas. Basic režimu Google žymos iki sutikimo neįkeliamos, o Advanced režimu jos gali būti įkeltos esant uždraustai saugyklai ir siųsti signalus be slapukų. Režimą reikia rinktis pagal teisinį vertinimą ir analitikos poreikius, o per auditą patikrinti numatytosios būsenos seką, atnaujinimą po spustelėjimo ir faktines užklausas kiekvienoje pasirinkimo būsenoje.
Ar slapukų auditas įrodo visišką BDAR atitiktį?
Ne, jis įrodo tik patikrintus slapukų, sekimo, CMP ir techninio sutikimų valdymo faktus. Frazė „svetainės BDAR auditas“ čia neapima visų įmonės duomenų tvarkymo procesų, sutarčių, duomenų subjektų teisių įgyvendinimo ar vidaus valdymo. Audito ataskaita suteikia teisininkui ar duomenų apsaugos specialistui pakartojamus svetainės elgsenos įrodymus, tačiau nepakeičia platesnio teisinio ir organizacinio vertinimo.
Kiek kainuoja slapukų ir sekimo auditas ir kiek laiko jis trunka?
Kaina prasideda nuo 800 €, o darbai paprastai trunka 1–4 savaites. Tikslią apimtį lemia svetainės šablonų, kalbų, naudotojų kelių, CMP ir žymų konteinerių skaičius, taip pat tai, ar reikia tik techninės patikros, ar ir konfigūracijos taisymų. Po diegimo atliekame pakartotinį skenavimą po 30 ir 180 dienų, naudodami tuos pačius scenarijus bei įrodymų laukus, kad patikrintume, ar pataisymai išliko.
Slapukų auditas, po kurio Jūsų svetainė atitinka BDAR ir ePrivacy reikalavimus — išsami slapukų konfigūracijos analizė, CMP baneris, Consent Mode v2.
