Verileri verimli bir şekilde yönetin

Birçok Google Ads uygulamasının temel işlevi, veri analizi, müşteri sorguları ve politika uyumluluk kontrolleri gibi kullanım alanları için hesap verilerini almaktır. Verileri getirirken, kullanımınızı Google sunucularında aşırı yüklenmeyecek veya hızın sınırlandırılması riskiyle karşı karşıya kalmayacak şekilde optimize etmeniz gerekir. Daha fazla bilgi için hız sınırlaması ve güncel bir iletişim e-posta adresi sağlama kılavuzlarına göz atın.

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ı kısıtlanırsa diğer hizmetler, yöntemler ve sorgu kalıpları etkilenmeden çalışmaya devam eder. Kısıtlanmış istekler için aşağıdaki hatalar bildirilir:

API Sürümü Hata kodu
<= s16 QuotaError.RESOURCE_EXHAUSTED
>= s17 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 amacıyla ayrı ayrı raporlar için de bir maliyet metriği sunacağız.

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

Bu alanların döndürdüğü maliyet metriği

  • 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 amacıyla, sunucularımızda gördüğümüz çeşitli sorgu kalıplarının kaynak tüketimiyle ilgili ilk toplu istatistikleri yayınlıyoruz. Sorgularınızda ince ayar yapmanıza yardımcı olmak için belirli aralıklarla güncellenen rakamları yayınlayacağız.

Zaman aralığı Ortalama (p50). P70 (Kısmen yüksek) P95 (Çok yüksek)
Kısa vadeli (5 dakika) 6.000 30.000 1800000
Uzun vadeli (24 saat). 16000 90000 8400000

Örnek olarak, 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"

Bu sorguyu, segments.date filtresinin farklı değerleriyle değiştirecek şekilde değiştirerek farklı tarihlerde birden fazla müşteri hesabı için çalıştırırsınız. Aşağıdaki tabloda, kaynak kullanımınızın çeşitli kaynak kullanımı paketlerine uyması için belirli bir zaman aralığında çalıştırabileceğiniz rapor sayısı gösterilmektedir.

Zaman aralığı Ortalama Kısmen yüksek Çok yüksek
Kısa vadeli (5 dakika) 10 50 3.000
Uzun vadeli (24 saat). 26 150 14000

Bu sorgu kalıbının 5 dakikada 10 kez çalıştırılması ortalama kullanım olarak kabul edilirken, 5 dakikada 3.000 rapor çalıştırmak çok yüksek kullanım sayılır.

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

Verilerinizi önbelleğe alın

Veriye her ihtiyacınız olduğunda sunucuyu çağırmak yerine, API sunucularından getirdiğiniz varlık ayrıntılarını yerel bir veritabanında önbelleğe almanız gerekir. Bu, özellikle sık erişilen veya seyrek değişen varlıklar için geçerlidir. Sonuçları son senkronize etmenizden bu yana hangi nesnelerin değiştiğini tespit etmek için mümkünse change-event ve change-status özelliklerini kullanın.

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

Google Ads veri güncelliği ve verilerin ne sıklıkla güncellendiği ile ilgili yönergeler yayınlamıştır. Raporların ne sıklıkta getirileceğini 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 sınırlandırmanızı öneririz (örneğin, ilk yirmi Google Ads hesabı). Geri kalanı daha düşük sıklıkta, örneğin 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ı getirir. Hesap sınırları, bu seçimde etkili olan faktörlerden biridir.

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

  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 bir şekilde çalışır. Ancak Google Ads, kampanya başına 20.000 reklam grubu ve hesap başına 10.000 kampanyayı destekler. Bu nedenle bu kod, büyük bir Google Ads hesabında çalışırsa Google Ads API sunucularını aşırı yükleyebilir ve bu da hız sınırlamasına ve kısıtlamaya neden olabilir.

Tek bir rapor çalıştırıp yerel olarak işlemek daha iyi bir yaklaşım olur. Bellek içi eşleme kullanan bu tür yaklaşımlardan biri gösterilmiştir.

  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ının daha düşük olması nedeniyle Google Ads API sunucularındaki yükü azaltır.

Raporun bellekte tutamayacak kadar büyük olduğunu fark ederseniz aşağıdaki gibi bir LIMIT ifadesi ekleyerek sorguyu daha küçük gruplara ayırabilirsiniz:

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, varlıkları gruplandırmanın ve raporlama sorgularının sayısını azaltmanın başka bir yoludur. Daha fazla bilgi edinmek için etiket kılavuzuna bakın.

Getirdiklerinizi optimize edin

Rapor çalıştırırken sorgularınıza dahil ettiğiniz sütunlara dikkat etmeniz gerekir. Her saat çalışacak şekilde planlanan aşağıdaki örneği düşünün:

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

Yalnızca metrics.clicks ve metrics.impressions sütunları her saat değişebilir. Diğer tüm sütunlar seyrek olarak güncellenir veya hiç güncellenmez. Bu nedenle, bunları saatlik olarak getirmek son derece verimsizdir. Bu değerleri yerel bir veritabanında depolayabilir 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 filtreler uygulayarak indirdiğiniz satır sayısını azaltabilirsiniz.

Kullanılmayan hesapları temizleyin

Uygulamanız üçüncü taraf reklamveren hesaplarını yönetiyorsa uygulamanızı müşteri kaybını göz önünde bulundurarak geliştirmeniz gerekir. Uygulamanızı artık kullanmayan müşterilerin hesaplarını kaldırmak için işlemlerinizi 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önetmesi için uygulamanıza verdiği yetkilendirmeyi iptal edin.
  • Müşterinin Google Ads hesaplarına API çağrıları yapmayı durdurun. Bu durum özellikle kullanıcı müdahalesi olmadan çalışacak şekilde tasarlanmış cron işleri ve veri ardışık düzenleri gibi çevrimdışı işler için geçerlidir.
  • Müşteri yetkilendirmesini iptal ettiyse uygulamanız bu durumu düzgün 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 hesabı 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ı