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 |
|
GRP |
|
YOUTUBE_PROGRAMMATIC_GUARANTEED |
|
REACH |
|
UNIQUE_REACH_AUDIENCE |
|
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
bukanDONE
atauFAILED
, 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
bukanDONE
atauFAILED
, 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
bukanDONE
atauFAILED
, 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
bukanDONE
atauFAILED
, 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
bukanDONE
atauFAILED
, 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
.