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

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

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

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

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

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

• اندازه حساب های شما
• نماها و ستون هایی که در گزارش های خود واکشی می کنید
• بارگذاری روی سرورهای Google Ads API.

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

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

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

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

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