Vad AppsFlyer Samlar In

AppsFlyer SDK initierar en session så snart värdappen startar och samlar som standard in ett paket identifierare och kontextuella signaler: reklamidentifieraren på enhetsnivå (IDFA på iOS, GAID på Android), den leverantörsbegränsade IDFV på iOS, ett genererat AppsFlyer installations-ID som kvarstår mellan sessioner, IP-adress (används för geo-IP och för fingeravtrycksstil probabilistisk matchning), användaragent, enhetsmodell, OS-version, operatör och tidszon. Efter installation rapporterar SDK installations­händelsen till AppsFlyer:s servrar, där den matchas mot klick­data som vidarebefordrats av annonsnätverk. Efterföljande händelser i appen — Purchase, RegistrationComplete, Tutorial Complete, Custom — utlöses genom samma SDK och ärver samma identifierar­uppsättning.

Tillsynsmyndigheter har tydligt fastslått att detta är behandling av personuppgifter under GDPR. IDFA och GAID är personuppgifter eftersom de är beständiga identifierare på enhetsnivå. Den probabilistiska fingeravtrycksmatchningen som körs parallellt är ännu svårare att försvara utan samtycke eftersom det per definition är ett försök att identifiera en användare utan deras uttryckliga medverkan. CNIL, den italienska Garante och den spanska AEPD har alla inlett utredningar mot publicister vars attributionsstackar utlöstes innan samtycke gavs.

AppsFlyer:s Inbyggda Integritetskontroller

AppsFlyer exponerar en meningsfull uppsättning inbyggda integritets­primitiver. De är inte en ersättning för ett verkligt samtyckesramverk, men att förstå dem är avgörande eftersom de är de spakar en CMP använder för att kontrollera SDK-beteendet.

Start SDK API

SDK stöder ett initialiseringsläge där det är konfigurerat men inte överför några data förrän start() uttryckligen anropas. Detta är den enstaka viktigaste krokkoden för samtyckes­gating — som standard startar SDK automatiskt vid app-start, vilket är fel beteende för varje jurisdiktion med ett krav på förhandsgodkännande. Ställ isStopped till true vid initiering, eller använd API:et för uppskjuten start, och anropa bara start() när samtyckessignalen är registrerad.

Stop API

Om samtycke återkallas mitt i en session stoppar anrop till stop() all ytterligare överföring. Det tar inte retroaktivt bort data som redan skickats. För fullständig radering måste du lämna in en begäran om radering av registrerade via AppsFlyer:s integritetsporten — ett integrationsteam bör automatisera via AppsFlyer API snarare än ett manuellt arbetsflöde.

setSharingFilter

Detta filtrerar vilka nedströms annonsnätverk som tar emot postback-data. Det är rätt primitiv för granulerat samtycke per partner — till exempel att tillåta attribution generellt men blockera vidarebefordran till ett specifikt nätverk som användaren har avvisat.

Integrering med Apple App Tracking Transparency

På iOS läser AppsFlyer ATT-auktoriseringsstatusen och justerar sitt beteende automatiskt — om användaren avvisade ATT, överförs inte IDFA. ATT är oberoende av GDPR-samtycke, och många publicister blandar ihop dem. ATT kontrollerar en enskild signal på iOS-nivå; GDPR-samtycke kontrollerar allt annat.

Integration på iOS

Det pålitliga mönstret på iOS är att installera AppsFlyer SDK men skjuta upp initieringen tills både ATT och samtyckesflödet i appen har slutförts. Den minimala sekvensen är: appen startar, SDK:t konfigureras med isStopped = true, samtyckesbanret i appen visas, användaren accepterar de relevanta kategorierna, SDK:ts isStopped-flagga rensas och start() anropas. Om appen även behöver ATT (vilket den gör för alla användare där IDFA är meningsfullt), visas ATT-prompten vid sidan av eller efter banret i appen. De flesta CMP:er som stöder mobilt har ett callback-baserat API som levererar samtyckesbeslutet; det callback:et är rätt plats att anropa start().

Integration på Android

Android-implementeringen parallelliserar iOS med två skillnader. Först finns det ingen ATT-motsvarighet — GAID är tillgänglig om inte användaren har aktiverat sin enhets­nivå "Ta bort annons-ID"-inställning, vilket de flesta användare inte gör. Andra, Android:s livscykel är mer aggressiv med bakgrundskörning, så SDK-initieringen måste kopplas till samtyckestillståndet som lagras beständigt. Läs samtyckestillståndet från lokal lagring vid app-start, konfigurera SDK:t därefter och kontrollera igen vid återupptagning ifall användaren uppdaterade sitt val medan appen var i bakgrunden.

Integration på Mobil Webben

AppsFlyer opererar också på den mobila webben via sina produkter för smart banner och OneLink. Dessa är i princip webb­sidan­analytik och djuplänkverktyg som placerar kakor och anropar AppsFlyer-servrar från webbläsaren. De följer samma regler som alla andra webbspårningsytor: lägg dem bakom CMP:s marknadsföringskategori, låt inte skriptet för smart banner köras innan samtycke ges, och se till att OneLink-utlösta händelser från e-post- eller push-kampanjer respekterar användarens samtyckestillstånd.

Vanliga Fallgropar

Fyra integrationsmisstag dyker upp upprepade gånger i revisioner av AppsFlyer-driftsättningar.

Behandla ATT som GDPR-samtycke

ATT och GDPR-samtycke är olika signaler med olika räckvidd. En användare som accepterar ATT har godkänt IDFA-användning för spårning över appar; de har inte godkänt allt annat som SDK gör. För EU- och UK-trafik krävs båda signalerna, där banret i appen är det bindande och ATT är ett iOS-specifikt lager ovanpå.

Låta SDK Initieras vid Start

Detta är den vanligaste enskilda defekten. Standard­integrationen anropar start() omedelbart, vilket utlöser installations­händelsen med fullständig identifierares nyttolast innan användaren har sett samtyckesbanret. Åtgärden är okomplicerad: konfigurera isStopped = true vid integrations­tid och anropa start() enbart från samtyckescallback:et.

Glömma att Hantera Återkallelse

Om en användare accepterar och senare återkallar, måste SDK:t informeras om att sluta överföra. Använd stop() API och uppdatera det sparade samtyckestillståndet så att nästa app-start respekterar det nya beslutet.

Ignorera Server-till-Server-Postbacks

AppsFlyer vidarebefordrar konverteringshändelser till en lång svans av integrerade annonsnätverk via serverbaserade postbacks. Varje vidarebefordran bär personuppgifter och ärver samtyckesomfånget för den ursprungliga händelsen. Använd setSharingFilter för att säkerställa att vidarebefordran bara går till partners som täcks av användarens samtyckesval, inte till varje partner i din AppsFlyer-instrumentpanel.

Revisionschecklista

Sex konkreta frågor att besvara för varje AppsFlyer-driftsättning som berör EU, UK eller Californien-trafik.

• Väntar SDK:t på samtycke? Vid en ny installation på en testenheten belägen i EU, bekräfta att ingen AppsFlyer-slutpunkt tar emot någon begäran innan användaren har accepterat banret.
• Är ATT separerat från samtycke i appen? Bekräfta att banret i appen är den styrande samtyckessignalen och att ATT behandlas som ett extra iOS-specifikt lager.
• Är partner­vidarebefordran avgränsad till samtycke? Bekräfta att setSharingFilter är konfigurerat för att utesluta partners som användaren inte har godkänt.
• Stoppar återkallelse SDK:t? Bekräfta att anrop till stop() fungerar vid samtyckesåterkallelse och att det nya tillståndet kvarstår vid uppstart.
• Är server­postbacks granskade? Bekräfta att listan "Konfigurerade integrationer" i AppsFlyer-instrumentpanelen rent mappas till de marknadsföringspartners som anges i banret.
• Är dataradering automatiserad? Bekräfta att DSAR-begäranden utlöser AppsFlyer:s borttagnings-API, inte en manuell biljett.

Var AppsFlyer Passar i en Samtyckesfirst-Stack

Mobil attribution är en av de identifierar­tyngsta ytorna i marknadsförings­stacken, och AppsFlyer SDK är en av dess mest konsekventa enskilda integrationer. De goda nyheterna är att plattformen exponerar primitiverna — Start SDK, Stop, delnings­filter, borttagnings-API:er — som behövs för att göra samtyckesefterlevnad ren och verifierbar. Arbetet för publicister är att koppla dessa primitiver till en CMP som äger det bindande samtyckesbeslutet, behandla ATT som en kompletterande signal snarare än en ersättning, och se till att server­sidan partner­vidarebefordran inte kan undkomma samtyckeskuvertet som banret registrerade. Gjort korrekt är resultatet en attributionsstack som tillfredsställer tillsynsmyndigheter samtidigt som den bevarar installations- och händelsedata som användarförvärvsgrupper förlitar sig på.