Verileri verimli bir şekilde yönetin

Birçok Google Ads uygulamasının temel işlevi, veri analizi, müşteri sorguları ve politika uygunluk kontrolleri gibi kullanım alanları için hesap verilerini almaktır. Verileri getirirken Google sunucularına aşırı yükleme yapmamak veya sıklık sınırlaması riskiyle karşılaşmamak için kullanımınızı optimize etmeniz gerekir. Daha fazla bilgi için sıklık sınırlaması ve iletişim e-posta adresini güncel tutma ile ilgili kılavuzları inceleyin.

Raporlar için kaynak kullanımı politikasını anlama

Not: Bu politika hakkında daha fazla bilgi için kaynak kullanımı politikası blog yayınını inceleyin.

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ıtlanan istekler için aşağıdaki hatalar verilir:

Hata kodu
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION veya QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION yüksek kaynak kullanımının süresine bağlı olarak.

Bu hatalarla karşılaşırsanız QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION ile başarısız olan istekleri yeniden denemeden önce 5 dakika, QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION ile başarısız olan istekler için ise 30 dakika bekleyin.

Yüksek maliyetli raporlarınızı belirlemenize ve izlemenize yardımcı olmak için her bir 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

Aşağıdaki tabloda, Google Ads API sunucularındaki çeşitli sorgu kalıplarının kaynak tüketimiyle ilgili toplu istatistikler listelenmektedir. Bu istatistikler, yüksek maliyetli sorguları izlemenize ve hassas ayarlamanıza yardımcı olur:

Zaman aralığı	Ortalama (p50)	P70 (Orta düzeyde yüksek)	P95 (Çok yüksek)
Kısa vadeli (5 dk.)	6.000	30000	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 filtresi için farklı değerler kullanacak şekilde değiştirerek birden fazla müşteri hesabı için birkaç farklı tarihte çalıştırırsınız. Aşağıdaki tabloda, kaynak kullanımınızın çeşitli kaynak kullanımı gruplarına sığması için belirli bir zaman aralığında çalıştırabileceğiniz rapor sayısı gösterilmektedir.

Zaman aralığı	Ortalama	Orta-yüksek	Çok yüksek
Kısa vadeli (5 dk.)	10	50	3000
Uzun vadeli (24 saat)	26	150	14000

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

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

Verilerinizi önbelleğe alma

API sunucularından aldığınız varlık ayrıntılarını, özellikle sık erişilen veya nadiren değişen varlıklar için, veriye her ihtiyaç duyduğunuzda sunucuyu çağırmak yerine yerel bir veritabanında önbelleğe almanız gerekir. Sonuçları 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 kullanın.

Rapor çalıştırma sıklığını optimize etme

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

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ırlamanızı öneririz. Geri kalanlar 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 tercihi etkileyen faktörlerden biri hesap sınırlarıdır.

Ö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 en fazla 20.000 reklam grubunu ve hesap başına en fazla 10.000 kampanyayı destekler. Bu kod büyük bir Google Ads hesabında çalıştırılırsa Google Ads API sunucularına aşırı yük binebilir ve bu da sıklık sınırlamasına ve kısıtlamaya yol açabilir.

Tek bir rapor çalıştırmak ve bu raporu yerel olarak işlemek daha iyi bir yaklaşım olacaktır. Bellek içi harita kullanan bir yaklaşım aşağıda 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(customerId, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  foreach (GoogleAdsRow row in rows)
  {
    long adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

Bu sayede, daha az sayıda rapor çalıştırılacağı için Google Ads API sunucularındaki yük azalır.

Raporun belleğe sığmayacak kadar büyük olduğunu fark ederseniz sorguyu aşağıdaki gibi bir LIMIT gruplandırma ölçütü ifadesi ekleyerek daha küçük gruplara da 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, öğeleri gruplandırmanın ve raporlama sorgularının sayısını azaltmanın başka bir yoludur. Daha fazla bilgi edinmek için etiketler kılavuzuna bakın.

Getirdiğiniz verileri optimize etme

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 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 sütunlarıdır. 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 ya da 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 hususları göz önünde bulundurun:

• Müşterinizin, hesabını yönetmesi için uygulamanıza verdiği yetkiyi iptal edin.
• Müşterinin Google Ads hesaplarına API çağrısı yapmayı durdurun. Bu durum özellikle kullanıcı müdahalesi olmadan çalışacak şekilde tasarlanmış cron işleri ve Data Pipelines 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 iptal edilen hesapları tespit etmeniz 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.