إدارة البيانات بكفاءة

من الوظائف الأساسية للعديد من تطبيقات "إعلانات Google" استرداد بيانات الحساب لحالات استخدام مثل تحليل البيانات واستعلامات العملاء وعمليات التحقّق من الامتثال للسياسات. أثناء جلب البيانات، عليك تحسين استخدامك لكي لا تفرط في تحميل خوادم Google، أو تتعرّض لحدود المعدّل. لمزيد من التفاصيل، يُرجى الاطّلاع على الأدلة حول حدود المعدّل والحفاظ على عنوان بريد إلكتروني حديث للتواصل.

التعرّف على سياسة استخدام موارد Google للتقارير

لضمان استقرار خوادمها، تحدّ Google Ads API من GoogleAdsService.Search و GoogleAdsService.SearchStream أنماط طلبات البحث التي تستهلك كميات كبيرة من موارد واجهة برمجة التطبيقات. إذا تمّ الحدّ من نمط طلب بحث معيّن، ستستمر الخدمات والطرق وأنماط طلبات البحث الأخرى في العمل بدون أي تأثير. يتم عرض الأخطاء التالية للطلبات التي تمّ الحدّ منها:

إذا ظهرت لك هذه الأخطاء، انتظِر 5 دقائق قبل إعادة محاولة الطلبات التي تعذّر إتمامها بسبب QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION، و30 دقيقة للطلبات التي تعذّر إتمامها بسبب QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

لمساعدتك في تحديد تقاريرك المكلّفة وتتبُّعها، سنعرض أيضًا مقياس تكلفة للتقارير الفردية.

يعتمد مقياس التكلفة الذي تعرضه هذه الحقول على عوامل مختلفة، مثل

• حجم حساباتك
• طُرق العرض والأعمدة التي تجلبها في تقاريرك
• التحميل على خوادم 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 دقائق كاستخدام عالٍ جدًا.

هناك عدّة استراتيجيات لتحسين استهلاك الموارد في تقاريرك. ويتناول الجزء المتبقي من هذا الدليل بعضًا من هذه الاستراتيجيات.

تخزين بياناتك مؤقتًا

عليك تخزين تفاصيل الكيانات التي تجلبها من خوادم واجهة برمجة التطبيقات مؤقتًا في قاعدة بيانات محلية بدلاً من الاتصال بالخادم في كل مرة تحتاج فيها إلى البيانات، خاصةً للكيانات التي يتم الوصول إليها بشكلٍ متكرّر أو التي تتغيّر بشكلٍ غير متكرّر. استخدِم حدث التغيير وحالة التغيير حيثما أمكن لرصد العناصر التي تغيّرت منذ آخر مرة تمت فيها مزامنة النتائج.

تحسين معدّل تكرار تشغيل التقارير

نشرت "إعلانات Google" إرشادات حول سرعة توفُّر البيانات ومعدّل تكرار تعديل البيانات. عليك استخدام هذه الإرشادات لتحديد معدّل تكرار جلب التقارير.

إذا كنت بحاجة إلى تعديل الحسابات بشكلٍ منتظم، ننصحك بالحدّ من عدد هذه الحسابات إلى مجموعة صغيرة، مثلاً، أول عشرين حسابًا على "إعلانات Google" فقط. يمكن تعديل الحسابات المتبقية بمعدّل تكرار أقل، مثلاً، مرة أو مرّتين في اليوم.

تحسين حجم تقاريرك

يجب أن يجلب تطبيقك مجموعات كبيرة من البيانات بدلاً من تشغيل عدد كبير من التقارير الصغيرة. من العوامل التي تؤثر في هذا الاختيار حدود الحساب.

على سبيل المثال، لنفترض أنّ الرمز البرمجي التالي يجلب الإحصاءات لمجموعات إعلانية معيّنة ويعدِّل جدول قاعدة بيانات الإحصاءات:

  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" ما يصل إلى 20,000 مجموعة إعلانية لكل حملة و10,000 حملة لكل حساب. لذلك، إذا تم تشغيل هذا الرمز البرمجي على حساب كبير على "إعلانات Google"، يمكن أن يؤدي ذلك إلى إفراط تحميل خوادم 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" غير المستخدَمة، عليك مراعاة الإرشادات التالية:

• إبطال التفويض الذي منحه العميل لتطبيقك لإدارة حسابه
• التوقّف عن إجراء طلبات بيانات من واجهة برمجة التطبيقات لحسابات العميل على "إعلانات Google" ينطبق ذلك بشكلٍ خاص على المهام غير المتصلة بالإنترنت، مثل مهام cron ومسارات البيانات المصمّمة للتشغيل بدون تدخّل من المستخدِم.
• إذا أبطَل العميل التفويض، يجب أن يتعامل تطبيقك مع الموقف بشكلٍ سليم ويتجنّب إرسال طلبات بيانات غير صالحة من واجهة برمجة التطبيقات إلى خوادم واجهة برمجة التطبيقات من Google.
• إذا ألغى العميل حسابه على "إعلانات Google"، عليك رصد ذلك وتجنُّب إرسال طلبات بيانات غير صالحة من واجهة برمجة التطبيقات إلى خوادم واجهة برمجة التطبيقات من Google.
• بعد فترة زمنية مناسبة، احذف البيانات التي نزّلتها من حسابات العميل على "إعلانات Google" من قاعدة بياناتك المحلية.