داده ها را به طور موثر مدیریت کنید

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

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

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

کد خطا
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

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

  • حجم حساب‌های شما
  • نماها و ستون‌هایی که در گزارش‌های خود دریافت می‌کنید
  • بار روی سرورهای API گوگل ادز.

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

پنجره زمانی میانگین (p50). P70 (نسبتاً بالا) P95 (بسیار بالا)
کوتاه مدت (۵ دقیقه) ۶۰۰۰ ۳۰۰۰۰ ۱۸۰۰۰۰۰
بلند مدت (۲۴ ساعته). ۱۶۰۰۰ ۹۰۰۰۰ ۸۴۰۰۰۰۰

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

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

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

پنجره زمانی میانگین نسبتاً بالا بسیار بالا
کوتاه مدت (۵ دقیقه) ۱۰ ۵۰ ۳۰۰۰
بلند مدت (۲۴ ساعته). ۲۶ ۱۵۰ ۱۴۰۰۰

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

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

داده‌های خود را ذخیره کنید

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

بهینه سازی فرکانس اجرای گزارش ها

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

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

اندازه گزارش‌های خود را بهینه کنید

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

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

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

این کد روی یک حساب آزمایشی کوچک به خوبی کار می‌کند. با این حال، گوگل ادز تا 20،000 گروه تبلیغاتی در هر کمپین و 10،000 کمپین در هر حساب را پشتیبانی می‌کند. بنابراین اگر این کد روی یک حساب کاربری بزرگ گوگل ادز اجرا شود، می‌تواند سرورهای 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(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);
  }

این امر به دلیل کاهش تعداد گزارش‌های اجرا شده، بار سرورهای 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 هستند. سایر ستون‌ها به ندرت به‌روزرسانی می‌شوند یا اصلاً به‌روزرسانی نمی‌شوند، بنابراین واکشی آن‌ها به صورت ساعتی بسیار ناکارآمد است. می‌توانید این مقادیر را در یک پایگاه داده محلی ذخیره کنید و یک گزارش رویداد تغییر یا وضعیت تغییر را اجرا کنید تا تغییرات یک یا دو بار در روز دانلود شوند.

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

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

اگر برنامه شما حساب‌های مشتری شخص ثالث را مدیریت می‌کند، باید برنامه خود را با در نظر گرفتن ریزش مشتری توسعه دهید. شما باید به صورت دوره‌ای فرآیندها و انبارهای داده خود را تمیز کنید تا حساب‌های مشتریانی که دیگر از برنامه شما استفاده نمی‌کنند را حذف کنید. هنگام تمیز کردن حساب‌های کاربری بلااستفاده در گوگل ادز، نکات زیر را در نظر داشته باشید:

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