Saat mengelompokkan laporan gabungan, penting untuk mengoptimalkan strategi pengelompokan agar batas privasi tidak terlampaui. Berikut adalah beberapa strategi yang direkomendasikan untuk mengirim batch laporan ke Layanan Agregasi.
Mengumpulkan laporan
Saat mengumpulkan laporan untuk disertakan dalam batch, perhatikan hal berikut:
Melaporkan percobaan ulang upload
Catatan: Kriteria percobaan ulang dapat berubah sewaktu-waktu. Dalam hal ini, informasi di bagian ini akan diperbarui.
Di platform web dan OS, platform akan mencoba mengirim laporan tiga kali, tetapi jika
laporan gagal dikirim setelah percobaan ketiga, laporan tidak akan dikirim. Nilai scheduled_report_time
asli dipertahankan, terlepas dari kapan laporan dapat dikirim. Linimasa
untuk percobaan ulang berbeda-beda per platform:
- Browser web akan mengirim laporan saat browser online. Jika laporan gagal dikirim, laporan akan menunggu lima menit untuk percobaan kedua, lalu 15 menit untuk percobaan ketiga. Jika browser menjadi offline, percobaan berikutnya akan dilakukan satu menit setelah browser kembali online. Tidak ada penundaan maksimum untuk mengirim laporan di web. Artinya, jika browser offline, terlepas dari berapa lama laporan dibuat, setelah browser kembali online, browser akan mencoba mengirim laporan sesuai dengan kebijakan percobaan ulang.
- Ponsel Android memiliki koneksi jaringan yang konsisten. Dengan demikian, sistem akan menjalankan tugas untuk mengirim laporan sekali per jam. Artinya, jika laporan gagal dikirim, laporan tersebut akan dicoba lagi pada jam berikutnya, dan lagi pada jam berikutnya. Jika perangkat tidak memiliki koneksi, perangkat akan mencoba lagi mengirimkan laporan dengan tugas pelaporan berikutnya yang berjalan setelah perangkat terhubung ke jaringan lagi. Penundaan maksimumnya adalah 28 hari, yang berarti perangkat tidak akan mengirimkan laporan yang dibuat lebih dari 28 hari yang lalu.
Menunggu laporan
Sebaiknya tunggu laporan yang terlambat saat mengumpulkan laporan untuk pengelompokan. Laporan
terlambat dapat ditentukan dengan memeriksa nilai scheduled_report_time terhadap saat laporan
diterima. Perbedaan waktu antara laporan tersebut akan membantu menentukan berapa lama Anda mungkin ingin menunggu laporan yang terlambat. Misalnya, saat laporan yang tertunda dikumpulkan, periksa
kolom scheduled_report_time dan catat keterlambatan waktu dalam jam saat 90%, 95%, dan 99% laporan
diterima. Data tersebut dapat digunakan untuk menentukan berapa lama harus menunggu laporan yang terlambat.
Laporan gabungan instan
dapat digunakan untuk mengurangi kemungkinan laporan tertunda.
Visual berikut menunjukkan laporan yang terlambat disimpan dalam batch yang sesuai sesuai
dengan waktu laporan terjadwal. Batch T mewakili scheduled_report_time, dan T+X mewakili waktu tunggu
untuk laporan yang tertunda. Tindakan ini akan menghasilkan laporan ringkasan yang menyertakan sebagian besar laporan yang
disertakan dalam batch yang sesuai dengan waktu laporan terjadwalnya.
Akuntansi laporan agregat
Layanan Agregasi mempertahankan aturan"tidak ada duplikat". Aturan ini mewajibkan semua laporan Agregat dengan ID bersama yang sama harus disertakan dalam batch yang sama.
Setelah dikumpulkan, laporan harus dikelompokkan sedemikian rupa sehingga semua laporan dengan ID bersama yang sama menjadi bagian dari satu batch.
Jika laporan telah diproses dalam batch lain, pemrosesan dapat mengakibatkan error anggaran privasi habis. Membuat laporan secara massal dengan benar akan membantu mencegah batch ditolak karena aturan "tidak ada duplikat".
ID bersama adalah kunci yang dibuat untuk setiap laporan guna melacak pencatatan laporan agregat. ID bersama memastikan bahwa laporan dengan ID bersama yang sama hanya berkontribusi pada satu laporan ringkasan. Artinya, laporan yang dipetakan ke satu ID bersama harus disertakan dalam satu batch. Misalnya, jika Laporan X dan Laporan Y memiliki ID bersama yang sama, keduanya harus disertakan dalam batch yang sama untuk menghindari laporan yang dihapus karena duplikat.
Gambar berikut menunjukkan komponen shared_info yang di-hash bersama untuk menghasilkan ID bersama.
Gambar berikut menunjukkan cara dua laporan yang berbeda dapat memiliki ID bersama yang sama:
Catatan: scheduled_report_time terpotong berdasarkan jam, dan source_registration_time terpotong berdasarkan
hari. Selain itu, report_id tidak digunakan dalam pembuatan ID bersama. Tingkat perincian waktu dapat diperbarui pada masa mendatang.
Laporan duplikat dalam batch
Kolom shared_info dalam laporan agregat berisi UUID di kolom report_id, yang
digunakan untuk mengidentifikasi laporan duplikat dalam batch. Jika ada lebih dari satu laporan dengan
report_id yang sama dalam satu batch, hanya laporan pertama yang akan digabungkan, dan laporan lainnya akan dianggap
duplikat dan dihapus secara otomatis; agregasi akan berlanjut seperti biasa dan tidak ada error yang akan dikirim.
Meskipun tidak diperlukan, teknologi iklan dapat mengharapkan beberapa peningkatan performa dengan memfilter
laporan duplikat dengan ID laporan yang sama sebelum agregasi.
report_id bersifat unik untuk setiap laporan.
Laporan duplikat di seluruh batch
Setiap laporan diberi ID bersama, yang merupakan ID yang dihasilkan dari titik data gabungan yang berasal
dari kolom shared_info laporan. Beberapa laporan dapat memiliki ID bersama yang sama, dan setiap batch
dapat berisi beberapa ID bersama. Semua laporan dengan ID bersama yang sama harus berada dalam batch yang sama. Jika
laporan dengan ID bersama yang sama berakhir dalam beberapa batch, hanya batch pertama yang akan diterima,
dan laporan lainnya akan ditolak sebagai duplikat. Untuk mencegah hal ini, batch harus dibuat dengan tepat.
Gambar berikut menunjukkan contoh saat laporan dengan ID bersama yang sama di seluruh batch dapat menyebabkan
batch berikutnya gagal. Pada gambar, Anda dapat melihat bahwa dua laporan atau lebih dengan ID bersama yang sama
e679aa dikelompokkan ke dalam batch yang berbeda #1 dan #2. Karena anggaran untuk semua laporan dengan ID bersama
e679aa digunakan selama pembuatan laporan ringkasan Batch #1, Batch #2 tidak diizinkan dan gagal dengan
error.
Laporan batch
Berikut adalah cara yang direkomendasikan untuk membuat laporan secara massal guna menghindari duplikat dan mengoptimalkan pencatatan laporan gabungan.
Mengelompokkan menurut pengiklan
Catatan: Strategi ini hanya direkomendasikan untuk agregasi Pelaporan Atribusi.
Agregasi Pribadi tidak memiliki kolom attribution_destination, yang merupakan pengiklan. Sebaiknya kelompokkan berdasarkan pengiklan, yang berarti menyertakan laporan milik satu pengiklan dalam batch yang sama, agar tidak mencapai batas akun laporan agregat untuk setiap batch. Pengiklan adalah
kolom yang dipertimbangkan dalam pembuatan ID bersama sehingga laporan dengan pengiklan yang sama juga dapat memiliki
ID bersama yang sama, yang mengharuskan mereka berada dalam batch yang sama untuk menghindari error.
Mengelompokkan menurut waktu
Sebaiknya pertimbangkan waktu laporan terjadwal laporan (shared_info.scheduled_report_time) saat mengelompokkan. Waktu laporan terjadwal dipotong menjadi jam
dalam pembuatan ID bersama, sehingga laporan minimum harus dikelompokkan per interval jam, yang berarti
semua laporan dengan waktu laporan terjadwal dalam jam yang sama harus berada dalam batch yang sama untuk menghindari
laporan dengan ID bersama yang sama di beberapa batch, yang akan menyebabkan error tugas.
Frekuensi dan derau batch
Sebaiknya pertimbangkan dampak derau terhadap frekuensi pemrosesan laporan gabungan. Jika laporan gabungan digabungkan lebih sering, misalnya, laporan diproses sekali dalam satu jam, lebih sedikit peristiwa konversi yang akan disertakan dan derau akan memiliki dampak relatif yang lebih besar. Jika frekuensinya dikurangi dan laporan diproses seminggu sekali, derau akan memiliki dampak relatif yang lebih kecil. Untuk lebih memahami dampak derau pada batch, lakukan eksperimen dengan Noise Lab.