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

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

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

توجه: این بخش به یک تغییر آتی در Google Ads API اشاره دارد. برای کسب اطلاعات بیشتر به پست وبلاگ مراجعه کنید.

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

نسخه API	کد خطا
<= v17	QuotaError.RESOURCE_EXHAUSTED
>= v18	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.

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

پنجره زمانی	میانگین (p50).	P70 (متوسط ​​بالا)	P95 (بسیار زیاد)
کوتاه مدت (5 دقیقه)	6000	30000	1800000
بلند مدت (24 ساعت).	16000	90000	8400000

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

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

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

پنجره زمانی	میانگین	نسبتا بالا	خیلی بالا
کوتاه مدت (5 دقیقه)	10	50	3000
بلند مدت (24 ساعت).	26	150	14000

اجرای این الگوی پرس و جو 10 بار در 5 دقیقه به عنوان یک مصرف متوسط ​​محسوب می شود، در حالی که اجرای 3000 گزارش در 5 دقیقه به عنوان استفاده بسیار بالا به حساب می آید.

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

داده های خود را کش کنید

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

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

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 از 20000 گروه تبلیغاتی در هر کمپین و 10000 کمپین در هر حساب پشتیبانی می کند. بنابراین اگر این کد در برابر یک حساب 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(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);
  }

این کار باعث کاهش بار سرورهای 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 نامعتبر به سرورهای API Google خودداری کند.
• اگر مشتری حساب Google Ads خود را لغو کرده است، باید آن را شناسایی کنید و از ارسال تماس های API نامعتبر به سرورهای API Google خودداری کنید.
• پس از یک دوره زمانی مناسب، داده‌هایی را که از حساب‌های Google Ads مشتری دانلود کرده‌اید از پایگاه داده محلی خود حذف کنید.