Co AppsFlyer sbírá

AppsFlyer SDK inicializuje relaci, jakmile se hostitelská aplikace spustí, a ve výchozím nastavení sbírá sadu identifikátorů a kontextových signálů: reklamní identifikátor na úrovni zařízení (IDFA na iOS, GAID na Androidu), IDFV s rozsahem dodavatele na iOS, vygenerované AppsFlyer instalační ID, které přetrvává napříč relacemi, IP adresu (používanou pro geo-IP a pro pravděpodobnostní srovnávání ve stylu otisku prstu), user agent, model zařízení, verzi OS, operátora a časové pásmo. Po instalaci SDK hlásí událost instalace na servery AppsFlyer, kde je spárována s daty o kliknutích přeposlanými reklamními sítěmi. Následné události v aplikaci — Purchase, RegistrationComplete, Tutorial Complete, Custom — se spouštějí přes stejné SDK a dědí stejnou sadu identifikátorů.

Regulátoři byli explicitní, že se jedná o zpracování osobních údajů podle GDPR. IDFA a GAID jsou osobní údaje, protože se jedná o perzistentní identifikátory na úrovni zařízení. Pravděpodobnostní srovnávání otisků prstů, které běží současně, je ještě těžší obhájit bez souhlasu, protože se jedná, z definice, o pokus identifikovat uživatele bez jeho explicitní spolupráce. CNIL, italský Garante a španělský AEPD všechny zahájily vyšetřování proti vydavatelům, jejichž atribuční stacky se spustily před získáním souhlasu.

Nativní ovládací prvky ochrany soukromí AppsFlyer

AppsFlyer vystavuje smysluplnou sadu nativních primitiv ochrany soukromí. Nejsou náhradou skutečného rámce pro souhlas, ale jejich pochopení je zásadní, protože se jedná o páky, které CMP používá k řízení chování SDK.

Start SDK API

SDK podporuje inicializační režim, kde je nakonfigurováno, ale nepřenáší žádná data, dokud není explicitně zavoláno start(). Toto je nejdůležitější hák pro podmínění souhlasem — ve výchozím nastavení se SDK spouští automaticky při spuštění aplikace, což je nesprávné chování pro jakoukoli jurisdikci s požadavkem na předchozí souhlas. Nastavte isStopped na true při inicializaci, nebo použijte API s odloženým spuštěním, a zavolejte start() pouze tehdy, když je signál souhlasu zaznamenán.

Stop API

Pokud je souhlas odvolán uprostřed relace, zavolání stop() zastaví veškeré další přenosy. Retroaktivně neodstraňuje již odeslaná data. Pro úplné smazání je třeba podat žádost o smazání údajů subjektu údajů prostřednictvím portálu ochrany soukromí AppsFlyer — integrační týmy by to měly automatizovat prostřednictvím AppsFlyer API spíše než manuálním workflow.

setSharingFilter

Toto filtruje, které navazující reklamní sítě obdrží data postbacku. Je to správné primitivum pro granulární souhlas pro jednotlivé partnery — například povolení atribuce obecně, ale blokování přeposílání konkrétní síti, kterou uživatel odmítl.

Integrace Apple App Tracking Transparency

Na iOS AppsFlyer čte stav autorizace ATT a automaticky upravuje své chování — pokud uživatel odmítl ATT, IDFA se nepřenáší. ATT je nezávislý na souhlasu podle GDPR a mnoho vydavatelů je zaměňuje. ATT řídí jediný signál na úrovni iOS; souhlas podle GDPR řídí vše ostatní.

Integrace na iOS

Spolehlivý vzor na iOS je nainstalovat AppsFlyer SDK, ale odložit inicializaci, dokud nebude dokončen jak ATT, tak tok souhlasu v aplikaci. Minimální sekvence je: aplikace se spustí, SDK je nakonfigurováno s isStopped = true, banner souhlasu v aplikaci se zobrazí, uživatel přijme příslušné kategorie, příznak isStopped SDK je vymazán a je zavoláno start(). Pokud aplikace také potřebuje ATT (což potřebuje pro jakéhokoli uživatele, kde je IDFA smysluplné), výzva ATT se zobrazí vedle nebo po banneru v aplikaci. Většina CMP, které podporují mobilní zařízení, má API založené na callbacku, které dodává rozhodnutí o souhlasu; tento callback je správné místo pro zavolání start().

Integrace na Androidu

Implementace na Androidu je paralelní s iOS se dvěma rozdíly. Za prvé, neexistuje ekvivalent ATT — GAID je k dispozici, pokud uživatel nevyvolal nastavení „Smazat reklamní ID" na úrovni zařízení, což většina uživatelů nedělá. Za druhé, životní cyklus Androidu je agresivnější při přechodu do pozadí, takže inicializace SDK musí být svázána se stavem souhlasu uloženým trvale. Načtěte stav souhlasu z lokálního úložiště při spuštění aplikace, nakonfigurujte SDK odpovídajícím způsobem a znovu zkontrolujte při obnovení pro případ, že uživatel aktualizoval svou volbu, když byla aplikace na pozadí.

Integrace na mobilním webu

AppsFlyer funguje také na mobilním webu prostřednictvím svých produktů smart banner a OneLink. Jedná se v podstatě o webové analytické nástroje a nástroje pro deep-linking, které ukládají cookies a volají servery AppsFlyer z prohlížeče. Řídí se stejnými pravidly jako jakýkoli jiný povrch sledování na webu: podmíňte je kategorií marketingu CMP, nenechte skript smart banneru běžet před udělením souhlasu a zajistěte, aby jakékoli události spuštěné OneLink z e-mailových nebo push kampaní respektovaly stav souhlasu uživatele.

Časté úskalí

Čtyři chyby při integraci se opakovaně objevují v auditech nasazení AppsFlyer.

Považování ATT za souhlas podle GDPR

ATT a souhlas podle GDPR jsou různé signály s různým rozsahem. Uživatel, který přijme ATT, autorizoval použití IDFA pro sledování napříč aplikacemi; neautorizoval vše ostatní, co SDK dělá. Pro provoz v EU a UK jsou vyžadovány oba signály, přičemž banner v aplikaci je závazný a ATT je specifická vrstva iOS navíc.

Povolení inicializace SDK při spuštění

Toto je nejčastější jednotlivá závada. Výchozí integrace volá start() okamžitě, což spouští událost instalace s plným datovým zatížením identifikátorů, než uživatel viděl banner souhlasu. Náprava je jednoduchá: nakonfigurujte isStopped = true v době integrace a volejte start() pouze z callbacku souhlasu.

Zapomínání řešit odvolání

Pokud uživatel přijme a později odvolá, SDK je třeba říct, aby přestalo přenášet. Použijte stop() API a aktualizujte trvalý stav souhlasu, aby další spuštění aplikace respektovalo nové rozhodnutí.

Ignorování server-to-server postbacků

AppsFlyer přeposílá konverzní události dlouhému chvostu integrovaných reklamních sítí prostřednictvím postbacků na straně serveru. Každé přeposlání nese osobní údaje a dědí rozsah souhlasu původní události. Použijte setSharingFilter, abyste zajistili, že přeposlání jdou pouze partnerům pokrytým volbami souhlasu uživatele, ne každému partnerovi na vašem dashboardu AppsFlyer.

Kontrolní seznam auditu

Šest konkrétních otázek, na které je třeba odpovědět pro jakékoli nasazení AppsFlyer dotýkající se provozu v EU, UK nebo Kalifornii.

• Čeká SDK na souhlas? Na čerstvé instalaci na testovacím zařízení umístěném v EU potvrďte, že žádný endpoint AppsFlyer neobdrží žádný požadavek, dokud uživatel nepřijme banner.
• Je ATT odděleno od souhlasu v aplikaci? Potvrďte, že banner v aplikaci je řídící signál souhlasu a ATT je považováno za další vrstvu specifickou pro iOS.
• Je přeposílání partnerům omezeno na souhlas? Potvrďte, že setSharingFilter je nakonfigurováno tak, aby vyloučilo partnery, které uživatel neautorizoval.
• Zastaví odvolání SDK? Potvrďte, že zavolání stop() funguje při odvolání souhlasu a že nový stav přetrvává napříč spuštěními.
• Jsou server postbacky auditovány? Potvrďte, že seznam „Nakonfigurované integrace" na dashboardu AppsFlyer čistě mapuje na marketingové partnery zveřejněné v banneru.
• Je smazání dat automatizováno? Potvrďte, že DSAR požadavky spouštějí API pro smazání AppsFlyer, ne manuální ticket.

Kde AppsFlyer zapadá do stacku zaměřeného na souhlas

Mobilní atribuce je jedním z nejvíce náročných povrchů na identifikátory v marketingovém stacku a SDK AppsFlyer je jednou z jeho nejvýznamnějších jednotlivých integrací. Dobrá zpráva je, že platforma vystavuje primitiva — Start SDK, Stop, filtry sdílení, API pro smazání — potřebná k tomu, aby bylo vynucování souhlasu čisté a ověřitelné. Práce pro vydavatele je připojit tato primitiva k CMP, které vlastní závazné rozhodnutí o souhlasu, považovat ATT za doplňkový signál spíše než náhradu a ujistit se, že přeposílání partnerů na straně serveru nemůže uniknout obálce souhlasu, kterou banner zaznamenal. Pokud je to provedeno správně, výsledkem je atribuční stack, který uspokojuje regulátory a zároveň zachovává instalační a událostní data, na kterých týmy pro získávání uživatelů závisí.