Perlindungan privasi untuk laporan agregat

Layanan Agregasi membuat laporan ringkasan data konversi mendetail dan pengukuran jangkauan dari laporan gabungan mentah. Agar data pengguna tetap bersifat pribadi dan aman, Layanan Agregasi menggunakan framework yang mendukung privasi diferensial (DP) untuk mengukur dan membatasi jumlah informasi yang diungkapkan laporan ini tentang setiap pengguna.

Panduan ini membahas alat dan strategi untuk membuat laporan gabungan yang membantu menjaga keamanan data tentang setiap pengguna:

Laporan ringkasan dengan derau tambahan

Saat Anda mengelompokkan laporan gabungan, Layanan Agregasi akan membuat laporan ringkasan. Laporan ringkasan ini adalah gabungan dari semua kontribusi dari semua kunci domain standar, dengan derau statistik yang ditambahkan.

Derau yang ditambahkan ke laporan tidak bergantung pada jumlah laporan yang digabungkan, nilai laporan individual, atau nilai laporan gabungan. Derau diambil dari versi diskret distribusi Laplace, dan diskalakan ke anggaran kontribusi (sensitivitas L1) yang diterapkan oleh klien bergantung pada API pengukuran yang sesuai dan parameter privasi epsilon.

Untuk mempelajari derau dan implikasinya terhadap data laporan lebih lanjut, lihat Memahami derau dalam laporan ringkasan.

Anggaran kontribusi

Untuk mengontrol sensitivitas laporan ringkasan, jumlah kontribusi yang diteruskan dalam panggilan terikat dengan batas pembatas kontribusi tertentu, yang juga dikenal sebagai anggaran kontribusi. Anggaran kontribusi bervariasi bergantung pada apakah Anda menggunakan Attribution Reporting API atau Private Aggregation API.

Untuk mempelajari lebih lanjut cara menetapkan anggaran kontribusi untuk setiap API, lihat bagian dokumentasi API berikut:

Strategi untuk pengelompokan laporan

Saat Anda mengelompokkan laporan gabungan, penting untuk mengoptimalkan strategi pengelompokan agar batas privasi tidak terlampaui. Dua konsep penting untuk mengelompokkan laporan dengan benar adalah aturan"tidak ada duplikat" dan ide batch terpisah.

Aturan "Tidak ada duplikat"

Layanan Agregasi menerapkan aturan "tidak ada duplikat". Aturan ini menyatakan bahwa laporan gabungan, yang diidentifikasi secara unik oleh report_id, hanya dapat muncul satu kali dalam satu batch. Jika laporan gabungan muncul lebih dari sekali per batch, laporan pertama akan disertakan dalam agregasi, laporan berikutnya dengan report_id yang sama akan dihapus, dan batch berhasil diselesaikan.

Aturan ini juga menyatakan bahwa ID bersama yang sama tidak boleh muncul di lebih dari satu batch. Jika ID Bersama telah disertakan dalam batch sebelumnya yang berhasil, batch berikutnya yang juga menyertakan ID bersama yang sama akan gagal.

Laporan yang sama hanya dapat digunakan sekali per batch.
Gambar 1. Jika laporan muncul lebih dari sekali dalam batch, agregasi akan menyertakan instance pertama dan menghapus laporan berikutnya dengan ID yang sama.

Tanpa aturan "tidak ada duplikat", penyerang dapat memperoleh insight tentang konten batch tertentu dengan memanipulasi konten batch melalui penyertaan salinan duplikat laporan dalam satu batch atau beberapa batch.

Untuk mempelajari lebih lanjut cara menerapkan aturan "tidak ada duplikat" dalam batch laporan atau di beberapa batch, lihat Laporan duplikat dalam batch.

Batch terpisah

Untuk menghindari situasi ketika ada tumpang-tindih antar-batch, Layanan Agregasi menerapkan batch yang tidak tumpang-tindih. Artinya, dua batch atau lebih tidak dapat berisi laporan yang memiliki ID bersama yang sama. ID bersama adalah kombinasi data yang dikumpulkan dari kolom shared_info laporan agregat, bersama dengan ID pemfilteran dari permintaan tugas. Jika tidak ada ID pemfilteran yang ditentukan, nilai default 0 akan digunakan.

Pada contoh kolom shared_info berikut, Anda dapat melihat API, attribution_destination (untuk Pelaporan Atribusi), reporting_origin, scheduled_report_time, source_registration_time (untuk Pelaporan Atribusi), dan version. Kolom ini, kecuali report_id, bersama dengan ID pemfilteran dari permintaan tugas, berkontribusi pada ID bersama.

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://privacy-sandbox-demos-shop.dev",
  "report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
  "reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
  "scheduled_report_time": "1707786751",
  "source_registration_time": "0",
  "version": "0.1"
}

Karena source_registration_time terpotong berdasarkan hari dan scheduled_report_time terpotong berdasarkan jam, ada laporan yang memiliki ID bersama yang sama. Dalam contoh ini, Report1 dan Report2 memiliki kolom info bersama. Kedua laporan memiliki API, versi, attribution_destination, reporting_origin, dan source_registration_time yang sama. Karena report_id bukan bagian dari ID bersama, Anda dapat mengabaikan perbedaan ini.

Dalam contoh berikut untuk Report1 dan Report2, nilai scheduled_report_time sama.

Info yang dibagikan Report1:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Info yang dibagikan Report2:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Waktu laporan terjadwal adalah "19 Februari 2024 pukul 21.08.10" untuk Laporan1 dan "19 Februari 2024 pukul 21.55.10" untuk Laporan2. Karena nilai untuk kolom scheduled_report_time dipotong menjadi jam, kedua laporan memiliki 1708376890 (nilai yang dienkode untuk "19 Februari 2024 21.00") sebagai nilai untuk kolom scheduled_report_time.

Dengan semua kolom lain dan ID pemfilteran yang sama, kedua laporan memiliki ID bersama yang sama. Selain itu, karena kedua laporan memiliki ID bersama yang sama, keduanya harus disertakan dalam batch yang sama.

Jika Report1 dikelompokkan dalam batch yang sebelumnya berhasil dan Report2 diproses dalam batch berikutnya, batch dengan Report2 akan gagal dengan error PRIVACY_BUDGET_EXHAUSTED. Jika hal ini terjadi, hapus laporan dengan ID bersama yang telah berhasil dikelompokkan dalam batch sebelumnya, lalu coba lagi. Untuk informasi selengkapnya tentang error ini, lihat Kode error dan mitigasi untuk Layanan Agregasi.

Laporan dengan ID bersama yang sama harus disertakan dalam batch yang sama.
Gambar 2. Batch 2 berisi laporan yang memiliki ID bersama dengan laporan di Batch 1, sehingga Batch 2 gagal.

Kunci agregasi yang telah dideklarasikan sebelumnya

Saat Anda mengirimkan batch ke Layanan Agregasi, batch tersebut harus menyertakan laporan gabungan yang diterima dari asal pelaporan dan file domain output. Domain output berisi kunci, atau bucket, yang diambil dari laporan agregat.

Dari sudut pandang privasi, derau ditambahkan ke semua kunci yang telah dideklarasikan sebelumnya di domain output, meskipun tidak ada laporan nyata yang cocok dengan kunci tertentu. Menentukan domain output akan melindungi dari serangan yang kehadiran kuncinya dalam output mengungkapkan sesuatu tentang satu pengguna atau peristiwa. Misalnya, jika Anda hanya menampilkan kampanye kepada satu pengguna, menerima kunci dalam output akan mengungkapkan bahwa pengguna tersebut kemudian melakukan konversi, meskipun dengan derau yang ditambahkan. Dengan menentukan domain ini terlebih dahulu, Anda dapat memastikan bahwa domain tersebut tidak mengungkapkan apa pun tentang kontribusi pengguna.

Anda dapat mendeklarasikan kunci 128-bit ini di Attribution Reporting API atau Private Aggregation API dan menggunakannya untuk mengenkode dimensi yang ingin dilacak.

Hanya kunci yang telah dideklarasikan sebelumnya yang dipertimbangkan untuk agregasi dan disertakan dalam laporan ringkasan. Nilai gabungan bucket dalam laporan ringkasan memiliki derau statistik yang ditambahkan, yang tercermin dalam laporan ringkasan yang dibuat.

Batch privasi di Layanan Agregasi.
Gambar 3. Laporan ringkasan hanya berisi kunci yang telah dideklarasikan sebelumnya, yang juga dikenal sebagai bucket.

Jika kunci agregasi disertakan dalam file domain output, tetapi tidak berada dalam laporan batch, meskipun nilai gabungannya nol, laporan ringkasan akhir kemungkinan tidak nol karena derau yang ditambahkan untuk menjaga privasi.