Mengelola data secara efisien

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 atau risiko dibatasi kapasitasnya. Untuk mengetahui detail selengkapnya, lihat panduan tentang pembatasan kapasitas dan mempertahankan alamat email kontak terbaru.

Memahami kebijakan penggunaan resource Google untuk laporan

Untuk memastikan stabilitas servernya, Google Ads API men-throttle pola kueri GoogleAdsService.Search dan GoogleAdsService.SearchStream yang menggunakan jumlah resource API secara berlebihan. Jika pola kueri tertentu dibatasi, layanan, metode, dan pola kueri lainnya tidak akan terpengaruh. Error berikut ditampilkan untuk permintaan yang di-throttle:

Versi API Kode error
<= V16 QuotaError.RESOURCE_EXHAUSTED
>= V17 QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION atau QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION bergantung pada durasi penggunaan resource yang tinggi.

Untuk membantu Anda mengidentifikasi dan memantau laporan yang mahal, kami juga akan menampilkan metrik biaya untuk masing-masing laporan.

Metode Kolom biaya
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

Metrik biaya yang ditampilkan oleh {i>field<i} ini bergantung pada berbagai faktor seperti

  • Ukuran akun
  • Tampilan dan kolom yang Anda ambil di laporan
  • Beban di server Google Ads API.

Untuk membantu Anda melacak kueri yang mahal, kami memublikasikan statistik gabungan awal terkait konsumsi resource dari berbagai pola kueri yang terlihat di server kami. Kami akan memublikasikan angka yang diperbarui secara berkala untuk membantu Anda menyesuaikan kueri.

Periode waktu Rata-rata (p50). P70 (Cukup tinggi) P95 (Sangat tinggi)
Jangka pendek (5 mnt) 6.000 30000 1800000
Jangka panjang (24 jam). 16000 90000 8400000

Sebagai contoh, anggap Anda menjalankan pola kueri seperti berikut, yang menghabiskan 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 individual dengan mengubah kueri untuk mengganti nilai yang berbeda untuk filter segments.date. Tabel berikut menunjukkan jumlah laporan yang dapat Anda jalankan dalam periode waktu tertentu, sehingga penggunaan resource Anda sesuai dengan berbagai bucket penggunaan resource.

Periode waktu Biasa Cukup tinggi Sangat tinggi
Jangka pendek (5 mnt) 10 50 3.000
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 konsumsi resource dalam laporan Anda. Bagian selanjutnya dari panduan ini membahas beberapa strategi tersebut.

Menyimpan data Anda dalam cache

Sebaiknya Anda 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 change-event dan change-status jika memungkinkan untuk mendeteksi objek yang berubah sejak terakhir kali Anda menyinkronkan hasil.

Mengoptimalkan frekuensi laporan yang berjalan

Google Ads telah memublikasikan panduan seputar keaktualan data dan seberapa sering data diperbarui. Sebaiknya Anda 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. Sisanya dapat diperbarui pada frekuensi yang lebih rendah, misalnya, sekali atau dua kali sehari.

Mengoptimalkan ukuran laporan

Aplikasi Anda harus mengambil batch data dalam jumlah besar, bukan menjalankan laporan kecil dalam jumlah besar. Faktor yang menentukan pilihan ini adalah batas akun.

Misalnya, pertimbangkan kode berikut yang menampilkan 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 pada 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 pada akun Google Ads yang besar, kode tersebut dapat membebani server Google Ads API, sehingga menyebabkan pembatasan kapasitas dan throttling.

Pendekatan yang lebih baik adalah menjalankan satu laporan, dan memprosesnya secara lokal. Salah satu pendekatan tersebut 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 lebih sedikit laporan yang dijalankan.

Jika mendapati bahwa laporan terlalu besar untuk disimpan di 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.

Optimalkan hasil yang Anda ambil

Saat menjalankan laporan, Anda harus memperhatikan kolom yang disertakan dalam kueri. Pertimbangkan contoh berikut yang dijadwalkan untuk berjalan 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 di database lokal dan menjalankan laporan change-event atau change-status untuk mendownload perubahan sekali atau dua kali sehari.

Dalam beberapa kasus, Anda dapat mengurangi jumlah baris yang didownload dengan menerapkan filter yang sesuai.

Menghapus akun yang tidak digunakan

Jika aplikasi Anda mengelola akun pengiklan pihak ketiga, Anda perlu mengembangkan aplikasi dengan mempertimbangkan churn pelanggan. Anda harus secara berkala membersihkan proses dan penyimpanan data untuk menghapus akun bagi pelanggan yang tidak lagi menggunakan aplikasi Anda. Saat membersihkan akun Google Ads yang tidak digunakan, perhatikan panduan berikut:

  • Cabut otorisasi yang diberikan pelanggan kepada aplikasi Anda untuk mengelola akunnya.
  • Berhenti melakukan panggilan API ke akun Google Ads pelanggan. Hal ini berlaku terutama 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 ini dengan baik dan menghindari mengirim panggilan API yang tidak valid ke server API Google.
  • Jika pelanggan telah membatalkan akun Google Ads mereka, Anda harus mendeteksinya dan menghindari mengirim panggilan API yang tidak valid ke server API Google.
  • Hapus data yang didownload dari akun Google Ads pelanggan dari database lokal Anda setelah jangka waktu yang sesuai.