Je app is klaar, de privacyverklaring is AVG-conform opgesteld, en dan begint het publicatieproces. Apple vraagt of je Financial Info verzamelt. Google wil weten of je gegevens shared worden met derden. Je kijkt naar je verklaring en denkt: dit staat er toch allemaal in? Dat klopt, maar de terminologie matcht niet. En als je store-formulier andere conclusies lijkt te trekken dan je privacyverklaring, heb je een concreet compliance-probleem.

Twee stores, twee logica’s: waarom dit echt een probleem is

Apple Privacy Labels en Google Play Data Safety zijn geen simpele samenvattingen van je privacyverklaring. Ze zijn aparte systemen met eigen categorieën, eigen definities en eigen regels over wat ‘gegevens verzamelen’ betekent. Als je het store-formulier invult op basis van gevoel of een snelle scan van je bestaande tekst, ontstaan er inconsistenties. Die inconsistenties kunnen leiden tot afwijzing in de review, een verwijdering uit de store, of erger: een toezichthouder die twee tegenstrijdige documenten naast elkaar legt.

Het architectuurverschil: snapshot versus doorlopend proces

Apple werkt met een snapshot-model. Op het moment dat jij een app-update ter review instuurt, bekijkt Apple je opgegeven labels. Die labels blijven zichtbaar in de store totdat je een volgende update publiceert, ook als de werkelijkheid intussen is veranderd. Je kunt dus maanden lang verouderde labels tonen zonder dat Apple daar automatisch iets van merkt.

Google werkt anders. Het Data Safety-formulier staat los van je release-cyclus. Je kunt het op elk moment aanpassen, en Google verwacht dat je dat ook doet zodra je gegevenspraktijken veranderen. Dat klinkt vrijer, maar het risico is juist dat het formulier wordt vergeten als er geen release-moment is dat je eraan herinnert.

Praktisch gevolg: bij Apple is een app-update het triggerpunt om je labels te checken. Bij Google moet je een eigen triggerpunt inbouwen.

Categorieënduel: wat Apple en Google benoemen dat de AVG niet kent

De AVG spreekt over persoonsgegevens en bijzondere categorieën. Apple en Google hebben hun eigen vocabulaire, en die overlapt maar gedeeltelijk. Onderstaande tabel helpt je vertalen.

Apple-categorie Google-equivalent AVG-vertaling Valkuil
Financial Info Financial Info Financiële gegevens (persoonsgegevens) Apple rekent ook betaalmethode-type hieronder; Google scheidt betaalgeschiedenis apart
Sensitive Info Health and Fitness / Personal Communications Bijzondere categorieën (art. 9 AVG) Apple bundelt gezondheid, geloof en seksualiteit; Google splitst dit in aparte rubrieken
Usage Data App Activity Gebruiksgegevens / loggegevens Apple telt sessieduur mee; Google rekent zoekgeschiedenis binnen de app apart
Device ID Device or Other IDs Technische identificatoren (persoonsgegevens als koppelbaar) Apple vraagt of ID gekoppeld is aan identiteit; Google vraagt of ID gedeeld wordt
(geen equivalent) App Info and Performance Crashlogs, diagnostische gegevens Apple heeft hier wel een categorie voor (Diagnostics), maar plaatst die anders in de flow

Het definitieverschil dat je verklaring kan ondermijnen

Dit is het punt waar de meeste inconsistenties ontstaan. Apple vraagt of gegevens linked to identity zijn, dus of een datapunt herleidbaar is tot een specifieke gebruiker. Google vraagt of gegevens shared worden met derden.

Neem een analytics-SDK als voorbeeld, Mixpanel of Amplitude. Die SDK verzamelt gebruiksgedrag en koppelt dat intern aan een gebruikers-ID. Bij Apple moet je dat waarschijnlijk aanvinken als ‘linked to identity’. Bij Google hoef je dat alleen te melden als je die data actief deelt met derde partijen, buiten de serviceprovider-uitzondering om.

Jouw privacyverklaring zegt misschien: ‘Wij delen geen persoonsgegevens met derden voor commerciële doeleinden.’ Dat is correct voor Google. Maar als je bij Apple toch ‘not linked to identity’ hebt aangevinkt, terwijl de SDK dat wel doet, heb je een strijdigheid.

Third-party SDKs: de grootste blinde vlek

Apple is hier streng: jij bent verantwoordelijk voor de labels van alle SDKs in je app. Ook als jij de SDK niet zelf hebt gebouwd. Google vraagt alleen wat jíj als developer deelt, niet wat de SDK intern doet. Dat maakt Apple-labels bewerkelijker, maar ook dichter bij de AVG-verwerkingsverantwoordelijkheid.

Doorloop deze stappen voor een SDK-inventarisatie die beide stores dekt:

Stap 1. Maak een volledige lijst van alle SDKs in je app. Gebruik je package manager (CocoaPods, Gradle, npm) om niets te missen. Een webshop-app met vijftien SDKs voor analytics, betalingen, crashrapportage en A/B-testen is eerder regel dan uitzondering.

Stap 2. Zoek per SDK de officiële privacydocumentatie op. Grote partijen als Google (Firebase), Meta (SDK), Braze en Adjust publiceren Apple-specifieke privacy manifests. Gebruik die als bron, niet je eigen aannames.

Stap 3. Noteer per SDK welke Apple-categorieën van toepassing zijn en of de data linked to identity is. Dit is je Apple-input.

Stap 4. Bepaal per SDK welke data jij actief exporteert of deelt buiten de app-infrastructuur. Dit is je Google-input en je AVG-verwerkingsregister.

Stap 5. Leg de uitkomsten naast je bestaande privacyverklaring. Elke SDK-categorie die je in stap 3 of 4 hebt gevonden, moet ergens in je verklaring terugkomen.

Auditprotocol: in welke volgorde je werkt

Begin altijd met Google Data Safety, daarna Apple Labels. Waarom? Google’s categorieën sluiten beter aan op de AVG-logica van ‘welke data verwerk je en deel je’. Dat geeft je een gestructureerde basis. Vervolgens pas je Apple’s linked-to-identity-laag toe, die vaak aanvullende details vereist maar zelden iets nieuws onthult als je de Google-ronde grondig hebt gedaan.

Velden die direct corresponderen met AVG-verwerkingsgronden: Google’s Data collected for analytics komt overeen met gerechtvaardigde belangen of toestemming; Data shared with third parties raakt aan je vermelding van ontvangers in de privacyverklaring (art. 13 AVG). Apple’s Data used to track you is vrijwel altijd toestemming-plichtig en moet als zodanig in je verklaring staan.

De drie meest voorkomende strijdigheden en hoe je ze oplost

Strijdigheid 1: je verklaring noemt ‘geen tracking’ maar je Apple-label zegt anders. Dit gebeurt als je een retargeting-SDK hebt toegevoegd na het schrijven van de verklaring. Herschrijf je verklaring zodat tracking expliciet wordt benoemd, inclusief het doel (gerichte advertenties) en de grondslag (toestemming via je cookiebanner of app-permissie).

Strijdigheid 2: je Google-formulier zegt ‘data niet gedeeld met derden’ maar je verklaring noemt wel partijen. Waarschijnlijk heb je je analyticspartner als ontvanger vermeld, terwijl Google die als serviceprovider beschouwt (en die uitzondering dus niet laat tellen als ‘gedeeld’). Consisteer dit door in je verklaring hetzelfde onderscheid te maken: ontvangers die als verwerker optreden versus derden die data voor eigen doeleinden gebruiken.

Strijdigheid 3: Apple-label vermeldt financiële gegevens maar je verklaring niet. Dit komt vaak voor bij apps die Stripe of een andere betaalprovider integreren. Voeg een aparte paragraaf toe over betalingsgegevens: wie die verwerkt (de provider, niet jij), op welke grondslag, en dat jij zelf geen volledige kaartgegevens opslaat.

Onderhoud na publicatie: sync houden zonder chaos

Zet een intern wijzigingslog op in een eenvoudig spreadsheet of document met vier kolommen: datum, gewijzigd onderdeel (SDK, functie, datapraktijk), impact op Apple-label (ja of nee), impact op Google-formulier (ja of nee). Vul dit in bij elke sprint review of release-beslissing.

Bij Apple is de regel helder: bij elke app-update moet je je labels opnieuw bevestigen. Maak er een vast punt van in je release-checklist, net als het updaten van de versienummers.

Bij Google geldt geen vaste trigger, maar een kwartaalcheck is een reëel minimum. Plan dat in als terugkerende agenda-afspraak. Als je in december een nieuwe SDK toevoegt voor seizoensgebonden functies en je vergeet het formulier bij te werken, kun je het nieuwe jaar beginnen met een inconsistentie die maanden onzichtbaar blijft.