Verileri verimli bir şekilde yönetin

Birçok Google Ads uygulamasının temel işlevi, veri analizi, müşteri sorguları ve politikaya uygunluk kontrolleri gibi kullanım alanları için hesap verilerini almaktır. Verileri getirirken Google sunucularının aşırı yüklenmemesi veya hız sınırlamasına tabi tutulma riski olmaması için kullanımınızı optimize etmeniz gerekir. Daha fazla bilgi için hızı sınırlama ve güncel bir iletişim e-posta adresi kullanmayla ilgili kılavuzları inceleyin.

Google'ın raporlar için kaynak kullanımı politikasını anlama

Google Ads API, sunucularının kararlılığını sağlamak için aşırı miktarda API kaynağı tüketen GoogleAdsService.Search ve GoogleAdsService.SearchStream sorgu kalıplarını kısıtlar. Belirli bir sorgu kalıbı sınırlandırılırsa diğer hizmetler, yöntemler ve sorgu kalıpları bu durumdan etkilenmeden çalışmaya devam eder. Kısıtlanmış istekler için aşağıdaki hatalar atılır:

API Sürümü Hata kodu
<= v17 QuotaError.RESOURCE_EXHAUSTED
>= v18 Yüksek kaynak kullanımının süresine bağlı olarak QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION veya QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

Pahalı raporlarınızı tespit etmenize ve izlemenize yardımcı olmak için her rapor için bir maliyet metriği de döndürürüz.

Yöntem Maliyet alanı
GoogleAdsService.Search SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream SearchGoogleAdsStreamResponse.query_resource_consumption

Bu alanlar tarafından döndürülen maliyet metriği aşağıdakiler gibi çeşitli faktörlere bağlıdır:

  • Hesaplarınızın boyutu
  • Raporlarınızda getirdiğiniz görünümler ve sütunlar
  • Google Ads API sunucularındaki yük.

Pahalı sorguları izlemenize yardımcı olmak için sunucularımızda gördüğümüz çeşitli sorgu kalıplarının kaynak tüketimi hakkında ilk toplu istatistikleri yayınlıyoruz. Sorgularınızda ince ayar yapmanıza yardımcı olmak için güncellenmiş sayıları düzenli olarak yayınlayacağız.

Zaman aralığı Ortalama (p50). P70 (Orta-yüksek) P95 (Çok yüksek)
Kısa süreli (5 dakika) 6.000 30000 1800000
Uzun süreli (24 saat). 16000 90000 8400000

Örneğin, rapor başına 600 birim kaynak tüketen aşağıdaki gibi bir sorgu kalıbı çalıştırdığınızı varsayalım.

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

Sorguyu, segments.date filtresi için farklı değerlerle değiştirecek şekilde değiştirerek birden fazla müşteri hesabı için birden fazla tarihte çalıştırırsınız. Aşağıdaki tabloda, belirli bir zaman aralığında çalıştırabileceğiniz raporların sayısı gösterilmektedir. Bu raporlar, kaynak kullanımınızı çeşitli kaynak kullanımı gruplarına sığdırır.

Zaman aralığı Ortalama Orta düzeyde yüksek Çok yüksek
Kısa süreli (5 dakika) 10 50 3000
Uzun süreli (24 saat). 26 150 14000

Bu sorgu kalıbının 5 dakika içinde 10 kez çalıştırılması ortalama kullanım olarak kabul edilirken 5 dakika içinde 3.000 raporun çalıştırılması çok yüksek kullanım olarak kabul edilir.

Raporlarınızın kaynak tüketimini optimize etmek için çeşitli stratejiler vardır. Bu kılavuzun geri kalanında bu stratejilerden bazıları ele alınmaktadır.

Verilerinizi önbelleğe alma

Özellikle sık erişilen veya nadiren değişen varlıklar için, verilere her ihtiyaç duyduğunuzda sunucuyu çağırmaktansa API sunucularından aldığınız varlık ayrıntılarını yerel bir veritabanında önbelleğe almanız gerekir. Sonuçları en son senkronize ettiğinizden bu yana hangi nesnelerin değiştiğini tespit etmek için mümkün olduğunda change-event ve change-status öğelerini kullanın.

Raporların çalıştırılma sıklığını optimize etme

Google Ads, verilerin güncelliği ve verilerin ne sıklıkta güncellendiğiyle ilgili yönetmelik yayınlamıştır. Raporları ne sıklıkta getireceğinizi belirlemek için bu kılavuzu kullanmanız gerekir.

Hesapları düzenli olarak güncellemeniz gerekiyorsa bu tür hesapların sayısını küçük bir grupla (ör. yalnızca en iyi yirmi Google Ads hesabı) sınırlandırmanızı öneririz. Diğer veriler daha düşük bir sıklıkta (ör. günde bir veya iki kez) güncellenebilir.

Raporlarınızın boyutunu optimize etme

Uygulamanız çok sayıda küçük rapor çalıştırmak yerine büyük veri grupları getirmelidir. Bu seçimde hesap sınırlamaları da etkilidir.

Örneğin, belirli reklam gruplarının istatistiklerini alan ve bir istatistik veritabanı tablosunu güncelleyen aşağıdaki kodu ele alalım:

  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);
  }

Bu kod, küçük bir test hesabında iyi çalışır. Ancak Google Ads, kampanya başına 20.000'e kadar reklam grubu ve hesap başına 10.000 kampanyayı destekler. Bu nedenle, bu kod büyük bir Google Ads hesabında çalıştırılırsa Google Ads API sunucularının yükünü artırarak hız sınırlamasına ve akış kısıtlamasına neden olabilir.

Daha iyi bir yaklaşım, tek bir rapor çalıştırmak ve bunu yerel olarak işlemektir. Bellek içi harita kullanan bu yaklaşımlardan biri gösterilmektedir.

  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);
  }

Bu, çalıştırılan rapor sayısı daha az olduğu için Google Ads API sunucularındaki yükü azaltır.

Raporun bellekte tutulamayacak kadar büyük olduğunu fark ederseniz aşağıdaki gibi bir LIMIT yan tümcesi ekleyerek sorguyu daha küçük gruplara da bölebilirsiniz:

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

Etiketler, öğeleri gruplandırmanın ve raporlama sorgularının sayısını azaltmanın başka bir yoludur. Daha fazla bilgi için etiket kılavuzuna bakın.

Getirdiğiniz verileri optimize etme

Rapor çalıştırırken sorgularınıza eklediğiniz sütunlara dikkat etmeniz gerekir. Her saat çalıştırılmak üzere planlanmış aşağıdaki örneği inceleyin:

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

Her saat değişebilecek tek sütunlar metrics.clicks ve metrics.impressions'dır. Diğer tüm sütunlar nadiren veya hiç güncellenmez. Bu nedenle, bunları saatlik olarak getirmenin verimliliği çok düşüktür. Bu değerleri yerel bir veritabanında saklayabilir ve değişiklikleri günde bir veya iki kez indirmek için bir change-event veya change-status raporu çalıştırabilirsiniz.

Bazı durumlarda, uygun filtreleri uygulayarak indirdiğiniz satır sayısını azaltabilirsiniz.

Kullanılmayan hesapları temizleme

Uygulamanız üçüncü taraf müşteri hesaplarını yönetiyorsa uygulamanızı müşteri kaybını göz önünde bulundurarak geliştirmeniz gerekir. Artık uygulamanızı kullanmayan müşterilerin hesaplarını kaldırmak için süreçlerinizi ve veri depolarınızı düzenli olarak temizlemeniz gerekir. Kullanılmayan Google Ads hesaplarını temizlerken aşağıdaki yönergeleri göz önünde bulundurun:

  • Müşterinizin, hesabını yönetmek için uygulamanıza verdiği yetkiyi iptal edin.
  • Müşterinin Google Ads hesaplarına API çağrısı yapmayı bırakın. Bu, özellikle kullanıcı müdahalesi olmadan çalışacak şekilde tasarlanmış cron işleri ve veri ardışık düzeni gibi çevrimdışı işler için geçerlidir.
  • Müşteri yetkisini iptal ettiyse uygulamanız bu durumu sorunsuz bir şekilde ele almalı ve Google'ın API sunucularına geçersiz API çağrıları göndermekten kaçınmalıdır.
  • Müşteri Google Ads hesabını iptal ettiyse bunu algılamanız ve Google'ın API sunucularına geçersiz API çağrıları göndermekten kaçınmanız gerekir.
  • Müşterinin Google Ads hesaplarından indirdiğiniz verileri uygun bir süre sonra yerel veritabanınızdan silin.
Önceki
İzleme
Sonraki
Hız sınırları