Lewati ke konten utama
Didit Raih $7,5 Juta untuk Membangun Infrastruktur Identitas dan Fraud
Didit
Kembali ke blog
Blog · 13 Maret 2026

Mengoptimalkan SDK iOS Anda untuk ITP dan Pencegahan Pelacakan Safari (ID)

Intelligent Tracking Prevention (ITP) Safari dan fitur privasi lainnya terus berkembang, menimbulkan tantangan bagi SDK iOS yang mengandalkan metode pelacakan tradisional.

Oleh DiditDiperbarui
optimizing-ios-sdk-safari-itp-tracking-prevention.png

Rangkul Konteks Pihak PertamaITP Safari sangat membatasi cookie pihak ketiga. Rancang SDK iOS Anda untuk beroperasi dalam konteks pihak pertama sedapat mungkin, memanfaatkan solusi sisi server atau integrasi langsung.

Prioritaskan Pengenal yang Menjaga PrivasiJauhi pengenal lintas-situs yang persisten. Fokus pada pengenal yang bersifat sementara atau yang disetujui pengguna, menghormati pengaturan privasi pengguna dan kerangka kerja App Tracking Transparency Apple.

Terapkan Fallback yang KuatAntisipasi bahwa beberapa titik data atau mekanisme pelacakan mungkin diblokir. Bangun SDK Anda dengan degradasi yang anggun dan strategi fallback untuk mempertahankan fungsionalitas inti bahkan saat ITP aktif.

Tetap Terkini dengan Kebijakan AppleITP dan kebijakan privasi bersifat dinamis. Tinjau secara teratur dokumentasi pengembang dan pembaruan privasi Apple untuk memastikan SDK Anda tetap sesuai dan efektif.

Intelligent Tracking Prevention (ITP) Safari secara fundamental telah mengubah lanskap pelacakan web, terutama bagi pengembang yang mengandalkan cookie pihak ketiga dan pengenal persisten. Bagi SDK iOS, ini menghadirkan serangkaian tantangan yang unik, terutama saat berintegrasi dengan tampilan web atau menangani komunikasi lintas domain. Komitmen berkelanjutan Apple terhadap privasi pengguna, yang diperkuat oleh fitur-fitur seperti App Tracking Transparency (ATT) dan kebijakan yang lebih ketat tentang pengumpulan data, berarti bahwa pengembang SDK harus secara proaktif mengadaptasi strategi mereka untuk memastikan fungsionalitas, menjaga integritas data, dan menghormati persetujuan pengguna.

Posting blog ini membahas seluk-beluk ITP dan mekanisme privasi serupa di Safari pada iOS, menawarkan wawasan yang dapat ditindaklanjuti dan contoh praktis untuk mengoptimalkan SDK Anda. Tujuan kami adalah membantu Anda membangun SDK yang tangguh dan menjaga privasi yang tidak hanya berfungsi dengan andal tetapi juga menumbuhkan kepercayaan pengguna di dunia digital yang semakin sadar privasi.

Memahami ITP Safari dan Dampaknya pada SDK iOS

Intelligent Tracking Prevention (ITP) adalah serangkaian teknologi peningkat privasi yang dibangun di Safari (dan WebKit). Fungsi utamanya adalah membatasi pelacakan lintas-situs dengan membatasi penggunaan cookie dan bentuk data situs web lainnya oleh pihak ketiga. Selama bertahun-tahun, ITP telah berkembang melalui beberapa iterasi, masing-masing memperkenalkan kontrol yang lebih ketat:

  • Memblokir Cookie Pihak Ketiga: Aspek yang paling signifikan. ITP secara agresif mempartisi atau memblokir cookie pihak ketiga, sehingga sulit bagi pengiklan dan penyedia analitik untuk melacak pengguna di berbagai situs web.
  • Storage Access API: Diperkenalkan sebagai cara yang menjaga privasi bagi konten yang disematkan untuk meminta akses ke penyimpanan pihak pertamanya ketika pengguna berinteraksi dengannya.
  • Perlindungan Dekorasi Tautan: ITP juga dapat menghapus parameter pelacakan dari URL untuk mencegah pelacakan melalui dekorasi tautan.
  • Kebijakan Referrer: Safari sering mengirimkan kebijakan referrer yang lebih ketat (misalnya, strict-origin-when-cross-origin), membatasi jumlah informasi yang diteruskan ke situs pihak ketiga.
  • Pencegahan Pelacakan Pantulan Ephemeral: Mengidentifikasi dan mengurangi teknik di mana pelacak mengarahkan pengguna melalui situs mereka untuk mengatur cookie pihak pertama.

Untuk SDK iOS, terutama yang berinteraksi dengan konten web (misalnya, browser dalam aplikasi, alur autentikasi, gateway pembayaran, atau analitik tertanam), dampak ITP bisa sangat besar. Jika SDK Anda mengandalkan pengaturan atau pembacaan cookie dari domain pihak ketiga dalam WKWebView, atau jika mengharapkan informasi referrer tertentu diteruskan, ITP dapat merusak mekanisme ini, yang mengarah ke:

  • Gagalnya proses autentikasi atau pembayaran.
  • Data atribusi atau analitik yang tidak akurat.
  • Pengalaman pengguna yang rusak karena informasi status atau sesi yang hilang.

Strategi Pengembangan SDK iOS yang Tahan ITP

Beradaptasi dengan ITP membutuhkan perubahan pola pikir dari pelacakan tradisional ke penanganan data yang berpusat pada privasi. Berikut adalah strategi utamanya:

1. Prioritaskan Konteks Pihak Pertama dan Solusi Sisi Server

Cara paling efektif untuk menghindari pembatasan ITP pada cookie pihak ketiga adalah dengan beroperasi dalam konteks pihak pertama. Ini berarti domain yang mengatur cookie atau mengakses penyimpanan sama dengan domain yang sedang dikunjungi pengguna.

Contoh Praktis: Pelacakan Sisi Server untuk Analitik

Alih-alih mengandalkan skrip analitik pihak ketiga yang disematkan di WKWebView Anda yang mencoba mengatur cookie-nya sendiri, pertimbangkan pendekatan sisi server:

  1. SDK Mengumpulkan Data: Aplikasi iOS Anda (atau konten web dalam WKWebView Anda) mengumpulkan data interaksi pengguna yang relevan (misalnya, produk yang dilihat, tombol yang diklik).
  2. Kirim Data ke Backend Anda: Data ini dikirim langsung ke server backend Anda sendiri.
  3. Backend Meneruskan ke Penyedia Analitik: Backend Anda kemudian meneruskan data ini ke API penyedia analitik Anda. Karena komunikasi ini terjadi server-ke-server, komunikasi ini melewati pembatasan ITP pada cookie sisi klien.

Pendekatan ini memberi Anda kendali penuh atas data, memastikan data dikirim dengan andal, dan tidak tunduk pada pencegahan pelacakan sisi browser.

2. Manfaatkan Storage Access API untuk Kebutuhan Lintas-Situs

Ketika Anda benar-benar membutuhkan akses ke cookie lintas-situs dalam WKWebView yang disematkan (misalnya, untuk single sign-on dengan penyedia identitas), Storage Access API adalah metode yang disetujui dan menjaga privasi. API ini memungkinkan konten pihak ketiga untuk meminta izin eksplisit dari pengguna untuk mengakses penyimpanan pihak pertamanya.

Contoh Praktis: SSO Seamless di WKWebView

Bayangkan SDK Anda menyematkan WKWebView untuk alur autentikasi yang perlu mengakses cookie dari penyedia identitas (IDP) Anda untuk mencapai SSO. Tanpa Storage Access API, Safari akan memblokir cookie ini.

Sisi klien (dalam konten web yang disematkan):

document.requestStorageAccess().then(function() {
    // Akses penyimpanan diberikan, sekarang Anda dapat membuat permintaan yang menggunakan cookie
    // misal, muat iframe SSO atau buat permintaan XHR ke IDP
}).catch(function() {
    // Akses penyimpanan ditolak atau interaksi pengguna diperlukan
    // Tangani dengan baik, mungkin kembali ke login pengalihan penuh
});

SDK iOS (WKUIDelegate dan WKNavigationDelegate):

Anda perlu menangani prompt pengguna yang disajikan Safari. Metode WKUIDelegate webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (atau permintaan izin serupa) mungkin dipanggil, tetapi untuk akses penyimpanan, prompt biasanya ditangani oleh Safari itu sendiri. Pastikan WKWebViewConfiguration Anda diatur dengan benar, terutama websiteDataStore.

3. Adopsi Pengenal yang Menjaga Privasi dan Persetujuan Pengguna

Dengan App Tracking Transparency (ATT), Apple memerlukan persetujuan eksplisit dari pengguna untuk pelacakan di seluruh aplikasi dan situs web yang dimiliki oleh perusahaan lain. SDK Anda harus menghormati ini. Jauhi ketergantungan pada pengenal perangkat persisten untuk tujuan pelacakan tanpa persetujuan.

Contoh Praktis: Menangani ATT dan IDFA

Jika SDK Anda sebelumnya mengandalkan Identifier for Advertisers (IDFA) untuk atribusi atau penargetan:

  1. Minta Otorisasi ATT: Gunakan AppTrackingTransparency.framework untuk meminta otorisasi pengguna sebelum mengakses IDFA.
  2. Penggunaan IDFA Bersyarat: Hanya ambil dan gunakan IDFA jika pengguna memberikan izin.
  3. Pengenal Alternatif: Jika ditolak, andalkan pengenal ephemeral (misalnya, ID sesi) atau ID yang dihasilkan server yang tidak persisten yang tidak digunakan untuk pelacakan lintas-situs.

Contoh Swift:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // Gunakan IDFA untuk pelacakan yang disetujui
            case .denied, .notDetermined, .restricted:
                print("Otorisasi ATT ditolak atau tidak ditentukan.")
                // Andalkan metode menjaga privasi lainnya
            @unknown default:
                break
            }
        }
    } else {
        // Fallback untuk versi iOS sebelum 14
        // Periksa apakah pelacakan diaktifkan melalui ASIdentifierManager.shared().isAdvertisingTrackingEnabled
    }
}

Bagaimana Didit Membantu

Didit, sebagai platform identitas all-in-one, secara inheren selaras dengan pendekatan privasi-pertama, membuatnya tangguh terhadap ITP dan mekanisme pencegahan pelacakan serupa. Fokus inti kami adalah memverifikasi manusia nyata dengan aman, bukan pada pelacakan lintas-situs. Arsitektur Didit dirancang untuk menangani verifikasi identitas, biometrik, deteksi penipuan, dan autentikasi dalam satu sistem yang terkontrol, meminimalkan ketergantungan pada cookie pelacakan pihak ketiga. Kami mencapai ini dengan:

  • Integrasi Pihak Pertama: SDK dan API Didit dirancang untuk integrasi langsung, pihak pertama ke dalam aplikasi Anda, memastikan bahwa proses verifikasi identitas terjadi dalam konteks aplikasi Anda, sebagian besar melewati masalah ITP yang terkait dengan pelacakan lintas-situs.
  • Pemrosesan Sisi Server: Banyak kemampuan Didit yang kuat, seperti penyaringan AML dan analisis sinyal penipuan, beroperasi server-ke-server. Ini berarti pemrosesan data sensitif dan pemeriksaan identitas terjadi dengan aman di backend kami, menghilangkan kerentanan pelacakan sisi klien.
  • Biometrik Ephemeral: Didit memproses data biometrik dalam memori dan menghapusnya, hanya mengembalikan hasil boolean ke aplikasi Anda. Pendekatan "privasi berdasarkan desain" ini berarti kami tidak menyimpan pengenal biometrik persisten untuk pelacakan, selaras sempurna dengan tujuan ITP.
  • Alur Autentikasi Aman: Metode autentikasi kami, termasuk re-autentikasi biometrik, dibangun agar aman dan pribadi, menggunakan mekanisme tantangan-respons yang tidak bergantung pada cookie lintas-situs untuk manajemen status.
  • Kepatuhan dan Kepercayaan: Dengan kepatuhan SOC 2 Type II, ISO 27001, dan GDPR, Didit dibangun di atas fondasi privasi dan keamanan data, yang secara alami membuat platform kami tangguh terhadap perubahan dalam teknologi pencegahan pelacakan.

Siap Memulai?

Mengadaptasi SDK iOS Anda untuk ITP Safari dan lanskap privasi yang lebih luas bukan hanya tentang kepatuhan; ini tentang membangun kepercayaan dengan pengguna Anda dan memastikan umur panjang produk Anda. Dengan merangkul konteks pihak pertama, memanfaatkan API yang sesuai seperti Storage Access, memprioritaskan persetujuan pengguna, dan tetap terinformasi tentang kebijakan Apple yang berkembang, Anda dapat membuat SDK yang tangguh dan menghormati privasi.

Jelajahi bagaimana platform identitas privasi-pertama Didit dapat menyederhanakan kepatuhan Anda dan meningkatkan pengalaman pengguna. Kunjungi situs web kami, lihat dokumentasi teknis kami, atau minta demo untuk melihat Didit beraksi.

Infrastruktur untuk identitas dan fraud.

Satu API untuk KYC, KYB, Transaction Monitoring, dan Wallet Screening. Integrasi dalam 5 menit.

Minta AI untuk merangkum halaman ini
Optimalkan SDK iOS untuk ITP & Pencegahan Pelacakan Safari.