Mit gyűjt az AppsFlyer

Az AppsFlyer SDK egy munkamenetet inicializál, amint a gazdaalkalmazás elindul, és alapértelmezés szerint azonosítók és kontextuális jelek egy csomagját gyűjti: az eszközszintű hirdetési azonosítót (IDFA iOS-en, GAID Androidon), a gyártóhoz kötött IDFV-t iOS-en, egy generált AppsFlyer telepítési azonosítót, amely munkamenetek között is megmarad, IP-címet (geo-IP-hez és ujjlenyomat-stílusú valószínűségi egyeztetéshez használva), user agentet, eszközmodellt, operációs rendszer verziót, szolgáltatót és időzónát. A telepítés után az SDK jelenti a telepítési eseményt az AppsFlyer szervereinek, ahol az egyeztetésre kerül a hirdetési hálózatok által továbbított kattintási adatokkal. A későbbi alkalmazáson belüli események — Vásárlás, RegisztrációKész, Bemutató Kész, Egyéni — ugyanezen az SDK-n keresztül indulnak, és ugyanazt az azonosítókészletet öröklik.

A szabályozók egyértelműen kimondták, hogy ez személyes adatok feldolgozása a GDPR értelmében. Az IDFA és a GAID személyes adatok, mert tartós eszközszintű azonosítók. A mellettük futó valószínűségi ujjlenyomat-egyeztetést még nehezebb megvédeni hozzájárulás nélkül, mert az definíció szerint egy felhasználó azonosítására tett kísérlet az explicit együttműködésük nélkül. A CNIL, az olasz Garante és a spanyol AEPD mind vizsgálatokat indítottak olyan kiadók ellen, akiknek az attribúciós rendszerei a hozzájárulás előtt aktiválódtak.

Az AppsFlyer natív adatvédelmi vezérlői

Az AppsFlyer értelmes natív adatvédelmi primitíveket kínál. Ezek nem helyettesítik a valódi hozzájárulási keretrendszert, de megértésük elengedhetetlen, mert ezek azok a vezérlők, amelyeket egy CMP használ az SDK viselkedésének szabályozására.

A Start SDK API

Az SDK támogat egy inicializálási módot, amelyben konfigurálva van, de nem továbbít semmilyen adatot, amíg a start() kifejezetten meg nem hívásra kerül. Ez az egyetlen legfontosabb hook a hozzájárulás-kapuzáshoz — alapértelmezés szerint az SDK automatikusan elindul az alkalmazás indításakor, ami helytelen viselkedés bármely joghatóságban, ahol előzetes hozzájárulás szükséges. Állítsa az isStopped értékét true-ra az inicializáláskor, vagy használja a késleltetett indítás API-t, és csak akkor hívja meg a start()-ot, amikor a hozzájárulási jel rögzítésre került.

Stop API

Ha a hozzájárulást a munkamenet közben visszavonják, a stop() meghívása leállítja az összes további adattovábbítást. Ez nem törli visszamenőlegesen a már elküldött adatokat. A teljes törléshez adatalany-törlési kérelmet kell benyújtani az AppsFlyer adatvédelmi portálján keresztül — ezt az integrációs csapatoknak az AppsFlyer API-n keresztül kell automatizálniuk, nem kézi munkafolyamattal.

setSharingFilter

Ez szűri, mely downstream hirdetési hálózatok kapnak visszajelzési adatokat. Ez a megfelelő primitív a részletes, partnerenkénti hozzájáruláshoz — például az attribúció általános engedélyezéséhez, miközben blokkolja a továbbítást egy adott hálózat felé, amelyet a felhasználó elutasított.

Apple App Tracking Transparency integráció

iOS-en az AppsFlyer kiolvassa az ATT engedélyezési állapotot és automatikusan módosítja viselkedését — ha a felhasználó elutasította az ATT-t, az IDFA nem kerül továbbításra. Az ATT független a GDPR hozzájárulástól, és sok kiadó összekeveri őket. Az ATT egyetlen iOS-szintű jelet vezérel; a GDPR hozzájárulás minden mást szabályoz.

Integráció iOS-en

A megbízható minta iOS-en az, hogy telepítjük az AppsFlyer SDK-t, de késleltetjük az inicializálást, amíg mind az ATT, mind az alkalmazáson belüli hozzájárulási folyamat be nem fejeződött. A minimális sorrend: az alkalmazás elindul, az SDK konfigurálásra kerül isStopped = true értékkel, az alkalmazáson belüli hozzájárulási banner megjelenik, a felhasználó elfogadja a releváns kategóriákat, az SDK isStopped jelzője törlődik és meghívásra kerül a start(). Ha az alkalmazásnak ATT-re is szüksége van (ami minden olyan felhasználó esetében szükséges, ahol az IDFA releváns), az ATT felszólítás az alkalmazáson belüli banner mellett vagy után jelenik meg. A legtöbb mobilt támogató CMP callback-alapú API-val rendelkezik, amely továbbítja a hozzájárulási döntést; ez a callback a megfelelő hely a start() meghívására.

Integráció Androidon

Az Android implementáció párhuzamos az iOS-sel, két különbséggel. Először, nincs ATT megfelelő — a GAID elérhető, hacsak a felhasználó nem aktiválta az eszközszintű „Hirdetési azonosító törlése" beállítást, amit a legtöbb felhasználó nem tesz meg. Másodszor, az Android életciklusa agresszívebben kezeli a háttérbe helyezést, ezért az SDK inicializálását a tartósan tárolt hozzájárulási állapothoz kell kötni. Olvassa ki a hozzájárulási állapotot a helyi tárolóból az alkalmazás indításakor, konfigurálja az SDK-t ennek megfelelően, és ellenőrizze újra folytatáskor arra az esetre, ha a felhasználó frissítette választását, amíg az alkalmazás háttérben volt.

Integráció a mobil weben

Az AppsFlyer a mobil weben is működik az okos banner és a OneLink termékein keresztül. Ezek lényegében webes analitikai és mélylinkező eszközök, amelyek sütiket helyeznek el és az AppsFlyer szervereit hívják a böngészőből. Ugyanazok a szabályok vonatkoznak rájuk, mint bármely más webes nyomkövetési felületre: kapuzza őket a CMP marketing kategóriája mögé, ne engedje az okos banner szkriptet futni a hozzájárulás megadása előtt, és biztosítsa, hogy a OneLink által kiváltott események e-mail vagy push kampányokból tiszteletben tartsák a felhasználó hozzájárulási állapotát.

Gyakori buktatók

Négy integrációs hiba jelenik meg ismétlődően az AppsFlyer telepítések auditjainál.

Az ATT kezelése GDPR hozzájárulásként

Az ATT és a GDPR hozzájárulás különböző jelek, különböző hatókörrel. Egy felhasználó, aki elfogadja az ATT-t, engedélyezte az IDFA használatát alkalmazások közötti nyomkövetésre; nem engedélyezte mindent, amit az SDK egyébként csinál. Az EU és UK forgalom esetében mindkét jel szükséges, ahol az alkalmazáson belüli banner a kötelező érvényű, és az ATT egy iOS-specifikus réteg felette.

Az SDK inicializálásának engedélyezése indításkor

Ez a leggyakoribb egyedi hiba. Az alapértelmezett integráció azonnal meghívja a start()-ot, ami a telepítési eseményt teljes azonosító-csomaggal indítja el, mielőtt a felhasználó látta volna a hozzájárulási bannert. A javítás egyszerű: konfigurálja az isStopped = true értéket az integráció idején, és csak a hozzájárulási callback-ből hívja meg a start()-ot.

A visszavonás kezelésének elfelejtése

Ha egy felhasználó elfogad, majd később visszavon, az SDK-nak jelezni kell, hogy állítsa le az adattovábbítást. Használja a stop() API-t és frissítse a tartósan tárolt hozzájárulási állapotot, hogy a következő alkalmazásindítás tiszteletben tartsa az új döntést.

A szerver-szerver visszajelzések figyelmen kívül hagyása

Az AppsFlyer konverziós eseményeket továbbít az integrált hirdetési hálózatok hosszú sorának szerveroldali visszajelzéseken keresztül. Minden továbbítás személyes adatokat hordoz, és örökli az eredeti esemény hozzájárulási hatókörét. Használja a setSharingFilter-t annak biztosítására, hogy a továbbítások csak a felhasználó hozzájárulási választásai által lefedett partnerekhez jussanak el, ne az AppsFlyer irányítópultján szereplő összes partnerhez.

Audit ellenőrzőlista

Hat konkrét kérdés, amelyet meg kell válaszolni bármely EU, UK vagy kaliforniai forgalmat érintő AppsFlyer telepítés esetében.

• Vár-e az SDK a hozzájárulásra? Friss telepítéskor egy EU-ban található teszteszközön erősítse meg, hogy egyetlen AppsFlyer végpont sem kap kérést, mielőtt a felhasználó elfogadta a bannert.
• El van-e választva az ATT az alkalmazáson belüli hozzájárulástól? Erősítse meg, hogy az alkalmazáson belüli banner az irányadó hozzájárulási jel, és az ATT egy további iOS-specifikus rétegként van kezelve.
• A partnertovábbítás a hozzájárulás hatóköréhez van-e igazítva? Erősítse meg, hogy a setSharingFilter úgy van konfigurálva, hogy kizárja azokat a partnereket, akiket a felhasználó nem engedélyezett.
• Leállítja-e a visszavonás az SDK-t? Erősítse meg, hogy a stop() meghívása működik a hozzájárulás visszavonásakor, és az új állapot megmarad az újraindítások között.
• Auditáltak-e a szerver visszajelzések? Erősítse meg, hogy az AppsFlyer irányítópult „Konfigurált integrációk" listája tisztán leképezi a bannerben feltüntetett marketing partnereket.
• Automatizált-e az adattörlés? Erősítse meg, hogy a DSAR kérelmek az AppsFlyer törlési API-ját aktiválják, nem kézi jegykezelést.

Az AppsFlyer helye a hozzájárulás-központú rendszerben

A mobil attribúció az egyik leginkább azonosító-intenzív felület a marketing rendszerben, és az AppsFlyer SDK-ja az egyik legjelentősebb egyedi integráció. A jó hír az, hogy a platform biztosítja a primitíveket — Start SDK, Stop, megosztási szűrők, törlési API-k —, amelyek szükségesek ahhoz, hogy a hozzájárulás érvényesítése tiszta és ellenőrizhető legyen. A kiadók feladata az, hogy ezeket a primitíveket egy olyan CMP-hez kössék, amely a kötelező érvényű hozzájárulási döntés tulajdonosa, az ATT-t kiegészítő jelként kezeljék helyettesítő helyett, és biztosítsák, hogy a szerveroldali partnertovábbítás ne léphessen ki a banner által rögzített hozzájárulási keretből. Helyesen végrehajtva az eredmény egy attribúciós rendszer, amely kielégíti a szabályozókat, miközben megőrzi a telepítési és eseményadatokat, amelyekre a felhasználószerzési csapatok támaszkodnak.