GDPR på jeres website: cookies, samtykke og datastrømme

Et website er en af de steder, I behandler personoplysninger uden at tænke på det som et system. En IP, et cookie-id, en formular, et chatvindue, en video der kalder hjem. GDPR spørger om formål, grundlag, minimering og de registreredes rettigheder. Cookie-reglerne — ePrivacy, som Danmark har implementeret — spørger derudover, om I må sætte eller læse noget i browseren, før der er et gyldigt samtykke, medmindre det er strengt nødvendigt for den tjeneste, brugeren bad om.

De to regler bliver ofte mast sammen til "vi skal have et banner". Banneret er UI. Det løser ingenting, hvis Tag Manager fyrer Facebook, LinkedIn og et heat-map af, før nogen har valgt. Det løser heller ingenting, hvis I påstår legitim interesse i al analytics, mens værktøjet sætter tredjeparts-cookies og bygger en profil på tværs af sites.

Det her er et andet problem end hvor serveren står. Hosting og underleverandører i cloud er en residency- og DPA-samtale. Website-GDPR er det, der forlader browseren på en fremmed maskine: hvem får URL, user-agent, formularfelter, optage af sessionen. I kan have data i en EU-region og stadig lække et browse-mønster til fem amerikanske pixels. Begge dele skal I kunne forklare. De erstatter ikke hinanden.

Vi skriver det, fordi bureauer elsker at sælge et CMP som færdigt arbejde. CMP'et er et værktøj. Arbejdet er at kende jeres kald, at gate dem, og at lade politikken beskrive virkeligheden. Uden det er I compliant i Figma og i brud i production.

Første lag er teksten. Privatlivspolitik og cookie-deklaration skal sige, hvem I er, hvad I samler ind, hvorfor, hvor længe, og hvem der er databehandler. Det er kedeligt, og det er nødvendigt. Det er også det lag, folk opdaterer sidst. En politik der stadig nævner et værktøj, I slukkede, eller mangler det chat-produkt, I tændte i sidste uge, er et signal om, at I ikke har et inventar.

Andet lag er cookies og lignende teknik — localStorage, pixels, fingerprint-agtige signaler. Nødvendige er de, uden hvilke den tjeneste brugeren bad om, ikke virker: kurv, login-session, load-balancing, et samtykke-valg I skal huske. Alt der måler, retargeter, personaliserer på tværs eller optager sessionen, er typisk samtykke. "Vi bruger det til at forbedre sitet" er et formål. Det er ikke automatisk et grundlag.

Tredje lag er netværket. Åbn DevTools. Reload. Se hvad der går, før I klikker. Det er jeres rigtige datakort. Et kald til et analyse-domain, et dobbeltklik-id, en CNAME der ligner first-party men peger på en vendor — det er behandling. Hvis banneret stadig viser "afventer valg", og kaldet allerede er sket, er banneret dekoration.

De tre lag skal stemme overens. Politik uden kald er fiktion. Kald uden politik er det, en tilsynssag peger på. Cookies uden kald kan være rester. Kald uden cookies kan stadig være personoplysninger. Tænk i strømme, ikke i "har vi husket cookie-banneret".

Nødvendigt er det, der får den handling, brugeren bad om, til at virke. En kurv. En session efter login. Et load-balancer-cookie. Et samtykke-cookie der husker "nej tak". Et security-token. Det er en kort liste. Den bliver ikke længere, fordi marketing kalder et værktøj "essentielt". Hvis sitet virker uden kaldet, var kaldet ikke nødvendigt.

Analytics er det hyppigste selvbedrag. First-party, cookieless, aggregeret måling kan i nogle designs forsvares uden samtykke — det er et juridisk kald, og det kræver, at I faktisk har slået identifikatorer og deling fra. Klassisk pageview med et klient-id, der følger brugeren, og som I blander med ads, er ikke det design. Antag ikke "statistik er legitim interesse" og lad GTM stå åben. Byg målingen, så I kan forklare den, eller spørg om lov.

Marketing-pixels, A/B-værktøjer der profiler, session replay, most heatmaps, embedded sociale feeds og "smart" chat der sender URL og snippet til en model, er samtykke-land. Chat kan være funktionel, hvis den er jeres egen, først åbner efter et klik, og ikke lækker siden til en tredjepart før tid. Den chat, der injector et script på alle sider og lytter med det samme, er det ikke.

Embeds er det, folk glemmer. YouTube, maps, en booking-iframe, et review-widget. De sætter ofte cookies, I ikke har listet. En ærlig løsning er at vise en pladsholder og først loade embeddet efter ja — eller efter et bevidst klik på "vis kort". Det er mere arbejde end at paste et iframe. Det er også det, der gør politikken sand.

Det tekniske krav er simpelt at sige og nemt at fejle: intet samtykke-krævende script må evalueres, før valget er ja. Ikke "må ikke sætte cookie". Evalueres. Et script der kører og så "vælger ikke at sætte", har ofte allerede sendt IP og URL. Server-side tagging flytter kaldet. Det sletter det ikke. Hvis I sender de samme events til samme vendor, har I stadig en behandling — I har bare gjort den sværere at se i browseren.

På et Next.js-site betyder det: tredjepart i en loader, der læser samtykke-state, ikke i root-layout som default. Chat, analytics, pixels, embeds. Consent Mode og tilsvarende signaler er nyttige, når I allerede har et ærligt inventar. De er ikke en fritagelse til at loade tagget alligevel. Et default-on tag med "consent unknown" er det mønster, vi ser oftest — og det er det forkerte default.

På WordPress betyder det: temaet og de plugins, der injector i head, ikke kun CMP-pluginet. Et SEO-plugin, et chat-plugin og et pixel-plugin kan alle ignorere banneret. Ét sted der styrer, hvad der må loade, slår fem plugins der hver især "støtter GDPR".

Tilbagekaldelse er det, I glemmer bagefter. Brugeren skal kunne sige nej i morgen. Så skal I slukke de tags, slette de cookies I kan, og lade politikken sige hvordan. Hvis "administrer cookies" linker til en død anker, har I bygget et museum. Sæt det i footeren, og test at et nej faktisk fjerner kaldet ved næste load.