Panduan dasar integrasi SDK

Direkomendasikan untuk

Pemasar

Tanggal terakhir diupdate:15 Mei, 2023 07:55

Sekilas: Bekerja sama dengan pengembang aplikasi seluler atau CTV Anda untuk mengintegrasikan dan menginstal SDK ke aplikasi Android atau iOS. Setelah tugas integrasi dasar selesai, aplikasi Anda siap untuk atribusi install dan pengukuran in-app event.

Bacaan terkait

Untuk gambaran lengkap tentang perencanaan integrasi SDK dengan aplikasi Anda, pastikan untuk membaca artikel berikut:

Tinjauan integrasi SDK
Panduan integrasi SDK dasar (artikel ini)
Panduan tambahan integrasi SDK
Tinjauan TV Terhubung (CTV) dan over-the-top (OTT)

Mengambil kode pengembang

Sebelum pengembang Anda dapat menginstal dan mengintegrasikan SDK, Anda harus mengambil kode pengembang. AppsFlyer menggunakan kode pengembang untuk mengidentifikasi akun Anda secara unik. Kode pengembang bersifat wajib karena memungkinkan SDK mengirim dan mengambil data milik akun Anda dengan aman.

Untuk mengambil kode pengembang Anda:

Di AppsFlyer, buka Konfigurasi > Pengaturan Aplikasi .
Salin kode pengembang, dan kirimkan ke pengembang seluler Anda.
Berikan petunjuk kepada pengembang seluler Anda untuk menginstal dan mengintegrasikan SDK .

Di mana memulai SDK?

Saat merencanakan integrasi SDK AppsFlyer, keputusan pertama yang harus Anda buat adalah di mana menginisialisasi dan memulai SDK dalam alur peluncuran aplikasi Anda.

Aturan dasarnya adalah agar SDK mulai mengirim data sesegera mungkin setelah meluncurkan aplikasi.Hal ini memastikan bahwa SDK menangkap kejadian penginstalan dan semua kejadian dalam aplikasi lainnya yang terjadi dalam sesi tersebut.

Namun, untuk mematuhi peraturan privasi seperti GDPR dan CCPA, pengiriman data ke AppsFlyer sering kali perlu ditunda hingga pengguna setuju untuk membagikan informasi mereka.

Memulai SDK di Android

Pilih di kelas mana untuk memulai SDK

Pilih apakah akan memulai SDK di kelas Aplikasi global atau kelas Aktivitas :

Mulai SDK di kelas Aplikasi global: Umumnya, menginisialisasi SDK di kelas/subkelas Aplikasi global adalah praktik yang baik karena kelas Aplikasi dimuat dan diinisialisasi sebelum UI aplikasi apa pun ditampilkan. Hal ini memastikan bahwa SDK dapat dimulai dalam skenario apa pun, termasuk deep linking.
Mulai SDK di kelas Aktivitas (awal yang ditangguhkan) untuk memungkinkan pengguna ikut serta dalam berbagi data. Ini karena mendapatkan persetujuan pengguna memerlukan antarmuka pengguna (UI) yang dirender dalam kelas Aktivitas .

Pilih skenario opt-out/in (tidak ikut serta/ikut serta)

Pilih skenario opt-out (tidak ikut serta) yang menguraikan cara memulaipanggilan dengan cara yang mematuhi peraturan privasi seperti GDPR dan CCPA. Misalnya, pilih antara skenario Opt-out (tidak ikut serta) saat penginstalan, skenario opt-out satu kali, atau mencegah berbagi data dengan skenario pihak ketiga.

Untuk informasi selengkapnya tentang skenario opt-out (tidak ikut serta) yang tersedia, termasuk contoh kode, lihat skenario keikutsertaan dan ketidakikutsertaan.

petunjuk pengembang Android

Beri tahu pengembang tentang keputusan Anda tentang hal-hal berikut:
- Di kelas apa - Aplikasi atau Aktivitas - untuk memulai SDK?
- Skenario opt-in/opt-out mana yang akan digunakan?
Kirimkan tautan referensi berikut kepada pengembang Anda:

Memulai SDK di iOS

Menunda dimulainya SDK di iOS

Pertimbangan penting saat merencanakan cara memulai SDK adalah apakah akan menunda start (mulai) hingga izin pengguna diberikan.

SDK menyediakan metode waitForATTUserAuthorization , yang memungkinkan Anda mengonfigurasi berapa lama SDK harus menunggu persetujuan pengguna sebelum mengirimkan data ke server AppsFlyer.

Untuk informasi selengkapnya tentang aliran data metode dan interaksinya dengan kerangka kerja ATT iOS, lihat bagian dukungan Konfigurasi Transparansi Pelacakan Aplikasi (ATT) .

Pilih skenario opt-out/in (tidak ikut serta/ikut serta)

Pilih skenario opt-out (tidak ikut serta) yang menguraikan cara memulaipanggilan dengan cara yang mematuhi peraturan privasi seperti GDPR dan CCPA. Misalnya, pilih antara skenario Opt-out saat penginstalan, skenario opt-out satu kali, atau mencegah berbagi data dengan skenario pihak ketiga.

Untuk informasi selengkapnya tentang berbagai skenario ketidakikutsertaan yang tersedia, lihat skenario opt-in dan opt-out.

petunjuk pengembang iOS

Bagikan dengan pengembang Anda informasi berikut:

Berapa lama waktu tunggu sebelum mengirimkan data ke AppsFlyer dalam hitungan detik?
Skenario opt-in/opt-out mana yang akan digunakan?
Tautan Pengembang:
- Memulai iOS SDK untuk panduan pengembang dan referensi tentang cara memulai SDK.
- Mengonfigurasi dukungan Transparansi Pelacakan Aplikasi (ATT) untuk informasi tentang alur data metode waitForATTUserAuthorization dan cara interaksinya dengan kerangka kerja ATT iOS
- Mengaktifkan dukungan Transparansi Pelacakan Aplikasi (ATT) untuk panduan pengembang dan referensi di waitForATTUserAuthorization

Atribusi

SDK mengumpulkan pengenal (identifier) untuk tujuan atribusi.Untuk memastikan bahwa penginstalan dicatat dan diatribusikan dengan benar, tinjau dan ikuti panduan ini.

Semua platform

Pengenal unik untuk penginstalan

ID AppsFlyer dibuat secara otomatis untuk setiap penginstalan aplikasi baru. Tidak ada tindakan yang diperlukan oleh pemasar.

Anda dapat menggunakan pengenal ini untuk melakukan tindakan berikut:

Mengirim in-app event server ke server .
Mencocokkan ID AppsFlyer dengan catatan pengguna di sistem back end
Mengunduh laporan in-app event data lengkap dan menggunakan appsflyer_id untuk menganalisis perilaku dan perjalanan pengguna.

Mengintegrasikan pengenal unik dari sistem BI Anda dengan AppsFlyer

Menetapkan ID pengguna Pelanggan (CUID) Anda sendiri di SDK AppsFlyer untuk referensi silang ID unik dari sistem BI Anda dengan ID AppsFlyer dan pengenal lainnya. CUID tersedia di laporan data lengkap AppsFlyer. Anda juga dapat menggunakannya dalam API postback untuk referensi silang dengan ID internal Anda.

Lihat petunjuk pengembang untuk menerapkan CUID.

Khusus Android

Bagian berikut menjelaskan pertimbangan atribusi untuk Google Play Store atau toko aplikasi pihak ketiga.

Aplikasi atribut dipublikasikan di Google Play

Pengarah Instal (Instal referrer) Google Play

API Pengarah Instal Google Play meningkatkan akurasi atribusi, melindungi dari kecurangan penginstalan, dan memungkinkan pengambilan data rujukan dari Google Play secara aman (misalnya, versi aplikasi pada saat pertama kali aplikasi diinstal).

Anda disarankan untuk memberikan petunjuk ini kepada pengembang untuk menambahkan API pengarah instal Google Play.

GAID

Mulai SDK V4.8.0, AppsFlyer secara otomatis mengumpulkan pengenal perangkat ini.

Atribusikan aplikasi di toko aplikasi pihak ketiga

Dengan AppsFlyer, Anda dapat pengatribusikan penginstalan yang berasal dari toko aplikasi pihak ketiga, seperti Amazon, Opera, GetJar, Baidu, dan Huawei. Hal ini memungkinkan Anda untuk mempromosikan aplikasi dan menjangkau audiens yang lebih besar di pasar tempat Google Play Store tidak tersedia.

AppsFlyer mendukung atribusi dalam konteks toko aplikasi pihak ketiga sebagai berikut:

IMEI atau ID Android: SDK tidak secara otomatis mengumpulkan IMEI atau ID Android. Namun, jika ada kebutuhan untuk mengumpulkan pengenal ini (misalnya, untuk aplikasi di pasar domestik China ) pengembang Anda dapat menerapkan salah satu jenis pengumpulan berikut:
- Pengumpulan manual: Aplikasi meneruskan IMEI atau ID Android ke SDK (menggunakan setImeiData atau setAndroidIdData API). SDK mengirimkan data ke server AppsFlyer.
- Mengaktifkan pengumpulan ID perangkat: Memaksa SDK untuk mengumpulkan IMEI atau ID Android.
OAID: Penginstalan atribut dari toko aplikasi Android pihak ketiga. Untuk informasi selengkapnya, lihat Panduan untuk menerapkan OAID .
Pengarah instal (Instal referrer): SDK mendukung pengambilan data pengarah dari Galeri Samsung dan Huawei AppGallery.

Khusus iOS

Bagian berikut mencakup informasi penting tentang dukungan untuk perangkat iOS 14+.

Mengonfigurasi dukungan App Tracking Transparency (ATT)

Latar belakang

Mulai iOS 14.5, pengumpulan IDFA mewajibkan persetujuan pengguna. Singkatnya, itu berarti akses IDFA diatur oleh framework App Tracking Transparency (Transparansi Pengukuran Aplikasi) (ATT). Di perangkat iOS 14+, SDK menggunakan framework ATT untuk mendapatkan akses ke IDFA perangkat.

Untuk pengenalan ke ATT, lihat prinsip ATT.

Ketika atribusi terjadi menggunakan IDFA, penting bahwa IDFA dikirim pada peluncuran pertama. Karena alasan ini, SDK menyediakan utilitas waitForATTUserAuthorization.

Ikhtisar waitForATTUserAuthorization

Penting!

Jangan panggil metode waitForATTUserAuthorization jika Anda tidak ingin menjalankan prompt ATT.

waitForATTUserAuthorization memungkinkan Anda untuk mengonfigurasi berapa lama SDK harus ditangguhkan dan menunggu status ATT sebelum mengirim data ke server AppsFlyer.

Saat pengguna meluncurkan aplikasi, status ATT tidak ditentukan. Selama waktu tunggu waitForATTUserAuthorization , SDK mengantrekan event peluncuran dan in-app event berturut-turut dalam memori, mirip dengan cara pencatatan peristiwa offline:

Jika pengguna menyetujui prompt ATT (pengumpulan IDFA):
- SDK menambahkan IDFA ke event yang disimpan dalam cache.
- SDK memulai dan mengirim event yang disimpan dalam cache dengan IDFA (tanpa menunggu waktu tunggu berakhir).
Jika pengguna menolak prompt ATT: SDK memulai dan mengirim event yang disimpan dalam cache tanpa IDFA (tanpa menunggu waktu habis).
Jika waktu tunggu berakhir dan status ATT tetap tidak ditentukan , SDK memulai dan mengirim event yang disimpan dalam cache tanpa IDFA.

Pertimbangan

Memanggil metode requestTrackingAuthorization tanpa mengatur waitForATTUserAuthorization akan menyebabkan peluncuran dan event yang dikirim tanpa IDFA untuk perangkat iOS 14+.
Jika pengguna memindahkan aplikasi ke latar belakang selama waktu tunggu:
- Timer dijeda hingga aplikasi kembali ke latar depan.
- Event disimpan dalam cache in-memory.
Jika pengguna mematikan aplikasi, aplikasi akan dimatikan selama waktu tunggu:
- Timer direstart pada peluncuran aplikasi berikutnya.
- Event yang disimpan dalam cache akan hilang.

Menyesuaikan dialog persetujuan ATT

Anda dapat menyesuaikan prompt ATT. Pesan yang jelas menyatakan bahwa tujuan permintaan dapat membantu meningkatkan tingkat aktivasi pengguna.

Pertimbangkan hal berikut saat membuat pesan Anda:

Gunakan kata-kata terbaik untuk menjelaskan kepada pengguna Anda mengapa aplikasi meminta persetujuan pengguna.
Beri tahu pengguna tentang bagaimana data mereka akan digunakan. P elajari lebih lanjut tentang privasi pengguna dan penggunaan data.

Setelah pesan Anda selesai, berikan teks dan petunjuk implementasi kepada pengembang Anda.

Lihat beberapa contoh eksternal prompt ATT.

Dukungan untuk atribusi SKAN

Catatan

Untuk sepenuhnya mendukung atribusi SKAN, upgrade ke iOS SDK V6.2.3+.

SKAdNetworkadalah kelas yang digunakan oleh iOS yang memvalidasi penginstalan yang didorong pengiklan. Proses validasi penginstalan aplikasi melibatkan aplikasi sumber dan aplikasi yang diiklankan

Aplikasi sumber adalah aplikasi yang berpartisipasi dalam kampanye iklan dengan menampilkan iklan dari jaringan iklan. Mengonfigurasi aplikasi Anda untuk menampilkan iklan tidak termasuk dalam cakupan AppsFlyer SDK. Untuk mengonfigurasi, ikuti petunjuk Apple.

Untuk aplikasi yang diiklankan (aplikasi dengan SDK AppsFlyer), Solusi SKAdNetwork AppsFlyer menggunakan SKAdNetwork untuk menyediakan postback atribusi saat AppsFlyer mengumpulkan, menafsirkan, dan menggabungkan data sekaligus menjaga privasi pengguna. Ketika aplikasi diluncurkan untuk pertama kalinya, platform AppsFlyer menggunakan konfigurasi yang diatur pemasar untuk memerintahkan SDK tentang cara mengatur nilai konversi SKAdNetwork.

Untuk menggunakan solusi SKAN :

Pemasar harus mengonfigurasi pengukuran SKAdNetwork di AppsFlyer. Pengembang tidak perlu melakukan apa pun.
SDK AppsFlyer secara otomatis memanggil API SKAN yang diperlukan.
Pastikan untuk menonaktifkan panggilan SKAN di SDK lain jika Anda mengandalkan AppsFlyer untuk atribusi SKAN.
Tidak ada tindakan atau proses pendaftaran lain yang diperlukan oleh programmer atau pemasar di App Store.

Untuk menonaktifkan atribusi SKAdNetwork, instruksikan pengembang Anda untuk menonaktifkannya di SDK.

Merekam in-app event

In-app event (IAE) menyediakan wawasan tentang aktivitas yang terjadi di aplikasi Anda. Merekam in-app event membantu Anda mengukur KPI seperti Return on Investment (ROI) dan Lifetime Value (LTV). Sebaiknya luangkan waktu untuk menentukan event yang ingin Anda rekam.

Setelah Anda menentukan in-app event yang ingin diukur, kirim nama event dan parameter ke pengembang Anda, dan sertakan tautan ke petunjuk penerapan.

Untuk mempelajari lebih lanjut tentang in-app event, lihat panduan Rich in-app event kami .

Semua platform

Rekam pendapatan

Anda dapat mengirimkan pendapatan dengan in-app event apa pun. Pastikan Anda menggunakan parameter af_revenue untuk menyertakan pendapatan. Ini adalah satu-satunya parameter event yang dihitung oleh AppsFlyer sebagai pendapatan nyata di dashboard dan dalam laporan data lengkap. Pelajari lebih lanjut.

Untuk petunjuk programmer, lihat mencatat pendapatan .

Validasi pembelian in-app

SDK AppsFlyer menyediakan verifikasi server untuk pembelian in-app. Memvalidasi pembelian in-app secara otomatis mengirimkan event pembelian in-app ke AppsFlyer. Mengirim event ini sendiri membuat salinan pelaporan event.

Industri vertikal

Lihat daftar in-app event yang direkomendasikan per bisnis vertikal ., misalnya, perjalanan, game, atau eCommerce.

Tautan langsung (deep linking) dengan OneLink

OneLink adalah solusi AppsFlyer untuk atribusi multi-platform, pengarahan, dan deep linking.

Semua platform

Deteksi dan pengarahan perangkat

Untuk pengguna yang tidak menginstal aplikasi Anda, OneLink mendeteksi jenis perangkat dan mengarahkan mereka ke tujuan yang benar (misalnya, Google Play, Apple App Store, toko aplikasi pihak ketiga, atau halaman web). Ini berdasarkan pengaturan template OneLink Anda. Pelajari lebih lanjut

Penautan Langsung

Untuk pengguna yang menginstal aplikasi Anda, OneLink akan membuka aplikasi. Selain membuka aplikasi, Anda juga dapat menautkan langsung pengguna (deep link) ke aktivitas atau laman tertentu di dalam aplikasi. Ini mewajibkan pengembang Anda untuk menerapkan Unified Deep Linking/Tautan Langsung Terpadu (UDL).

Catatan:

UDL mewajibkan SDK V6.1+.
Pelanggan yang telah menggunakan OneLink untuk deep linking dapat menggunakan metode lama, bukan UDL.

Lihat panduan kami tentang mengatur Deep linking dan deferred deep linking.

Deferred deep linking (tautan langsung tertunda) :

Bagi pengguna yang tidak menginstal aplikasi Anda, OneLink mendeteksi jenis perangkat dan mengarahkan mereka ke tujuan yang benar: Google Play, Apple App Store, toko aplikasi pihak ketiga, atau laman web. Setelah pengguna meluncurkan aplikasi, Anda dapat menggunakan deferred deep linking (tautan langsung tertunda) untuk mengarahkan mereka ke aktivitas atau laman tertentu di dalam aplikasi.

Hal ini mengharuskan programmer Anda untuk menerapkan penautan langsung yang tertunda dan diperluas.

Catatan:

UDL mewajibkan SDK V6.1+.
Pelanggan yang telah menggunakan OneLink untuk deferred deep linking (tautan langsung tertunda) dapat menggunakan metode lama, bukan UDL.

Lihat panduan kami tentang mengatur Deep linking dan deferred deep linking.

Mengakses data atribusi dan deep linking

Tabel berikut menjelaskan metode yang tersedia untuk mengambil data atribusi dan deep linking:

Metode	Siapa saja yang terlibat?	Kembalikan hasil	Metode pengambilan	Data atribusi	Data deep linking	Ketersediaan
Push API	Pemasar Programmer back-end	Biasanya dalam beberapa menit	Backend	Y	N	Premium
Pull API	Pemasar Programmer back-end	Periodik (tidak real-time). Anda dapat menjadwalkan unduhan laporan data lengkap.	Backend	Y	Y	Premium untuk laporan data lengkap
Data Locker	Pemasar Programmer back-end	Laporan per jam tersedia dalam 1 - 3 jam	Penyimpanan cloud melalui salah satu opsi berikut: Bucket milik AppsFlyer di AWS Penyimpanan milik Anda (AWS atau GCS)	Y	Y	Premium
Dapatkan data konversi (Get Conversion Data/GCD)	Pemasar Programmer seluler Lihat dokumentasi pengembang	Hingga 5 detik	SDK	Y	Y	Semua akun
Deep Linking Terpadu (Unified Deep Linking/UDL)	Pemasar Programmer seluler Lihat dokumentasi pengembang	Hingga 1 detik	SDK	N	Y	Semua akun

Perhatikan hal berikut untuk pengguna iOS 14.5+ yang tidak memberikan persetujuan:

Ketika menggunakan UDL untuk media berbayar dan milik sendiri, data deep linking tersedia.
Ketika menggunakan GCD untuk media berbayar, datanya terbatas dan tidak termasuk rincian atribusi dan deep linking.

Tips

Kami menyarankan hal berikut:

Gunakan Push API saat mengambil data atribusi dan mengirimkannya ke server Anda untuk diproses lebih lanjut. Metode ini menunggu data tersedia, dan karena itu sangat akurat dan mendekati waktu aktual. GCD mengembalikan data secara waktu aktual, tetapi mungkin tidak akurat saat keputusan atribusi akhir ditentukan setelah lebih dari 5 detik.
Gunakan Pull API untuk secara periodik (misalnya, setiap hari) melengkapi data atribusi waktu aktual, dan untuk mengompensasi kesalahan komunikasi yang mungkin terjadi.

Menguji integrasi SDK Anda

Setelah integrasi SDK selesai, Anda dapat membuka dashboard AppsFlyer, dan dari laman Uji Integrasi SDK, uji penginstalan organik dan non-organik, in-app event, dan deep linking. Ini memastikan bahwa penginstalan dan in-app event dicatat dan diatribusikan dengan benar.

Jika Anda memerlukan pengembang untuk menguji integrasi SDK, tambahkan pengembang sebagai pengguna di akun Anda, sehingga mereka dapat mengakses dasbor.

Untuk skenario dan petunjuk pengujian, lihat pengujian integrasi SDK .