Data, privatliv og drift

Cookies og tracking: Et banner hjælper kun, hvis teknologien respekterer valget

En app kan se færdig ud og stadig sende besøgsdata til analyse-, annonce- eller indlejringstjenester, før brugeren har valgt. En driftsklar samtykkeløsning forbinder teksten i banneret med de scripts, netværkskald og lagringer, der faktisk må køre.

Guiden er en teknisk arbejdsramme – ikke juridisk rådgivning

Reglerne afhænger af formål, teknologi, leverandører og det konkrete dataflow. Brug guiden til at finde og afprøve den tekniske adfærd, og få en faglig vurdering, hvis grundlag, tredjepartsroller eller undtagelser er uklare.

Kortlæg teknologien – ikke kun cookienavnene

De danske myndigheders vejledning er teknologineutral. Gennemgangen skal derfor også finde pixels, lokal lagring, enheds-id'er, fingerprinting og andre metoder, der gemmer eller læser oplysninger på brugerens udstyr. Et tomt cookiepanel beviser ikke, at appen ikke sender data.

Søg i kode og konfiguration: Find tag managers, analyse-SDK'er, annoncepixels, chat, video, kort, A/B-test, fejlsporing og sociale indlejringer.
Se lagring i en ren browser: Kontrollér cookies, local storage, session storage, IndexedDB og service workers før og efter hvert valg.
Se netværket: Genindlæs siden med åbent netværkspanel, og notér domæne, requesttype og tidspunkt for hvert tredjepartskald.
Følg hele appen: Login, betaling, formularer og indlejret indhold kan aktivere teknologier, som forsiden ikke gør.

Saml fundene i et register med teknologi, leverandør, formål, data, funktionsvarighed, kategori, ejer og de sider eller handlinger, der udløser den. Registeret skal beskrive live-adfærden – ikke en standardskabelon fra en leverandør.

Kategorisér efter det faktiske formål

En teknologi kan i visse tilfælde bruges uden samtykke, hvis den er strengt nødvendig for eksempelvis login, sikkerhed eller en funktion, brugeren udtrykkeligt har bedt om. Statistik og personaliseret markedsføring kræver som udgangspunkt samtykke. Et bibliotek, et leverandørnavn eller ordet “funktionalitet” afgør ikke kategorien; det gør det konkrete formål og brugen af data.

Nødvendig drift: Session, sikkerhed eller en efterspurgt kernefunktion. Beskriv hvorfor teknologien er nødvendig; brug ikke kategorien som restgruppe.
Præferencer: Valg som sprog eller visning. Vurder om funktionen er efterspurgt og nødvendig, eller om den først må aktiveres efter brugerens samtykke.
Statistik: Måling af brug, forløb og effekt. Som udgangspunkt slukket, indtil brugeren har valgt kategorien.
Markedsføring: Annonceattribution, remarketing eller personalisering. Hold den adskilt fra statistik og fra appens nødvendige funktion.

Et samtykke til statistik er ikke et samtykke til markedsføring. Brugeren skal kunne vælge relevante formål hver for sig, og appen skal håndhæve samme opdeling i den tekniske konfiguration.

Gør valget reelt i bannerets første lag

Samtykke skal være frivilligt, specifikt, informeret og utvetydigt. Der skal være en umiddelbar mulighed for både at acceptere og afvise, og designet må ikke skubbe brugeren mod accept. Forudafkrydsede valg, fortsat brug af siden eller en generel accept af vilkår er ikke en aktiv tilladelse.

Vis formålene tidligt: Fortæl i første lag, hvad der ønskes tilladelse til, og hvem der står bag.
Giv tre forståelige veje: “Afvis alle”, “Tilpas” og “Acceptér alle” skal være brugbare uden skjulte omveje.
Lad valg starte slukket: Kun teknologier, som faktisk er nødvendige, må være aktive uden samtykke.
Gør detaljerne tilgængelige: Navn, leverandør, formål og funktionsvarighed skal stemme med registeret og kunne findes fra banneret.
Blokér ikke kernefunktionen unødigt: Et nej til statistik eller marketing må ikke i sig selv ødelægge login, betaling eller det værktøj, brugeren kom for at anvende.

Lad samtykket styre indlæsningen – ikke kun rapporteringen

Den sikreste tekniske standard er, at statistik- og marketingscripts ikke hentes eller initialiseres, før den relevante kategori er valgt. Gem et afgrænset samtykkevalg, læs det tidligt ved hver sideindlæsning, og aktivér kun de integrationer, som valget dækker.

Ukendt valg: Kør nødvendig funktion, vis banneret, og hold øvrige kategorier slukket.
Afvist kategori: Indlæs ikke kategoriens tags, og send ikke dens events til en kø, der afleverer dem senere.
Accepteret kategori: Aktivér kun den konkrete integration og dens tilladte events.
Ændret valg: Opdatér tilstanden med det samme, stop fremtidig indsamling og fjern de lagrede værdier, løsningen selv kontrollerer, når det er relevant.

Et UI-flag som analytics: false er ikke en kontrol, hvis tag manageren, SDK'et eller et indlejret script allerede er startet. Håndhævelsen skal sidde på den vej, der faktisk indlæser kode og sender requests.

Consent Mode er et signal – ikke selve samtykket

Google beskriver Consent Mode som en måde at fortælle tags og SDK'er om brugerens valg. Virksomheden skal stadig indhente valget, sende den korrekte tilstand og sikre, at både Google-tags og andre tredjepartstags respekterer den.

Basic Consent Mode

Google-tags blokeres, indtil brugeren vælger. Ved afvisning sendes ingen data til Google. Det er den letteste model at kontrollere i netværkspanelet.

Advanced Consent Mode

Tags indlæses med afvist standard og kan sende målinger uden cookies. Brug ikke betegnelsen “uden cookies” som bevis for, at der ikke indsamles eller overføres data; den konkrete brug kræver særskilt vurdering.

Hvis Google-tags bruges, skal standardtilstanden sættes, før kommandoer der sender måledata, og valget skal opdateres på den side, hvor brugeren foretager det. Consent Mode gemmer ikke selv brugerens valg; det skal samtykkeløsningen håndtere.

Versionér valg og dokumentation, når opsætningen ændres

Et gammelt ja dækker ikke automatisk en ny leverandør eller et nyt formål. Knyt den gemte tilstand til en samtykkeversion. Når formål eller teknologier ændres væsentligt, skal appen behandle det gamle valg efter den opdaterede vurdering og om nødvendigt bede om et nyt valg, før de nye teknologier aktiveres.

Gem versionsbevis: Bevar skærmbilleder, tekster, kategorier og leverandøroversigt for hver anvendt version.
Minimér selve logningen: Dokumentationskravet er ikke en grund til at oprette et nyt detaljeret spor om hver besøgende.
Sæt en ejer: En navngiven person vurderer nye tags, plugins og indlejringer, før de kommer i produktion.
Test efter ændringen: Et nyt script kan omgå banneret, selv om teksten og den gemte samtykkeversion er korrekt.

Gør tilbagetrækning lige så virkelig som accept

Der skal være vedvarende adgang til oplysningerne og en let vej til at ændre eller trække samtykket tilbage. Et synligt link eller ikon på alle relevante sider er mere robust end en vej, der kun findes i et gammelt banner.

Åbn de aktuelle kategorier uden at kræve login eller søgning i lange vilkår.
Opdatér samtykket, før siden navigerer videre eller genindlæses.
Stop fremtidige events og deaktiver de tags, løsningen kan kontrollere.
Fjern egne ikke-nødvendige lagringer, hvor det er relevant, og forklar begrænsninger ved tredjepartsdata.
Kontrollér at appens nødvendige funktion stadig virker efter fuld afvisning.

Test beslutningen i browseren og på netværket

Test i en ny browserprofil eller efter fuld rydning af webstedsdata. Gennemfør hver situation med åbent lager- og netværkspanel, og sammenhold resultatet med registeret og det, banneret lover.

Intet valg: Ingen statistik- eller marketingteknologi, der kræver samtykke, må lagre eller sende data før et valg.
Afvis alle: Ingen statistik- eller marketingtags, cookies eller events må starte bagefter.
Kun statistik: Statistik må virke, mens marketing fortsat er slukket.
Acceptér alle: De oplyste tjenester må starte; ukendte tredjeparter er stadig et fund.
Tilbagetræk: Fremtidige requests stopper, og det nye valg gælder på næste side og efter genstart.
Ny samtykkeversion: Et tidligere valg må ikke automatisk aktivere et nyt formål eller en ny leverandør.
Fejl og langsomt net: En forsinket bannerkode må ikke lade tracking vinde kapløbet ved sideindlæsning.

Se efter requests – ikke kun cookies. En tjeneste kan sende data uden at lægge en traditionel cookie. “Der kom ingen cookie” er derfor ikke det samme som “der blev ikke sendt noget”.

Typiske fejl i AI-byggede samtykkeløsninger

Banneret skjuler kun UI'et: Analytics-scriptet ligger stadig direkte i HTML og kører ved første sidevisning.
Alt kaldes nødvendigt: Statistik, chat, video og marketing samles under funktionalitet uden konkret nødvendighed.
Afvisning kræver flere klik: Accept er tydelig, mens afvisning gemmes i indstillinger eller bag et luk-ikon.
Valgene er forudfyldte: Brugeren bekræfter et valg, som løsningen allerede har truffet.
Consent Mode forveksles med samtykke: Et teknisk signal bruges som erstatning for information, valg og dokumentation.
Ny pixel arver gammelt ja: En leverandør eller et formål tilføjes uden ny version og ny vurdering.
Tilbagetrækning ændrer kun knappen: Tags og requests fortsætter, selv om panelet viser “afvist”.
Cookieoversigten er en ønskeliste: Navne, formål eller varigheder matcher ikke det, en ren browser faktisk finder.

Tjekliste før statistik eller marketing går live

☐ Cookies, lokal lagring, pixels, SDK'er, indlejringer og tredjepartsrequests er kortlagt i hele appen.
☐ Hver teknologi har dokumenteret leverandør, formål, data, funktionsvarighed, kategori og ejer.
☐ Kun konkret nødvendige teknologier starter uden et samtykkevalg.
☐ Statistik og marketing er adskilte valg og starter slukket.
☐ Første lag giver en umiddelbar og forståelig vej til at acceptere, afvise eller tilpasse.
☐ Design og standardvalg skubber ikke brugeren mod accept.
☐ Samtykket styrer den faktiske indlæsning af scripts og events – ikke kun bannerets udseende.
☐ Google Consent Mode og andre leverandørsignaler afspejler valget uden at blive behandlet som selve samtykket.
☐ En synlig indstilling gør det let at ændre eller trække samtykket tilbage på alle relevante sider.
☐ Samtykkeversion, tekster, skærmbilleder og leverandøroversigt dokumenteres uden unødig personsporing.
☐ Nye formål og leverandører kan ikke arve et gammelt samtykke ukritisk.
☐ Intet valg, fuld afvisning, delvist valg, accept, tilbagetrækning, versionsskift og langsom indlæsning er afprøvet i en ren browser.
☐ Netværkstrafik og browserlagring stemmer med det, brugeren fik at vide.

Relaterede guides

GDPR, dataflow, sletning og ansvar Sikkert login og teknisk nødvendige sessioner Logning og overvågning uden unødige data Driftsdokumentation og ansvar Teststrategi for kritiske brugerrejser Se hele guidebiblioteket

Officielle kilder

Teknologier, leverandørfunktioner og myndighedsvejledning kan ændre sig. Brug de aktuelle kilder til den konkrete opsætning, og kontrollér altid appens faktiske lagring og netværkstrafik efter en ændring.

Virker appen, men er det uklart, hvad den sender fra browseren?

Startklar er til virksomheder med en fungerende AI-bygget app, som skal kunne bruges trygt af kunder eller medarbejdere. Her kan tracking, samtykke, dokumentation og test blive gennemgået i den stack og med de leverandører, appen faktisk bruger.

Se Startklar-forløbet