Praktik Terbaik Pelaporan

Membuat laporan baru di UI terlebih dahulu

Laporan memiliki 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 membuat laporan, klik fitur"Coba API ini" di halaman dokumen referensi untuk menjalankan queries.get resource Query. Anda dapat menggunakan JSON yang ditampilkan untuk membuat laporan selanjutnya.

Peringatan: Kueri dan laporan yang dihasilkannya hanya dapat diakses di API oleh pengguna yang membuatnya. Izin untuk menjalankan kueri dan mengambil laporan menggunakan API tidak dapat diberikan melalui setelan berbagi UI.

Menggunakan metrik dan filter khusus untuk jenis laporan

Beberapa nilai metrik dan filter bersifat 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 adalah beberapa cara untuk mengidentifikasi filter dan nilai metrik Bid Manager API yang relevan. Tabel ini bukan 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
INVENTORY_AVAILABILITY	Filter dengan awalan FILTER_TRUEVIEW_IAR.
YOUTUBE	Filter dengan awalan FILTER_TRUEVIEW, tidak termasuk filter dengan awalan FILTER_TRUEVIEW_IAR. 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-buang 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 memboroskan resource karena dijalankan secara terpisah dan dapat dijalankan terhadap set data yang tidak lengkap. Laporan terjadwal memanfaatkan resource pelaporan sebaik mungkin karena dijalankan secara massal dan dijamin tidak akan dijalankan hingga data hari sebelumnya selesai pemrosesan. Lihat kolom penjadwalan yang tersedia untuk mengetahui detailnya.

Menggabungkan laporan serupa

Jika Anda secara rutin membuat laporan dengan metrik dan rentang tanggal yang sama untuk berbagai pengiklan atau partner, sebaiknya gabungkan laporan tersebut untuk mengoptimalkan volume laporan mereka.

Anda dapat menggabungkan laporan serupa dengan menambahkan filter semua laporan dan menambahkan semua jenis filter sebagai dimensi. Setelah pembuatan, Anda dapat membagi baris laporan yang dihasilkan dengan 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 periode 24 jam. Agar tidak melebihi kuota ini:

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

Laporan terjadwal aktif

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

• Gabungkan laporan terjadwal serupa untuk mengurangi jumlah keseluruhan laporan terjadwal.
• Nonaktifkan laporan terjadwal yang tidak diperlukan.
• 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 selesai dengan melakukan polling menggunakan logika backoff eksponensial.

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

Menggunakan backoff eksponensial saat melakukan polling status laporan

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

Meskipun polling diperlukan, penerapan yang tidak efisien dapat menghabiskan kuota Anda dengan cepat saat melihat laporan yang berjalan lama. Oleh karena itu, sebaiknya gunakan 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, selama jumlah waktu yang semakin meningkat. 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.

Catatan: Alur ini mengasumsikan bahwa Anda memiliki ID untuk laporan yang Anda polling. Jika ingin melakukan polling pada laporan yang baru saja dijalankan untuk kueri, Anda dapat memanggil queries.reports.list dengan parameter value orderBy key.reportId desc dan menggunakan reportId laporan pertama dalam daftar.

Alur untuk mengimplementasikan backoff eksponensial sederhana adalah sebagai berikut:

1. Buat permintaan queries.reports.get ke API.
2. Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, yang menunjukkan bahwa laporan belum selesai berjalan harus melanjutkan polling.
3. Tunggu 5 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
4. Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, yang menunjukkan bahwa laporan belum selesai berjalan harus melanjutkan polling.
5. Tunggu 10 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
6. Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, yang menunjukkan bahwa laporan belum selesai berjalan harus melanjutkan polling.
7. Tunggu 20 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
8. Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, yang menunjukkan bahwa laporan belum selesai berjalan harus melanjutkan polling.
9. Tunggu 40 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
10. Ambil objek laporan. Jika kolom metadata.status.state bukan DONE atau FAILED, yang menunjukkan bahwa laporan belum selesai berjalan harus melanjutkan polling.
11. Tunggu 80 detik + jumlah milidetik acak, lalu coba lagi permintaan tersebut.
12. Lanjutkan pola ini hingga objek laporan diperbarui atau waktu berlalu maksimum 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.