Dataindsamling til marketing: kilder, samtykke og datakvalitet

Start med kortet: hvor kommer oplysningerne egentlig fra?

Inden samtalen falder på samtykker og systemer, er der god grund til at skitsere et enkelt kort over, hvor oplysningerne kommer fra. De fleste virksomheder har tre kildekategorier: (1) oplysninger, virksomheden selv skaber under driften, (2) oplysninger, kunden afgiver aktivt, og (3) oplysninger, der ankommer via eksterne parter som platform, betalingsleverandør og hosting.

Den første kategori er den, man oftest glemmer, fordi ingen har tastet den ind. Den opstår af sig selv, når en webserver besvarer et kald: en serverlog kan rumme navnet på den fil, der blev anmodet om, IP-adressen, dato og tidspunkt for kaldet, den overførte datamængde og hvilken udbyder, der stod bag anmodningen. Det er oplysninger om en fysisk person, selv om de mest af alt ligner driftsteknik.

Kategori nummer to er den letteste at få øje på: navn, adresse, kontaktoplysninger, betalingsoplysninger og selve ordren – plus det kundekort, der oprettes, hvis kunden vælger en kundekonto. Den tredje kategori ankommer i form af bekræftelser, betalingsstatus og tekniske oplysninger fra de leverandører, der indgår i købsflowet.

Pointen med kortlægningen er ikke at sortere efter teknologi – logfil, formular, API – men efter formål. Oplysninger om fysiske personer indsamles og anvendes dagligt til mange forskellige formål, og netop derfor skal hver enkelt kilde forklares med et formål og ikke med den teknik, der opsamler den. Skriv derfor kortet sådan: kilde, formål, hvem der er ansvarlig, og hvor længe oplysningerne bliver liggende.

Formål før grundlag: ét retsgrundlag pr. datakilde

Samme type oplysning kan hvile på forskellige behandlingsgrundlag, alt efter hvad den bruges til. Skal du levere den vare, kunden har bestilt, og håndtere reklamationer og fortrydelsesret, behandles ordreoplysningerne for at opfylde aftalen. Vælger kunden en kundekonto, gælder samme grundlag for de oplysninger, kontoen består af.

Når de samme oplysninger indgår i regnskabs- og bogføringsmæssige sammenhænge, skifter grundlaget til retlig forpligtelse. Her er det hverken kundens ønske eller virksomhedens interesse, der bærer behandlingen, men de bogførings- og skattemæssige regler, der kræver, at oplysningerne opbevares og kan dokumenteres.

For driftslogge og anden teknisk telemetri er grundlaget typisk en legitim interesse: at sikre en sikker og fejlfri drift af websitet og at forbedre tilbuddet. Den interesse skal kunne vejes op mod den registreredes interesser og rettigheder – den er ikke et frikort, men en afvejning, man skal kunne gøre rede for.

Den klassiske fejl er at vælge ét grundlag som standardsvar for hele dataindsamlingen, fx samtykke, fordi det føles som det sikreste. Konsekvensen er, at man indhenter samtykke til noget, der ikke behøver det, og samtidig svækker sit grundlag for det, der faktisk kræver samtykke. Gør det modsatte: tag udgangspunkt i formålet, find grundlaget, og dokumentér koblingen kilde for kilde.

Samtykket: rigtigt værktøj til nogle formål, blindspor til andre

Samtykke er ét behandlingsgrundlag blandt flere – ikke et generelt alibi. Det hører hjemme der, hvor formålet ikke kan begrundes i en aftale eller en legitim interesse: typisk nyhedsbreve og andre løbende henvendelser til personer, samt målrettet markedsføring og sporing, hvor den registrerede med rimelighed skal kunne sige nej.

Driftslogge og ordredata hører ikke til i den kategori. Du beder ikke kunden om samtykke til, at webserveren registrerer en anmodning, eller til at ordren bliver behandlet. Lægger du samtykke ned over de behandlinger, der i forvejen har et selvstændigt grundlag, skaber du et problem uden at løse noget: samtykket bliver en ekstra forudsætning, som kan trækkes tilbage, og som du ikke havde brug for.

Det andet centrale punkt er frivilligheden. Et samtykke, der reelt ikke kan afvises uden at ydelsen forsvinder, gør ikke behandlingen mere lovlig – det flytter blot problemet fra samtykkereglerne til spørgsmålet om, hvorvidt samtykket overhovedet blev givet frit. Skal kunden sige ja til markedsføring for at kunne gennemføre et køb, er der ikke tale om et valg, men om en betingelse.

I praksis betyder det, at samtykket skal være særskilt, forståeligt og lige så nemt at trække tilbage, som det var at give – og det skal kunne dokumenteres, så du senere kan vise, hvad den enkelte sagde ja til, hvornår og til hvilket formål. Opbevar dokumentationen adskilt fra selve markedsføringslisten.

Datakvalitet er også en udløbsdato

Datakvalitet bliver ofte reduceret til, om felterne er udfyldt korrekt – rigtigt postnummer, gyldig e-mail, ingen dubletter. Men kvalitet handler i lige så høj grad om, hvorvidt oplysningerne stadig er relevante for det formål, de blev indsamlet til, og om de bliver gemt længere, end der er brug for.

Adgangsdata er det klare eksempel på kort levetid. I praksis ses privatlivspolitikker, hvor serverlogge udelukkende vurderes for at sikre en fejlfri drift og forbedre tilbuddet, og hvor adgangsdata slettes senest syv dage efter besøgets afslutning. Loggen har gjort sit arbejde, når fejlen er fundet, eller fraværet af fejl er konstateret.

Forretningsoplysninger har en anden rytme. Når aftalen er gennemført, begrænses behandlingen af oplysningerne til det, der fortsat er nødvendigt, og de slettes først, når de lovpligtige opbevaringsfrister efter bogførings- og skattereglerne er udløbet. Det er ikke dovenskab i systemet, men et bevidst valg, der følger af en retlig forpligtelse.

Forskellige levetider er altså ikke tilfældigheder, men beslutninger. Skriv dem ned som en sletteplan: hvilke oplysninger, hvilket formål, hvornår de begrænses, og hvornår de slettes. En sletteplan er også det nemmeste sted at opdage, at man er begyndt at gemme noget, fordi det var nemt, snarere end fordi det var nødvendigt.

Levetid for forskellige typer oplysninger

• Kundekontooplysninger — Opbevares til kunden sletter konto eller aftalen ophæves, men ikke længere end lovgivning tillader

Fra enkeltoplysning til profil: hvad ændrer sig?

Indsamlingen skifter karakter, når oplysningerne ikke længere bruges til at levere en konkret vare eller ydelse, men til at opdele kunder i segmenter, målrette indhold og optimere websitet. Den enkelte oplysning er den samme, men sammenstillingen fortæller noget andet og mere, end kunden selv har givet udtryk for.

Det stiller krav til gennemsigtigheden. Der er forskel på at beskrive en behandling som "vi behandler dine data" og at beskrive, at data bruges til målretning på sitet, til optimering af websitet og til opdeling i segmenter. Mange privatlivspolitikker har da også selvstændige afsnit om netop ciblage på sitet og optimering af websitet samt om automatiseret beslutningstagning og profilering – netop fordi det er en anden behandling end ordrehåndteringen og skal kunne læses særskilt.

Internt betyder det, at dokumentationen skal følge de nye formål: hvilke data indgår i segmenteringen, hvad bygger opdelingen på, hvor længe profilen lever, og hvem har adgang til den. En profil, der er bygget på oplysninger indsamlet til et helt andet formål, er svær at forsvare, uanset hvor godt den virker.

For den registrerede er det afgørende punkt, at behandling båret af en legitim interesse kan mødes med indsigelse. Den ret er ikke ubetinget – den gælder ikke for behandling, der er nødvendig for at opfylde en aftale, og den er ikke en generel ret til at afvise enhver behandling – men den betyder, at du skal kunne håndtere en indsigelse konkret: undersøge, om din interesse alligevel vejer tungest, og give et begrundet svar, hvis den gør.

Tredjeparterne i kæden: aftaler og grænser for overførsel

Når webshoppen kører på en ekstern platform, eller når betalinger går gennem en betalingsleverandør, behandler de på din vegne. Platformen behandler i så fald de oplysninger, du lægger ind i shoppen – typisk bestillings-, kunde- og betalingsoplysninger – for at gennemføre aftalen og for at holde sitet teknisk kørende. Det samarbejde skal være dækket af en databehandleraftale om den behandling, leverandøren udfører på virksomhedens vegne, så ansvar og instrukser står skriftligt mellem parterne.

Forlader oplysningerne EU/EØS, skal der desuden være et gyldigt overførselsgrundlag. Det kan være en tilstrækkelighedsbeslutning, hvor det pågældende tredjeland har et beskyttelsesniveau, som Kommissionen har vurderet som tilstrækkeligt, eller det kan være standardkontraktbestemmelser, der lægges ind som aftalevilkår. For overførsler til USA ses i praksis både EU-US Data Privacy Framework og standardkontraktbestemmelser som grundlag, og tilstrækkelighedsbeslutninger kan dække lande som fx Canada.

Rækkefølgen er vigtig: først find ud af, hvor oplysningerne faktisk havner, derefter hvilket grundlag der bærer overførslen, og til sidst hvad der kan stå i din egen datapolitik. Man skal ikke love kunden mere, end kæden af leverandører og overførselsgrundlag kan indfri – en datapolitik, der beskriver fuld kontrol over data, som i praksis ligger hos en ekstern platform i et tredjeland, holder ikke.

Praktisk hjælper det at føre en liste over leverandører med fire kolonner: hvad behandler de, på hvilket grundlag, hvor ligger dataene, og hvilken aftale dækker det. Listen skal opdateres, når en leverandør skiftes – det er i skiftet, hullerne opstår.

Overførsel af personoplysninger uden for EU/EØS: gyldige grundlag

Indsigt, berigtigelse og sletning som løbende kvalitetskontrol

De registreredes rettigheder bliver ofte behandlet som en juridisk parentes i bunden af datapolitikken. I praksis er de noget andet: en løbende kvalitetskontrol, der kommer udefra og ikke kan ignoreres. En indsigtsanmodning afslører med jævne mellemrum oplysninger, der er forældede, forkerte eller aldrig burde være gemt.

Tænk rækkefølgen sådan: find dataene, vurdér dem, og ret eller slet. Indsigt tvinger dig til at finde frem til, hvad der faktisk ligger – også i de systemer, ingen lige tænker på. Berigtigelse og sletning fjerner derefter det, der ikke længere er rigtigt eller relevant, og holder mængden af oplysninger nede på det niveau, formålet kræver.

Samtidig skal man turde sige nej, når det er det korrekte svar. Nogle anmodninger kan ikke imødekommes, fordi oplysningerne fortsat er nødvendige for et andet formål – fx oplysninger, der indgår i bogføringen og derfor skal opbevares, selv om kundeforholdet er ophørt. Svaret skal i så fald ikke være tavshed, men en begrundelse: hvilket formål, hvilket grundlag, og hvornår oplysningerne forventes slettet.

Behandl anmodningerne som en del af det daglige arbejde med datakvalitet og ikke som en undtagelse. Det er samme øvelse som sletteplanen, blot med en ekstern udløser – og den afslører hurtigt, om grundlaget for den enkelte datakilde stadig holder.