AppsFlyer Мобилна Атрибуција и Сагласност за Колачиће: Водич за Интеграцију за 2026. за Издаваче Апликација
За програмере апликација, мобилно мерење је суштински другачији проблем од веб мерења. Колачићи о којима бринуверских издавачи не постоје унутар изворне апликације, али идентификатори који их замењују — IDFA, GAID, IDFV, ID-ови инсталације, хеширани имејлови, отисци уређаја изведени из IP адресе — постављају иста правна питања и одговарају истим регулаторима. AppsFlyer, најширокодеплојирани партнер за мобилно мерење у мобилним играма, финтеку и потрошачким апликацијама, стоји у средини овог процеса. Његов SDK прикупља идентификаторе квалитета атрибуције, његови сервери их повезују са постбек-овима рекламних мрежа, а резултујућа атрибуција храни буџете за прибављање корисника преко сваког главног канала. Ниједна од тих обрада не дешава се без законске основе, а законска основа коју GDPR и Директива ePrivacy заправо захтевају је сагласност — прикупљена пре иницијализације SDK-а, забележена као доказ и пропагирана до сваке интеграције на ниже. Овај водич пролази кроз шта AppsFlyer прикупља, како га интегрисати са оквиром за управљање сагласношћу на iOS, Android и мобилном вебу, и како сопствени приватни примитиви платформе (Start SDK API, ATT сигнали и Оквир за приватност података) уклапају у слику.
Шта AppsFlyer Прикупља
AppsFlyer SDK иницијализује сесију чим апликација домаћин почне и, подразумевано, прикупља скуп идентификатора и контекстуалних сигнала: идентификатор оглашавања на нивоу уређаја (IDFA на iOS, GAID на Android), IDFV са обимом продавца на iOS, генерисани AppsFlyer ID инсталације који траје кроз сесије, IP адресу (коришћену за geo-IP и за вероватносно подударање у стилу отиска прста), корисничког агента, модел уређаја, верзију OS, оператера и временску зону. Након инсталације 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 захтеви активирају AppsFlyer API за брисање, а не ручну карту.
Где AppsFlyer Стаје у Слогу Прво-Сагласност
Мобилна атрибуција је једна од површина са највише идентификатора у маркетиншком стогу, а AppsFlyer SDK је једна од његових најутицајнијих јединствених интеграција. Добра вест је да платформа открива примитиве — Start SDK, Stop, филтери дељења, API-ови за брисање — потребне да се спровођење сагласности учини чистим и верификабилним. Посао за издаваче је да повежу те примитиве са CMP-ом који поседује обавезујућу одлуку о сагласности, третирају ATT као комплементарни сигнал а не замену, и осигурају да прослеђивање партнерима на страни сервера не може побећи из omotače сагласности коју је банер забележио. Урађено исправно, резултат је слог атрибуције који задовољава регулаторе уз очување података о инсталацији и догађајима на које се ослањају тимови за прибављање корисника.