Evästebannerin tarkistus: estääkö se todella ei-välttämättömät skriptit? 7 yleistä virhettä

Hylkää-painike ei vielä todista, että seuranta loppuu. Käytännön opas bannerin tarkistamiseen Network- ja Application-paneelien, suostumustilan sekä uusintatestien avulla.

Avaat sivuston uudessa selainprofiilissa, painat ”Hylkää” ja näet evästeilmoituksen katoavan. Päällisin puolin kaikki näyttää olevan kunnossa, mutta evästebannerin tarkistus alkaa juuri tästä hetkestä: lähtikö mainosalustalle pyyntö jo ennen klikkausta, yrittikö vastaus asettaa selaimen tallennustilaan jääneen tunnisteen ja saivatko tagit hylkäyksen jälkeen oikean suostumustilan? Painike on vain ohjauspaneeli, ja tarkistuksessa on selvitettävä, onko sen alla todella johdot kytketty, sillä CMP ei ehkä ole vielä asettanut oletustilaa, kun tagienhallinta jo suorittaa ensimmäisen sääntönsä.

Bannerin silmämääräinen tarkastelu tai automaattisen skannerin vihreä valintamerkki ei kerro, mitä latauksen ensimmäisinä sekunteina tapahtui, eikä se myöskään paljasta, mikä skripti käynnisti toiminnon, mikä suostumustila sillä oli silloin käytettävissään tai vastaako näkyvä lopputila koko sitä edeltänyttä tapahtumaketjua. Siksi vertaamme samalla aikajanalla sivuston toimintaa ennen valintaa, kaikkien ei-välttämättömien luokkien hylkäämisen jälkeen, hyväksymisen jälkeen ja myöhemmin tehdyn suostumuksen peruuttamisen jälkeen sekä arvioimme jokaisessa tilassa verkkopyynnöt, vastausotsakkeet, evästeet, localStoragen ja muut tallennustilat, suostumussignaalien järjestyksen sekä kyseisen toiminnon käynnistäjän. Vain tällainen vertailu erottaa oikein määritetyn toteutuksen bannerista, joka vain sulkeutuu.

Tämä on tekninen artikkeli, ei yksilöllinen oikeudellinen lausunto, ja se osoittaa, miten kerätään tarkistettavia tosiseikkoja tekemättä päätelmiä, joihin näyttö ei riitä. Jos sivusto käyttää Google Tag Manageria, Google Analytics 4:ää, Google Adsia, Meta Pixeliä, upotettuja videoita, chat-ikkunaa tai muita kolmannen osapuolen työkaluja, yhdellä näytöllä näkyvä evästeluettelo on vain osa kokonaisuutta. Olennaisin kysymys ei siksi ole ”onko banneri asennettu?” vaan ”mitä sivusto tekee käyttäjän kussakin valintatilanteessa?”

Mitä evästebannerin tarkistus selvittää — ja mitä se ei todista

Tarkistuksessa käydään läpi tekninen suostumusketju sivun ensimmäisestä pyynnöstä käyttäjän valintaa seuraavaan tilanmuutokseen, eikä ketjua voi arvioida vain lopputilan perusteella, sillä alkuperäinen latausjärjestys on voinut jo käynnistää toiminnon, jota myöhemmin suljettu banneri ei enää peru. Tarkistus kattaa skriptien latausjärjestyksen, verkkoyhteydet, evästeet ja muut tallennustilat, CMP:n eli suostumustenkäsittelyalustan signaalit, Google Consent Mode v2 ‑määrityksen, luokkien toiminnan ja mahdollisuuden muuttaa valintaa myöhemmin; tuloksena on näyttöä evästeiden ja seurannan teknisestä kerroksesta, ei todistus siitä, että organisaation koko henkilötietojen käsittely olisi oikeudellisesti moitteetonta.

Oikeudellisesti on erotettava kaksi toisiinsa liittyvää tasoa: ePrivacy-direktiivin 5 artiklan 3 kohta koskee tietojen tallentamista käyttäjän päätelaitteelle ja pääsyä laitteella jo oleviin tietoihin, eikä tämä tekninen soveltamisala rajoitu tiedostoihin, joiden nimessä lukee ”cookie”; Suomessa asiasta säädetään sähköisen viestinnän palveluista annetun lain (917/2014) 205 §:ssä. Yleinen tietosuoja-asetus eli GDPR tulee kyseeseen, kun käsitellään henkilötietoja, ja se määrittää myös pätevän suostumuksen laadun ja peruuttamisen periaatteet, joten yhden sääntelytason tekninen tarkistus ei korvaa toisen oikeudellista arviointia. Nimeämme nämä tasot raportissa erikseen, jotta havaittua teknistä tosiseikkaa ei esitetä sitä laajempana oikeudellisena johtopäätöksenä.

Traficom ohjeistaa, ettei ei-välttämättömiä evästeitä tai vastaavia seurantatekniikoita saa ottaa käyttöön ennen käyttäjän valintaa ja että toimimaton kieltäytymismahdollisuus estää vapaaehtoisen suostumuksen syntymisen, mutta pelkkä luokan nimi ”necessary” ei todista mitään. Välttämättömyyspoikkeusta on tulkittava suppeasti: toiminnon on oltava tarpeen käyttäjän nimenomaisesti pyytämän palvelun tai viestinnän toteuttamiseksi, ei vain hyödyllinen analytiikalle, markkinoinnille tai sivuston omistajan sisäisille tarpeille; tarkistajan on yhdistettävä toiminto siihen ominaisuuteen, joka tekee sen tarpeelliseksi, ja samalla varmistettava, ettei samaan luokkaan ole piilotettu aivan muuta tarkoitusta, jota käyttäjän pyytämä ominaisuus ei oikeuta.

Hakuterminä käytetty ilmaus ”verkkosivuston GDPR-auditointi” tarkoittaa tässä palvelussa vain evästeiden, seurannan ja suostumuksen hallinnan laajuutta, joten sen ulkopuolelle jäävät muiden käsittelytoimien oikeusperusteet, rekisteröityjen pyynnöt, sopimukset ja sisäinen hallinto. Evästeiden ja seurannan auditointipalvelumme tuottaa tekniset tosiseikat, joiden avulla juristi tai tietosuoja-asiantuntija voi arvioida juuri tämän osan sivustosta perustellusti. GDPR-vaatimustenmukaisuus ei silti ole yksi kytkin, jonka tekninen skanneri voisi kääntää päälle koko organisaatiolle; rajaus ei ole vastuun välttelyä, vaan se kertoo selvästi, mitä raportti todistaa ja mitkä kysymykset on vielä ratkaistava teknisen tarkistuksen ulkopuolella.

Miten tarkistuksessa saadaan näyttöä pelkän skannaustuloksen sijaan

Hyvä testi alkaa puhtaasta selainprofiilista, jossa ei ole aiemmin tallennettua suostumusvalintaa, sivuston evästeitä tai selainlaajennusten synnyttämiä pyyntöjä. Ennen ensimmäistäkään klikkausta otetaan Network-loki käyttöön, tarkistetaan Application-osio ja tallennetaan alkutila, minkä jälkeen sama toimintasarja toistetaan hylkäyksen, suostumuksen ja suostumuksen peruuttamisen jälkeen. Jokainen skenaario aloitetaan dokumentoidusta tilasta ja koko loki säilytetään, sillä muuten eilinen valinta voi näyttää tämän päivän bannerivirheeltä tai päinvastoin peittää todellisen virheen.

Network-merkintä todistaa, että selain yritti ottaa yhteyttä tiettyyn osoitteeseen, ja siitä voidaan nähdä käynnistäjä, tila, pyyntö- ja vastausotsakkeet sekä lähetetyt tiedot, mutta merkintä ei vielä todista, että eväste olisi tallennettu. Vastausotsake Set-Cookie osoittaa palvelimen yrityksen asettaa eväste, mutta selain voi estää yrityksen, kun taas JavaScript voi puolestaan kirjoittaa document.cookie-arvon tai localStorage-tietueen ilman tällaista otsaketta. Todellinen lopputulos on siksi tarkistettava Application-näkymästä, eikä yksikään merkki saa korvata muita; näkyvä pyyntö analytiikkaverkkotunnukseen todistaa tiedonsiirtoyrityksen, ei automaattisesti analytiikkaevästeen onnistunutta asettamista tai sitä, että palvelin vastaanotti tietyn henkilötietojoukon.

Kirjaamme jokaisesta havainnosta tarkistetun URL-osoitteen ja käyttäjäpolun, ajan, laite- ja selainympäristön, valitun suostumustilan, pyynnön käynnistäjän ja kohteen, lähetyksen tuloksen sekä tallennustilan muutokset, jotta täsmälleen sama testi voidaan toistaa korjauksen jälkeen. Automaattinen skannaus tuottaa laajan alustavan inventaarion, mutta se ei käy läpi kaikkia valikoita, ostopolun vaiheita, kirjautumista edellyttäviä alueita, kieliversioita tai dynaamisesti avautuvia integraatioita eikä myöskään pysty päättelemään käyttötarkoitusta luotettavasti pelkän tiedostonimen tai verkkotunnuksen perusteella. Siksi sitä seuraavat manuaaliset skenaariot ja keskustelu työkalujen omistajien kanssa: kuka otti työkalun käyttöön, mihin tarkoitukseen, missä tagisäilössä se sijaitsee ja mitä suostumussignaalia sen pitää noudattaa, sillä näyttö ilman kontekstia on vain kuvakaappaus; konteksti ilman näyttöä on vain lupaus.

1. Ei-välttämättömät skriptit käynnistyvät ennen käyttäjän valintaa

Kriittinen järjestysvirhe syntyy, kun CMP-banneri ilmestyy nopeasti mutta analytiikka- tai mainostagi on jo käynnistynyt, joten käyttäjä lukee vielä painikkeiden tekstejä, vaikka selain on jo ottanut yhteyttä kolmanteen osapuoleen tai tallentanut tunnisteen. Traficomin ohje on tältä osin yksiselitteinen: ei-välttämättömiä evästeitä ei saa ottaa käyttöön ennen valintaa; siksi tekninen tarkistus alkaa sivun ensimmäisestä latauksesta, ei siitä hetkestä, jolloin tarkistaja ehti löytää ”Hylkää”-painikkeen ja painaa sitä.

Google Tag Managerissa tavallinen syy on tapahtumien väärä järjestys, sillä suostumuksen oletustila on asetettava ennen tageja Suostumuksen alustus – Kaikki sivut ‑triggerillä tai muulla tavalla, joka takaa saman järjestyksen, ja päivitys lähetetään vasta käyttäjän toiminnon jälkeen. Jos oletustila saapuu liian myöhään, tagi voi nähdä hetken määrittämättömän tai aiemmin tallennetun tilan ja käynnistyä, eikä nopeasti sulkeutuva banneri korjaa tätä kilpatilannetta, sillä vika on suoritusjärjestyksessä eikä animaatiossa.

Väite ”evästeet latautuvat ennen suostumusta” on purettava tarkistuksessa täsmällisempiin osiin. Itse skripti on voinut latautua, verkkopyyntö lähteä, evästeetön signaali tulla lähetetyksi, palvelin yrittää asettaa evästeen Set-Cookie-otsakkeella tai tunniste tallentua oikeasti, ja kullakin toiminnolla on näytön kannalta eri merkitys; suostumustilan edistyneessä versiossa (Advanced) osa Google-tageista voi latautua suostumuksen ollessa evätty ja lähettää evästeettömiä pingejä, joten pelkkä skriptin läsnäolo ei riitä osoittamaan rikkomusta eikä vaatimustenmukaisuutta.

Korjaus alkaa työkalukartasta ja yhdestä selkeästä tilamallista: mitkä tagit saavat toimia ilman valintaa, mitkä edellyttävät tiettyä luokkaa ja mikä tapahtuma muuttaa oletustilan. Määritysmuutoksen jälkeen testi toistetaan puhtaassa profiilissa Network-loki tallentaen, ja erityisesti ensimmäisiä pyyntöjä sekä niiden käynnistäjiä seurataan; jos virhe näkyy vain joskus, se viittaa tavallisesti CMP:n, tagisäilön ja sivuston koodin väliseen kilpatilanteeseen, ja vika on korjattava itse latausjärjestyksessä eikä peitettävä visuaalisesti nopeammalla bannerilla.

2. ”Hylkää” muuttaa käyttöliittymää mutta ei datavirtaa

Painike voi sulkea bannerin, näyttää valinnan harmaana ja jopa tallentaa arvon ”denied”, vaikka kolmannen osapuolen tagit jatkavat toimintaansa ennallaan, joten hylkäystesti ei koske kadonnutta tekstiä, vaan kahden tilan vertailua. Tallennamme pyynnöt ja tallennustilat ennen kaikkien ei-välttämättömien luokkien hylkäämistä ja sen jälkeen sekä tarkistamme, jäävätkö kyseiset tagit ilman käynnistävää tapahtumaa, ilmestyykö uusia tunnisteita ja säilyykö hylkäys seuraavilla sivulatauksilla. Aiempi istunto voi pilata testin helposti: jos suostumus annettiin eilen, tämän päivän ”Hylkää” voi ensin ladata sivun eilisen tilan mukaan ja muuttaa sen vasta sen jälkeen, jolloin ensimmäinen pyyntö on jo lähtenyt; myös evästeiden manuaalinen poistaminen vaiheiden välissä luo keinotekoisen puhtaan alun eikä testaa todellista peruutusmekanismia. Ensimmäinen hylkäys ja myöhempi suostumuksen peruuttaminen ovat siksi eri skenaarioita: ensimmäinen alkaa ilman päätöstä ja toinen tietoisesti annetusta suostumuksesta, eikä niiden tuloksia saa yhdistää samaan kuvakaappaukseen.

Sivusto saa hylkäyksen jälkeenkin tehdä toimia, jotka ovat todella välttämättömiä käyttäjän nimenomaisesti pyytämälle turvallisuus-, ostoskori- tai muulle toiminnolle, joten väite ”jokainen pyyntö hylkäyksen jälkeen on väärin” olisi yhtä epätarkka kuin bannerin vihreä valintamerkki. Jokaisen jäljelle jäävän yhteyden tarkoitus, käynnistäjä ja tallennustoiminto on selvitettävä, minkä jälkeen CMP määritetään niin, että hylkäys päivittää ensin suostumustilan ja tagit käyttävät sisäänrakennettuja tai erikseen määritettyjä suostumustarkistuksia. Toimiva painike muuttaa siihen kytketyn datavirran ennakoitavasti useilla sivuilla. Jos hylkäys pysäyttää mainostagin mutta jättää ensimmäisen osapuolen istuntoevästeen, tulos voi olla odotettu, mutta jos yksi luokka käynnistää toisen huomaamatta, määritys ei ole luotettava; korjauksen jälkeen hylkäys on voitava toistaa useilla sivuilla ilman tallennustilan manuaalista tyhjentämistä ja saada joka kerta sama, toistettava ja osoitettava tila.

3. Luokat ja evästeseloste eivät vastaa todellista inventaariota

Banneri voi olla teknisesti oikein määritetty ja silti johtaa harhaan, jos luokat tai evästeseloste kuvaavat eri sivustoa; näin käy usein, kun mallipohja kopioidaan, tagisäilö otetaan toisesta toteutuksesta tai uusi työkalu lisätään päivittämättä dokumentaatiota. Selosteeseen jää silloin jo käytöstä poistettu eväste, mutta videosoitinta, chat-ikkunaa tai mainonnan konversiotagia ei mainita. Käyttäjä tekee valinnan puutteellisten tietojen perusteella, eikä yritys tällöin pysty perustelemaan, kuka tiedot vastaanottaa, mihin tarkoitukseen niitä käsitellään ja kuinka kauan tunniste säilyy.

Traficomin ohjeessa evästeseloste perustuu todelliseen inventaarioon, jossa kerrotaan tarkoitus, palveluntarjoaja tai vastaanottaja ja säilytysaika, eikä vain siihen, mitä CMP:n luettelo tunnisti automaattisesti. Samannimisellä evästeellä voi olla eri määrityksissä eri käyttötarkoitus, kun taas räätälöidylle ensimmäisen osapuolen tunnisteelle ei ehkä löydy julkisesta tietokannasta lainkaan kuvausta, joten tarkistuksessa tekninen kohde yhdistetään sivuston omistajan todelliseen tarkoitukseen ja vastuussa olevaan työkaluun; tehtävänä ei ole kopioida luettelon arvausta vaan varmistaa, että määritys, vastaanottaja ja säilytysaika vastaavat sitä, mitä yritys oikeasti käyttää ja pystyy selittämään.

Inventaario ei pääty Cookies-välilehteen, vaan tarkistettavia ovat myös localStorage, sessionStorage, IndexedDB, pikseli- ja palvelinpyynnöt sekä URL-osoitteissa tai lomakepoluissa käytettävät tunnisteet silloin, kun niitä käytetään seurantaan. EDPB:n teknisissä suuntaviivoissa selvennetään, ettei ePrivacy-sääntelyn soveltamisala ole sidottu yhteen tallennustekniikkaan. Selosteen lupaus ”emme käytä evästeitä” ei siis vielä vastaa siihen, käyttääkö sivusto muuta menetelmää päätelaitteen tietoihin pääsemiseksi tai lähettääkö se mittaussignaaleja; evästenimien luettelo on inventaarion alku, ei kattava kuvaus tekniikoista, joilla tunnisteita voidaan tallentaa, lukea tai lähettää.

Käytännöllinen ratkaisu on keskitetty rekisteri, jonka perusteella ylläpidetään CMP-luokitusta, selosteen teknistä taulukkoa ja testiskenaarioita sekä merkitään jokaiselle tietueelle työkalun omistaja yrityksessä, toimittaja, tarkoitus, käynnistävä suostumustila, käytetty tallennustila, vastaanottaja ja säilytysaika. Uuden tagin lisääminen ei silloin ole pelkkä muutos Google Tag Manager ‑säilössä, vaan hallittu muutos, jossa käyttäjälle annettavat tiedot ja testitapaukset päivitetään ennen julkaisua; sama rekisteri antaa uusintatestille lähtökohdan muutoksen jälkeen ja osoittaa, kuka yrityksessä vastaa poikkeaman korjaamisesta.

4. Yksi Network-pyyntö tulkitaan virheellisesti todisteeksi evästeestä

Network-paneelissa näkyvä analytiikkaverkkotunnus on tärkeä havainto, mutta siitä yksin ei seuraa, että ”eväste asetettiin”, sillä merkintä todistaa yhteysyrityksen ja näyttää, mitä selain lisäsi URL-osoitteeseen, otsakkeisiin tai pyynnön sisältöön; epäonnistunut, estetty tai peruttu pyyntö ei kuitenkaan ole sama asia kuin palvelimelle onnistuneesti saapuneet tiedot. Evästeen osalta on tarkistettava, sisälsikö pyyntöotsake Cookie-arvon, näkyikö vastauksessa Set-Cookie, estikö selain sen ja päätyikö tietue todella tallennustilaan, sillä pyyntö voidaan estää tai perua ennen kuin palvelin vastaanottaa tiedot. Tämä näytön raja on tuotava esiin myös havainnon sanamuodossa: yhteysyritystä, lähetyksen tulosta ja tallentamista ei saa sulauttaa yhdeksi väitteeksi.

Myöskään vastakkainen päätelmä ei ole varma. Evästeetön pyyntö voi sisältää suostumustilan ja muita parametreja, ja sivusto voi käyttää localStorage-tunnistetta, URL-parametria tai muuta teknistä menetelmää, joten evästeen puuttuminen ei tee yhteydestä automaattisesti anonyymiä eikä tarkoita, ettei pyyntö sisältäisi dataa. Set-Cookie taas on palvelimen ohje selaimelle, ei takuu tietueen tallentumisesta, sillä selain voi hylätä sen verkkotunnuksen, turvallisuusmääritteiden, kolmannen osapuolen rajoitusten tai muun säännön vuoksi, kun taas JavaScriptillä asetettu ensimmäisen osapuolen eväste voi ilmestyä ilman tätä vastausotsaketta. DevTools näyttää myös estämisen syyt, joten Set-Cookie-otsakkeen esiintyminen on luettava yhdessä selaimen päätöksen ja Application-näkymän todellisen tilan kanssa; jos Cookies-taulukkoon ei ilmesty uutta riviä, emme silti pidä pyyntöä datattomana, vaan tarkistamme URL-osoitteen, otsakkeet, parametrit ja muut tallennustilat.

Luotettavin menetelmä yhdistää samalle aikajanalle kolme näkymää: mikä käynnisti pyynnön, mitä palvelin käski selaimen tehdä ja mitä tiettyyn selainprofiiliin sen jälkeen todella jäi, ja raportti nimeää tietoisesti vain sen, mikä on osoitettu. Kirjoitamme esimerkiksi ”verkkotunnukseen X lähetettiin pyyntö ennen valintaa”, ”vastauksessa havaittiin yritys asettaa eväste” tai ”tunniste Y säilyi Application-näkymässä hylkäyksen jälkeen”. Kehittäjä voi toistaa tällaisen vaiheen, juristi näkee teknisen tosiseikan rajat ja tulosta voidaan verrata objektiivisesti korjauksen jälkeen; yhdestä kuvakaappauksesta emme päättele koko henkilötietojen käsittelyketjua, sillä se voi todistaa vain tietyn toiminnon, tilan ja kuvan ottamisajan.

5. Suostumuksen peruuttaminen on piilotettu tai teknisesti puutteellinen

Suostumus ei ole kertaluonteinen klikkaus, jonka sivusto saa unohtaa. GDPR:n 7 artiklan 3 kohdan mukaan suostumus on voitava peruuttaa milloin tahansa ja peruuttamisen on oltava yhtä helppoa kuin suostumuksen antamisen; Traficom selittää saman periaatteen käytännönläheisesti. Jos suostumus voidaan antaa etusivun ensimmäisessä näkymässä mutta sen peruuttaminen edellyttää tietosuojaselosteen alaosion etsimistä, sähköpostin lähettämistä tai selainasetusten tyhjentämistä, mekanismi ei ole yhtä helposti saavutettavissa. Tavallinen ratkaisu on pysyvä valintojen hallintalinkki sivuston alatunnisteessa, ja tarkistamme, löytyykö se jokaiselta sivulta myös sen jälkeen, kun banneri ei enää näy, sillä juuri silloin käyttäjä yrittää muuttaa aiempaa päätöstään.

Tekninen testi alkaa tietoisesti annetusta suostumuksesta ja oikeasti käynnistyneistä tageista, minkä jälkeen tarkistaja avaa valintojen hallinnan, peruuttaa ei-välttämättömien luokkien suostumuksen ja jatkaa sivuston selaamista luomatta keinotekoista alkutilaa poistamalla tallennustietoja käsin. On varmistettava, lähettääkö CMP päivitetyn tilan ja saavatko tagit sen, lakkaavatko uudet suostumukseen perustuvat datavirrat käynnistymästä ja mitä paikallisesti tallennetuille tunnisteille tapahtuu; näin löytyy painike, joka tallentaa uuden valinnan mutta ei ilmoita siitä jo ladatuille tageille. Samalla tallennamme muutostapahtumien järjestyksen, jotta oikein tallennettu valinta voidaan erottaa tilanteesta, jossa siitä riippuva tagi saa päivityksen liian myöhään tai ei lainkaan.

Peruuttaminen vaikuttaa tulevaan käsittelyyn eikä itsessään kirjoita historiaa uudelleen tai poista kaikkia aiemmin lainmukaisesti käsiteltyjä tietoja; sen jälkeen kyseiseen suostumukseen perustuva jatkokäsittely on lopetettava, mutta palvelimelle jo päätyneiden tietojen säilyttäminen tai poistaminen voi vaatia erillisen arvion. Siksi erotamme raportissa tulevan datavirran pysäyttämisen aiempien tietojen säilyttämisestä emmekä lupaa, että tekninen valinnanmuutos ratkaisee molemmat; korjauksen on yhdistettävä käyttöliittymä integraatioon: linkin on löydyttävä jokaiselta sivulta, CMP:n on näytettävä nykyinen tila, muutoksen on tavoitettava jokainen siitä riippuva tagi ja testi on toistettava useilla luokkayhdistelmillä. ”Hylkää kaikki” voi toimia, vaikka erillisen markkinointikytkimen poistaminen käytöstä ei vaikuttaisi mihinkään; myös selaimen tunnisteiden poistamista on arvioitava niiden tehtävän perusteella lupaamatta, että yksi CMP-klikkaus puhdistaa automaattisesti jokaisen kolmannen osapuolen järjestelmän.

6. Suostumustilan perus- ja edistynyt versio sekoitetaan tai mallinnettua dataa luvataan

Google Consent Moden perusversio (Basic) ja edistynyt versio (Advanced) eivät ole saman kytkimen kaksi ulkoasua. Perusversiossa Google-tagit estetään, kunnes käyttäjä tekee valinnan: jos suostumusta ei anneta, tagit eivät käynnisty eikä Google saa niiden välittämää dataa, kun taas suostumuksen jälkeen tagit voivat aloittaa tavallisen mittauksen. Edistyneessä versiossa tagit latautuvat suostumuksen oletustilan ollessa evätty ja voivat lähettää evästeettömiä pingejä, joten tätä versiota ei saa kuvata tilaksi, jossa ”mitään ei lähetetä”, eikä perusversio ole automaattisesti huonompi analytiikkamääritys; ero on tagien todellisessa toiminnassa ennen valintaa, ei bannerin ulkoasussa tai yhden asetuksen nimessä.

Valinnan on perustuttava yrityksen oikeudelliseen arvioon ja analytiikkatarpeisiin, ei oletukseen siitä, että Googlen tuotenimi ratkaisisi itsessään ePrivacy- tai GDPR-vaatimukset. Googlen suostumustilan dokumentaatio erottaa tagien estämisen perusversiossa edistyneen version evästeettömistä signaaleista, mutta tarkistuksessa käymme silti läpi todellisen määrityksen: tulevatko oletustilat voimaan ennen tageja, mikä päivitys lähetetään klikkauksen jälkeen ja mitkä pyynnöt todella ilmestyvät kussakin tilassa. Tuotetilan nimi ei ole oikeudellinen johtopäätös, joten raportissa kuvataan tarkistettu datavirta ja yrityksen valitsema määritys eikä anneta sille automaattista vaatimustenmukaisuusmerkkiä.

”Evästeetön” ei tarkoita ”tiedoton”, joten signaalin nimi ei saa raportissa korvata sen sisällön ja tarkoituksen arviointia. Network-paneelista on tarkistettava kohde, parametrit, suostumustila ja käynnistäjä, ja Google Tag Assistant tai suostumustilan vianetsintätyökalut auttavat puolestaan tarkistamaan oletustilan ja päivitetyn tilan. Näkymät täydentävät toisiaan: ensimmäinen näyttää yksittäisen testin datavirran, toinen määrityksen logiikan; jos näkymät eivät vastaa toisiaan, kauniimpaa näyttöä ei pidä suosia, vaan on löydettävä kohta, jossa oletus- tai päivitystapahtuma ei tavoittanut tagia tarkoitetussa järjestyksessä.

Mallinnettu data ei myöskään ole taattu palkinto edistyneen version käyttöönotosta. Google Analytics 4:n käyttäytymismallinnuksen saatavuus riippuu Googlen määrittämistä mittauskokonaisuutta, datamäärää ja laatua koskevista ehdoista, ja ominaisuus voi puuttua tai poistua, jos ehdot eivät enää täyty; mallinnus ei palauta yksittäisten suostumuksen evänneiden käyttäjien istuntoja. Tarjouksessa lupaamme siksi oikean määrityksen ja tarkistettavan signaalijärjestyksen, emme tiettyä mallinnetun datan määrää, jonka Googlen järjestelmä ja kyseisen mittauskokonaisuuden kelpoisuus ratkaisevat; tarkistuksen tulos on toistettava määritys ja signaalien varmennus, ei lupaus datamäärästä, jota palveluntarjoaja ei hallitse.

7. Testi rajoittuu ensimmäiseen sivuun ja ensimmäiseen päivään

Etusivu kattaa harvoin koko seurannan inventaarion: videotagi voi latautua vasta toiston käynnistyessä, karttaintegraatio vasta yhteystietosivulla, mainonnan konversiotagi vasta lomakkeen lähettämisen jälkeen, maksutyökalu vasta ostoskorin viimeisessä vaiheessa ja chat- tai personointiskripti vasta tietyn ajan kuluttua. Tarkistaja, joka avaa yhden URL-osoitteen, odottaa muutaman sekunnin ja sulkee skannerin, voi kirjoittaa teknisesti oikean raportin tästä yhdestä näkymästä mutta samalla vaarallisen puutteellisen raportin koko sivustosta, joten jokainen tila on avattava toiminnolla, joka sen oikeasti käynnistää, eikä etusivun inventaariota saa olettaa kaikkien mallipohjien ja käyttäjäpolkujen edustajaksi.

Rakennamme skenaariot todellisten käyttäjäpolkujen ja sivuston mallipohjien mukaan, ja niihin kuuluvat julkinen sivu, artikkeli, yhteydenottolomake, tilialue, ostoprosessi, upotettu sisältö sekä jokainen olennainen kieli- tai alueversio. Myös mobiilinäkymä on tarkistettava, sillä siinä CMP-painikkeet voivat mennä päällekkäin tai valintalinkki jäädä saavuttamattomiin, vaikka kaikki toimii työpöytänäkymässä; automaattinen skannaus laajentaa kattavuutta, kun taas manuaalinen skenaario avaa tilat, joita botti ei ilman tiliä, klikkausta tai syötettä koskaan näe. Kieli- ja alueversiot eivät mobiilinäkymän tavoin ole koristeellisia kopioita, jos integraatioiden latautuminen tai käyttäjälle tarjottujen valintojen saatavuus eroaa niissä.

Kertaluonteinen tarkistus ei kata ajan myötä syntyviä muutoksia, sillä uusi markkinointitagi, CMP:n mallipohjan vaihto tai tuotu Google Tag Manager ‑säilö voi rikkoa aiemmin oikean järjestyksen ilman näkyvää muutosta bannerissa. Siksi jokainen uusi työkalu on testattava ennen julkaisua ja vertailu toistettava myöhemmin; tämä menettely kannattaa sisällyttää jo verkkosivuston toteutussopimukseen, kuten selitimme verkkosivujen tilaamisen 10 virhettä käsittelevässä artikkelissamme. Tarkistusprosessissamme sivusto skannataan toteutuksen jälkeen uudelleen 30 ja 180 päivän kuluttua samoja skenaarioita ja samoja dokumentointikenttiä käyttäen. Näin nähdään, säilyykö korjaus tavallisessa julkaisurytmissä ja onko myöhemmin ilmestynyt uusia työkaluja tai määrityspoikkeamia: ensimmäinen tarkistuspiste osoittaa, säilyikö toteutus päivittäisessä julkaisutyössä, ja toinen paljastaa myöhemmät muutokset, minkä jälkeen uusintatestissä vertaamme tiettyä pyyntöä, tallennustilaa ja suostumustilaa alkuperäiseen havaintoon emmekä tyydy vaikutelmaan, että ”nyt näyttää paremmalta”.

Mitä saat teknisestä evästeiden ja seurannan auditoinnista

Ensimmäinen tulos on varmennettu inventaario evästeistä, tallennustiloista, tageista ja kolmansien osapuolten pyynnöistä, minkä jälkeen jokainen havainto yhdistetään sivuun, käyttäjän toimintoon ja suostumustilaan ja sen yhteyteen kirjataan näyttö sekä näytön raja: Network-merkintä, Set-Cookie-yritys, Application-näkymään todella tallentunut eväste, localStorage-tietue tai CMP-tapahtuma. Kehittäjä saa näin toistettavan virheen epämääräisen ”korjatkaa GDPR” -huomautuksen sijaan, ja tietosuojasta vastaava näkee, mitkä tosiseikat tarvitsevat vielä oikeudellisen päätöksen; jokaiselle havainnolle jää myös toistopolku, jolla sama sivu, valinta, pyyntö ja tallennustulos voidaan tarkistaa toteutuksen jälkeen.

Toinen osa on toteutus: järjestämme CMP-luokat sekä Google Tag Managerin oletus- ja päivitystapahtumien järjestyksen, määritämme suostumustarkistukset Google Analytics 4:lle, Google Adsille, Meta Pixelille ja muille työkaluille sekä laadimme evästeselosteen ja tietosuojaselosteen tekstin. Valitsemme suostumustilan perus- tai edistyneen version oikeudellisen arviosi ja analytiikkatarpeidesi perusteella. Emme esitä edistynyttä versiota yleispätevästi oikeana vaihtoehtona emmekä lupaa mallinnettua dataa, jos kyseinen Google Analytics ‑mittauskokonaisuus ei täytä Googlen ehtoja; toteutuksen tulos tarkistetaan samoissa suostumustiloissa, joissa alkuperäinen havainto tallennettiin, jotta määritysmuutos voidaan perustella vertailukelpoisella näytöllä.

Palvelun hinta on alkaen 800 € ja toimitusaika 1–4 viikkoa sivuston laajuuden, kielten ja mallipohjien määrän, CMP:n ja tagisäilöjen monimutkaisuuden sekä tarvittavien integraatioiden mukaan. Erotamme ennen työn alkua hinnassa ja aikataulussa selvästi tarkistuksessa kerättävän näytön, tekniset korjaukset ja kysymykset, jotka yrityksen juristin tai tietosuoja-asiantuntijan on ratkaistava; teemme 30 ja 180 päivän kuluttua uusintaskannauksen tallennettujen skenaarioiden pohjalta, joten hinta ja toimitusaika koskevat näin täsmällisesti nimettyä teknistä laajuutta, eivät epämääräistä lupausta saada yrityksen koko tietosuoja kuntoon.

Jos tarvitset ”verkkosivuston GDPR-auditointia”, sovimme ensin, että tässä sillä tarkoitetaan evästeitä, seurantaa, CMP:tä ja suostumustilaa eikä koko organisaation täydellistä GDPR-vaatimustenmukaisuuden tarkastusta, joten lupaamme vain sen, minkä voimme teknisesti osoittaa: sivuston toiminnan ennen valintaa, hylkäyksen, suostumuksen ja sen peruuttamisen jälkeen, työkaluille lähetetyt signaalit sekä kohdat, joissa näyttö ei vielä riitä oikeudelliseen johtopäätökseen. Rajaus mahdollistaa teknisen työn päättämisen tarkistettavaan tulokseen ja oikeudellisten kysymysten siirtämisen henkilölle, joka vastaa laajemmasta henkilötietojen käsittelystä. Tilaa evästeiden ja seurannan auditointi lähettämällä meille sivuston osoite sekä käytössä olevan CMP:n tai tagienhallinnan nimi.