Wat AppsFlyer verzamelt

De AppsFlyer SDK initialiseert een sessie zodra de host-app start en verzamelt standaard een bundel identificatoren en contextuele signalen: de apparaatbrede advertentie-identificator (IDFA op iOS, GAID op Android), de leveranciergebonden IDFV op iOS, een gegenereerde AppsFlyer-installatie-ID die over sessies heen blijft bestaan, IP-adres (gebruikt voor geo-IP en voor vingerafdrukachtige probabilistische matching), user agent, apparaatmodel, OS-versie, provider en tijdzone. Na installatie rapporteert de SDK de installatiegebeurtenis aan de servers van AppsFlyer, waar deze wordt gematcht met de klikgegevens die door advertentienetwerken zijn doorgestuurd. Daaropvolgende in-app-gebeurtenissen – Aankoop, RegistratieVoltooid, Tutorial Voltooid, Aangepast – worden via dezelfde SDK verstuurd en erven dezelfde set identificatoren.

Toezichthouders zijn expliciet geweest dat dit verwerking van persoonsgegevens is onder de GDPR. De IDFA en GAID zijn persoonsgegevens omdat het persistente identificatoren op apparaatniveau zijn. De probabilistische vingerafdrukmatching die ernaast draait is nog moeilijker te verdedigen zonder toestemming, omdat het per definitie een poging is om een gebruiker te identificeren zonder diens expliciete medewerking. De CNIL, de Italiaanse Garante en de Spaanse AEPD hebben allemaal onderzoeken geopend tegen uitgevers wiens attributiestacks activeerden vóór toestemming.

Native privacycontroles van AppsFlyer

AppsFlyer biedt een betekenisvolle set native privacyprimitieven. Ze zijn geen vervanging voor een echt toestemmingsframework, maar het is essentieel ze te begrijpen omdat het de hendels zijn die een CMP gebruikt om SDK-gedrag te sturen.

De Start SDK API

De SDK ondersteunt een initialisatiemodus waarbij deze geconfigureerd is maar geen gegevens verzendt totdat start() expliciet wordt aangeroepen. Dit is de belangrijkste hook voor toestemmingsafscherming – standaard start de SDK automatisch bij het opstarten van de app, wat het verkeerde gedrag is voor elke jurisdictie met een vereiste van voorafgaande toestemming. Stel isStopped in op true bij initialisatie, of gebruik de uitgestelde-start-API, en roep start() pas aan wanneer het toestemmingssignaal is vastgelegd.

Stop API

Als toestemming halverwege een sessie wordt ingetrokken, stopt het aanroepen van stop() alle verdere verzending. Het verwijdert niet met terugwerkende kracht gegevens die al zijn verzonden. Voor volledige verwijdering moet je een verwijderingsverzoek van de betrokkene indienen via het privacyportaal van AppsFlyer – een integratie die teams moeten automatiseren via de AppsFlyer API in plaats van een handmatig werkproces.

setSharingFilter

Dit filtert welke downstream advertentienetwerken postbackgegevens ontvangen. Het is het juiste primitief voor granulaire toestemming per partner – bijvoorbeeld attributie in het algemeen toestaan maar doorsturen naar een specifiek netwerk dat de gebruiker heeft afgewezen blokkeren.

Apple App Tracking Transparency-integratie

Op iOS leest AppsFlyer de ATT-autorisatiestatus en past zijn gedrag automatisch aan – als de gebruiker ATT heeft geweigerd, wordt IDFA niet verzonden. ATT staat los van GDPR-toestemming, en veel uitgevers verwarren ze met elkaar. ATT bestuurt één enkel iOS-signaal; GDPR-toestemming bestuurt al het andere.

Integratie op iOS

Het betrouwbare patroon op iOS is de AppsFlyer SDK te installeren maar initialisatie uit te stellen totdat zowel ATT als de in-app toestemmingsstroom zijn voltooid. De minimale volgorde is: de app start, de SDK wordt geconfigureerd met isStopped = true, de in-app toestemmingsbanner wordt weergegeven, de gebruiker accepteert de relevante categorieën, de isStopped-vlag van de SDK wordt gewist en start() wordt aangeroepen. Als de app ook ATT nodig heeft (wat het geval is voor elke gebruiker bij wie IDFA relevant is), wordt de ATT-prompt naast of na de in-app banner getoond. De meeste CMP's die mobiel ondersteunen hebben een callback-gebaseerde API die de toestemmingsbeslissing levert; die callback is de juiste plek om start() aan te roepen.

Integratie op Android

De Android-implementatie loopt parallel met iOS met twee verschillen. Ten eerste is er geen ATT-equivalent – GAID is beschikbaar tenzij de gebruiker de apparaatinstelling "Advertentie-ID verwijderen" heeft gebruikt, wat de meeste gebruikers niet doen. Ten tweede is de Android-levenscyclus agressiever met achtergrondplaatsing, dus de SDK-initialisatie moet worden gekoppeld aan de persistent opgeslagen toestemmingsstatus. Lees de toestemmingsstatus uit de lokale opslag bij het opstarten van de app, configureer de SDK dienovereenkomstig en controleer opnieuw bij hervatting voor het geval de gebruiker hun keuze heeft bijgewerkt terwijl de app op de achtergrond stond.

Integratie op het mobiele web

AppsFlyer opereert ook op het mobiele web via zijn slimme banner- en OneLink-producten. Dit zijn in wezen webanalyse- en deep-link-tools die cookies plaatsen en AppsFlyer-servers aanroepen vanuit de browser. Ze volgen dezelfde regels als elk ander webtrackingoppervlak: scherm ze af achter de marketingcategorie van de CMP, laat het slimme-bannerscript niet draaien vóór toestemming is verleend en zorg ervoor dat alle OneLink-geactiveerde gebeurtenissen vanuit e-mail- of pushcampagnes de toestemmingsstatus van de gebruiker respecteren.

Veelvoorkomende valkuilen

Vier integratiefouten komen herhaaldelijk naar voren bij audits van AppsFlyer-implementaties.

ATT behandelen als GDPR-toestemming

ATT en GDPR-toestemming zijn verschillende signalen met verschillende reikwijdtes. Een gebruiker die ATT accepteert heeft IDFA-gebruik voor cross-app tracking geautoriseerd; deze heeft niet alles geautoriseerd wat de SDK verder doet. Voor EU- en UK-verkeer zijn beide signalen vereist, waarbij de in-app banner het bindende signaal is en ATT een iOS-specifieke laag erbovenop.

De SDK laten initialiseren bij het opstarten

Dit is het meest voorkomende enkele defect. De standaardintegratie roept start() onmiddellijk aan, waardoor de installatiegebeurtenis met volledige identificatorpayload wordt verstuurd voordat de gebruiker de toestemmingsbanner heeft gezien. De remedie is eenvoudig: configureer isStopped = true bij integratietijd en roep start() alleen aan vanuit de toestemmingscallback.

Vergeten intrekking af te handelen

Als een gebruiker accepteert en later intrekt, moet de SDK worden verteld te stoppen met verzenden. Gebruik de stop() API en werk de persistent opgeslagen toestemmingsstatus bij zodat de volgende app-start de nieuwe beslissing respecteert.

Server-naar-server postbacks negeren

AppsFlyer stuurt conversiegebeurtenissen door naar een lange staart van geïntegreerde advertentienetwerken via server-side postbacks. Elke doorsturen bevat persoonsgegevens en erft de toestemmingsreikwijdte van de oorspronkelijke gebeurtenis. Gebruik setSharingFilter om ervoor te zorgen dat doorsturen alleen gaat naar partners die gedekt worden door de toestemmingskeuzes van de gebruiker, niet naar elke partner in je AppsFlyer-dashboard.

Auditchecklist

Zes concrete vragen om te beantwoorden voor elke AppsFlyer-implementatie die EU-, UK- of Californisch verkeer raakt.

• Wacht de SDK op toestemming? Bevestig op een schone installatie op een testapparaat in de EU dat geen enkel AppsFlyer-eindpunt een verzoek ontvangt voordat de gebruiker de banner heeft geaccepteerd.
• Is ATT gescheiden van in-app toestemming? Bevestig dat de in-app banner het bepalende toestemmingssignaal is en ATT wordt behandeld als een aanvullende iOS-specifieke laag.
• Is partnerdoorsturen afgestemd op toestemming? Bevestig dat setSharingFilter is geconfigureerd om partners uit te sluiten die de gebruiker niet heeft geautoriseerd.
• Stopt intrekking de SDK? Bevestig dat het aanroepen van stop() werkt bij intrekking van toestemming en dat de nieuwe status over herstarts heen blijft bestaan.
• Worden serverpostbacks gecontroleerd? Bevestig dat de lijst "Geconfigureerde integraties" in het AppsFlyer-dashboard correct overeenkomt met de marketingpartners die in de banner worden vermeld.
• Is gegevensverwijdering geautomatiseerd? Bevestig dat DSAR-verzoeken de verwijderings-API van AppsFlyer activeren, niet een handmatig ticket.

Waar AppsFlyer past in een toestemming-eerst-stack

Mobiele attributie is een van de meest identificatorzware oppervlakken in de marketingstack, en de SDK van AppsFlyer is een van de meest consequentiële enkele integraties. Het goede nieuws is dat het platform de primitieven biedt – Start SDK, Stop, deelfilters, verwijderings-API's – die nodig zijn om toestemmingshandhaving schoon en verifieerbaar te maken. Het werk voor uitgevers is om die primitieven te koppelen aan een CMP die de bindende toestemmingsbeslissing bezit, ATT te behandelen als een aanvullend signaal in plaats van een vervanging, en ervoor te zorgen dat server-side partnerdoorsturen niet kan ontsnappen aan de toestemmingsenvelop die de banner heeft vastgelegd. Correct uitgevoerd is het resultaat een attributiestack die toezichthouders tevreden stelt terwijl de installatie- en gebeurtenisgegevens behouden blijven waarvan gebruikerswervingsteams afhankelijk zijn.