Wat App Tracking Transparency werkelijk regelt

ATT is een toestemmingspoort die Apple afdwingt in iOS en iPadOS. Wanneer een app toegang wil tot de Identifier for Advertisers (IDFA) van het apparaat of tracking wil uitvoeren die de gebruiker koppelt aan apps en websites van andere exploitanten, moet het requestTrackingAuthorization aanroepen en een systeemvraag weergeven die de gebruiker vraagt tracking toe te staan of te weigeren. De reactie van de gebruiker is binair, persistent totdat ze het in Instellingen wijzigen, en zichtbaar voor de app via de trackingAuthorizationStatus API.

Apple's definitie van tracking

Apple's ontwikkelaarsgids definieert tracking specifiek en nauw: het koppelen van gebruikers- of apparaatgegevens verzameld uit uw app met gebruikers- of apparaatgegevens verzameld uit de apps, websites of offline-eigendommen van andere bedrijven voor gerichte reclame of meting, of het delen van gebruikers- of apparaatgegevens met gegevensmakelaars. De definitie sluit bewust eerstepartijgebruik van gegevens binnen de app, anonieme geaggregeerde analyses en verwerking voor fraudepreventie of wettelijke naleving uit — die activiteiten vereisen geen ATT-vraag ongeacht of de gebruiker deze heeft verleend.

Wat ATT niet doet

ATT is geen toestemmingsbeheersysteem in de zin van de GDPR. Het verzamelt geen gedetailleerde doelvoorkeuren, het registreert geen toestemmingsbevestiging met beleidsversies, het verspreidt geen signalen naar webverkopers binnen een WKWebView, en het voldoet niet aan de rechtmatige-grondslag-vereiste voor het opslaan of lezen van cookies op het apparaat van een gebruiker. Een uitgever die de ATT-vraag behandelt als zijn volledige nalevingshouding voor een hybride app staat één brief van een toezichthouder verwijderd van een boete, omdat de cookielading in de webweergave een afzonderlijke gebeurtenis is onder ePrivacy en een eigen toestemmingslaag nodig heeft.

Hoe GDPR en ePrivacy van toepassing zijn binnen een WKWebView

De webweergave in een hybride app is niet op magische wijze vrijgesteld van de regels die van toepassing zijn op een desktopbrowser. Op het moment dat de WKWebView een cookie leest of schrijft die niet strikt noodzakelijk is, wordt ePrivacy getriggerd. Op het moment dat de WKWebView een analyse- of advertentieverzoek verstuurt dat persoonsgegevens bevat, wordt GDPR getriggerd. Apple's container verandert de analyse niet — wat verandert is het implementatievlak, omdat de toestemmingsbanner binnen de webweergave moet renderen en de toestemmingsstatus zichtbaar moet zijn voor de native code die mogelijk ook dezelfde gegevens leest.

De banner in de webweergave

Het standaardpatroon is om een CMP-banner in de WKWebView te renderen op dezelfde manier als op een website. De banner plaatst cookies in de cookieopslag van de webweergave, stuurt een toestemmingsupdategebeurtenis naar de JavaScript-context van de pagina en werkt een Google Consent Mode v2-toestandsmachine bij die door de analyse- en advertentietags van de pagina wordt gelezen. De implementatie verschilt niet van een normale web-CMP — wat verschilt is dat de cookieopslag beperkt is tot de WKWebView en niet zichtbaar is voor andere apps of Safari, wat nuttig is voor isolatie maar niet nuttig als de uitgever ook een website beheert waar de gebruiker al heeft ingestemd.

Toestemming delen tussen de webweergave en de native shell

Het moeilijkere probleem is de brug tussen de WKWebView en de native shell. De native shell kan zijn eigen analytics SDK hebben die de IDFA leest nadat de gebruiker ATT heeft verleend, terwijl de webweergave zijn eigen toestemmingsbanner heeft die de gebruiker al dan niet heeft geaccepteerd. Als de gebruiker ATT verleent maar advertentietoestemming in de webweergave weigert, kan de native SDK nog steeds de IDFA lezen maar mogen de tags van de webweergave dat niet. Als de gebruiker ATT weigert maar de advertentietoestemming van de webweergave accepteert, is de native SDK geblokkeerd maar moeten de tags van de webweergave nog steeds worden geactiveerd — hoewel de IDFA-gebaseerde identifier van de native SDK uiteraard niet door de brug kan. Het schoonste patroon is één bron van waarheid — de CMP — blootgesteld via een JavaScript-brug die de native shell leest bij het starten van de app en bij elke toestemmingswijziging, met een parallelle ATT-vraag die de advertentiebeslissing van de CMP volgt in plaats van opnieuw te vragen.

De CPRA- en Amerikaanse staatslaag

Voor Amerikaanse uitgevers heeft het beeld een derde laag. CPRA, plus de reeks staatswetten die Virginia, Colorado, Connecticut en Utah volgden, behandelen de IDFA op dezelfde manier als webcookies — beide zijn persoonsgegevens waarvan de verkoop of het delen een recht op opt-out activeert. De Global Privacy Control-header die webbrowsers verzenden is het consumentgerichte signaal, en de Multi-State Privacy Agreement (MSPA) van het IAB met bijbehorende US Privacy String is het uitgeversgerichte signaal. Een hybride app die in de VS wordt uitgebracht, moet een link 'Mijn persoonlijke informatie niet verkopen of delen' binnen de app zelf tonen, de resulterende opt-out doorsturen naar zowel de CMP van de webweergave als de meet-SDK van de native shell, en elke inkomende GPC-header respecteren die via een deeplink op de webweergave aankomt.

Kinderen en COPPA in hybride apps

Als de app beoordeeld is voor kinderen of als er een redelijke verwachting is van kindergebruikers, voegen COPPA in de VS en de GDPR-K-bepalingen in de EU extra beperkingen toe bovenop ATT en standaardtoestemming. De IDFA mag helemaal niet worden aangevraagd voor kinderaccounts, de advertentietoestemming van de webweergave moet standaard op weigeren staan, en elke SDK van derden in de native shell moet COPPA-conform zijn bevestigd voordat deze wordt uitgebracht. App Store-beoordeling wijst apps af die voor kinderen zijn beoordeeld en de standaard ATT-vraag tonen, wat een veelvoorkomende implementatiefout is wanneer teams één binary voor alle doelgroepen bouwen.

Het engineeringpatroon dat wordt uitgebracht

De hybride app-architectuur die zowel de App Store-beoordeling als een EU-privacyaudit doorstaat, heeft een klein aantal herhaalbare elementen. De CMP-banner in de WKWebView is de bron van waarheid voor advertentietoestemming. De ATT-vraag wordt alleen getoond nadat de CMP is opgelost, alleen als de gebruiker advertentietoestemming heeft geaccepteerd, en alleen met een aangepaste pre-vraag die uitlegt wat tracking mogelijk maakt. Een JavaScript-brug legt de toestemmingsstatus van de CMP bloot aan de native shell bij het starten van de app en stuurt een gebeurtenis bij elke toestemmingswijziging. De SDK's van de native shell zijn afhankelijk van zowel de CMP-advertentietoestemming als de ATT-autorisatiestatus; als één van beide het verzoek weigert, is dat voldoende om de SDK te blokkeren.

Pre-vragen en de Apple-richtlijn

Apple staat een pre-vraag toe — en verwacht deze in de praktijk — vóór de ATT-systeemvraag die in de stem van de uitgever uitlegt waarom de app tracking wil en wat de gebruiker daarvoor terugkrijgt. Een goed geschreven pre-vraag kan opt-inpercentages aanzienlijk verhogen. Wat Apple niet toestaat is een pre-vraag die probeert de systeemvraag te omzeilen, die de gevolgen van weigering onjuist weergeeft, of die de app-functionaliteit afhankelijk maakt van trackingautorisatie. Beoordelaars wijzen apps af voor alle drie de patronen en in toenemende mate voor het gebruik van de pre-vraag om met manipulatieve teksten naar opt-in te sturen.

Server-side en SKAdNetwork als terugvalopties

Wanneer ATT wordt geweigerd of advertentietoestemming wordt afgewezen in de webweergave, kan de uitgever nog steeds terugvallen op SKAdNetwork voor attributie — Apple's privacybeschermend netwerk dat conversiedata levert zonder individuele gebruikersidentifiers bloot te stellen. SKAdNetwork is niet onderworpen aan ATT en werkt ongeacht de toestemmingsbeslissing van de gebruiker, waardoor het de juiste standaard is voor meting wanneer het gepersonaliseerde pad gesloten is. Server-naar-server postbacks van de native shell naar een door de uitgever beheerde identiteitsservice kunnen ook het meetgat opvullen, mits de data echt eerstepartij is en niet is samengevoegd met data van andere exploitanten op een manier die het terugtrekt in Apple's trackingdefinitie.

Veelgemaakte fouten die afwijzingen of audits veroorzaken

De hybride apps die worden verwijderd of beboet, falen doorgaans op dezelfde manier. De CMP-banner in de WKWebView wordt geactiveerd voordat de ATT-vraag is opgelost, waarbij cookies op het apparaat worden geplaatst terwijl Apple's toestemming nog in behandeling is — een bevinding die kan resulteren in afwijzing door de App Store. De ATT-vraag wordt getoond zonder pre-vraag en bij een koude start, waardoor lage opt-inpercentages en een verwarrende gebruikerservaring worden geproduceerd die het verloop verhoogt. De analytics SDK van de native shell leest de IDFA voordat de CMP zijn eerste toestemmingsgebeurtenis heeft afgevuurd, waardoor persoonsgegevens op de draad worden geplaatst zonder duidelijke rechtmatige grondslag. De toestemmingsstatus van de webweergave en de autorisatiestatus van de native shell worden bewaard in afzonderlijke opslageenheden zonder synchronisatie, waardoor een gebruiker wordt geproduceerd die adverteren in de webweergave heeft geweigerd maar wiens native advertentie-SDK nog steeds wordt geactiveerd. Elk van deze is een reparatie van één tot twee engineeringdagen en een regressietestrun — maar elk is ook precies het patroon waarmee een auditor of beoordelaar begint.

De conclusie

ATT en cookietoestemming zijn geen overbodige overlays. ATT is een toestemmingspoort beperkt tot een specifieke iOS API, en cookietoestemming is een rechtmatige grondslag voor het verwerken van gegevens in elke browserklasseomgeving, inclusief een WKWebView. Een hybride app heeft beide nodig, samen bedraad zodat de gebruiker één coherente beslissing ziet in plaats van twee tegenstrijdige vragen, en zodat de native shell en de webweergave hetzelfde antwoord respecteren. De uitgevers die dit goed doen, brengen apps uit die beoordeling doorstaan, betrouwbaar geld opleveren en nooit verschijnen in de handhavingssamenvatting van een toezichthouder. De uitgevers die ATT behandelen als het volledige antwoord of die de webweergavetoestemming en de native shell laten uiteenlopen, brengen 2026 afwisselend door met App Store-beoordelingsvergaderingen en auditresponsebrieven. Bouw de brug één keer, behandel de CMP als de bron van waarheid, en laat ATT het iOS-specifieke slot zijn bovenop een privacyhouding die al coherent is op de weblaag.