Mengapa Amplitude memerlukan persetujuan

SDK Browser Amplitude default dan SDK seluler Amplitude melakukan jauh lebih banyak daripada sekadar merekam tampilan halaman. Saat inisialisasi, mereka menetapkan pengenal perangkat di penyimpanan pihak pertama, menghasilkan pengenal sesi, menangkap referrer, menguraikan UTM dan pengenal klik dari URL, dan mulai mengantrekan peristiwa yang ditangkap secara otomatis: tampilan halaman, klik elemen, interaksi formulir, unduhan file, dan — dalam rilis terbaru — pemutaran ulang sesi. Mereka juga akan memperkaya peristiwa-peristiwa tersebut dengan geolokasi berbasis IP, data perangkat berbasis agen pengguna, dan jika dikonfigurasi, pengayaan pihak ketiga dari mitra data.

Setiap langkah tersebut melibatkan dasar hukum persetujuan yang terpisah. Menyimpan pengenal perangkat adalah operasi penyimpanan-dan-akses berdasarkan Pasal 5(3) Direktif ePrivacy, yang memerlukan persetujuan sebelumnya, bebas, spesifik, terinformasi, dan tidak ambigu di Kawasan Ekonomi Eropa, Inggris Raya, dan yurisdiksi mana pun yang telah mengadopsi standar yang sama. Menangkap peristiwa perilaku yang terkait dengan pengenal tersebut adalah pemrosesan data pribadi berdasarkan GDPR. Pengayaan dengan data pihak ketiga memperkenalkan hubungan pengontrol kedua. CCPA dan CPRA mengklasifikasikan pemrosesan yang sama sebagai penjualan atau berbagi kecuali penerbit memiliki kontrak penyedia layanan dengan lingkup yang tepat dengan Amplitude — yang tersedia, tetapi hanya jika integrasi dikonfigurasi untuk menonaktifkan fitur periklanan.

Apa yang dikumpulkan Amplitude sebelum persetujuan — dan apa yang harus ditekan

Kesalahan implementasi paling umum adalah memperlakukan Amplitude sebagai alat analitik ringan yang dapat berjalan berdampingan dengan spanduk cookie. Tidak bisa. Pada panggilan amplitude.init() default, SDK akan, dalam paint pertama halaman, menulis setidaknya satu entri cookie atau penyimpanan lokal, mengirim panggilan identify, dan mulai menyangga peristiwa. Tidak ada yang diizinkan sebelum pengguna menerima kategori persetujuan yang relevan secara afirmatif.

Oleh karena itu, integrasi yang patuh harus menunda amplitude.init() hingga CMP telah memberi sinyal bahwa kategori persetujuan analitik telah diberikan. SDK tidak boleh dimuat sama sekali dari tag <script> yang bergantung pada persetujuan yang bergantung pada sinyal tujuan 8 CMP (analitik) atau tujuan 1 (penyimpanan dan akses), tergantung pada kerangka mana yang diekspos CMP. Jika SDK harus dimuat lebih awal — misalnya karena dibundel ke dalam kode aplikasi dan tidak dapat diambil secara malas — panggilan inisialisasi harus meneruskan defaultTracking: false dan optOut: true sehingga tidak ada peristiwa yang dipancarkan sampai persetujuan direkam, lalu peristiwa opt-in yang ditangguhkan harus membalik bendera-bendera tersebut.

Cookie dan penyimpanan yang ditulis Amplitude

SDK Browser 2.x menulis satu cookie pihak pertama bernama AMP_{apiKey} secara default, dengan kedaluwarsa satu tahun, berisi pengenal perangkat dan metadata sesi. Versi lama juga menulis amplitude_id_{apiKey}. SDK seluler mempertahankan pengenal yang sama di dalam penyimpanan sandbox aplikasi. Pemutaran ulang sesi menambahkan cookie kedua, AMP_MKTG_{apiKey}, dan mitra pengayaan Amplitude dapat menetapkan cookie pihak ketiga tambahan jika modul penargetan eksperimen atau audiens diaktifkan. Semua ini tidak esensial dan memerlukan persetujuan.

Memetakan Amplitude ke kerangka persetujuan

Amplitude tidak secara native mengimplementasikan Google Consent Mode v2, IAB TCF, atau IAB Global Privacy Platform. Itu bukan cacat — Amplitude adalah platform analitik pihak pertama, bukan vendor teknologi iklan — tetapi itu berarti tanggung jawab integrasi ada pada penerbit. Pola yang berhasil dalam praktik adalah memperlakukan setiap modul Amplitude sebagai gerbang persetujuan terpisah dan mengikatnya ke sinyal spesifik yang sudah diekspos CMP.

• Peristiwa analitik inti terikat pada tujuan analitik. Dalam istilah TCF, ini paling umum adalah tujuan 8 (mengukur kinerja konten) dikombinasikan dengan tujuan 1 (menyimpan dan/atau mengakses informasi). Untuk Google Consent Mode ini memetakan ke analytics_storage.
• Pemutaran ulang sesi harus berada di balik sinyal yang lebih ketat. Pemutaran ulang menangkap DOM yang dirender, termasuk nilai formulir kecuali disamarkan secara eksplisit, sehingga opt-in preferences atau functional yang terpisah sesuai, dan pemutaran ulang harus default ke nonaktif bahkan ketika analitik diberikan.
• Audiens, kohort, dan pengayaan pihak ketiga terikat pada tujuan pemasaran. Dalam istilah TCF ini adalah tujuan 7 (mengukur kinerja iklan) atau tujuan 9 (menerapkan riset pasar). Untuk Google Consent Mode ini memetakan ke ad_storage dan ad_user_data.
• Eksperimentasi — Amplitude Experiment dapat berjalan dengan alokasi anonim dan efemeral berdasarkan legitimate interest, tetapi alokasi persisten yang terikat pada pengenal pengguna memerlukan persetujuan yang sama dengan analitik inti.

Pola integrasi yang berhasil

Implementasi referensi yang bertahan dari tinjauan regulator memiliki empat bagian yang bergerak: CMP yang mengekspos peristiwa real-time ketika pengguna mengubah persetujuan, pemuat SDK yang ditangguhkan yang hanya mengambil Amplitude setelah peristiwa itu aktif untuk kategori yang relevan, penjaga tingkat sesi yang menghormati opt-out tanpa kehilangan pengenal perangkat anonim sebelumnya milik pengguna di mana hukum mengizinkan, dan jembatan sisi server untuk peristiwa yang benar-benar memerlukan pengumpulan terlepas dari persetujuan — seperti telemetri keamanan atau deteksi penipuan — yang dirutekan melalui titik akhir terpisah dengan dasar hukumnya sendiri.

Implementasi web

Di web, pola paling bersih adalah mengekspos status persetujuan CMP melalui objek window.__cmp_consent atau callback __tcfapi standar, lalu memiliki skrip bootstrap kecil yang berlangganan perubahan persetujuan. Ketika persetujuan analitik berubah dari false ke true, bootstrap mengambil Amplitude SDK dari CDN yang dikelola CMP, memanggil amplitude.init(apiKey, undefined, { defaultTracking: true }), dan memutar ulang peristiwa yang telah diantrekan dalam memori saat persetujuan tertunda. Ketika persetujuan berubah kembali ke false, bootstrap memanggil amplitude.setOptOut(true), menghapus cookie AMP_ melalui kedaluwarsa document.cookie, dan menghapus status dalam memori apa pun. Secara kritis, bootstrap tidak boleh pernah menginisialisasi Amplitude secara malas dalam alur permintaan yang sama dengan render spanduk — SDK harus menunggu pemberian eksplisit.

Implementasi seluler

Di iOS, padanannya adalah mempertahankan impor framework Amplitude tetapi menunda Amplitude.instance().initialize(apiKey: apiKey) hingga alur persetujuan dalam aplikasi telah mengembalikan sinyal analitik positif. Prompt ATT adalah masalah terpisah: ATT mengatur IDFA, sementara pengenal Amplitude adalah UUID SDK sendiri yang disimpan di sandbox aplikasi. Keduanya memerlukan persetujuan di EEA, tetapi dasar hukum dan promptnya berbeda. Di Android logika yang sama berlaku dengan Amplitude.getInstance().initializeApolloClient() atau padanannya tergantung pada versi SDK.

Mode sisi server

Amplitude mendukung penyerapan sisi server melalui HTTP V2 API. Peristiwa sisi server tidak dikecualikan dari persetujuan — dasar hukum mengikuti data, bukan transportnya — tetapi penyerapan sisi server memberi penerbit kontrol penuh atas bidang mana yang dikirim, yang membuatnya lebih mudah untuk menghormati persetujuan parsial. Pola umum adalah menangkap set peristiwa minimal hanya-esensial di sisi server berdasarkan legitimate interest, dan hanya memperkaya peristiwa-peristiwa tersebut dengan detail perilaku setelah pengguna memberikan persetujuan analitik di klien.

Memvalidasi integrasi

Langkah validasi adalah yang paling sering dilewati penerbit dan paling sering diperiksa regulator. Deployment Amplitude yang terintegrasi dengan benar harus lulus empat pemeriksaan. Pertama, browser dengan spanduk persetujuan ditampilkan tetapi belum ada pilihan yang dibuat harus menghasilkan nol permintaan ke api.amplitude.com atau api.eu.amplitude.com dan nol cookie AMP_ di document.cookie. Kedua, menolak kategori analitik harus mempertahankan keadaan tersebut — tidak ada peristiwa, tidak ada cookie, tidak ada entri penyimpanan lokal dengan awalan AMP_. Ketiga, menerima analitik harus menghasilkan satu identify diikuti oleh lalu lintas peristiwa, dan cookie AMP_ harus muncul dengan atribut SameSite yang konsisten dengan kebijakan CMP penerbit. Keempat, menarik kembali persetujuan setelahnya harus segera menghentikan peristiwa lebih lanjut dan menghapus pengenal yang disimpan — pembersihan yang tertunda adalah temuan.

Jejak audit penting secara terpisah. Berdasarkan panduan spanduk cookie EDPB 2023 dan prioritas satuan tugas 2026 yang diperbarui, regulator mengharapkan penerbit dapat membuktikan, untuk peristiwa mana pun dalam proyek Amplitude, bahwa pengguna yang menghasilkannya telah memberikan persetujuan yang valid pada saat pengambilan. Itu mengharuskan log persetujuan CMP dapat dikueri berdasarkan pengenal perangkat atau pengenal sesi, dan payload peristiwa Amplitude membawa bidang versi persetujuan yang menghubungkan kembali ke log tersebut. Menyimpan string persetujuan sebagai properti pengguna kustom pada setiap peristiwa adalah cara paling sederhana untuk membuat tautan tersebut dapat diaudit.

Memilih wilayah dan residensi data yang tepat

Amplitude mengoperasikan dua wilayah produksi: AS (api.amplitude.com) dan EU (api.eu.amplitude.com). Untuk lalu lintas EEA dan Inggris, wilayah EU adalah default yang tepat — wilayah ini menjaga data tetap berada di dalam EEA dan mengurangi permukaan risiko transfer yang telah menjadi pusat dari setiap tinjauan analitik oleh keputusan Schrems II dan EU-US Data Privacy Framework. Beralih wilayah tidak retroaktif: data yang ada tetap di tempat pertama kali dicerna. Bagi penerbit yang merencanakan peluncuran CMP, oleh karena itu worth mengonfirmasi wilayah sebelum scaling, dan worth mendokumentasikan pilihan tersebut dalam pemberitahuan privasi sehingga rantai dasar hukum bersih dari pengumpulan hingga penyimpanan. Wilayah yang dipilih dengan benar, dipasangkan dengan SDK yang dibatasi dengan benar dan log persetujuan yang dapat dikueri, adalah yang mengubah deployment Amplitude dari risiko regulasi menjadi bagian yang dapat dipertahankan dari tumpukan analitik.