Hvad AppsFlyer indsamler

AppsFlyer SDK initialiserer en session, så snart værts-appen starter, og indsamler som standard et bundt af identifikatorer og kontekstuelle signaler: enhedens annonceidentifikator (IDFA på iOS, GAID på Android), den vendor-scopede IDFV på iOS, et genereret AppsFlyer installations-ID der persisterer på tværs af sessioner, IP-adresse (brugt til geo-IP og til fingerprint-baseret probabilistisk matching), user agent, enhedsmodel, OS-version, operatør og tidszone. Efter installation rapporterer SDK'et installationseventen til AppsFlyerServerne, hvor den matches mod klikdata videresendt af annoncenetværk. Efterfølgende in-app-events — Purchase, RegistrationComplete, Tutorial Complete, Custom — fyres gennem samme SDK og arver samme identifikator-sæt.

Tilsynsmyndigheder har været eksplicitte om, at dette er behandling af persondata under GDPR. IDFA og GAID er persondata, fordi de er persistente identifikatorer på enhedsniveau. Den probabilistiske fingerprint-matching, der kører sideløbende, er endnu sværere at forsvare uden samtykke, fordi det pr. definition er et forsøg på at identificere en bruger uden deres eksplicitte samarbejde. CNIL, den italienske Garante og den spanske AEPD har alle åbnet undersøgelser mod udgivere, hvis attribution-stacks fyrede før samtykke.

Native AppsFlyer Privacy-kontroller

AppsFlyer eksponerer et meningsfuldt sæt af native privacy-funktioner. De er ikke en erstatning for et reelt consent-framework, men at forstå dem er essentielt, fordi de er de greb en CMP bruger til at kontrollere SDK-adfærd.

Start SDK API

SDK'et understøtter en initialiseringstilstand, hvor det er konfigureret, men ikke transmitterer nogen data, før start() eksplicit kaldes. Dette er det vigtigste hook til consent-gating — som standard starter SDK'et automatisk ved app-start, hvilket er den forkerte adfærd for enhver jurisdiktion med et krav om forudgående samtykke. Sæt isStopped til true ved initialisering, eller brug deferred-start API'et, og kald kun start(), når samtykke-signalet er registreret.

Stop API

Hvis samtykke trækkes tilbage midt i sessionen, stopper kald af stop() al yderligere transmission. Det sletter ikke retroaktivt data, der allerede er sendt. For fuld sletning skal du indgive en registrerets sletningsanmodning gennem AppsFlyers privacy-portal — en integration teams bør automatisere via AppsFlyer API i stedet for en manuel workflow.

setSharingFilter

Dette filtrerer, hvilke downstream annoncenetværk der modtager postback-data. Det er den rigtige funktion til granulært samtykke pr. partner — for eksempel at tillade attribution generelt, men blokere videresendelser til et specifikt netværk, som brugeren har afvist.

Apple App Tracking Transparency integration

På iOS læser AppsFlyer ATT-autorisationsstatus og justerer sin adfærd automatisk — hvis brugeren afviste ATT, transmitteres IDFA ikke. ATT er uafhængigt af GDPR-samtykke, og mange udgivere sammenblander dem. ATT kontrollerer et enkelt iOS-niveau-signal; GDPR-samtykke kontrollerer alt andet.

Integration på iOS

Det pålidelige mønster på iOS er at installere AppsFlyer SDK, men udsætte initialisering, indtil både ATT og in-app consent-flowet er afsluttet. Den minimale sekvens er: app starter, SDK'et konfigureres med isStopped = true, in-app consent-banneret vises, brugeren accepterer de relevante kategorier, SDK'ets isStopped-flag cleares og start() kaldes. Hvis appen også har brug for ATT (hvilket den har for enhver bruger, hvor IDFA er meningsfuld), vises ATT-prompten sammen med eller efter in-app-banneret. De fleste CMP'er, der understøtter mobil, har en callback-baseret API, der leverer samtykke-beslutningen; den callback er det rigtige sted at kalde start().

Integration på Android

Android-implementeringen parallelt iOS med to forskelle. For det første er der ingen ATT-ækvivalent — GAID er tilgængelig, medmindre brugeren har aktiveret deres "Slet annoncerings-ID"-indstilling på enhedsniveau, hvilket de fleste brugere ikke gør. For det andet er Androids lifecycle mere aggressiv omkring baggrundskørsel, så SDK-initialiseringen skal være bundet til samtykke-tilstanden gemt persistent. Læs samtykke-tilstanden fra lokal storage ved app-start, konfigurer SDK'et i overensstemmelse hermed, og genkontroller ved genoptagelse i tilfælde af, at brugeren opdaterede deres valg, mens appen var i baggrunden.

Integration på Mobile Web

AppsFlyer opererer også på den mobile web gennem dets smart banner og OneLink-produkter. Disse er essentielt web-side analytics og deep-link-værktøjer, der dropper cookies og kalder AppsFlyer-servere fra browseren. De følger de samme regler som enhver anden tracking-overflade: gate dem bag CMP'ens marketing-kategori, lad ikke smart banner-scriptet køre før samtykke er givet, og sikr at alle OneLink-triggede events fra e-mail- eller push-kampagner overholder brugerens samtykke-tilstand.

Almindelige faldgruber

Fire integrationsfejl dukker gentagne gange op i audits af AppsFlyer-deployments.

At behandle ATT som GDPR-samtykke

ATT og GDPR-samtykke er forskellige signaler med forskellige anvendelsesområder. En bruger, der accepterer ATT, har autoriseret IDFA-brug til cross-app-tracking; de har ikke autoriseret alt andet, SDK'et gør. For EU- og UK-trafik er begge signaler påkrævet, hvor in-app-banneret er det bindende signal, og ATT er et iOS-specifikt lag ovenpå.

At lade SDK'et initialisere ved start

Dette er den mest almindelige enkelte fejl. Standard-integrationen kalder start() øjeblikkeligt, hvilket fyrer installationseventen med fuld identifikator-payload, før brugeren har set consent-banneret. Afhjælpningen er ligetil: konfigurer isStopped = true ved integrationstidspunktet og kald start() kun fra consent-callbacken.

At glemme at håndtere tilbagetrækning

Hvis en bruger accepterer og senere tilbagekalder, skal SDK'et fortælles at stoppe med at transmittere. Brug stop() API'et og opdater den persisterede samtykke-tilstand, så den næste app-start respekterer den nye beslutning.

At ignorere server-til-server postbacks

AppsFlyer videresender konverteringsevents til en lang hale af integrerede annoncenetværk via server-side postbacks. Hver videresendelse bærer persondata og arver samtykke-scopet fra det oprindelige event. Brug setSharingFilter til at sikre, at videresendelser kun går til partnere dækket af brugerens samtykke-valg, ikke til alle partnere i dit AppsFlyer-dashboard.

Audit-tjekliste

Seks konkrete spørgsmål at besvare for enhver AppsFlyer-deployment, der berører EU-, UK- eller Californien-trafik.

• Venter SDK'et på samtykke? På en ny installation på en EU-lokaliseret testenhed, bekræft at intet AppsFlyer-endpoint modtager nogen anmodning, før brugeren har accepteret banneret.
• Er ATT adskilt fra in-app-samtykke? Bekræft at in-app-banneret er det kontrollerende samtykke-signal, og ATT behandles som et yderligere iOS-specifikt lag.
• Er partner-forwarding scopet til samtykke? Bekræft at setSharingFilter er konfigureret til at ekskludere partnere, som brugeren ikke har autoriseret.
• Stopper tilbagetrækning SDK'et? Bekræft at kald af stop() virker ved samtykke-tilbagekaldelse, og at den nye tilstand persisterer på tværs af app-starts.
• Er server-postbacks auditeret? Bekræft at AppsFlyer-dashboardets liste over konfigurerede integrationer mapper rent til de marketing-partnere, der er oplyst i banneret.
• Er datasletning automatiseret? Bekræft at DSAR-anmodninger triggerer AppsFlyersletnings-API, ikke en manuel ticket.

Hvor AppsFlyer passer ind i en Consent-First Stack

Mobil attribution er en af de mest identifikator-tunge overflader i marketing-stacken, og AppsFlyersSDK er en af dens mest konsekvente enkelte integrationer. Den gode nyhed er, at platformen eksponerer de funktioner — Start SDK, Stop, sharing-filtre, sletnings-API'er — der er nødvendige for at gøre consent-håndhævelse rent og verificerbart. Arbejdet for udgivere er at forbinde disse funktioner til en CMP, der ejer den bindende samtykke-beslutning, behandle ATT som et komplementært signal frem for en erstatning, og sikre at server-side partner-forwarding ikke kan slippe uden om den samtykke-kuvert, banneret registrerede. Gjort korrekt er resultatet en attribution-stack, der tilfredsstiller tilsynsmyndigheder, samtidig med at den bevarer de installations- og event-data, som user acquisition-teams er afhængige af.