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üklenmemek 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.
Raporlarla ilgili kaynak kullanım politikası hakkında
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 verilir:
| Hata kodu |
|---|
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION
veya QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION
alabilirsiniz. |
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ğıdaki 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, pahalı sorguları izlemenize ve hassas ayarlamanıza yardımcı olmak için Google Ads API sunucularındaki çeşitli sorgu kalıplarının kaynak tüketimiyle ilgili toplu istatistikler listelenmektedir:
| 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 |
Ö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ğ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 uygun olması 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 dakika) | 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ını 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 nedenle, bu kod büyük bir Google Ads hesabında çalıştırılırsa Google Ads API sunucularını aşırı yükleyebilir ve bu da sıklık sınırlamasına ve sınırlamaya yol açabilir.
Daha iyi bir yaklaşım, tek bir rapor çalıştırmak ve bunu yerel olarak işlemek olacaktır. Bellek içi eşleme 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, çalıştırılan rapor sayısı azaldığı için Google Ads API sunucularındaki yük de 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 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 saklayabilir ve değişiklikleri günde bir veya iki kez indirmek için change-event ya da change-status raporu çalıştırabilirsiniz.
Bazı durumlarda, uygun filtreler 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. Uygulamanızı artık 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, uygulamanıza hesabını yönetmesi için 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 tasarlanan cron işleri ve Data Pipelines gibi çevrimdışı işler için geçerlidir.
- Müşteri yetkilendirmeyi 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 etmeli ve Google'ın API sunucularına geçersiz API çağrıları göndermekten kaçınmalısınız.
- Müşterinin Google Ads hesaplarından indirdiğiniz verileri uygun bir süre sonra yerel veritabanınızdan silin.