Apa yang Dikumpulkan AppsFlyer

SDK AppsFlyer menginisialisasi sesi segera setelah aplikasi host dimulai dan, secara default, mengumpulkan sekumpulan pengidentifikasi dan sinyal kontekstual: pengidentifikasi iklan tingkat perangkat (IDFA di iOS, GAID di Android), IDFV yang dicakupkan ke vendor di iOS, ID instalasi AppsFlyer yang dihasilkan dan bertahan di seluruh sesi, alamat IP (digunakan untuk geo-IP dan untuk pencocokan probabilistik gaya sidik jari), user agent, model perangkat, versi OS, operator, dan zona waktu. Setelah instalasi, SDK melaporkan peristiwa instalasi ke server AppsFlyer, di mana ia dicocokkan dengan data klik yang diteruskan oleh jaringan iklan. Peristiwa dalam aplikasi berikutnya — Purchase, RegistrationComplete, Tutorial Complete, Custom — dikirim melalui SDK yang sama dan mewarisi set pengidentifikasi yang sama.

Regulator telah secara eksplisit menyatakan bahwa ini adalah pemrosesan data pribadi berdasarkan GDPR. IDFA dan GAID adalah data pribadi karena merupakan pengidentifikasi persisten tingkat perangkat. Pencocokan sidik jari probabilistik yang berjalan bersamaan bahkan lebih sulit dipertahankan tanpa persetujuan karena, menurut definisi, ini adalah upaya untuk mengidentifikasi pengguna tanpa kerja sama eksplisit mereka. CNIL, Garante Italia, dan AEPD Spanyol semuanya telah membuka investigasi terhadap penerbit yang tumpukan atribusinya aktif sebelum persetujuan diberikan.

Kontrol Privasi Bawaan AppsFlyer

AppsFlyer menyediakan serangkaian primitif privasi bawaan yang bermakna. Mereka bukan pengganti kerangka kerja persetujuan yang sesungguhnya, tetapi memahaminya sangat penting karena mereka adalah tuas yang digunakan CMP untuk mengontrol perilaku SDK.

Start SDK API

SDK mendukung mode inisialisasi di mana ia dikonfigurasi tetapi tidak mentransmisikan data apa pun sampai start() secara eksplisit dipanggil. Ini adalah hook tunggal yang paling penting untuk gating persetujuan — secara default SDK dimulai secara otomatis saat peluncuran aplikasi, yang merupakan perilaku yang salah untuk yurisdiksi mana pun dengan persyaratan persetujuan terlebih dahulu. Atur isStopped ke true saat inisialisasi, atau gunakan deferred-start API, dan hanya panggil start() ketika sinyal persetujuan telah dicatat.

Stop API

Jika persetujuan ditarik di tengah sesi, memanggil stop() menghentikan semua transmisi selanjutnya. Ini tidak secara retroaktif menghapus data yang sudah dikirim. Untuk penghapusan penuh, Anda perlu mengajukan permintaan penghapusan subjek data melalui portal privasi AppsFlyer — integrasi yang harus diotomatisasi tim melalui API AppsFlyer daripada alur kerja manual.

setSharingFilter

Ini memfilter jaringan iklan hilir mana yang menerima data postback. Ini adalah primitif yang tepat untuk persetujuan granular per mitra — misalnya, mengizinkan atribusi secara umum tetapi memblokir penerusan ke jaringan tertentu yang ditolak pengguna.

Integrasi Apple App Tracking Transparency

Di iOS, AppsFlyer membaca status otorisasi ATT dan menyesuaikan perilakunya secara otomatis — jika pengguna menolak ATT, IDFA tidak ditransmisikan. ATT independen dari persetujuan GDPR, dan banyak penerbit mencampuradukkannya. ATT mengontrol satu sinyal tingkat iOS; persetujuan GDPR mengontrol semua hal lainnya.

Integrasi di iOS

Pola yang andal di iOS adalah menginstal SDK AppsFlyer tetapi menunda inisialisasi sampai ATT dan alur persetujuan dalam aplikasi selesai. Urutan minimal adalah: aplikasi diluncurkan, SDK dikonfigurasi dengan isStopped = true, banner persetujuan dalam aplikasi ditampilkan, pengguna menerima kategori yang relevan, flag isStopped SDK dihapus dan start() dipanggil. Jika aplikasi juga memerlukan ATT (yang diperlukan untuk setiap pengguna di mana IDFA bermakna), prompt ATT ditampilkan bersamaan atau setelah banner dalam aplikasi. Sebagian besar CMP yang mendukung mobile memiliki API berbasis callback yang mengirimkan keputusan persetujuan; callback tersebut adalah tempat yang tepat untuk memanggil start().

Integrasi di Android

Implementasi Android paralel dengan iOS dengan dua perbedaan. Pertama, tidak ada padanan ATT — GAID tersedia kecuali pengguna telah menggunakan pengaturan tingkat perangkat "Hapus ID iklan", yang tidak dilakukan sebagian besar pengguna. Kedua, siklus hidup Android lebih agresif dalam mem-background-kan, sehingga inisialisasi SDK perlu dikaitkan dengan status persetujuan yang disimpan secara persisten. Baca status persetujuan dari penyimpanan lokal saat peluncuran aplikasi, konfigurasi SDK sesuai, dan periksa ulang saat resume jika pengguna memperbarui pilihan mereka saat aplikasi di-background-kan.

Integrasi di Web Mobile

AppsFlyer juga beroperasi di web mobile melalui produk smart banner dan OneLink-nya. Ini pada dasarnya adalah alat analitik sisi web dan deep-link yang menempatkan cookie dan memanggil server AppsFlyer dari browser. Mereka mengikuti aturan yang sama seperti permukaan pelacakan web lainnya: batasi di balik kategori pemasaran CMP, jangan biarkan skrip smart banner berjalan sebelum persetujuan diberikan, dan pastikan bahwa setiap peristiwa yang dipicu OneLink dari kampanye email atau push menghormati status persetujuan pengguna.

Kesalahan Umum

Empat kesalahan integrasi muncul berulang kali dalam audit penerapan AppsFlyer.

Memperlakukan ATT sebagai persetujuan GDPR

ATT dan persetujuan GDPR adalah sinyal yang berbeda dengan cakupan yang berbeda. Pengguna yang menerima ATT telah mengotorisasi penggunaan IDFA untuk pelacakan lintas aplikasi; mereka belum mengotorisasi semua hal lain yang dilakukan SDK. Untuk lalu lintas EU dan UK kedua sinyal diperlukan, dengan banner dalam aplikasi menjadi yang mengikat dan ATT menjadi lapisan khusus iOS di atasnya.

Membiarkan SDK diinisialisasi saat peluncuran

Ini adalah cacat tunggal yang paling umum. Integrasi default memanggil start() segera, yang memicu peristiwa instalasi dengan payload pengidentifikasi penuh sebelum pengguna melihat banner persetujuan. Remediasinya langsung: konfigurasi isStopped = true pada saat integrasi dan panggil start() hanya dari callback persetujuan.

Lupa menangani penarikan

Jika pengguna menerima dan kemudian mencabut, SDK perlu diberitahu untuk berhenti mentransmisikan. Gunakan API stop() dan perbarui status persetujuan yang tersimpan agar peluncuran aplikasi berikutnya menghormati keputusan baru.

Mengabaikan postback server-ke-server

AppsFlyer meneruskan peristiwa konversi ke daftar panjang jaringan iklan terintegrasi melalui postback sisi server. Setiap penerusan membawa data pribadi dan mewarisi cakupan persetujuan dari peristiwa asli. Gunakan setSharingFilter untuk memastikan bahwa penerusan hanya ke mitra yang tercakup dalam pilihan persetujuan pengguna, bukan ke setiap mitra di dasbor AppsFlyer Anda.

Daftar Periksa Audit

Enam pertanyaan konkret yang harus dijawab untuk setiap penerapan AppsFlyer yang menyentuh lalu lintas EU, UK, atau California.

• Apakah SDK menunggu persetujuan? Pada instalasi baru di perangkat uji yang berlokasi di EU, konfirmasi bahwa tidak ada endpoint AppsFlyer yang menerima permintaan apa pun sebelum pengguna menerima banner.
• Apakah ATT dipisahkan dari persetujuan dalam aplikasi? Konfirmasi bahwa banner dalam aplikasi adalah sinyal persetujuan yang mengendalikan dan ATT diperlakukan sebagai lapisan tambahan khusus iOS.
• Apakah penerusan mitra dicakupkan ke persetujuan? Konfirmasi bahwa setSharingFilter dikonfigurasi untuk mengecualikan mitra yang belum diotorisasi pengguna.
• Apakah penarikan menghentikan SDK? Konfirmasi bahwa memanggil stop() berfungsi pada pencabutan persetujuan dan bahwa status baru bertahan di seluruh peluncuran.
• Apakah postback server diaudit? Konfirmasi bahwa daftar "Integrasi yang Dikonfigurasi" di dasbor AppsFlyer memetakan dengan bersih ke mitra pemasaran yang diungkapkan di banner.
• Apakah penghapusan data diotomatisasi? Konfirmasi bahwa permintaan DSAR memicu API penghapusan AppsFlyer, bukan tiket manual.

Di Mana AppsFlyer Cocok dalam Stack yang Mengutamakan Persetujuan

Atribusi mobile adalah salah satu permukaan yang paling padat pengidentifikasi dalam stack pemasaran, dan SDK AppsFlyer adalah salah satu integrasi tunggal yang paling berdampak. Kabar baiknya adalah platform ini menyediakan primitif — Start SDK, Stop, filter berbagi, API penghapusan — yang diperlukan untuk membuat penegakan persetujuan bersih dan dapat diverifikasi. Tugas bagi penerbit adalah menghubungkan primitif tersebut ke CMP yang memiliki keputusan persetujuan yang mengikat, memperlakukan ATT sebagai sinyal pelengkap bukan pengganti, dan memastikan penerusan mitra sisi server tidak dapat lolos dari amplop persetujuan yang dicatat banner. Jika dilakukan dengan benar, hasilnya adalah stack atribusi yang memuaskan regulator sambil tetap mempertahankan data instalasi dan peristiwa yang diandalkan tim akuisisi pengguna.