AppsFlyer Mobil Attribusjon og Cookie-samtykke: En integrasjonsguide for 2026 for apputgivere
For apputviklere er mobilmåling et grunnleggende annerledes problem enn webmåling. Informasjonskapslene som nettutgivere bekymrer seg for, finnes ikke inne i en innebygd app, men identifikatorene som erstatter dem — IDFA, GAID, IDFV, installasjons-ID-er, hashede e-poster, IP-avledede enhetsavtrykk — reiser de samme juridiske spørsmålene og svarer til de samme regulatorene. AppsFlyer, den mest utbredte mobilmålingspartneren innen mobilspill, fintech og forbrukerapper, befinner seg midt i denne pipelinen. SDK-en samler inn attribusjonsgrads-identifikatorer, serverne korrelerer dem med annonsenettverk-postbacks, og den resulterende attribusjonen mater brukeranskaffelsesbudsjetter på tvers av alle store kanaler. Ingen av disse prosesseringene skjer uten lovlig grunnlag, og det lovlige grunnlaget GDPR og ePrivacy-direktivet faktisk krever er samtykke — innsamlet før SDK-en initialiseres, registrert som bevis og propagert til alle nedstrøms integrasjoner. Denne guiden går gjennom hva AppsFlyer samler inn, hvordan du integrerer det med et rammeverk for samtykkehåndtering på iOS, Android og mobilnettet, og hvordan plattformens egne personvernprimitiver (Start SDK API, ATT-signaler og Data Privacy Framework) passer inn i bildet.
Hva AppsFlyer samler inn
AppsFlyer SDK initialiserer en økt så snart vertsappen starter, og samler som standard inn en samling identifikatorer og kontekstsignaler: enhetsidentifikatoren for reklame (IDFA på iOS, GAID på Android), den leverandørscopede IDFV på iOS, en generert AppsFlyer installasjons-ID som vedvarer på tvers av økter, IP-adresse (brukt til geo-IP og fingeravtrykkbasert probabilistisk matching), brukeragent, enhetsmodell, OS-versjon, operatør og tidssone. Etter installasjon rapporterer SDK-en installasjonshendelsen til AppsFlyers servere, der den matches mot klikkdata videresendt av annonsenettverk. Påfølgende hendelser i appen — Purchase, RegistrationComplete, Tutorial Complete, Custom — utløses gjennom den samme SDK-en og arver det samme identifikatorsett.
Regulatorer har vært eksplisitte på at dette er behandling av personopplysninger under GDPR. IDFA og GAID er personopplysninger fordi de er vedvarende identifikatorer på enhetsnivå. Den probabilistiske fingeravtrykksmatchingen som kjører parallelt er enda vanskeligere å forsvare uten samtykke fordi den, per definisjon, er et forsøk på å identifisere en bruker uten deres eksplisitte samarbeid. CNIL, det italienske Garante og det spanske AEPD har alle åpnet undersøkelser mot utgivere hvis attribusjonsstakker utløste seg før samtykke.
Native AppsFlyer personvernkontroller
AppsFlyer eksponerer et meningsfylt sett med native personvernprimitiver. De er ikke et substitutt for et reelt samtykkeverk, men å forstå dem er essensielt fordi de er hendlene en CMP bruker for å kontrollere SDK-atferd.
Start SDK API
SDK-en støtter en initialiseringsmodus der den er konfigurert men ikke sender noen data før start() er eksplisitt kalt. Dette er den eneste viktigste hooken for samtykkegatering — som standard starter SDK-en automatisk ved appstart, noe som er feil atferd for enhver jurisdiksjon med krav om forhåndssamtykke. Sett isStopped til true ved initialisering, eller bruk utsatt-start API, og kall bare start() når samtykke-signalet er registrert.
Stop API
Hvis samtykke trekkes tilbake midt i en økt, vil kalling av stop() stoppe all videre overføring. Det sletter ikke retroaktivt data som allerede er sendt. For full sletting må du sende inn en forespørsel om sletting av registrert person gjennom AppsFlyers personvernportal — noe integrasjonsteam bør automatisere via AppsFlyer API i stedet for en manuell arbeidsflyt.
setSharingFilter
Dette filtrerer hvilke nedstrøms annonsenettverk som mottar postback-data. Det er riktig primitiv for granulert per-partner-samtykke — for eksempel å tillate attribusjon generelt, men blokkere videresendinger til et bestemt nettverk som brukeren har avvist.
Apple App Tracking Transparency integrasjon
På iOS leser AppsFlyer ATT-autorisasjonsstatusen og justerer atferden automatisk — hvis brukeren avslo ATT, overføres ikke IDFA. ATT er uavhengig fra GDPR-samtykke, og mange utgivere blander dem. ATT kontrollerer et enkelt iOS-nivåsignal; GDPR-samtykke kontrollerer alt annet.
Integrasjon på iOS
Det pålitelige mønsteret på iOS er å installere AppsFlyer SDK, men utsette initialisering til både ATT og samtykkeflyten i appen er fullført. Den minimale sekvensen er: appen starter, SDK-en er konfigurert med isStopped = true, samtykkebannen i appen vises, brukeren aksepterer de relevante kategoriene, SDK-ens isStopped-flagg fjernes og start() kalles. Hvis appen også trenger ATT (noe den gjør for enhver bruker der IDFA er meningsfull), vises ATT-prompten samtidig med eller etter bannen i appen. De fleste CMPs som støtter mobil har en tilbakekallingsbasert API som leverer samtykkevedtaket; den tilbakekallingen er det rette stedet å kalle start().
Integrasjon på Android
Android-implementeringen parallelliserer iOS med to forskjeller. For det første er det ingen ATT-ekvivalent — GAID er tilgjengelig med mindre brukeren har aktivert enhetsinnstillingen «Slett reklame-ID», noe de fleste brukere ikke gjør. For det andre er Androids livssyklus mer aggressiv med bakgrunnsprosessering, så SDK-initialiseringen må knyttes til samtykkestatus lagret vedvarende. Les samtykkestatus fra lokal lagring ved appstart, konfigurer SDK-en deretter, og sjekk på nytt ved gjenopptakelse i tilfelle brukeren oppdaterte sitt valg mens appen var i bakgrunnen.
Integrasjon på mobilnettet
AppsFlyer opererer også på mobilnettet gjennom sine smartbanner- og OneLink-produkter. Disse er i bunn og grunn nettside-analytics og dyplenke-verktøy som dropper informasjonskapsler og kaller AppsFlyer-servere fra nettleseren. De følger de samme reglene som enhver annen nettsporing: plasser dem bak CMPs markedsføringskategori, ikke la smartbanner-skriptet kjøre før samtykke er gitt, og sørg for at hendelser utløst av OneLink fra e-post- eller pushkampanjer respekterer brukerens samtykkestatus.
Vanlige fallgruver
Fire integrasjonsfeil dukker gjentatte ganger opp i revisjoner av AppsFlyer-implementeringer.
Å behandle ATT som GDPR-samtykke
ATT og GDPR-samtykke er forskjellige signaler med forskjellig omfang. En bruker som godtar ATT har autorisert IDFA-bruk for sporing på tvers av apper; de har ikke autorisert alt annet SDK-en gjør. For EU- og UK-trafikk kreves begge signaler, med bannen i appen som den bindende og ATT som et iOS-spesifikt lag på toppen.
La SDK-en initialiseres ved oppstart
Dette er den vanligste enkeltfeilen. Standardintegrasjonen kaller start() umiddelbart, noe som utløser installasjonshendelsen med full identifikator-nyttelast før brukeren har sett samtykkebannen. Utbedringen er enkel: konfigurer isStopped = true ved integrasjonstid og kall start() kun fra samtykkecallbacken.
Glemme å håndtere tilbaketrekking
Hvis en bruker aksepterer og senere trekker tilbake, må SDK-en gis beskjed om å slutte å overføre. Bruk stop() API og oppdater den vedvarende samtykkestatus slik at neste appstart respekterer den nye beslutningen.
Ignorere server-til-server postbacks
AppsFlyer videresender konverteringshendelser til en lang rekke integrerte annonsenettverk via server-side postbacks. Hvert videresend bærer personopplysninger og arver samtykkemfanget fra den opprinnelige hendelsen. Bruk setSharingFilter for å sikre at videresendinger kun går til partnere dekket av brukerens samtykkevalg, ikke til alle partnere i AppsFlyer-dashboardet ditt.
Revisjonssjekkliste
Seks konkrete spørsmål å besvare for enhver AppsFlyer-implementering som berører EU-, UK- eller California-trafikk.
- Venter SDK-en på samtykke? På en fersk installasjon på en EU-basert testenhet, bekreft at ingen AppsFlyer-endepunkt mottar noen forespørsel før brukeren har akseptert bannen.
- Er ATT atskilt fra samtykke i appen? Bekreft at bannen i appen er det kontrollerende samtykkesignalet og at ATT behandles som et ekstra iOS-spesifikt lag.
- Er partner-videresending begrenset til samtykke? Bekreft at setSharingFilter er konfigurert til å ekskludere partnere brukeren ikke har autorisert.
- Stopper tilbaketrekking SDK-en? Bekreft at kalling av stop() fungerer ved samtykkeopphevelse og at den nye tilstanden vedvarer på tvers av oppstarter.
- Er server-postbacks revidert? Bekreft at AppsFlyer-dashboardets «Konfigurerte integrasjoner»-liste tilsvarer rent markedsføringspartnerne som er oppgitt i bannen.
- Er datasletting automatisert? Bekreft at DSAR-forespørsler utløser AppsFlyers slettings-API, ikke en manuell billett.
Hvor AppsFlyer passer inn i en samtykke-først-stabel
Mobilattribusjon er en av de mest identifikatortunge overflatene i markedsføringsstabelen, og AppsFlyers SDK er en av de mest konsekvensrike enkeltintegrasjonene. Den gode nyheten er at plattformen eksponerer primitivene — Start SDK, Stop, delingsfiltere, slettings-API-er — som trengs for å gjøre samtykkehåndhevelse ren og verifiserbar. Arbeidet for utgivere er å koble disse primitivene til en CMP som eier det bindende samtykkevedtaket, behandle ATT som et komplementert signal snarere enn en erstatning, og sørge for at server-side partnervideresending ikke kan unnslippe samtykkeomslaget bannen registrerte. Gjort riktig, er resultatet en attribusjonsstabel som tilfredsstiller regulatorer mens den bevarer installasjons- og hendelsesdataene brukeranskaffelsesteam er avhengige av.