Richtlijn voor toestemmingsbeheer voor mobiele apps
Overzicht
Dit document biedt uitgebreide richtlijnen voor het implementeren van toestemmingsbeheer in mobiele applicaties en zorgt ervoor dat wordt voldaan aan de regelgeving inzake gegevensbescherming, waaronder de AVG, LGPD en de vereisten van het Transparency & Consent Framework (TCF) van het IAB. Het behandelt de juiste verwerking van toestemming van gebruikers voor diensten van derden, waaronder advertentienetwerken, analyseplatforms en andere trackingdiensten.
Implementatievereisten
1. Initialiseer geen diensten van derden zonder toestemmingsverificatie
Implementatiestappen:
- Controleren of de gebruiker een toestemmingsbeslissing heeft genomen
- Controleer de toestemming voor de specifieke leverancier/service
- Initialiseer de service alleen als aan beide voorwaarden is voldaan
- Als er voor een bepaalde leverancier of voor een bepaald doel geen toestemming is verleend, moet u het volgende doen:
- Sla de initialisatie van die service over (bijvoorbeeld Google AdMob);
- Gebruik privacyvriendelijke alternatieven, indien beschikbaar;
- Beperk de beschikbare functionaliteiten op basis van uw productinkomstenstrategie. Bijvoorbeeld: in een volledig gratis app die alleen afhankelijk is van de weergave van advertenties als inkomstenbron, kunt u een vriendelijke melding weergeven dat de app niet of slechts gedeeltelijk beschikbaar zal zijn, tenzij toestemming is gegeven voor marketingdoeleinden.
2. Twee-fase toestemmingscontrole
Voer altijd beide controles uit zoals vereist door artikel 7(1) van de AVG en de IAB TCF-specificaties:
Fase 1: Heeft de gebruiker een beslissing genomen?
- Controleren of de gebruiker interactie heeft gehad met de toestemmingslaag
- Indien er geen besluit is genomen, geen persoonsgegevens verwerken
Fase 2: Geeft de gebruiker toestemming voor een specifiek doel?
- Controleer of er toestemming is verleend voor de specifieke dienst van derden
- Voor elke leverancier/dienst is een individuele toestemmingsverificatie vereist
Gebruikersworkflowscenario's
Scenario 1: Normale gebruikersworkflow
Stroom: Gebruiker opent app → SDK toont toestemmingslaag (indien nodig) → Gebruiker maakt keuze → App gaat verder met de juiste services
Belangrijk: navigatie of gebaren via de terugknop zijn uitgeschakeld op onze mobiele SDK's. De gebruiker kan de toestemmingslaag dus niet sluiten zonder de juiste toestemming.
Implementatiestappen:
- App opstarten: Initialiseer het platform voor toestemmingsbeheer. Hiervoor gebruikt u de methode checkAndOpen(). Bekijk de voorbeelden in onze helpdocumentatie (iOS, Android)
- Toestemmingscontrole: in de vorige stap wordt automatisch bepaald of toestemming nodig is of niet, zodat de gebruiker een weloverwogen beslissing kan nemen over zijn toestemming.
- Service-initialisatie: initialiseer services op basis van de toestemming van de gebruiker
Implementatievoorbeeld:
// This hypothetical example assumes you have implemented:
// - OneSignal (s1448)
// - Google Ads/AdMob (s1)
// - Google Analytics (s26)
class yourGreatApp {
void function onAppLaunch() {
if shouldInitializeService("s148") {
OneSignal.initialize("your-token")
}
if shouldInitializeService("s1") {
AdMobService.initialize()
}
if shouldInitializeService("s26") {
FirebaseAnalytics.initializeApp("your-token")
}
}
boolean private function shouldInitializeService(string: purposeId):
// Phase 1: Check if user has made any decision
consentStatus = CMPManager.getUserStatus()
if consentStatus.status = "choiceDoesntExist"
return false // Consent Layer was not yet displayed to this client
return CMPManager.shared.getStatusForPurpose(id: purposeId) == "granted"
}
}Scenario 2: Geen internetverbinding
Stroom: Gebruiker opent app zonder internet → CMP kan toestemmingslaag niet laden → App moet netjes worden afgehandeld
Kritische observaties:
- Onze mobiele SDK kan geen configuratie ophalen van servers
- Eerdere toestemmingsbeslissingen kunnen nog steeds geldig zijn (conform artikel 7(3) van de AVG over het intrekken van toestemming).
- De app moet in een gedegradeerde modus functioneren zonder verwerking van persoonsgegevens, indien er nog geen toestemming is gegeven.
Implementatiestrategie:
- Controleer op mogelijke gegevens over de aanhoudende toestemming van eerdere sessies (u zult
getUserStatus()(zoals in het vorige voorbeeld) - Als er al eerder toestemming is gegeven, ga dan op de normale manier te werk
- Indien geen aanhoudende toestemming en geen internet:
-
- Blokkeer alle niet-essentiële diensten van derden
- Toon een gebruiksvriendelijk bericht waarin de situatie wordt uitgelegd
- Stel de connectiviteitslistener in om het opnieuw te proberen wanneer de verbinding is hersteld en geef de toestemmingslaag weer wanneer dit gebeurt
- Basisfunctionaliteit van de app toestaan waarvoor geen verwerking van persoonsgegevens nodig is
Overwegingen met betrekking tot de gebruikerservaring:
- Geef een duidelijk bericht weer over beperkte functionaliteit
- Implementeer de optie om opnieuw te proberen wanneer de verbinding beschikbaar is
- Leg uit dat er geen persoonlijke gegevens worden gedeeld totdat er privacykeuzes zijn gemaakt
- Bied de mogelijkheid om in beperkte modus door te gaan
Scenario 3: Geen toestemming nodig
Situatie: Gebruiker bevindt zich buiten de EU en CMP is geconfigureerd om alleen in de EU weer te geven → Geen toestemmingslaag weergegeven
Implementatiestrategie:
- Initialiseer de CMP-configuratie zoals normaal
- Laat CMP bepalen of de toestemmingslaag moet worden weergegeven met behulp van
checkAndOpen() - Als er geen toestemming nodig is, zal de gebruikersstatus 'choiceExists' retourneren en zullen de leveranciers en doeleinden worden ingesteld op 'toegekend'.
- Initialiseer alle services normaal
Reageren op toestemmingswijzigingen
Wijzigingen in toestemming kunnen in verschillende scenario's plaatsvinden:
- Gebruiker opent toestemmingsinstellingen en wijzigt voorkeuren
- Toestemming verloopt en moet worden vernieuwd (deze instelling vindt u onder Juridisch op uw CMP-dashboard)
- Wijzigingen in de wettelijke vereisten die het onthouden van toestemming afdwingen
- Gebruiker verzoekt om verwijdering van gegevens
De checkAndOpen() De methode reageert op al deze situaties. Implementeer een listener die toestemmingswijzigingen bijhoudt. U kunt de didReceiveConsent terugbellen voor dat (iOS en AndroidAls een bepaalde leverancier of een bepaald doel op enig moment wordt afgewezen, dient u onmiddellijk actie te ondernemen en de services dienovereenkomstig te blokkeren.
Controlelijst testen
Functioneel testen
Normale stroomtest:
- App start correct en toont toestemmingslaag indien nodig
- De toestemmingskeuzes van de gebruiker worden correct vastgelegd en gerespecteerd
- Diensten worden alleen geïnitialiseerd met de juiste toestemming
- App functioneert correct na toestemmingsbeslissingen
Afwijzingsstroomtest:
- Gebruikersafwijzing blokkeert op de juiste manier diensten van derden
- De app blijft functioneel of gaat in de gedegradeerde modus, afhankelijk van uw inkomstenstrategie
Offline testen:
- App kan probleemloos overweg met een internetverbinding
- Gecachte toestemmingsgegevens worden op de juiste manier gebruikt
- De privacyvriendelijke modus wordt geactiveerd wanneer nodig
- Herstel van de verbinding activeert de juiste logica voor opnieuw proberen
Time-outtesten:
- Time-out van de toestemmingslaag activeert een passende terugval
- App loopt niet vast of crasht niet tijdens time-out
- De fallback-modus blokkeert de gegevensverwerking op de juiste manier
- Gebruiker ontvangt duidelijke communicatie over de status
Nalevingstests
Verificatie van gegevensverwerking:
- Er worden geen trackinggegevens verzonden voordat de gebruiker een toestemmingsbeslissing neemt
- Leveranciers-ID's correct gekoppeld aan daadwerkelijke diensten
- Individuele serviceblokkering werkt zoals bedoeld
- Toestemmingsgranulariteit correct geïmplementeerd
Verificatie van wettelijke vereisten:
- Bij intrekking van de toestemming wordt de gegevensverwerking onmiddellijk stopgezet
- Rechten van betrokkenen kunnen worden uitgeoefend via de app
- Er wordt een goed controletraject bijgehouden voor toestemmingsbeslissingen
- Juridische basis gedocumenteerd voor alle gegevensverwerking
Problemen oplossen
Veelvoorkomende problemen en oplossingen
Probleem: Services worden geïnitialiseerd, zelfs als de toestemming wordt geweigerd
Hoofdoorzaken:
- Ontbrekende toestemmingscontrole vóór service-initialisatie
- Onjuiste leveranciers-ID-toewijzing
Oplossingen:
- Voeg expliciete toestemmingscontrole toe vóór ALLE initialisatie van services van derden
- Controleer of de leveranciers-ID's overeenkomen met die in de wereldwijde leverancierslijst
- Implementeer een goede synchronisatie tussen toestemming en service-initialisatie
- Duidelijke service-instanties wanneer toestemming wordt ingetrokken
Probleem: toestemmingslaag wordt nooit weergegeven
Mogelijke oorzaken:
- Onjuiste CMP-configuratie (verkeerde ID, domein, enz.)
- Netwerkverbindingsproblemen
- Gebruiker bevindt zich buiten het geografische doelgebied
- Problemen met app-integratie
Stappen voor foutopsporing:
- Controleer of de CMP-configuratie overeenkomt met de accountinstellingen
- Test de netwerkconnectiviteit en de toegankelijkheid van de CMP-server
- Controleer de consolelogboeken op foutmeldingen
- Test met force-open toestemmingslaag om integratie te verifiëren
- Bevestig geografische targetinginstellingen in het CMP-dashboard
Checklist voor implementatieprioriteit
Hoge prioriteit (moet voltooid zijn vóór de lancering):
- Toestemmingsverificatie geïmplementeerd vóór ALLE initialisatie van diensten van derden
- Correcte foutbehandeling bij time-out-, netwerk- en configuratieproblemen
- Basisfunctionaliteit van de app blijft behouden als toestemming niet kan worden vastgesteld
- Alle leveranciers-ID's zijn geverifieerd en correct gekoppeld aan de daadwerkelijke services
Voortdurende verbeteringen:
- Volg de analyses op uw CMP-dashboard voor succespercentages van toestemmingen
- A/B-testen voor optimalisatie van de toestemmingslaag
- Integratie met aanvullende compliance-frameworks
- Verbeterde gebruikersvoorlichting over privacykeuzes
Onthoud: kies bij twijfel over toestemmingsvereisten altijd voor de meest privacybeschermende aanpak. Het is beter om overdreven voorzichtig te zijn dan de privacy van gebruikers of wettelijke vereisten te schenden.
