‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

مدیریت کارآمد داده‌ها

یکی از عملکردهای اصلی بسیاری از برنامه‌های Google Ads بازیابی داده‌های حساب برای موارد استفاده‌ای مانند تجزیه‌وتحلیل داده‌ها، پُرسمان‌های مشتری، و بررسی‌های رعایت خط‌مشی است. هنگام واکشی داده‌ها، باید استفاده‌تان را بهینه‌سازی کنید تا بار اضافی بر سرورهای Google تحمیل نشود، یا با خطر محدود شدن نرخ مواجه نشوید. برای جزئیات بیشتر، راهنماهای مربوط به محدود کردن نرخ و حفظ نشانی ایمیل تماس به‌روز را ببینید.

آشنایی با خط‌مشی استفاده از منابع برای گزارش‌ها

برای اطمینان از پایداری سرورهای Google Ads API، این میانای برنامه‌سازی کاربردی الگوهای پُرسمان GoogleAdsService.Search و GoogleAdsService.SearchStream را که مقدار زیادی از منابع میانای برنامه‌سازی کاربردی را مصرف می‌کنند محدود می‌کند. اگر الگوی پُرسمان خاصی محدود شود، سایر سرویس‌ها، روش‌ها، و الگوهای پُرسمان بدون تأثیر به کار خود ادامه می‌دهند. خطاهای زیر برای درخواست‌های محدودشده ایجاد می‌شود:

کد خطا
`QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION` یا `QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION` بسته به مدت‌زمان استفاده زیاد از منابع.

اگر با این خطاها مواجه شدید، ۵ دقیقه صبر کنید و سپس درخواست‌هایی را که با QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION ناموفق بوده‌اند دوباره امتحان کنید، و برای درخواست‌هایی که با QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION ناموفق بوده‌اند ۳۰ دقیقه صبر کنید.

برای کمک به شما در شناسایی و نظارت بر گزارش‌های گران‌قیمت، یک سنجه هزینه نیز برای گزارش‌های فردی برمی‌گردانیم:

روش	فیلد هزینه
`GoogleAdsService.Search`	`SearchGoogleAdsResponse.query_resource_consumption`
`GoogleAdsService.SearchStream`	`SearchGoogleAdsStreamResponse.query_resource_consumption`

سنجه هزینه برگردانده‌شده توسط این فیلدها به عوامل مختلفی بستگی دارد، ازجمله:

اندازه حساب‌های شما
نماها و ستون‌هایی که در گزارش‌هایتان واکشی می‌کنید
بار روی سرورهای Google Ads API

جدول زیر آمار انبوهشی مصرف منابع الگوهای پُرسمان مختلف را در سرورهای Google Ads API فهرست می‌کند تا به شما کمک کند پُرسمان‌های پرهزینه را ردیابی و تنظیم دقیق کنید:

بازه زمانی	میانگین (p50)	‫P70 (نسبتاً بالا)	P95 (بسیار بالا)
کوتاه‌مدت (۵ دقیقه)	6000	۳۰۰۰۰	1800000
بلندمدت (۲۴ ساعت)	16000	90000	8400000

به‌عنوان مثال، فرض کنید الگوی پُرسمانی را به‌صورت زیر اجرا می‌کنید که برای هر گزارش ۶۰۰ واحد منابع مصرف می‌کند:

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

این پُرسمان را برای چندین حساب مشتری در چند تاریخ جداگانه اجرا می‌کنید و پُرسمان را برای جایگزین کردن مقادیر مختلف برای فیلتر segments.date اصلاح می‌کنید. جدول زیر تعداد گزارش‌هایی را که می‌توانید در یک پنجره زمانی مشخص اجرا کنید نشان می‌دهد، به‌طوری‌که استفاده شما از منابع در دسته‌های مختلف استفاده از منابع قرار می‌گیرد.

بازه زمانی	متوسط	نسبتاً زیاد	بسیار زیاد
کوتاه‌مدت (۵ دقیقه)	10	50	۳۰۰۰
بلندمدت (۲۴ ساعت)	26	۱۵۰	14000

اجرای این الگوی پُرسمان ۱۰ بار در ۵ دقیقه به‌عنوان استفاده متوسط محسوب می‌شود، درحالی‌که اجرای ۳۰۰۰ گزارش در ۵ دقیقه به‌عنوان استفاده بسیار زیاد محسوب می‌شود.

چندین استراتژی برای بهینه‌سازی مصرف منابع گزارش‌های شما وجود دارد. بقیه این راهنما برخی‌از این راهبردها را پوشش می‌دهد.

داده‌هایتان را در حافظه نهان ذخیره کنید

باید جزئیات موجودیتی را که از سرورهای میانای برنامه‌سازی کاربردی واکشی می‌کنید در پایگاه داده محلی ذخیره کنید، به‌جای اینکه هربار که به داده‌ها نیاز دارید سرور را فراخوانی کنید، به‌ویژه برای موجودیت‌هایی که به‌طور مکرر به آن‌ها دسترسی پیدا می‌شود یا به‌ندرت تغییر می‌کنند. درصورت امکان، از change-event و change-status استفاده کنید تا تشخیص دهید کدام اشیاء از آخرین باری که نتایج را همگام‌سازی کرده‌اید تغییر کرده‌اند.

بهینه‌سازی بسامد اجرای گزارش‌ها

Google Ads رهنمودهایی را درباره تازگی داده‌ها و تعداد دفعات به‌روزرسانی داده‌ها منتشر کرده است. باید از این راهنمایی برای تعیین تعداد دفعات واکشی گزارش‌ها استفاده کنید.

اگر لازم است حساب‌ها را به‌طور منظم به‌روز کنید، توصیه می‌کنیم تعداد این حساب‌ها را به مجموعه کوچکی محدود کنید، برای مثال، فقط بیست حساب Google Ads برتر. بقیه را می‌توان با بسامد کمتری به‌روز کرد، مثلاً یک یا دو بار در روز.

بهینه‌سازی اندازه گزارش‌ها

برنامه شما باید به‌جای اجرای تعداد زیادی گزارش کوچک، دسته‌های بزرگ داده را واکشی کند. عاملی که در این انتخاب نقش دارد حدود حساب است.

برای مثال، کد زیر را درنظر بگیرید که آمار گروه‌های آگهی خاصی را استخراج می‌کند و جدول پایگاه داده آمار را به‌روز می‌کند:

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

این کد در حساب آزمایشی کوچک به‌خوبی کار می‌کند. بااین‌حال، Google Ads تا ۲۰٬۰۰۰ گروه آگهی در هر پویش و ۱۰٬۰۰۰ پویش در هر حساب را پشتیبانی می‌کند. بنابراین اگر این کد در یک حساب Google Ads بزرگ اجرا شود، می‌تواند سرورهای Google Ads API را بیش‌ازحد بارگذاری کند، که منجر به محدود کردن نرخ و کاهش سرعت می‌شود.

رویکرد بهتر این است که یک گزارش را اجرا کنید و آن را به‌صورت محلی پردازش کنید. یکی از این رویکردها بااستفاده از نقشه درون‌حافظه‌ای نشان داده شده است:

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

این کار بار روی سرورهای Google Ads API را به‌دلیل تعداد کمتر گزارش‌های درحال اجرا کاهش می‌دهد.

اگر متوجه شدید که گزارش برای نگهداری در حافظه خیلی بزرگ است، می‌توانید با افزودن عبارت LIMIT، پُرسمان را به گروه‌های کوچک‌تر تقسیم کنید:

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

برچسب‌ها روش دیگری برای گروه‌بندی نهادها و کاهش تعداد پُرسمان‌های گزارش‌دهی هستند. برای کسب اطلاعات بیشتر، راهنمای برچسب‌ها را ببینید.

بهینه‌سازی آنچه واکشی می‌کنید

هنگام اجرای گزارش‌ها، باید به ستون‌هایی که در پُرسمان‌هایتان اضافه می‌کنید توجه داشته باشید. مثال زیر را درنظر بگیرید که برای اجرا در هر ساعت زمان‌بندی شده است:

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

تنها ستون‌هایی که احتمالاً هر ساعت تغییر می‌کنند metrics.clicks و metrics.impressions هستند. همه ستون‌های دیگر به‌ندرت یا اصلاً به‌روز نمی‌شوند، بنابراین واکشی ساعتی آن‌ها بسیار ناکارآمد است. می‌توانید این مقادیر را در پایگاه داده محلی ذخیره کنید و گزارش رویداد تغییر یا وضعیت تغییر را اجرا کنید تا تغییرات را یک یا دو بار در روز بارگیری کنید.

در برخی موارد، می‌توانید با اعمال فیلترهای مناسب، تعداد ردیف‌هایی را که بارگیری می‌کنید کاهش دهید.

پاک‌سازی حساب‌های بلااستفاده

اگر برنامه‌تان حساب‌های مشتریان طرف سوم را مدیریت می‌کند، باید برنامه‌تان را با درنظر گرفتن ریزش مشتری توسعه دهید. باید به‌طور دوره‌ای فرایندها و انبارهای داده‌تان را پاک‌سازی کنید تا حساب‌های مشتریانی را که دیگر از برنامه‌تان استفاده نمی‌کنند بردارید. هنگام پاک‌سازی حساب‌های Google Ads استفاده‌نشده، راهنمایی‌های زیر را درنظر داشته باشید:

مجوزی را که مشتری به برنامه شما برای مدیریت حسابش داده است لغو کنید.
برقراری تماس‌های API با حساب‌های Google Ads مشتری را متوقف کنید. این امر به‌ویژه برای کارهای آفلاین مانند کارهای cron و خطوط لوله داده که برای اجرا بدون دخالت کاربر طراحی شده‌اند، اعمال می‌شود.
اگر مشتری مجوز خود را لغو کرده باشد، برنامه شما باید وضعیت را به‌درستی مدیریت کند و از ارسال فراخوانی‌های نامعتبر API به سرورهای Google API خودداری کند.
اگر مشتری حساب Google Ads خود را لغو کرده است، باید حساب‌های لغوشده را شناسایی کنید و از ارسال فراخوانی‌های نامعتبر API به سرورهای Google API خودداری کنید.
داده‌هایی را که از حساب‌های Google Ads مشتری بارگیری کرده‌اید، پس‌از مدت زمان مناسبی از پایگاه داده محلی‌تان حذف کنید.