Saat ini kami memigrasikan sebagian jenis laporan dari pelaporan offline ke pelaporan instan. Setelah pengguna dimigrasikan, respons queries.list akan menyertakan laporan instan yang sudah ada. Lihat postingan blog kami untuk informasi selengkapnya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Praktik Terbaik Pelaporan

Membuat laporan baru di UI terlebih dahulu

Laporan tunduk pada sejumlah batasan dan persyaratan yang berkaitan dengan jenis pelaporan, filter, dimensi, dan metrik. Batasan ini diterapkan di API, yang menampilkan error HTTP 400. Untuk menghindari error saat membuat laporan, sebaiknya buat laporan baru terlebih dahulu di UI Display & Video 360.

Setelah mem-build laporan, klik fitur"Coba API ini" di halaman dokumen referensi untuk melakukan queries.get resource Query. Anda dapat menggunakan JSON yang ditampilkan untuk membuat laporan di masa mendatang.

Menggunakan metrik dan filter khusus untuk jenis laporan

Beberapa nilai metrik dan filter khusus untuk jenis laporan tertentu. Selain membuat laporan di UI terlebih dahulu, Anda juga dapat mengidentifikasi metrik dan filter yang termasuk dalam nilai ReportType tertentu berdasarkan nilai Bid Manager API-nya.

Berikut beberapa cara untuk mengidentifikasi filter dan nilai metrik Bid Manager API yang relevan. Tabel ini bukanlah daftar lengkap filter dan metrik yang dapat digunakan dalam jenis laporan ini. Tidak semua nilai dapat digunakan bersama dalam satu laporan.

`ReportType`	Filter dan Metrik yang Relevan
`YOUTUBE`	Filter dengan awalan `FILTER_TRUEVIEW`. Metrik dengan awalan `METRIC_TRUEVIEW`.
`GRP`	Metrik dengan awalan `METRIC_GRP`.
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	Filter dengan awalan `FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED`. Metrik dengan awalan `METRIC_PROGRAMMATIC_GUARANTEED`.
`REACH`	Metrik dengan awalan `METRIC_UNIQUE_REACH`.
`UNIQUE_REACH_AUDIENCE`	Metrik dengan awalan `METRIC_UNIQUE_REACH`.

Menyimpan dan menggunakan kembali laporan

Sebaiknya buat dan simpan laporan untuk kueri yang Anda jalankan secara rutin karena menyisipkan dan menghapus laporan yang sama beberapa kali akan membuang resource. Menggunakan nilai Range yang ditetapkan, seperti PREVIOUS_DAY atau LAST_7_DAYS, di kolom dataRange akan membuat laporan lebih dapat digunakan kembali.

Menjadwalkan laporan

Laporan ad hoc atau satu kali dapat membuang-buang resource karena dijalankan secara terpisah dan dapat dijalankan pada set data yang tidak lengkap. Laporan terjadwal mengoptimalkan penggunaan resource pelaporan karena dijalankan secara massal dan dijamin tidak akan dieksekusi hingga data hari sebelumnya selesai diproses. Lihat kolom penjadwalan yang tersedia untuk mengetahui detailnya.

Menggabungkan laporan serupa

Jika Anda rutin membuat laporan dengan metrik dan rentang tanggal yang sama untuk pengiklan atau partner yang berbeda, sebaiknya Anda menggabungkan laporan untuk mengoptimalkan volume laporannya.

Anda dapat menggabungkan laporan serupa dengan menambahkan filter dari semua laporan dan menambahkan semua jenis filter sebagai dimensi. Setelah pembuatan, Anda dapat memisahkan baris laporan yang dihasilkan berdasarkan nilai filter asli untuk menghasilkan laporan asli.

Mempertimbangkan kuota pelaporan

Penggunaan fitur pelaporan Display & Video 360 yang bertanggung jawab diterapkan melalui kuota penggunaan seluruh produk berikut.

Eksekusi laporan ad hoc per hari

Membatasi jumlah laporan ad hoc yang dapat dijalankan pengguna dalam jangka waktu 24 jam. Agar tidak melebihi kuota ini:

Gabungkan laporan yang serupa untuk mengurangi volume laporan.
Jadwalkan laporan ad hoc berulang untuk secara khusus mengurangi volume laporan ad hoc.
Nonaktifkan skrip API yang tidak diperlukan.

Laporan terjadwal yang aktif

Membatasi jumlah laporan yang dapat dijadwalkan secara aktif oleh pengguna pada waktu tertentu. Agar tidak melebihi kuota ini:

Gabungkan laporan terjadwal yang serupa untuk mengurangi jumlah keseluruhan laporan terjadwal.
Nonaktifkan laporan terjadwal yang tidak perlu.
Nonaktifkan skrip API yang tidak diperlukan.

Laporan serentak

Membatasi jumlah laporan yang dapat dijalankan pengguna secara bersamaan. Agar tidak melebihi kuota ini:

Menjadwalkan laporan yang berjalan secara rutin.
Nonaktifkan skrip API yang tidak diperlukan.
Lacak kapan laporan Anda selesai dengan melakukan polling menggunakan logika backoff eksponensial.

Jika Anda telah mengoptimalkan penerapan pelaporan dan masih melebihi kuota yang diberikan, hubungi dukungan Display & Video 360 menggunakan formulir kontak.

Menggunakan backoff eksponensial saat melakukan polling untuk status laporan

Anda tidak dapat memprediksi berapa lama waktu yang diperlukan untuk menjalankan laporan. Durasi waktu dapat berkisar dari detik hingga jam, bergantung pada banyak faktor, misalnya, rentang tanggal dan jumlah data yang akan diproses. Tidak ada korelasi antara waktu proses laporan dan jumlah baris yang ditampilkan dalam laporan. Oleh karena itu, Anda perlu mengambil resource laporan secara rutin menggunakan metode queries.reports.get dan memeriksa apakah kolom metadata.status.state resource telah diperbarui ke DONE atau FAILED untuk menentukan apakah resource telah selesai berjalan. Ini adalah proses yang dikenal sebagai "polling".

Meskipun polling diperlukan, penerapan yang tidak efisien dapat dengan cepat menghabiskan kuota Anda saat menemukan laporan yang berjalan lama. Oleh karena itu, sebaiknya Anda menggunakan backoff eksponensial untuk membatasi percobaan ulang dan menghemat kuota.

Backoff eksponensial

Backoff eksponensial adalah strategi penanganan error standar untuk aplikasi jaringan, yang mana klien secara berkala mencoba lagi permintaan dengan menambah lamanya waktu antara setiap permintaan yang gagal. Jika digunakan dengan benar, backoff eksponensial akan meningkatkan efisiensi penggunaan bandwidth, mengurangi jumlah permintaan yang diperlukan untuk mendapatkan respons yang berhasil, dan memaksimalkan throughput permintaan dalam lingkungan serentak.

Alur untuk mengimplementasikan backoff eksponensial sederhana adalah sebagai berikut:

Buat permintaan queries.reports.get ke API.
Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, hal ini menunjukkan bahwa laporan belum selesai berjalan dan harus melanjutkan polling.
Tunggu 5 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, hal ini menunjukkan bahwa laporan belum selesai berjalan dan harus melanjutkan polling.
Tunggu 10 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, hal ini menunjukkan bahwa laporan belum selesai berjalan dan harus melanjutkan polling.
Tunggu 20 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, hal ini menunjukkan bahwa laporan belum selesai berjalan dan harus melanjutkan polling.
Tunggu 40 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, hal ini menunjukkan bahwa laporan belum selesai berjalan dan harus melanjutkan polling.
Tunggu 80 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
Lanjutkan pola ini hingga objek laporan diperbarui atau waktu maksimum yang berlalu tercapai.

Jika laporan selesai berjalan dan berakhir dalam status DONE, Anda dapat mengambil file laporan yang dihasilkan dari Google Cloud Storage di jalur yang diberikan di kolom metadata.googleCloudStoragePath.