Saat membuat batch laporan yang dapat diagregasi, penting untuk mengoptimalkan strategi pembuatan batch 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-hal berikut:
Coba lagi upload laporan
Catatan: Kriteria percobaan ulang dapat berubah. Informasi di bagian ini akan diperbarui dalam kasus tersebut.
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, kapan pun laporan dapat dikirim. Linimasa untuk percobaan ulang berbeda-beda di setiap platform:
- Browser web akan mengirim laporan saat browser online. Jika gagal dikirim, laporan akan menunggu lima menit untuk percobaan ulang kedua, lalu 15 menit untuk percobaan ulang ketiga. Jika browser offline, percobaan ulang berikutnya akan dilakukan satu menit setelah browser kembali online. Tidak ada penundaan maksimum dalam mengirim laporan di web; artinya, jika browser offline, berapa pun lamanya laporan dibuat, setelah browser kembali online, browser akan mencoba mengirim laporan sesuai dengan kebijakan percobaan ulang.
- Ponsel Android memiliki koneksi jaringan yang stabil. Oleh karena itu, tugas akan dijalankan untuk mengirim laporan sekali per jam. Artinya, jika laporan gagal dikirim, laporan akan dicoba dikirim lagi pada jam berikutnya, dan lagi pada jam setelahnya. Jika perangkat tidak memiliki koneksi, perangkat akan mencoba lagi mengirim laporan dengan tugas pelaporan berikutnya yang berjalan setelah perangkat terhubung ke jaringan lagi. Penundaan maksimum adalah 28 hari, yang berarti perangkat tidak akan mengirim laporan yang dibuat lebih dari 28 hari yang lalu.
Menunggu laporan
Sebaiknya tunggu laporan yang terlambat tiba saat mengumpulkan laporan untuk pengelompokan. Laporan
terlambat dapat ditentukan dengan memeriksa nilai scheduled_report_time terhadap waktu laporan
diterima. Perbedaan waktu antara laporan tersebut akan membantu menentukan berapa lama Anda harus menunggu laporan yang terlambat tiba. Misalnya, saat laporan yang tertunda dikumpulkan, periksa kolom
scheduled_report_time dan catat penundaan waktu dalam jam saat 90%, 95%, dan 99% laporan
diterima. Data tersebut dapat digunakan untuk menentukan durasi tunggu laporan yang terlambat tiba.
Laporan gabungan instan
dapat digunakan untuk mengurangi kemungkinan laporan tertunda.
Visual berikut menunjukkan laporan yang terlambat tiba dan disimpan dalam batch yang sesuai berdasarkan
waktu laporan terjadwal. Batch T merepresentasikan scheduled_report_time, dan T+X merepresentasikan waktu tunggu
untuk laporan yang tertunda. Hal ini menghasilkan laporan ringkasan yang mencakup sebagian besar laporan yang disertakan dalam batch yang sesuai dengan waktu laporan terjadwalnya.
Akuntansi laporan agregat
Layanan Agregasi mempertahankan "aturan tanpa duplikat". Aturan ini memastikan bahwa semua laporan yang Dapat Digabungkan dengan ID bersama yang sama harus disertakan dalam batch yang sama.
Setelah laporan dikumpulkan, laporan tersebut harus dikelompokkan sedemikian rupa sehingga semua laporan dengan ID bersama yang sama menjadi bagian dari satu kelompok.
Jika laporan telah diproses dalam batch lain, pemrosesan dapat menghasilkan error anggaran privasi habis. Mengelompokkan laporan dengan benar membantu mencegah penolakan batch karena aturan "tidak ada duplikat".
ID bersama adalah kunci yang dibuat untuk setiap laporan guna melacak akuntansi laporan yang dapat diagregasi. 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 bersama 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 dihapus karena duplikasi.
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 dipangkas per jam, dan source_registration_time dipangkas per
hari. Selain itu, report_id tidak digunakan dalam pembuatan ID bersama. Perincian waktu dapat diperbarui pada masa mendatang.
Duplikasikan laporan dalam batch
Kolom shared_info dalam laporan yang dapat diagregasi 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 batch, hanya laporan pertama yang akan digabungkan, dan laporan lainnya akan dianggap
duplikat dan dihapus tanpa pemberitahuan; penggabungan akan dilanjutkan seperti biasa dan tidak ada error yang akan dikirim.
Meskipun tidak diwajibkan, teknologi iklan dapat mengharapkan beberapa peningkatan performa dengan memfilter laporan duplikat dengan ID laporan yang sama sebelum penggabungan.
report_id bersifat unik untuk setiap laporan.
Duplikasikan laporan di seluruh batch
Setiap laporan diberi ID bersama, yaitu ID yang dibuat dari gabungan titik data 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 di beberapa batch, hanya batch pertama yang akan diterima,
dan batch 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. Dalam gambar, Anda dapat melihat bahwa dua laporan atau lebih dengan ID bersama yang sama
e679aa dikelompokkan ke dalam batch #1 dan #2 yang berbeda. 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 batch laporan guna menghindari duplikat dan mengoptimalkan akuntansi laporan gabungan.
Batch menurut pengiklan
Catatan: Strategi ini hanya direkomendasikan untuk agregasi Pelaporan Atribusi.
Agregasi Pribadi tidak memiliki kolom attribution_destination, yang merupakan pengiklan. Sebaiknya lakukan pengelompokan menurut pengiklan, yang berarti menyertakan laporan milik satu pengiklan dalam batch yang sama, untuk menghindari batas akun laporan yang dapat diagregasi 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 laporan tersebut berada dalam batch yang sama untuk menghindari error.
Batch menurut waktu
Sebaiknya pertimbangkan waktu laporan terjadwal laporan (shared_info.scheduled_report_time) saat membuat batch. Waktu laporan terjadwal dipersingkat menjadi per jam
dalam pembuatan ID bersama, jadi minimal laporan harus dikelompokkan dalam interval per jam, yang berarti
semua laporan dengan waktu laporan terjadwal dalam jam yang sama harus masuk 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 seberapa sering laporan yang dapat digabungkan diproses. Jika laporan agregat dikelompokkan lebih sering-misalnya, laporan diproses sekali per jam-lebih sedikit peristiwa konversi yang akan disertakan dan derau akan memiliki dampak relatif yang lebih besar. Jika frekuensi dikurangi dan laporan diproses seminggu sekali, derau akan memiliki dampak relatif yang lebih kecil. Untuk lebih memahami dampak derau pada batch, bereksperimenlah dengan Noise Lab.