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

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

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

«میانای برنامه‌سازی کاربردی Google Ads» برای اطمینان از پایداری سرورهایش، الگوهای پُرسمانی را که مقادیر 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» را بیش‌ازحد بار کند و منجر به محدودیت نرخ و محدودیت پهنای باند شود.

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

  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 مشتری بارگیری کرده‌اید، پس‌از مدت زمان مناسبی از پایگاه داده محلی‌تان حذف کنید.