Fungsi inti dari banyak aplikasi Google Ads adalah mengambil data akun untuk digunakan kasus seperti analisis data, kueri pelanggan, dan pemeriksaan kepatuhan terhadap kebijakan. Saat mengambil data, Anda harus mengoptimalkan penggunaan agar tidak kelebihan beban Server Google, atau risiko dibatasi kapasitas. Untuk mengetahui detail selengkapnya, lihat panduan di pembatasan kapasitas dan mempertahankan alamat email kontak terbaru.
Memahami kebijakan penggunaan resource Google untuk laporan
Untuk memastikan stabilitas servernya, Google Ads API melakukan throttle
GoogleAdsService.Search dan
GoogleAdsService.SearchStream pola kueri yang menggunakan terlalu banyak
jumlah resource API. Jika pola kueri tertentu diperlambat, metode
layanan, metode, dan pola kueri akan terus bekerja tanpa terpengaruh. Tujuan
error berikut ditampilkan untuk permintaan yang dibatasi:
| Versi API | Kode error |
|---|---|
| <= v17 | QuotaError.RESOURCE_EXHAUSTED |
| >= V18 | QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
atau QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION bergantung pada
seiring durasi penggunaan resource yang tinggi. |
Untuk membantu mengidentifikasi dan memantau laporan yang mahal, kami juga akan menampilkan metrik biaya untuk laporan individual.
| Metode | Kolom biaya |
|---|---|
GoogleAdsService.Search |
SearchGoogleAdsResponse.query_resource_consumption |
GoogleAdsService.SearchStream |
SearchGoogleAdsStreamResponse.query_resource_consumption |
Metrik biaya yang ditampilkan oleh kolom tersebut bergantung pada berbagai faktor seperti
- Ukuran akun
- Tampilan dan kolom yang Anda ambil dalam laporan
- Beban di server Google Ads API.
Untuk membantu Anda melacak kueri yang mahal, kami memublikasikan data gabungan awal statistik seputar konsumsi resource berbagai pola kueri yang kita lihat server kami. Kami akan memublikasikan angka yang diperbarui secara berkala untuk membantu Anda melakukan pengoptimalan kueri Anda.
| Periode waktu | Rata-rata (p50). | P70 (Cukup tinggi) | P95 (Sangat tinggi) |
|---|---|---|---|
| Jangka pendek (5 mnt) | 6000 | 30000 | 1800000 |
| Jangka panjang (24 jam). | 16000 | 90000 | 8400000 |
Sebagai contoh, asumsikan 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 segments.date
filter. Tabel berikut menunjukkan jumlah laporan yang dapat Anda jalankan dalam
periode waktu sehingga penggunaan resource Anda sesuai dengan berbagai penggunaan resource
bucket.
| Periode waktu | Biasa | Cukup tinggi | Sangat tinggi |
|---|---|---|---|
| Jangka pendek (5 mnt) | 10 | 50 | 3000 |
| Jangka panjang (24 jam). | 26 | 150 | 14000 |
Menjalankan pola kueri ini 10 kali dalam 5 menit akan dihitung sebagai rata-rata penggunaan, sedangkan menjalankan 3.000 laporan dalam 5 menit akan dihitung sebagai penggunaan yang sangat tinggi.
Ada beberapa strategi untuk mengoptimalkan konsumsi sumber daya laporan. Bagian selanjutnya dari panduan ini mencakup beberapa strategi tersebut.
Menyimpan data Anda dalam cache
Anda harus menyimpan detail entitas yang Anda ambil dari server API ke dalam cache alih-alih memanggil server setiap kali Anda membutuhkan data, khususnya untuk entitas yang sering diakses atau yang mengubah jarang. Gunakan change-event dan change-status untuk mungkin untuk mendeteksi objek mana yang berubah sejak terakhir kali Anda menyinkronkan hasilnya.
Mengoptimalkan frekuensi menjalankan laporan
Google Ads telah memublikasikan pedoman terkait keaktualan data dan cara data tersebut sering diperbarui. Sebaiknya Anda menggunakan panduan ini untuk menentukan cara secara rutin untuk mengambil laporan.
Jika Anda perlu memperbarui akun secara rutin, sebaiknya batasi jumlah akun tersebut ke sedikit, misalnya, hanya 20 akun Google Ads teratas menggunakan akun layanan. Yang lainnya dapat diperbarui pada frekuensi yang lebih rendah, misalnya, sekali atau dua kali sehari.
Mengoptimalkan ukuran laporan
Aplikasi Anda harus mengambil data dalam batch besar, bukan menjalankan sejumlah laporan kecil. Faktor yang memengaruhi pilihan ini adalah akun batasan ini.
Misalnya, pertimbangkan kode berikut yang menarik statistik untuk iklan tertentu mengelompokkan dan memperbarui tabel {i>database<i} 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 pada akun pengujian yang kecil. Namun, Google Ads mendukung hingga 20.000 grup iklan per kampanye dan 10.000 kampanye per akun. Jadi jika kode ini berjalan pada akun Google Ads yang besar, tindakan ini dapat membebani server Google Ads API, yang mengarah ke pembatasan kapasitas dan throttling.
Pendekatan yang lebih baik adalah menjalankan satu laporan, dan memprosesnya secara lokal. paket Premium AI pendekatan tersebut menggunakan peta dalam memori.
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 lebih rendah sedang dijalankan.
Jika laporan terlalu besar untuk disimpan di memori, Anda juga dapat
perinci 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 entitas dan mengurangi jumlah pelaporan terhadap kueri. Lihat panduan label untuk mempelajari lebih lanjut.
Optimalkan item yang Anda ambil
Saat menjalankan laporan, Anda harus memperhatikan kolom yang Anda sertakan di kueri Anda. 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 cenderung berubah setiap jam adalah metrics.clicks dan
metrics.impressions. Semua kolom lainnya jarang diperbarui atau tidak diperbarui pada
sehingga akan sangat tidak efisien untuk mengambilnya setiap jam. Anda bisa menyimpan
dalam database lokal dan menjalankan change-event 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.
Bersihkan akun yang tidak digunakan
Jika aplikasi Anda mengelola akun pengiklan pihak ketiga, Anda harus mengembangkan aplikasi dengan mempertimbangkan churn pelanggan. Sebaiknya Anda secara berkala membersihkan proses dan penyimpanan data Anda untuk menghapus akun bagi pelanggan yang lagi untuk menggunakan aplikasi Anda. Saat membersihkan akun Google Ads yang tidak digunakan, pertahankan panduan berikut ini:
- Cabut otorisasi yang diberikan pelanggan untuk mengelola aplikasi Anda akun mereka.
- Berhenti melakukan panggilan API ke akun Google Ads pelanggan. Ini berlaku terutama untuk pekerjaan {i>offline<i} seperti {i>cron job <i}dan pipeline data yang dirancang untuk berjalan tanpa intervensi pengguna.
- Jika pelanggan mencabut otorisasinya, permohonan Anda harus menangani situasi dengan baik dan menghindari mengirim panggilan API yang tidak valid ke Server API Google.
- Jika pelanggan telah membatalkan akun Google Ads, Anda harus mendeteksi dan menghindari mengirim panggilan API yang tidak valid ke server API Google.
- Hapus data yang Anda download dari akun Google Ads pelanggan dari {i>database<i} lokal setelah periode waktu yang tepat.