Test av samtykkebanner: blokkerer det faktisk valgfrie skript? 7 vanlige feil

Knappen «Avvis» beviser ikke at sporingen stopper. Slik tester du banneret med Network, Application, Consent Mode og gjentatte kontroller.

Du åpner nettstedet i en ny nettleserprofil, trykker på «Avvis» og ser at varselet om informasjonskapsler forsvinner. Utenfra ser alt ut til å være i orden, men en test av samtykkebanner begynner nettopp her: Ble det allerede sendt en forespørsel til en annonseplattform før du klikket, forsøkte svaret å angi en identifikator som ble liggende i nettleserens lagring, og fikk taggene riktig samtykkestatus etter avvisningen? Knappen er bare kontrollpanelet, og testen må vise om ledningene under panelet faktisk er koblet til, for CMP-en kan ennå mangle en standardstatus idet taggbeholderen allerede kjører sin første regel.

En visuell kontroll av banneret eller en grønn hake fra en automatisk skanner forteller ikke hva som skjedde de første sekundene, hvilket skript som utløste handlingen, hvilken samtykkestatus det hadde, eller om sluttstatusen stemmer med hendelsesforløpet. Derfor legger vi nettstedets oppførsel før valget, etter avvisning av alle valgfrie kategorier, etter samtykke og etter senere tilbaketrekking på samme tidslinje. I hver tilstand vurderer vi nettverksforespørsler, svarhoder, informasjonskapsler, localStorage og andre lagringsområder, rekkefølgen på samtykkesignalene og hva som utløste handlingen. Bare denne sammenligningen skiller et riktig oppsett fra et banner som bare lukker seg.

Dette er en teknisk artikkel, ikke en individuell juridisk vurdering. Den viser hvordan du samler etterprøvbare fakta uten å trekke konklusjoner som bevisene ikke gir grunnlag for. Bruker nettstedet Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, innebygde videoer, en chat eller andre tredjepartsverktøy, er listen over informasjonskapsler du ser i ett skjermbilde, bare en del av helheten. Det avgjørende spørsmålet er derfor ikke «er banneret installert?», men «hva gjør nettstedet i hver samtykkestatus brukeren kan velge?».

Hva en test av samtykkebanner undersøker — og ikke beviser

Testen følger den tekniske samtykkekjeden fra den første sideforespørselen til statusen endres etter brukerens valg, men sluttstatusen er ikke nok: Innlastingen kan allerede ha utløst en handling som et senere lukket banner ikke opphever. Omfanget omfatter skriptenes rekkefølge, nettverksforbindelser, informasjonskapsler og andre lagringsområder, signaler fra en plattform for samtykkestyring (CMP), oppsettet av Google Consent Mode, kategorienes virkemåte og muligheten til å endre valget senere. Resultatet er et teknisk bevisgrunnlag for hvordan nettstedet bruker informasjonskapsler og sporing, ikke et sertifikat på at hele organisasjonens behandling av personopplysninger er juridisk feilfri.

Juridisk må to sammenhengende nivåer skilles. Ekomloven § 3-15, som gjennomfører artikkel 5 nr. 3 i kommunikasjonsverndirektivet (ePrivacy-direktivet), gjelder lagring i brukerens terminalutstyr og tilgang til opplysninger som finnes der; virkeområdet er ikke begrenset til informasjonskapsler. GDPR blir relevant når personopplysninger behandles og regulerer også kravene til gyldig samtykke og tilbaketrekking. En teknisk kontroll etter det ene regelsettet erstatter derfor ikke en juridisk vurdering etter det andre. I rapporten skiller vi mellom nivåene, så et teknisk faktum ikke blir fremstilt som en bredere juridisk konklusjon.

Datatilsynet forklarer at valgfrie teknologier krever forhåndssamtykke, og at en avvisning uten et reelt valg ikke gir frivillig samtykke. Heller ikke kategorinavnet «necessary» beviser noe. Unntaket for det som er strengt nødvendig, skal tolkes snevert: Handlingen må enten utelukkende ha som formål å overføre kommunikasjon i et elektronisk kommunikasjonsnett eller være strengt nødvendig for å levere en informasjonssamfunnstjeneste som brukeren uttrykkelig har bedt om, ikke bare nyttig for analyse, markedsføring eller nettstedseierens interne behov. Den som tester, må knytte handlingen til funksjonen som gjør den nødvendig og kontrollere at kategorien ikke skjuler et annet formål som denne funksjonen ikke begrunner.

Søkefrasen «GDPR-sjekk av nettsted» viser i denne tjenesten bare til informasjonskapsler, sporing og samtykkestyring. Rettslige grunnlag for andre behandlingsprosesser, henvendelser fra registrerte, avtaler og intern styring faller utenfor. Gjennomgangen vår av informasjonskapsler og sporing gir de tekniske faktaene som en jurist eller et personvernombud trenger for å vurdere akkurat denne delen av nettstedet. GDPR-etterlevelse er likevel ikke én bryter som en teknisk skanner kan slå på for hele organisasjonen. Denne avgrensningen er ikke en ansvarsfraskrivelse; den sier tydelig hva rapporten beviser, og hvilke spørsmål som fortsatt må avgjøres utenfor den tekniske gjennomgangen.

Slik samler testen bevis, ikke bare et skannerresultat

En god test begynner i en ren nettleserprofil uten lagret samtykke, informasjonskapsler fra nettstedet eller forespørsler fra utvidelser. Før første klikk slår du på Network-loggen, kontrollerer Application-panelet og dokumenterer utgangstilstanden. Den samme handlingsrekken gjentas etter avvisning, samtykke og tilbaketrekking, alltid fra en dokumentert tilstand og med hele loggen bevart. Ellers kan gårsdagens valg se ut som en feil i dagens banner eller skjule den virkelige feilen.

En Network-rad beviser at nettleseren forsøkte å kontakte en adresse og viser utløser, status, forespørsels- og svarhoder og sendt informasjon, men ikke at en informasjonskapsel ble lagret. Set-Cookie viser serverens forsøk på å angi den, men nettleseren kan blokkere forsøket, mens JavaScript kan skrive til document.cookie eller localStorage uten dette hodet. Resultatet må derfor kontrolleres i Application, og ingen av tegnene erstatter de andre. En forespørsel til et analysedomene beviser et forsøk på dataflyt, ikke automatisk at en analyseinformasjonskapsel ble angitt, eller at serveren mottok et bestemt sett med personopplysninger.

For hvert funn noterer vi testet nettadresse og brukerreise, tidspunkt, enhet og nettleserkontekst, valgt samtykkestatus, utløser, mål, sendingsresultat og lagringsendringer, så testen kan gjentas etter rettingen. Automatisk skanning gir en bred startoversikt, men går ikke gjennom alle menyer, kjøpstrinn, innloggede områder, språkversjoner og dynamiske integrasjoner og kan ikke fastslå formålet fra et filnavn eller domene alene. Derfor følger manuelle scenarier og en samtale med verktøyeierne om hvem som innførte verktøyet, hvorfor, hvilken taggbeholder det ligger i, og hvilket samtykkesignal det skal følge. Slik knyttes funnet til planlagt oppsett. Bevis uten kontekst er bare et skjermbilde; kontekst uten bevis er bare et løfte.

1. Valgfrie skript starter før brukeren har valgt

En kritisk rekkefølgefeil oppstår når CMP-banneret vises raskt, men analyse- eller annonsetaggen allerede har startet. Brukeren leser fortsatt teksten på knappene mens nettleseren har kontaktet en tredjepart eller lagret en identifikator. Datatilsynets veiledning er klar på dette punktet: Valgfrie informasjonskapsler kan ikke aktiveres før brukeren har valgt. Den tekniske kontrollen må derfor begynne ved den første dokumentinnlastingen, ikke idet den som tester, endelig har funnet og trykket på «Avvis».

I Google Tag Manager er feil hendelsesrekkefølge en vanlig årsak. Standardstatusen for samtykke må angis før taggene, med utløseren «Samtykkeinitialisering – alle sider» eller en annen løsning som garanterer samme rekkefølge, og først etter brukerens handling sendes en oppdatering. Kommer standardstatusen for sent, kan en tagg et kort øyeblikk se en uavklart eller tidligere lagret status og starte. Et banner som lukker seg raskt, løser ikke dette kappløpet, for problemet ligger i kjørerekkefølgen, ikke i animasjonen.

Påstanden «informasjonskapsler lastes før samtykke» må presiseres. Selve skriptet kan være lastet, en nettverksforespørsel sendt, et signal uten informasjonskapsler gått ut, serveren kan ha forsøkt å angi en informasjonskapsel med Set-Cookie, eller en identifikator kan faktisk være lagret. Handlingene har ulik bevisverdi. I avansert samtykkemodus (Advanced Consent Mode) kan enkelte Google-tagger lastes inn med lagringsstatusen satt til «avvist» og sende ping uten informasjonskapsler. Skriptets tilstedeværelse er derfor ikke alene nok til å fastslå verken brudd eller etterlevelse.

Rettelsen begynner med et verktøykart og én tydelig statusmodell: Hvilke tagger kan kjøre uten valg, hvilke krever en kategori, og hvilken hendelse endrer standardstatusen? Etter endringen gjentas testen i en ren profil med lagret Network-logg, særlig de første forespørslene og utløserne deres. Opptrer feilen bare iblant, tyder det vanligvis på et kappløp mellom CMP-en, taggbeholderen og nettstedskoden. Det må rettes i innlastingsrekkefølgen, ikke skjules med et raskere banner.

2. «Avvis» endrer grensesnittet, men ikke dataflyten

Knappen kan lukke banneret, farge valget grått og lagre «denied», mens tredjepartstaggene fortsetter som før. Avvisningstesten sammenligner derfor to tilstander, ikke en tekst som forsvinner. Før og etter avvisning av alle valgfrie kategorier dokumenterer vi forespørsler og lagring og ser om taggene fortsatt utløses, nye identifikatorer dukker opp og avvisningen består på senere sider. En tidligere økt kan ødelegge testen: Ga du samtykke i går, kan dagens «Avvis» først laste gårsdagens status og endre den etterpå, når første forespørsel allerede er sendt. Manuell sletting mellom trinnene skaper kunstig renhet og tester ikke tilbaketrekkingen. Første avvisning og senere tilbaketrekking er derfor egne scenarier: Det første begynner uten valg, det andre med bevisst samtykke, og resultatene må ikke blandes i ett skjermbilde.

Etter avvisning kan nettstedet fortsatt gjøre det som er nødvendig for sikkerhet, handlekurven eller en annen funksjon brukeren uttrykkelig har bedt om. «Enhver forespørsel etter avvisning er feil» er derfor like upresist som skannerens grønne hake. Formål, utløser og lagringshandling for hver gjenværende forbindelse må avklares. CMP-en må så oppdatere samtykkestatusen før taggene bruker sine samtykkekontroller. Knappen virker når den forutsigbart endrer den tilkoblede dataflyten på flere sider. Stopper avvisningen en annonsetagg, men lar en førstepartsinformasjonskapsel for økten bli, kan det være forventet; aktiverer én kategori en annen i skjul, er oppsettet upålitelig. Etter rettingen skal avvisningen kunne gjentas uten manuell tømming og alltid gi samme, dokumenterbare tilstand.

3. Kategoriene og erklæringen stemmer ikke med den faktiske oversikten

Banneret kan være teknisk disiplinert og likevel villede dersom kategoriene eller erklæringen beskriver et annet nettsted. Det skjer etter kopiering av en mal, overtakelse av en taggbeholder eller innføring av et verktøy uten dokumentasjonsoppdatering. En ubrukt informasjonskapsel blir stående, mens en videoavspiller, chat eller konverteringstagg mangler. Brukeren velger på ufullstendig informasjon, og virksomheten kan ikke forklare mottaker, formål eller identifikatorens levetid.

Datatilsynet knytter den fullstendige informasjonen om informasjonskapsler til det som faktisk brukes, med formål, tjenesteleverandør eller mottaker og lagringstid, ikke bare det CMP-katalogen gjenkjenner automatisk. En informasjonskapsel med samme navn kan brukes forskjellig i ulike oppsett, mens en tilpasset førstepartsidentifikator kan mangle en beskrivelse i offentlige databaser. Testen må derfor knytte det tekniske objektet til nettstedseierens virkelige formål og den som har ansvaret for verktøyet. Oppgaven er ikke å skrive av katalogens gjetning, men å kontrollere at oppsett, mottaker og lagringstid stemmer med det virksomheten faktisk bruker og kan forklare.

Oversikten slutter ikke i fanen for informasjonskapsler. Kontroller localStorage, sessionStorage, IndexedDB, piksel- og serverforespørsler og identifikatorer i nettadresser eller skjemaflyter som brukes til sporing. EDPBs tekniske retningslinjer viser at ePrivacy-reglene ikke er bundet til én lagringsteknologi. «Vi bruker ikke informasjonskapsler» svarer derfor ikke på om nettstedet på annen måte får tilgang til opplysninger i brukerens terminalutstyr eller sender målesignaler. Navnelisten er starten på kartleggingen, ikke hele oversikten over teknologier som lagrer, leser eller sender identifikatorer.

En praktisk rettelse er ett kilderegister for CMP-klassifiseringen, den tekniske tabellen og testscenarioene. Hver post angir verktøyeier, leverandør, formål, aktiverende samtykkestatus, lagring, mottaker og lagringstid. En ny tagg er da ikke bare arbeid i Google Tag Manager, men en kontrollert endring som krever oppdatert brukerinformasjon og nye testtilfeller før publisering. Etter endringen gir registeret testen et reproduserbart startpunkt og viser hvem som skal rette avviket.

4. Én Network-forespørsel forveksles med bevis på en informasjonskapsel

Et analysedomene i Network-panelet er et viktig funn, men det alene gir ikke konklusjonen «en informasjonskapsel ble angitt». Raden beviser et forsøk på forbindelse og viser hva nettleseren la i nettadressen, hodene eller innholdet i forespørselen. En forespørsel som mislykkes, blokkeres eller avbrytes, er imidlertid ikke det samme som data serveren har mottatt. For informasjonskapselen må du kontrollere om forespørselshodet inneholdt Cookie, om Set-Cookie kom i svaret, om nettleseren blokkerte det, og om posten faktisk havnet i lagringen. En forespørsel kan blokkeres eller avbrytes før serveren mottar data, og denne grensen for beviset må også komme frem i formuleringen av funnet. Forsøket på forbindelse, sendingsresultatet og lagringen må ikke slås sammen til én påstand.

Den motsatte konklusjonen er heller ikke trygg. En forespørsel uten informasjonskapsel kan inneholde samtykkestatus og andre parametere, og nettstedet kan bruke en identifikator i localStorage, en parameter i nettadressen eller en annen teknisk metode. Fravær av en informasjonskapsel gjør ikke forbindelsen automatisk anonym eller tom. Set-Cookie er på sin side en instruks fra serveren til nettleseren, ikke en garanti for at posten ble lagret. Nettleseren kan avvise den på grunn av domenet, sikkerhetsattributter, tredjepartsbegrensninger eller en annen policy, mens en førstepartsinformasjonskapsel skrevet med JavaScript kan dukke opp uten dette svarhodet. DevTools viser også årsakene til blokkering. Forekomsten av Set-Cookie må derfor leses sammen med nettleserens avgjørelse og den faktiske tilstanden i Application. Er det ingen ny rad i fanen for informasjonskapsler, kaller vi ikke signalet «uten data», men kontrollerer nettadressen, hodene, parameterne og andre lagringsområder.

Den sikreste metoden kobler tre visninger på én tidslinje: hva som utløste forespørselen, hva serveren ba nettleseren gjøre, og hva som faktisk ble lagret i den bestemte nettleserprofilen. Rapporten beskriver bevisst bare det som kan dokumenteres. Vi skriver «en forespørsel ble sendt til domene X før valget», «svaret inneholdt et forsøk på å angi en informasjonskapsel» eller «identifikator Y var fortsatt lagret i Application-visningen etter avvisning». Da kan utvikleren gjenta trinnet, juristen se grensene for det tekniske faktumet, og resultatet sammenlignes objektivt etter rettingen. Vi utleder ikke hele behandlingskjeden fra ett skjermbilde, for det kan bare bevise den konkrete handlingen, tilstanden og tidspunktet da bildet ble tatt.

5. Tilbaketrekking av samtykke er skjult eller teknisk ufullstendig

Samtykke er ikke et engangsklikk nettstedet kan glemme. Artikkel 7 nr. 3 i GDPR gir rett til å trekke det tilbake når som helst og krever at det skal være like enkelt å trekke det tilbake som å gi det, noe Datatilsynet også forklarer praktisk. Kan du gi samtykke direkte i det første skjermbildet på forsiden, men må lete i en underseksjon av personvernerklæringen, sende e-post eller rydde i nettleserinnstillingene for å trekke samtykket tilbake, er mekanismen ikke like tilgjengelig. En vanlig løsning er en permanent lenke i bunnteksten for å administrere valgene. Vi kontrollerer at den kan finnes fra hver side, også når banneret ikke lenger vises, for det er nettopp da brukeren prøver å endre en tidligere beslutning.

Den tekniske testen begynner med et bevisst gitt samtykke og tagger som faktisk er aktivert. Deretter åpner den som tester samtykkeinnstillingene, trekker tilbake samtykket til de valgfrie kategoriene og fortsetter gjennom nettstedet uten å skape en kunstig start ved å tømme lagringen manuelt. Det må kontrolleres om CMP-en sender den oppdaterte statusen og taggene mottar den, om nye samtykkebaserte dataflyter stanser, og hva som skjer med identifikatorene som er lagret lokalt. Slik avdekkes en knapp som lagrer det nye valget, men ikke varsler tagger som allerede er lastet. Samtidig dokumenterer vi hendelsesrekkefølgen rundt endringen, slik at et riktig lagret valg kan skilles fra en situasjon der den avhengige taggen mottar oppdateringen for sent eller ikke i det hele tatt.

En tilbaketrekking virker fremover i tid; den endrer ikke i seg selv fortiden og sletter heller ikke alle data som tidligere ble behandlet lovlig. Den videre behandlingen som bygget på samtykket, må stanse, men lagring eller sletting av data serveren allerede har mottatt, kan kreve en egen vurdering. I rapporten skiller vi derfor stans i fremtidige dataflyter fra spørsmålet om lagring av eldre data og lover ikke at en teknisk endring av valget løser begge deler. Rettelsen må koble grensesnittet til integrasjonen: Lenken skal finnes fra hver side, CMP-en skal vise gjeldende status, endringen skal nå hver avhengige tagg, og testen skal gjentas med flere kombinasjoner av kategorier. «Avvis alle» kan virke selv om det å slå av bare markedsføringsbryteren ikke har noen effekt. Også sletting av identifikatorer i nettleseren må vurderes ut fra funksjonen deres, uten å love at ett klikk i CMP-en automatisk rydder opp i hvert tredjepartssystem.

6. Basic og Advanced Consent Mode blandes — eller det loves modellerte data

Basic og Advanced Consent Mode er ikke to utforminger av den samme bryteren; i Googles norske dokumentasjon omtales de som vanlig og avansert samtykkemodus. I vanlig modus lastes ikke Google-taggene inn før samtykke, og frem til da mottar Google ingen måledata fra disse taggene. Etter samtykke kan taggene begynne vanlig måling. I avansert modus lastes de inn med standardstatusene satt til «avvist», og mens samtykke ikke er gitt, kan de sende ping uten informasjonskapsler. Denne modusen kan derfor ikke beskrives som en tilstand der «ingenting sendes», og vanlig samtykkemodus er ikke automatisk et dårligere analyseoppsett. Forskjellen ligger i taggenes faktiske oppførsel før valget, ikke i hvordan banneret ser ut eller hva én innstilling heter.

Valget må bygge på virksomhetens juridiske vurdering og analysebehov, ikke på en antakelse om at navnet på et Google-produkt i seg selv oppfyller kravene i ePrivacy-reglene eller GDPR. Googles norske dokumentasjon om samtykkemodus skiller blokkering av tagger i vanlig samtykkemodus fra ping uten informasjonskapsler i avansert samtykkemodus. I testen kontrollerer vi det faktiske oppsettet: om standardstatusene gjelder før taggene, hvilken oppdatering som sendes etter klikket, og hvilke forespørsler som faktisk dukker opp i hver tilstand. Navnet på produktmodusen er ingen juridisk konklusjon. Rapporten beskriver derfor den testede flyten og oppsettet virksomheten har valgt, uten å gi det et automatisk samsvarsmerke.

«Uten informasjonskapsler» betyr ikke «uten informasjon», så navnet på signalet kan ikke erstatte en vurdering av innholdet og formålet. I Network-panelet må du kontrollere målet, parameterne, samtykkestatusen og hva som utløste forespørselen. Google Tag Assistant eller feilsøkingsverktøyene for samtykkemodus hjelper med å kontrollere standardstatusene og de oppdaterte statusene. Visningene utfyller hverandre: Den første viser dataflyten i det konkrete forsøket, mens den andre viser logikken i oppsettet. Er de uenige, skal du ikke velge det peneste skjermbildet, men finne ut hvor standard- eller oppdateringshendelsen ikke nådde taggen i planlagt rekkefølge.

Å slå på avansert samtykkemodus gir heller ingen garanti for modellerte data. Tilgangen til atferdsmodellering i Google Analytics 4 avhenger av om det aktuelle Google Analytics 4-området oppfyller Googles krav, blant annet til datamengde og datakvalitet, og funksjonen kan være utilgjengelig eller forsvinne dersom vilkårene ikke lenger er oppfylt. Modelleringen gjenskaper ikke øktene til enkeltbrukere som har avvist. I tilbudet lover vi derfor et riktig oppsett og en etterprøvbar signalrekkefølge, ikke en bestemt mengde modellerte data; tilgjengeligheten styres av Googles system og av om det aktuelle Google Analytics 4-området oppfyller kravene. Resultatet er et reproduserbart oppsett og en kontroll av signalene, ikke et løfte om en datamengde tjenesteleverandøren ikke kontrollerer.

7. Testen slutter på den første siden og den første dagen

Forsiden dekker sjelden hele oversikten over sporing. En videotagg kan bli aktivert først når videoen spilles av, en kartintegrasjon først på kontaktsiden, en annonsekonvertering først etter at et skjema er sendt, et betalingsverktøy først i siste trinn av handlekurven og et chat- eller personaliseringsskript først etter en viss tid. Den som åpner én nettadresse, venter noen sekunder og lukker skanneren, kan skrive en teknisk korrekt rapport om akkurat denne visningen og samtidig en farlig ufullstendig rapport om nettstedet som helhet. Hver tilstand må åpnes med handlingen som faktisk aktiverer den. Du kan ikke anta at oversikten på forsiden automatisk representerer alle maler og brukerreiser.

Vi bygger scenarioene rundt virkelige brukerreiser og sidemaler og dekker en offentlig side, en artikkel, kontaktskjemaet, kontoområdet, kjøpsflyten, innebygd innhold og hver viktig språk- eller regionversjon. Mobilvisningen må også kontrolleres; der kan CMP-knappene overlappe hverandre eller lenken til valgene bli utilgjengelig selv om alt virker på en datamaskin. En automatisk gjennomgang gir bredde, mens et manuelt scenario åpner tilstander som en robot uten konto, klikk eller inndata aldri vil se. Språk- og regionversjoner og mobilvisningen er ikke bare dekorative kopier dersom de endrer hvilke integrasjoner som lastes, eller hvilke valg brukeren får.

En engangstest dekker ikke endringer over tid. En ny markedsføringstagg, en byttet CMP-mal eller en importert Google Tag Manager-beholder kan ødelegge en tidligere riktig rekkefølge uten noen synlig endring i banneret. Derfor trenger hvert nytt verktøy en test før publisering og en ny sammenligning etterpå. Dette er en disiplin det lønner seg å planlegge allerede i avtalen om utvikling av nettstedet, slik vi forklarte i artikkelen om 10 feil når du skal bestille nettside. I vår prosess gjennomfører vi en ny skanning 30 og 180 dager etter innføringen, med de samme scenarioene og bevisfeltene, for å se om rettingen tåler den virkelige publiseringstakten, og om nye verktøy eller avvik i oppsettet har kommet til senere. Den første fristen viser om innføringen har tålt den daglige publiseringen, den andre avdekker senere endringer. I den nye testen sammenligner vi en bestemt forespørsel, lagring og samtykkestatus med det opprinnelige funnet, i stedet for å nøye oss med inntrykket «nå ser det bedre ut».

Dette får du i en teknisk gjennomgang av informasjonskapsler og sporing

Det første resultatet er en kontrollert oversikt over informasjonskapsler, lagringsområder, tagger og tredjepartsforespørsler. Hvert funn knyttes til en side, en brukerhandling og en samtykkestatus, og ved siden av står beviset og grensen for hva det viser: en Network-rad, et forsøk med Set-Cookie, en informasjonskapsel som faktisk finnes i Application, en post i localStorage eller en CMP-hendelse. Utvikleren får dermed en feil som kan gjenskapes, ikke den uklare beskjeden «fiks GDPR», mens den personvernansvarlige ser hvilke fakta som fortsatt krever en juridisk beslutning. Hvert funn dokumenteres også med en fast fremgangsmåte, slik at den samme siden, det samme valget, den samme forespørselen og det samme lagringsresultatet kan kontrolleres etter innføringen.

Den andre delen er innføringen. Vi rydder i CMP-kategoriene og rekkefølgen for standardstatus og oppdatering i Google Tag Manager, setter opp samtykkekontrollene for Google Analytics 4, Google Ads, Meta Pixel og andre verktøy, og utarbeider erklæringen om informasjonskapsler og teksten til personvernerklæringen. Om vi velger vanlig (Basic) eller avansert (Advanced) samtykkemodus, avhenger av den juridiske vurderingen din og analysebehovene dine. Vi fremstiller ikke den avanserte modusen som det universelt riktige valget og lover ikke modellerte data dersom det aktuelle Google Analytics 4-området ikke oppfyller Googles krav. Resultatet av innføringen kontrolleres i de samme samtykkestatusene som det opprinnelige funnet ble dokumentert i, slik at endringen i oppsettet kan underbygges med sammenlignbare bevis.

Prisen for tjenesten er fra 800 €, og leveringstiden er 1–4 uker, avhengig av størrelsen på nettstedet, antallet språk og maler, hvor sammensatte CMP-en og taggbeholderne er, og hvor mange integrasjoner som trengs. Før arbeidet begynner, skiller vi tydelig mellom bevisene fra gjennomgangen, de tekniske rettingene og spørsmålene som må avgjøres av virksomhetens jurist eller personvernombud, både i pris og tidsplan. Etter 30 og 180 dager gjennomfører vi en ny skanning mot de dokumenterte scenarioene. Prisen og fristen gjelder dermed et klart definert teknisk omfang, ikke et ubestemt løfte om å ordne hele virksomhetens personvern.

Trenger du en «GDPR-sjekk av nettsted», avklarer vi først at det her betyr omfanget for informasjonskapsler, sporing, CMP og Consent Mode, ikke en full kontroll av hele organisasjonens GDPR-etterlevelse. Derfor lover vi bare det vi kan bevise teknisk: nettstedets oppførsel før valget, etter avvisning, etter samtykke og etter tilbaketrekking, signalene som sendes til verktøyene, og punktene der beviset ennå ikke er tilstrekkelig for en juridisk konklusjon. Dette skillet gjør det mulig å fullføre det tekniske arbeidet med et etterprøvbart resultat og overlate de juridiske spørsmålene til den som har ansvar for den videre behandlingen av personopplysninger. Bestill en teknisk gjennomgang av informasjonskapsler og sporing ved å sende oss nettadressen og navnet på CMP-en eller taggbehandleren du bruker.