Kebijakan Privasi Aplikasi Android: Panduan 2026

Anda sering paling dekat dengan rilis ketika masalah kebijakan privasi muncul. Bangunan hijau. QA menyetujui. Checklist Play Console tampaknya sudah selesai. Kemudian seseorang bertanya pertanyaan sederhana yang berubah menjadi penghalang: apa yang sebenarnya aplikasi ini kumpulkan, mana SDK yang menerima data, di mana itu disampaikan, dan apakah aliran dalam aplikasi sesuai dengan daftar?

Mengapa itu penting Kebijakan Privasi untuk Aplikasi Android cannot be treated like end-of-sprint legal copy. It is part of shipping. If your app uses analytics, ads, crash reporting, authentication, payments, location, camera, contacts, or even an added SDK, the policy has to line up with what the code does.

The problem gets sharper when teams ship fast. CI/CD, feature flags, staged rollouts, and live updates make app behavior change faster than traditional review cycles. If your policy still reflects last month’s data flows, you’re already behind.

Isi Kandungan

• Mengapa Kebijakan Privasi Aplikasi Android Anda Lebih Penting Daripada Sebelumnya
  • A penghalang rilis yang biasanya muncul terlambat
  • Kepercayaan bergantung pada akurasi operasional
• Menguraikan Kunci Privasi Regulasi dan Aturan Platform
  • Aturan Google Play adalah persyaratan produk
  • Apa yang berubah dari GDPR, CCPA, dan COPPA untuk tim aplikasi
  • Pandangan komplian yang praktis
• Cara Membuat Kebijakan Privasi dari Awal
  • Mulai dengan inventori data, bukan template
  • Tulis klausa dari perilaku aplikasi yang nyata
  • Apa yang biasanya terlewatkan
• Menerbitkan dan Menghubungkan Kebijakan Anda untuk Komplian
  • Tempatkan kebijakan di semua permukaan yang diperlukan
  • Bangun alur pengungkapan yang benar
• Challenge Live Update Mengapa Kebijakan Anda Synchronized
  • Mengapa kebijakan statis gagal dalam alur rilis cepat
  • Model Sinkronisasi yang Berfungsi untuk Tim CI/CD
  • Bagaimana Mengatasi Flag Fitur dan Rilis Segmen
• Menghadapi Masa Depan dengan Strategi Privasi yang Tidak Terkalahkan

Mengapa Kebijakan Privasi Aplikasi Android Anda Lebih Penting dari Sebelumnya

Penangguhan Rilis yang Biasanya Tiba Terlalu Lambat

Tim sering tidak mengabaikan pekerjaan kebijakan privasi dengan sengaja. Mereka menunda karena aplikasi terkesan sebagai pekerjaan utama. Lalu minggu rilis tiba, dan tim menemukan bahwa kebijakan tidak hanya hilang. Kebijakan tersebut tidak lengkap, tidak sinkron dengan SDK perilaku, atau tidak konsisten dengan diskusi toko dan permintaan izin.

Mengapa itu berisiko karena ekosistem telah menunjukkan kualitas pengungkapan yang tidak seimbang. Sebuah studi menganalisis 50.000 aplikasi seluler menemukan bahwa lebih dari 77% mengalirkan data sensitif, dan itu mencatat bahwa aplikasi Android sering mengabaikan pengungkapan data keselamatan eksplisit, menurut Ringkasan Zimperium dari penelitian.

Saat itu terjadi, kebijakan privasi tidak lagi sebagai dokumen dan menjadi masalah kualitas rilis. Produk memiliki janji. Teknik memiliki implementasi. Kepatuhan memiliki defensibilitas. Jika ketiga hal tersebut tidak berbaris, seseorang akhirnya menebak.

Kepercayaan bergantung pada akurasi operasional

Pengguna tidak membaca setiap paragraf kebijakan, tetapi mereka mengamati kesalahan. Jika aplikasi meminta lokasi pada pertama kali peluncuran tanpa konteks yang jelas, atau aplikasi utilitas yang tampak sederhana mencapai kontak atau aktivitas perangkat, orang-orang menganggap yang terburuk. Mereka sering tidak salah untuk melakukan itu.

Kebijakan privasi yang solid untuk aplikasi android melakukan tiga pekerjaan sekaligus:

• Menggunakan distribusi mengatur diri dengan persyaratan dan harapan tinjauan toko aplikasi.
• Mengatur disiplin internal karena tim harus mendokumentasikan apa yang code dan SDKs lakukan.
• Mengurangi kejutan untuk pengguna ketika izin, pelacakan, dan fitur akun muncul di aplikasi.

Aturan praktis: Jika tim ahli tidak bisa menjelaskan aliran data dalam satu kalimat, maka kebijakan akan hampir selalu tidak jelas, tidak akurat, atau keduanya.

Praktik rilis cepat membuat hal ini lebih sulit. Rilis native mingguan adalah satu hal. Pipa yang dapat mengubah JavaScript, aset, konfigurasi, dan pengecualian fitur di produksi adalah hal lain. Dalam konfigurasi tersebut, kebijakan yang ditulis sekali dan dilupakan menjadi ketinggalan zaman dengan cepat. Bagian ini dari panduan ini berfokus pada cara menghindari pergeseran tersebut.

Menguraikan Regulasi Privasi Utama dan Aturan Platform

Aturan Google Play adalah persyaratan produk

Untuk tim Android, permukaan komplian yang paling langsung adalah Google Play. Google’s Bab Data Keamanan mengatur bagaimana pengembang menjelaskan praktik data pada daftar aplikasi. Google mengatakan pengembang harus mengungkapkan bagaimana aplikasi mengumpulkan, berbagi, dan mengolah berbagai jenis data, dan aplikasi harus meminta izin sebelum mengakses data tertentu setelah diunduh, seperti yang dijelaskan dalam panduan keamanan data Google Play.

Perubahan ini mengubah percakapan di dalam tim. Privasi bukan hanya halaman hukum yang dipasang di situs web Anda. Ini juga metadata pada daftar aplikasi, perilaku izin pada waktu eksekusi, dan jalur code yang sebenarnya yang mengumpulkan atau berbagi data. Jika salah satu dari itu berbeda, Anda telah menciptakan ketidaksesuaian yang dapat dilihat oleh pengguna dan pemeriksa.

Google Play harus dianggap seperti spesifikasi produk. Daftar, permintaan izin, kebijakan, dan perilaku waktu pelaksanaan harus menjelaskan aplikasi yang sama.

Tim yang sering mengirimkan aplikasi juga harus memperhatikan disiplin perilaku rilis di permukaan kebijakan dan deklarasi toko. Referensi operasional yang berguna adalah panduan ini untuk kepatuhan Google Play dan strategi pembaruanterutama jika proses rilis Anda sudah bergantung pada otomatisasi.

Apa yang berubah untuk tim aplikasi karena GDPR, CCPA, dan COPPA

kerangka hukum yang berlaku karena mereka mengubah apa yang perlu Anda jelaskan dan apa yang dikontrol oleh pengguna.

GDPR mendorong tim untuk lebih presisi tentang tujuan. “Kami mengumpulkan data analitik untuk meningkatkan aplikasi” sering terlalu luas sendiri. Anda perlu tahu acara mana, prosesor mana, logika penyimpanan mana, dan apakah salah satunya mendukung profil atau iklan.

CCPA dan CPRA memaksa berpikir lebih jelas tentang kategori dan pengiriman data. Jika stack monetisasi atau alat ukur Anda menggerakkan data ke vendor lain, kebijakan Anda harus menjelaskan hubungan tersebut dalam bahasa yang sederhana.

COPPA adalah tempat di mana banyak tim harus berhenti dan mendapatkan tinjauan hukum spesialis. Jika produk mengarahkan anak-anak, penggunaan kembali template aplikasi konsumen umum secara santai adalah langkah yang buruk.

Pengambilan kesimpulan yang paling penting: terungkap berdasarkan proses yang sebenarnya, bukan berdasarkan apa yang terdengar minimal.

Untuk tim yang beroperasi di berbagai wilayah, membantu untuk mengikuti perubahan harapan privasi internasional dalam satu tempat. Ringkasan ini tentang רגולציית פרטיות לעסקים בינלאומיים adalah referensi lintas batas yang berguna ketika aplikasi Android Anda melayani pasar yang berbeda.

A pandangan komplian praktis

Pengembang tidak perlu mengingat teks hukum. Mereka membutuhkan model yang berfungsi yang mengubah aturan menjadi keputusan pengiriman.

Gunakan daftar ini sebelum menyiapkan atau memperbarui kebijakan:

• Pengecekan pengumpulan. Daftar setiap kategori data pengguna dan perangkat yang dapat diakses oleh aplikasi atau SDK yang diintegrasikan.
• Pengecekan tujuan. Hubungkan setiap elemen data dengan fitur atau kebutuhan operasional yang saat ini ada.
• Pengecekan pengiriman. Nama setiap prosesor, penyedia infrastruktur, alat analisis, mitra iklan, atau alat dukungan yang menerima data.
• Pengecekan hak. Putuskan bagaimana pengguna meminta akses, penghapusan, perbaikan, atau perubahan persetujuan.
• Penyaringan audiens. Pastikan apakah aplikasi mencapai anak-anak, pengguna Eropa, pengguna California, atau lingkungan pelanggan yang diatur.

Menggunakan pendekatan ini lebih berguna daripada mencoba menulis halaman hukum panjang dari ingatan. Ini mengubah privasi menjadi sistem yang dapat Anda kelola.

Mengubah privasi menjadi sistem yang dapat dipertahankan.

Bagaimana Membuat Kebijakan Privasi dari Awal

Cara termudah untuk membuat kebijakan privasi untuk aplikasi android adalah dengan memulai dari perilaku, bukan template. Alur kerja yang praktis adalah untuk inventory every data type the app or its SDKs can access, map each data element to the feature that requires it, document every third party receiving the data, define security controls, and specify retention and deletionsebagaimana dijelaskan di , seperti yang dijelaskan dalam .

That order matters. If you begin with a template, you’ll write broad language and fill gaps with assumptions. If you begin with a data inventory, the document becomes specific enough to survive review from engineering, product, and legal.

Mulai inventaris Anda dengan kategori yang biasanya diabaikan oleh pengembang:

• pengumpulan data SDK seperti analitik, atribusi, mediasi iklan, pelaporan kegagalan, ulang rekaman sesi, obrolan dukungan, dan alat penipuan
• Input yang dikunci izin seperti lokasi, kamera, mikrofon, kontak, SMS, dan status telepon
• Data latar belakang dan data turunan termasuk aktivitas aplikasi, aplikasi yang diinstal, sinyal penggunaan perangkat, dan data terkait akun di berbagai layanan

Banyak tim menemukan draft kebijakan yang sebenarnya hanya setelah mereka memeriksa daftar dependensi.

Tulis klausa dari perilaku aplikasi yang nyata

Setelah inventori selesai, buatlah setiap bagian kebijakan dari spreadsheet atau sistem catatan yang sama. Jangan bertanya, “Apa yang biasanya dikatakan kebijakan privasi?” Tanyakan, “Apa yang dilakukan aplikasi ini hari ini?”

Struktur yang praktis seperti ini:

1. Data yang dikumpulkan
   Deskripsikan kategori dalam bahasa pengguna. Misalnya: informasi akun, data terkait pembayaran, lokasi, pesan dukungan, informasi perangkat, dan kejadian penggunaan.

2. Bagaimana kita menggunakan data Hubungkan penggunaan dengan fungsi produk. Autentikasi, pencegahan penipuan, dukungan pelanggan, analitik, pengiriman fitur, pembayaran, dan kewajiban hukum semua masuk di sini jika berlaku.

3. Bagian berbagi dengan pihak ketiga
   Identifikasi jenis vendor yang terlibat dan mengapa mereka menerima data. Hosting, analitik, pembayaran, pesan, dukungan pelanggan, dan pelaporan kegagalan adalah yang umum.

4. Keamanan dan retensi
   Jelaskan perlindungan secara kualitatif kecuali tim keamanan Anda telah menyetujui bahasa yang tepat. Beritahu berapa lama data disimpan atau kriteria yang digunakan untuk menentukan retensi.

5. Pilihan dan hak pengguna
   Termasuk kontrol akun, jalur penghapusan, pengaturan persetujuan, jalur kontak dukungan, dan penanganan hak daerah yang relevan.

Contoh gaya penulisan yang berguna:

Kami mengumpulkan informasi akun seperti alamat email dan detail login untuk membuat dan melindungi akun Anda. Kami juga mengumpulkan informasi penggunaan aplikasi untuk mengoperasikan fitur, mendiagnosis kesalahan, dan meningkatkan layanan. Jika Anda mengaktifkan fitur berbasis lokasi, kami mengumpulkan data lokasi hanya untuk fitur-fitur tersebut.

Itu lebih baik daripada salinan yang kabur karena menghubungkan data dengan fungsi.

Untuk tim yang meninjau contoh bagaimana perusahaan menggambarkan komitmen perlindungan data secara publik, Komitmen perlindungan data Formbricks adalah rujukan berguna untuk nada dan struktur. Jangan salinnya. Gunakan untuk mengkalibrasi kejelasan.

Praktik rekayasa terkait adalah mendokumentasikan aliran yang sama dalam catatan arsitektur aplikasi Anda. Panduan tentang menangani data pengguna di aplikasi Capacitor adalah komplement yang baik jika stack mobile Anda mencakup permukaan web dan native.

Yang biasanya terlewatkan

Gagal utama dalam membuat draft bukanlah kalimat buruk. Itu adalah aliran data yang hilang.

Kesalahan umum termasuk:

• Perilaku SDK yang disembunyikan. Aplikasi itu sendiri terlihat tidak berbahaya, tetapi sebuah library mengirimkan identifikasi, muatan kegagalan, atau data acara ke perangkat lain.
• Data akun yang digunakan kembali. Tim menggunakan informasi akun di layanan lain untuk dukungan, iklan, pencegahan penipuan, atau analitis tanpa memperjelas tujuan masing-masing.
• Keterlambatan penyimpananData dikumpulkan menurut kebijakan ini, tetapi tidak dijelaskan berapa lama data disimpan atau bagaimana proses penghapusan.
• Perubahan fiturProduk telah menghapus fitur beberapa bulan yang lalu, tetapi kebijakan masih menyebutkannya. Atau bahkan lebih buruk, alur baru telah diterapkan dan kebijakan tidak menangkapnya.

Kebijakan privasi yang baik lebih sedikit tentang kalimat hukum yang rapi dan lebih banyak tentang apakah peta teknis Anda sudah lengkap.

That’s why I prefer review ownership to be shared. Engineering verifies collection and sharing. Product verifies purpose and user-facing flow. Compliance or counsel verifies legal sufficiency. Any policy written by only one of those groups is usually incomplete.

Menerbitkan dan Menghubungkan Kebijakan Anda untuk Kepatuhan

A privacy policy document sitting in Notion or Google Docs does nothing for compliance. Users and reviewers need to be able to access it in the right places, and the app’s consent flow has to happen before collection starts.

Google-style rules make this explicit. A policy link alone isn’t enough if the app collects personal or sensitive user data. The policy must be visible on the store listing and in-app, and collection must not begin before affirmative consent. Back or home navigation doesn’t count as consent, according to Tim pengembangan harus secara umum menerbitkan kebijakan di tiga tempat: .

Tetapkan kebijakan di semua permukaan yang diperlukan

Tim development harus umumnya menerbitkan kebijakan tersebut di tiga tempat:

• URL Web Publik. Tampilkan di halaman stabil yang Anda kendalikan. Hindari dokumen sementara, ruang kerja pribadi, atau URL yang mungkin berubah setelah merancang ulang.
• Daftar Penerbitan Google Play. Tambahkan URL publik yang sama di bidang yang relevan di Console Play.
• Titik Akses Aplikasi. Tempatkan di tempat yang pengguna dapat mencapai tanpa harus mencari, biasanya Pengaturan, Akun, Tentang, atau Privasi.

Jika aplikasi memiliki alur pendaftaran, pembayaran, atau alur izin yang berat, tambahkan tautan kontekstual di sana juga. Pengguna tidak harus mencari melalui menu untuk memahami mengapa izin diminta.

Bangun Alur Pengungkapan dengan Benar

. Alur waktu eksekusi berperan sebesar alur yang dihosting. Jika aplikasi mengakses data sensitif, pola harus seperti ini:

1. Tampilkan pengungkapan yang jelas di dalam aplikasi.
2. Jelaskan apa data yang terlibat dan mengapa.
3. Tanyakan untuk opt-in eksplisit.
4. Hanya setelah itu, aktifkan API atau SDK yang relevan.

Aliran yang lemah terlihat seperti ini: instal aplikasi, SDK diinisialisasi, pengumpulan data dimulai pada peluncuran, dan halaman privasi ada di tempat dalam pengaturan. Itu adalah jenis kesalahan implementasi yang tepat yang menciptakan masalah.

Langkah-langkah ini patut direview bersama tim teknik dan produk:

Beberapa kesalahan publikasi muncul secara berulang:

• Tautan toko mengarah ke halaman utama bukan ke kebijakan itu sendiri.
• Tautan dalam aplikasi hanya ada setelah loginmeskipun pengumpulan data dimulai lebih awal.
• Penyataan transparansi diintegrasikan ke dalam teks syarat bukan spesifik untuk pengumpulan sensitif.
• Konsentasi dianggap diimplikasikan oleh lanjutan bukan melalui aksi afirmatif yang jelas.

Jika Anda hanya memperbaiki satu hal di sini, perbaiki urutan. Pengungkapan dan persetujuan harus terjadi sebelum pengumpulan, bukan setelahnya.

The Live Update Challenge Mengawasi Kebijakan Anda yang Synchronized

Mengapa kebijakan statis gagal dalam pipeline rilis cepat

Panduan privasi umum biasanya menjadi kurang berguna pada tahap tertentu. Ia memberitahu Anda apa yang harus ada dalam kebijakan privasi, tetapi tidak menjelaskan bagaimana menjaga keakuratan kebijakan ketika aplikasi Anda berubah di luar siklus tinjauan toko.

That gap is real. Existing guidance doesn’t answer how developers using live update platforms should handle compliance when shipping fixes without app store review. Open questions include whether policies must be updated before a live update deploys new data-handling code and what audit trail regulated teams need when updates modify data flows without store gatekeeping, as noted by Diskusi Free Privacy Policy tentang persyaratan kebijakan aplikasi Android.

Kebijakan statis mengasumsikan versi aplikasi yang stabil. CI/CD tidak bekerja seperti itu. Flag fitur, peluncuran tersegmentasi, konfigurasi remote, dan pengiriman bundle hidup dapat semua mengubah apa yang dilihat pengguna dan apa saja jalur data yang dieksekusi. Jika proses privasi Anda masih mengasumsikan "perbarui kebijakan ketika versi native berubah," Anda akan melewatkan perubahan material.

Model sinkronisasi yang berfungsi untuk tim CI/CD

Pemecahan masalah adalah menganggap privasi sebagai metadata rilis.

Setiap pembaruan yang dapat mempengaruhi koleksi, berbagi, penggunaan izin, atau tujuan data harus melewati pengecekan dampak privasi di pipa. Itu tidak berarti setiap rilis memerlukan tinjauan hukum. Artinya setiap rilis memerlukan klasifikasi.

Model yang praktis seperti ini:

Metode ini paling efektif ketika pipa rilis membawa metadata yang terstruktur. Misalnya: “menggunakan izin baru,” “menambahkan pihak ketiga SDK,” “mengubah logika penyimpanan,” “mengubah tujuan,” atau “tidak ada perubahan privasi.” Jika insinyur harus memilih satu sebelum menggabungkan atau mempromosikan rilis, Anda menciptakan akuntabilitas tanpa memperlambat setiap deploy.

Konsultasi operasional: Versi kebijakan seperti code, tautkan setiap revisi kebijakan yang dipublikasikan ke rilis atau saluran yang memperkenalkan perubahan, dan simpan catatan-catatan tersebut bersama.

Tim yang menggunakan pengiriman bundle hidup juga harus memahami mekanisme bagaimana update mendarat di perangkat. Penjelasan ini tentang bagaimana update hidup untuk Capacitor bekerja Membantu menjelaskan mengapa kebijakan sinkronisasi tidak boleh bergantung pada ulasan toko saja. Dalam prakteknya, salah satu pilihan untuk tim yang mengirimkan aplikasi Capacitor CapgoMengirimkan bundle web yang ditandatangani ke saluran dan menjaga kontrol versi dan peluncuran. Mekanisme-mekanisme tersebut berguna untuk memantau kebijakan jika Anda menerjemahkan identifikasi rilis ke revisi kebijakan.

Bagaimana mengatasi flag fitur dan peluncuran yang tersegmentasi

Flag fitur membuat pertanyaan yang sulit. Jika hanya beberapa pengguna yang menerima fitur pengumpulan data, apa yang harus dikatakan dalam kebijakan?

Langkah paling aman secara praktis adalah ini:

• Terapkan praktik pengumpulan data yang aktif untuk audiens yang menerima mereka. Jika sebuah kohort produksi mendapatkan aliran data baru, maka aliran tersebut harus ditutup sebelum atau ketika aliran tersebut aktif.
• Jangan menyembunyikan di balik code yang tidak aktif. Jika fitur ada di code tetapi tidak aktif di mana pun, catatnya secara internal, bukan sebagai pengumpulan pengguna wajah.
• Tautkan promosi ke aktivasi, bukan instalasi. Jika sebuah flag fitur mengaktifkan izin baru atau koleksi sensitif kemudian, tunjukkan pengungkapan dan dapatkan persetujuan pada titik aktivasi tersebut.
• Snapshot per saluran. Saluran beta, pengembangan, pelanggan bisnis, dan produksi dapat memerlukan snapshot kebijakan yang berbeda atau setidaknya catatan internal yang berbeda.

Apakah yang tidak berfungsi adalah satu kebijakan raksasa yang secara umum menyatakan bahwa aplikasi mungkin mengumpulkan hampir segala sesuatu di masa depan. Mungkin terasa lebih aman secara internal, tetapi itu memperlemah transparansi dan masih gagal ketika perilaku waktu eksekusi dan aliran persetujuan tidak sesuai dengan teks.

Untuk tim yang diatur, saya juga memerlukan tiga artefak untuk setiap perubahan privasi yang terkait dengan materi: perbedaan code, perbedaan kebijakan yang disetujui, dan perubahan pengungkapan yang dihadapi pengguna. Tanpa itu, rekonstruksi audit menjadi sangat menyakitkan.

Menghadapi Masa Depan dengan Strategi Privasi yang Tidak Terlupakan

Kebijakan privasi yang kuat untuk aplikasi android adalah proses pemeliharaan, bukan tugas satu kali. Tim masuk ke dalam kesulitan ketika mereka menganggapnya sebagai teks hukum yang dipasang di akhir persiapan rilis daripada rekaman operasional dari apa yang dilakukan aplikasi.

Sikap yang tahan lama adalah sederhana:

• Daftar aliran data sebelum menulis
• Peta setiap jenis data ke fitur atau tujuan yang hidup
• Ulas setiap SDK dan vendor, bukan hanya code pertama-tama
• Publikasikan kebijakan di mana pengguna dan Google mengharapkannya
• Batasi pengumpulan sensitif di belakang pengungkapan yang jelas dan persetujuan eksplisit
• Versi perubahan kebijakan bersamaan dengan perubahan rilis
• Tambahkan periksa privasi ke CI/CD, flag fitur, dan live update aliran

Diskiplin ini membuat lebih dari sekadar kesetaraan. Ini membuat rilis lebih mudah dipahami, memperhalus keputusan produk, dan memberikan tim dukungan dan keamanan jawaban yang dapat dibela ketika pengguna bertanya apa saja yang dikumpulkan aplikasi dan mengapa.

Tangani privasi sebagai bagian dari teknik rilis. Tim yang melakukannya mengirimkan aplikasi yang lebih bersih.

Jika tim Anda mengirimkan Capacitor atau aplikasi Electron dan membutuhkan perubahan kebijakan privasi untuk tetap sejalan dengan pembaruan produksi yang cepat, Capgo bernilai untuk dievaluasi sebagai bagian dari alur kerja tersebut. Ini memberikan tim pembaruan hidup yang terkendali, riwayat versi, pengelolaan rilis berdasarkan saluran, dan observabilitas rilis, yang dapat membantu menghubungkan perubahan perilaku aplikasi dengan pengungkapan dan perubahan kebijakan daripada meninggalkan kesetaraan pada ingatan manual.

Ditulis dengan Alat Outrank

Teruskan dari Kebijakan Privasi untuk Aplikasi Android: Panduan 2026

Jika Anda menggunakan Kebijakan Privasi untuk Aplikasi Android: Panduan 2026 untuk merencanakan keamanan dan kesetaraan, hubungkannya dengan Enkripsi untuk detail implementasi di Enkripsi, Kepatuhan untuk detail implementasi di Kepatuhan, Capgo Scanner Keamanan untuk alur kerja produk di Capgo Scanner Keamanan, Capgo Keamanan untuk alur kerja produk di Capgo Keamanan, dan Capgo Pusat Kepercayaan untuk alur kerja produk di Capgo Pusat Kepercayaan.