Integritet i appen – GDPR, samtycke och butiksetiketter
Av CodexierPublicerad 6 min läsning
En apps integritetsberättelse finns på fyra ställen: vad koden faktiskt samlar in, vad samtyckesskärmen frågar, vad integritetspolicyn lovar och vad App Stores och Google Plays integritetsetiketter deklarerar. När de fyra inte stämmer överens kommer konsekvenserna från olika håll: ett avslag i butiken, ett klagomål till IMY från en användare, eller en recension som säger att appen spårar mer än den erkänner. Den här guiden går igenom hur ni samordnar dem, med start i det enda stället som inte kan ljuga, koden.
Data appen faktiskt samlar in
De flesta integritetsproblem i appar kommer från uppgifter teamet inte visste att det samlade in. Analys-SDK:n som läser reklamidentifieraren som standard, kraschrapportören som fångar föregående skärm med dess formulärfält, kartbiblioteket som anropar sina egna servrar. Börja med en nätverkslogg från en testenhet under en hel session och lista varje ändpunkt och vad den tar emot. Lägg sedan till vad er egen backend lagrar. Den listan är sanningen som de tre andra dokumenten måste stämma med.
Samtycke och spårningsfrågor i appen
GDPR kräver inte samtycke för allt; den kräver en rättslig grund för varje ändamål, och samtycke är bara en av dem. Uppgifter som behövs för att leverera tjänsten användaren bett om vilar på avtalet. Analys och marknadsföringsspårning behöver oftast samtycke. Apples spårningsfråga är ett separat, ytterligare krav för allt som kopplar användaren till data från andra företag för reklam. Utforma samtycket så att det ställer rätt fråga i rätt ögonblick och fungerar när svaret är nej.
| Ändamål | Rättslig grund | När ni frågar | Om användaren avböjer |
|---|---|---|---|
| Konto, bokningar, ordrar | Avtal | Inget samtycke behövs; förklara i policyn | Ej tillämpligt |
| Kraschrapporter utan personuppgifter | Berättigat intresse | Informera, ingen fråga krävs | Ej tillämpligt |
| Produktanalys | Samtycke i de flesta upplägg | Första start, efter att värdet syns | Appen fungerar fullt ut, analys av |
| Pushnotiser | Systembehörighet plus ändamål | När användaren slår på en funktion som behöver dem | Funktionen förklarar vad de missar |
| Reklamspårning mellan appar | Samtycke plus Apples spårningsfråga | Bara om ni faktiskt gör detta | Ingen spårning; appen får inte försämras |
Integritetsetiketter i butikerna
Apples avsnitt App Privacy och Googles formulär Data Safety ber båda utvecklaren deklarera vad appen samlar in, om det kopplas till användaren och om det används för spårning. Båda är deklarationer ni ansvarar för, och båda butikerna kör automatiska kontroller som jämför deklarationen med vad appen gör. Fyll i dem från inventeringen, och uppdatera dem i samma release som ändrar dataflödet.
- Deklarera uppgifter som samlas in av SDK:er, inte bara av er egen kod; SDK-leverantörerna publicerar vad de samlar in just för detta.
- Kopplat till användaren betyder knutet till ett konto eller en identifierare. Kraschloggar med användar-id är kopplade; aggregerade räkningar är det inte.
- Säger ni att data inte samlas in men analys-SDK:n skickar en enhetsidentifierare, räkna med avslag eller en tvingad uppdatering.
- Spara en daterad kopia av varje inlämning så att ni kan visa vad som deklarerades när.
- Google kräver också en publik länk till integritetspolicyn som öppnas utan inloggning och stämmer med formuläret.
Tredjeparts-SDK:er och datadelning
Varje SDK i appen är ett företag som tar emot uppgifter om era användare, och enligt GDPR gör det dem till ett biträde ni behöver avtal med, eller en separat ansvarig ni måste namnge. Det praktiska arbetet är ett kort register och en regel för att lägga till nya.
SDK-register
Namn, leverantör, ändamål, uppgifter som skickas, behandlingsplats, biträdesavtal tecknat ja eller nej. En rad per SDK, granskad när ett beroende uppdateras.
Dataplats
Många leverantörer av analys och meddelanden behandlar i USA som standard. Välj en EU-region där det erbjuds och dokumentera överföringsmekanismen där det inte gör det.
Lägga till en SDK
Innan den går in i appen: vad samlar den in, behöver den samtycke, behöver policyn en ny mottagare, ändras butiksetiketterna. Fyra frågor, besvarade i pull requesten.
Begäran om radering och konton
Båda butikerna kräver nu att en app som låter användare skapa konto också låter dem radera det inifrån appen, och GDPR ger användare rätt till radering oavsett. Radering är en funktion, inte en supportprocess: den måste ta bort kontot, personuppgifterna i er backend och, så långt ni kan utlösa det, uppgifterna hos era biträden. Bestäm vad ni behåller av juridiska skäl, som fakturor enligt bokföringslagen, och säg det.
- En åtgärd Radera konto i inställningarna, med tydlig förklaring av vad som tas bort och vad som behålls och varför.
- Backendradering som följer med till relaterade poster, med en loggpost om att raderingen skett utan att uppgifterna sparas.
- Raderingsbegäran vidarebefordrad till biträden som håller uppgifter på användarnivå, som analys- eller meddelandeplattformar.
- Ett sätt att hantera begäran via mejl också, för användare som redan avinstallerat appen.
- Ett gallringsschema: vad som raderas automatiskt efter inaktivitet, och när.
När ni inte behöver detta av oss: en app utan konton, utan analys och utan tredjeparts-SDK:er har en kort policy och enkla etiketter, och plattformarnas mallar räcker. Arbetet växer med varje SDK och varje integration, och det måste göras om vid varje release som ändrar dataflöden, och därför behandlar vi det som en del av appunderhåll snarare än en engångsuppgift; månadspaketet på prissidan inkluderar SDK-registret och etikettuppdateringar. Vill ni veta om er nuvarande apps berättelse går ihop, boka ett samtal så tittar vi på den tillsammans.
Vanliga frågor
Behöver vi en samtyckesskärm vid första start?
Bara om ni gör något vid första start som kräver samtycke, typiskt analys eller marknadsföringsspårning. Kan ni skjuta upp det tills användaren sett värde, fråga då; samtyckesgraden blir högre och första intrycket renare. Uppgifter som behövs för själva tjänsten behöver ingen samtyckesfråga alls.
Vår analys-SDK säger att den är GDPR-kompatibel. Räcker det?
Nej. Leverantörens efterlevnad täcker deras sida; ni bestämmer fortfarande ändamålet, behöver en rättslig grund, måste namnge dem i policyn och etiketterna och måste teckna deras biträdesavtal. Kompatibla SDK:er gör detta möjligt, inte automatiskt.
Vad händer om butiksetiketterna är fel?
Apple och Google kan avvisa en uppdatering, kräva en rättelse eller vid upprepning ta bort appen. Användare och forskare jämför också etiketter med nätverkstrafik och rapporterar avvikelser offentligt. Rätta etiketterna i nästa release, och behåll inventeringen så att det inte händer igen.
Kan vi behålla vissa uppgifter efter kontoradering?
Ja, där lag kräver det, som fakturauppgifter enligt bokföringslagen, eller där ni har ett berättigat skäl som bedrägeriförebyggande med en bestämd lagringstid. Ange vad ni behåller och hur länge i raderingsflödet och policyn.
Osäker på om appens integritetsberättelse går ihop?
Femton minuter: berätta vilka SDK:er som finns i appen och vad etiketterna säger, så pekar vi ut var de fyra berättelserna troligen skiljer sig åt.
Boka ett kostnadsfritt 15-minuterssamtal