Какво събира AppsFlyer

AppsFlyer SDK инициализира сесия веднага щом хост приложението стартира и, по подразбиране, събира пакет от идентификатори и контекстни сигнали: идентификатора за реклама на ниво устройство (IDFA в iOS, GAID в Android), IDFV с обхват на доставчика в iOS, генериран AppsFlyer инсталационен идентификатор, който се запазва през сесиите, IP адрес (използван за гео-IP и за вероятностно съвпадение от тип отпечатък), потребителски агент, модел на устройството, версия на ОС, оператор и часова зона. След инсталация SDK съобщава инсталационното събитие към сървърите на AppsFlyer, където се съпоставя с данните за кликване, препратени от рекламни мрежи. Последващите събития в приложението — Purchase, RegistrationComplete, Tutorial Complete, Custom — се изстрелват през същия SDK и наследяват същия набор от идентификатори.

Регулаторите са били изрични, че това е обработка на лични данни по GDPR. IDFA и GAID са лични данни, защото са постоянни идентификатори на ниво устройство. Вероятностното съвпадение чрез отпечатък, което работи паралелно, е още по-трудно за защита без съгласие, защото е, по дефиниция, опит да се идентифицира потребител без неговото изрично сътрудничество. CNIL, италианския Garante и испанския AEPD са отворили разследвания срещу издатели, чиито стекове за атрибуция са се задействали преди съгласието.

Нативни контроли за поверителност на AppsFlyer

AppsFlyer предоставя значителен набор от нативни примитиви за поверителност. Те не са заместител на реална рамка за съгласие, но разбирането им е съществено, защото са лостовете, които CMP използва за контрол на поведението на SDK.

Start SDK API

SDK поддържа режим на инициализация, при който е конфигуриран, но не предава никакви данни, докато start() не бъде изрично извикан. Това е единственият най-важен кук за контролиране на съгласието — по подразбиране SDK стартира автоматично при стартиране на приложението, което е грешно поведение за всяка юрисдикция с изискване за предварително съгласие. Задайте isStopped на true при инициализация или използвайте API за отложено стартиране и извикайте start() само когато сигналът за съгласие е записан.

Stop API

Ако съгласието се оттегли по средата на сесията, извикването на stop() спира всяко по-нататъшно предаване. То не изтрива ретроактивно вече изпратените данни. За пълно изтриване трябва да подадете заявка за изтриване на данни на субект на данни чрез портала за поверителност на AppsFlyer — интеграция, която екипите трябва да автоматизират чрез AppsFlyer API, а не чрез ръчен работен процес.

setSharingFilter

Това филтрира кои последващи рекламни мрежи получават постбек данни. Това е правилният примитив за детайлизирано съгласие за всеки партньор — например, позволяване на атрибуция общо, но блокиране на препращания към конкретна мрежа, която потребителят е отхвърлил.

Интеграция с Apple App Tracking Transparency

В iOS, AppsFlyer чете статуса на ATT оторизация и автоматично коригира поведението си — ако потребителят е отхвърлил ATT, IDFA не се предава. ATT е независим от GDPR съгласието и много издатели ги бъркат. ATT контролира един единствен сигнал на ниво iOS; GDPR съгласието контролира всичко останало.

Интеграция в iOS

Надеждният модел в iOS е да инсталирате AppsFlyer SDK, но да отложите инициализацията, докато както ATT, така и потокът за съгласие в приложението са завършени. Минималната последователност е: приложението стартира, SDK е конфигуриран с isStopped = true, банерът за съгласие в приложението се показва, потребителят приема съответните категории, флагът isStopped на SDK е изчистен и start() е извикан. Ако приложението също се нуждае от ATT (което е така за всеки потребител, за когото IDFA е смислен), ATT подканата се показва заедно с или след банера в приложението. Повечето CMP, които поддържат мобилни, имат базиран на обратно извикване API, който доставя решението за съгласие; това обратно извикване е правилното място за извикване на start().

Интеграция в Android

Внедряването в Android е паралелно на iOS с две разлики. Първо, няма еквивалент на ATT — GAID е достъпен, освен ако потребителят не е използвал настройката си на ниво устройство "Изтриване на идентификатор за реклама", което повечето потребители не правят. Второ, жизненият цикъл на Android е по-агресивен относно поставянето на заден план, така че инициализацията на SDK трябва да бъде обвързана със състоянието на съгласието, запазено постоянно. Прочетете състоянието на съгласието от локално хранилище при стартиране на приложението, конфигурирайте SDK съответно и проверете отново при възобновяване, в случай че потребителят е актуализирал избора си, докато приложението е било на заден план.

Интеграция в мобилния уеб

AppsFlyer също работи в мобилния уеб чрез своите продукти за интелигентен банер и OneLink. Те са по същество уеб-страничен анализ и инструменти за дълбоки връзки, които пускат бисквитки и извикват AppsFlyer сървъри от браузъра. Те следват същите правила като всяка друга повърхност за уеб проследяване: поставете ги зад маркетинговата категория на CMP, не позволявайте скриптът на интелигентния банер да работи преди да е дадено съгласие и се уверете, че всички събития, задействани от OneLink от имейл или push кампании, зачитат състоянието на съгласие на потребителя.

Често срещани капани

Четири грешки при интеграция се появяват многократно в одити на внедрявания на AppsFlyer.

Третиране на ATT като GDPR съгласие

ATT и GDPR съгласието са различни сигнали с различни обхвати. Потребител, който приема ATT, е разрешил използването на IDFA за проследяване между приложения; той не е разрешил всичко останало, което SDK прави. За EU и UK трафик са необходими и двата сигнала, като банерът в приложението е обвързващият и ATT е специфичен за iOS слой отгоре.

Позволяване на SDK да се инициализира при стартиране

Това е най-честият единичен дефект. Интеграцията по подразбиране извиква start() незабавно, което изстрелва инсталационното събитие с пълен товар от идентификатори, преди потребителят да е видял банера за съгласие. Коригирането е ясно: конфигурирайте isStopped = true по време на интеграция и извикайте start() само от обратното извикване за съгласие.

Забравяне да се обработи оттегляне

Ако потребител приеме и по-късно оттегли, на SDK трябва да се каже да спре предаването. Използвайте stop() API и актуализирайте запазеното състояние на съгласие, така че следващото стартиране на приложението да зачита новото решение.

Игнориране на сървър-към-сървър постбеци

AppsFlyer препраща конверсионни събития към дълга опашка от интегрирани рекламни мрежи чрез постбеци от страна на сървъра. Всяко препращане носи лични данни и наследява обхвата на съгласие на оригиналното събитие. Използвайте setSharingFilter, за да гарантирате, че препращанията отиват само към партньори, покрити от изборите за съгласие на потребителя, а не към всеки партньор в таблото ви за управление на AppsFlyer.

Одитен контролен списък

Шест конкретни въпроса, на които да отговорите за всяко внедряване на AppsFlyer, докосващо EU, UK или Калифорнийски трафик.

• Чака ли SDK за съгласие? При нова инсталация в тестово устройство, намиращо се в EU, потвърдете, че никоя крайна точка на AppsFlyer не получава никаква заявка, преди потребителят да е приел банера.
• Разделени ли са ATT от съгласието в приложението? Потвърдете, че банерът в приложението е контролиращият сигнал за съгласие и ATT се третира като допълнителен специфичен за iOS слой.
• Ограничено ли е препращането към партньори до съгласието? Потвърдете, че setSharingFilter е конфигуриран да изключва партньори, които потребителят не е упълномощил.
• Спира ли оттеглянето SDK? Потвърдете, че извикването на stop() работи при оттегляне на съгласие и че новото състояние се запазва при стартирания.
• Одитирани ли са сървърните постбеци? Потвърдете, че списъкът "Конфигурирани интеграции" в таблото за управление на AppsFlyer се съпоставя ясно с маркетинговите партньори, оповестени в банера.
• Автоматизирано ли е изтриването на данни? Потвърдете, че DSAR заявките задействат API за изтриване на AppsFlyer, а не ръчен билет.

Къде AppsFlyer се вписва в стек, ориентиран към съгласие

Мобилната атрибуция е една от най-тежките по идентификатори повърхности в маркетинговия стек, а SDK на AppsFlyer е една от най-важните му единични интеграции. Добрата новина е, че платформата предоставя примитивите — Start SDK, Stop, филтри за споделяне, API за изтриване — необходими за изчистване и проверка на прилагането на съгласие. Работата за издателите е да свържат тези примитиви с CMP, който притежава обвързващото решение за съгласие, да третират ATT като допълнителен сигнал, а не като заместител, и да се уверят, че препращането на партньори от страна на сървъра не може да избяга от обвивката на съгласие, която банерът е записал. Направено правилно, резултатът е стек за атрибуция, който удовлетворява регулаторите, като същевременно запазва данните за инсталация и събития, от които екипите за придобиване на потребители зависят.