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

من الوظائف الأساسية للعديد من تطبيقات "إعلانات 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

يعرض الجدول التالي إحصاءات مجمّعة حول استهلاك الموارد لأنماط الطلبات المختلفة على خوادم 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(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" غير المستخدَمة، عليك مراعاة الإرشادات التالية:

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