Fungsi inti dari banyak aplikasi Google Ads adalah mengambil data akun untuk kasus penggunaan seperti analisis data, kueri pelanggan, dan pemeriksaan kepatuhan kebijakan. Saat mengambil data, Anda harus mengoptimalkan penggunaan agar tidak membebani server Google secara berlebihan, atau berisiko terkena pembatasan frekuensi. Untuk mengetahui detail selengkapnya, lihat panduan tentang pembatasan frekuensi dan mempertahankan alamat email kontak yang terbaru.
Memahami kebijakan penggunaan resource Google untuk laporan
Untuk memastikan stabilitas servernya, Google Ads API membatasi
GoogleAdsService.Search dan
GoogleAdsService.SearchStream pola kueri yang menggunakan
resource API dalam jumlah berlebihan. Jika pola kueri tertentu dibatasi, layanan, metode, dan pola kueri lainnya akan terus berfungsi tanpa terpengaruh. Error berikut ditampilkan untuk permintaan yang dibatasi:
| Kode error |
|---|
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
atau QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION bergantung
pada durasi penggunaan resource yang tinggi. |
Jika Anda mengalami error ini, tunggu 5 menit sebelum mencoba kembali permintaan yang gagal dengan QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, dan 30 menit untuk permintaan yang gagal dengan QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.
Untuk membantu Anda mengidentifikasi dan memantau laporan yang mahal, kami juga akan menampilkan metrik biaya untuk setiap laporan.
| Metode | Kolom biaya |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
Metrik biaya yang ditampilkan oleh kolom ini bergantung pada berbagai faktor seperti
- Ukuran akun Anda
- Tampilan dan kolom yang Anda ambil dalam laporan
- Beban pada server Google Ads API.
Untuk membantu Anda melacak kueri yang mahal, kami memublikasikan statistik gabungan awal terkait penggunaan resource dari berbagai pola kueri yang kami lihat di server kami. Kami akan memublikasikan angka yang diperbarui secara berkala untuk membantu Anda menyempurnakan kueri.
| Jendela waktu | Rata-rata (p50). | P70 (Cukup tinggi) | P95 (Sangat tinggi) |
|---|---|---|---|
| Jangka pendek (5 menit) | 6000 | 30000 | 1800000 |
| Jangka panjang (24 jam). | 16000 | 90000 | 8400000 |
Sebagai contoh, anggaplah Anda menjalankan pola kueri sebagai berikut, yang menggunakan 600 unit resource per laporan.
SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
segments.date = "YYYY-MM-DD"
Anda menjalankan kueri ini untuk beberapa akun pelanggan untuk beberapa tanggal tertentu dengan mengubah kueri untuk mengganti nilai yang berbeda untuk filter segments.date. Tabel berikut menunjukkan jumlah laporan yang dapat Anda jalankan dalam jangka waktu tertentu sehingga penggunaan resource Anda sesuai dengan berbagai bucket penggunaan resource.
| Jendela waktu | Rata-rata | Cukup tinggi | Sangat tinggi |
|---|---|---|---|
| Jangka pendek (5 menit) | 10 | 50 | 3000 |
| Jangka panjang (24 jam). | 26 | 150 | 14000 |
Menjalankan pola kueri ini 10 kali dalam 5 menit akan dihitung sebagai penggunaan rata-rata, sedangkan menjalankan 3.000 laporan dalam 5 menit akan dihitung sebagai penggunaan yang sangat tinggi.
Ada beberapa strategi untuk mengoptimalkan penggunaan resource laporan Anda. Bagian selanjutnya dari panduan ini membahas beberapa strategi tersebut.
Meng-cache data Anda
Anda harus meng-cache detail entity yang Anda ambil dari server API di database lokal, bukan memanggil server setiap kali Anda memerlukan data, terutama untuk entity yang sering diakses atau yang jarang berubah. Gunakan peristiwa perubahan dan status perubahan jika memungkinkan untuk mendeteksi objek mana yang berubah sejak terakhir kali Anda menyinkronkan hasilnya.
Mengoptimalkan frekuensi menjalankan laporan
Google Ads telah memublikasikan panduan terkait keaktualan data dan frekuensi data diperbarui. Anda harus menggunakan panduan ini untuk menentukan frekuensi pengambilan laporan.
Jika Anda perlu memperbarui akun secara rutin, sebaiknya batasi jumlah akun tersebut ke kumpulan kecil, misalnya, hanya dua puluh akun Google Ads teratas. Akun lainnya dapat diperbarui dengan frekuensi yang lebih rendah, misalnya, sekali atau dua kali sehari.
Mengoptimalkan ukuran laporan
Aplikasi Anda harus mengambil batch data yang besar, bukan menjalankan sejumlah besar laporan kecil. Faktor yang berperan dalam pilihan ini adalah batas akun.
Misalnya, pertimbangkan kode berikut yang mengambil statistik untuk grup iklan tertentu dan memperbarui tabel database statistik:
List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
foreach (long adGroupId in adGroupIds)
{
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
"ad_group.id = ${adGroupId}";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
InsertRowsIntoStatsTable(adGroupId, rows);
}
Kode ini berfungsi dengan baik di akun pengujian kecil. Namun, Google Ads mendukung hingga 20.000 grup iklan per kampanye dan 10.000 kampanye per akun. Jadi, jika kode ini dijalankan terhadap akun Google Ads yang besar, kode ini dapat membebani server Google Ads API secara berlebihan, sehingga menyebabkan pembatasan frekuensi dan pembatasan.
Pendekatan yang lebih baik adalah menjalankan satu laporan, dan memprosesnya secara lokal. Salah satu pendekatan yang menggunakan peta dalam memori ditampilkan.
Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();
string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
"metrics.cost_micros, metrics.impressions, segments.date FROM " +
"ad_group WHERE segments.date DURING LAST_7_DAYS";
List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);
var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
for each (GoogleAdsRow row in rows)
{
var adGroupId = row.AdGroup.Id;
if (adGroupIds.Contains(adGroupId))
{
CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
}
}
foreach (long adGroupId in memoryMap.Keys())
{
InsertRowsIntoStatsTable(adGroupId, rows);
}
Hal ini mengurangi beban pada server Google Ads API karena jumlah laporan yang dijalankan lebih rendah.
Jika laporan terlalu besar untuk disimpan dalam memori, Anda juga dapat membagi kueri menjadi grup yang lebih kecil dengan menambahkan klausa LIMIT seperti ini:
SELECT
ad_group.id,
ad_group.name,
metrics.clicks,
metrics.cost_micros,
metrics.impressions,
segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
AND ad_group.id IN (id1, id2, ...)
LIMIT 100000
Label adalah cara lain untuk mengelompokkan entity dan mengurangi jumlah kueri pelaporan. Lihat panduan label untuk mempelajari lebih lanjut.
Mengoptimalkan data yang Anda ambil
Saat menjalankan laporan, Anda harus memperhatikan kolom yang disertakan dalam kueri. Pertimbangkan contoh berikut yang dijadwalkan untuk dijalankan setiap jam:
SELECT
customer.id,
customer.currency_code,
campaign.id,
campaign.name,
ad_group.id,
ad_group.name,
ad_group_criterion.keyword.match_type,
ad_group_criterion.keyword.text,
ad_group_criterion.criterion_id,
ad_group_criterion.quality_info.creative_quality_score,
ad_group_criterion.system_serving_status,
ad_group_criterion.negative,
ad_group_criterion.quality_info.quality_score,
ad_group_criterion.quality_info.search_predicted_ctr,
ad_group_criterion.quality_info.post_click_quality_score,
metrics.historical_landing_page_quality_score,
metrics.search_click_share,
metrics.historical_creative_quality_score,
metrics.clicks,
metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS
Satu-satunya kolom yang mungkin berubah setiap jam adalah metrics.clicks dan metrics.impressions. Semua kolom lainnya jarang diperbarui atau tidak diperbarui sama sekali, sehingga sangat tidak efisien untuk mengambilnya setiap jam. Anda dapat menyimpan nilai ini
dalam database lokal dan menjalankan laporan peristiwa perubahan atau
status perubahan untuk mendownload perubahan sekali atau dua kali sehari.
Dalam beberapa kasus, Anda dapat mengurangi jumlah baris yang didownload dengan menerapkan filter yang sesuai.
Membersihkan akun yang tidak digunakan
Jika aplikasi Anda mengelola akun pelanggan pihak ketiga, Anda harus mengembangkan aplikasi dengan mempertimbangkan churn pelanggan. Anda harus membersihkan proses dan penyimpanan data secara berkala untuk menghapus akun pelanggan yang tidak lagi menggunakan aplikasi Anda. Saat membersihkan akun Google Ads yang tidak digunakan, perhatikan panduan berikut:
- Mencabut otorisasi yang diberikan pelanggan kepada aplikasi Anda untuk mengelola akunnya.
- Berhenti melakukan panggilan API ke akun Google Ads pelanggan. Hal ini terutama berlaku untuk tugas offline seperti cron job dan pipeline data yang dirancang untuk berjalan tanpa intervensi pengguna.
- Jika pelanggan mencabut otorisasinya, aplikasi Anda harus menangani situasi tersebut dengan baik dan menghindari pengiriman panggilan API yang tidak valid ke server API Google.
- Jika pelanggan telah membatalkan akun Google Ads-nya, Anda harus mendeteksi nya dan menghindari pengiriman panggilan API yang tidak valid ke server API Google.
- Hapus data yang Anda download dari akun Google Ads pelanggan dari database lokal setelah jangka waktu yang sesuai.