تستند البنية الأساسية الجديدة للنصوص البرمجية في "إعلانات Google" إلى Google Ads API. بسبب البنية المختلفة لواجهة برمجة التطبيقات هذه، قد تحتاج إلى تعديل النصوص البرمجية الحالية. لقد بذلنا قصارى جهدنا لضمان أكبر قدر ممكن من التوافق مع الإصدارات القديمة، لذا من المفترض أن تكون هذه التغييرات طفيفة.
التقارير
سيستمر عمل العديد من تقارير AWQL. في الخفاء، عند استخدام البنية الأساسية الجديدة، ستحوّل النصوص البرمجية طلب البحث بتنسيق AWQL إلى GAQL (لغة الطلب الجديدة لواجهة برمجة التطبيقات مع "إعلانات Google")، وسيتم تنفيذه ضد الخلفية الجديدة، ثم تحويل النتائج مرة أخرى إلى التنسيق الذي كانت تستخدمه تقارير AWQL في الأصل. سيتمّ تمرير طلبات البحث التي تستخدم لغة GAQL كما هي.
لهذا السبب، ننصحك بالاطّلاع على النصوص البرمجية وتعديل طلبات البحث في AWQL إلى GAQL كلما أمكن ذلك. يمكنك استخدام أداة نقل طلبات البحث التي تستخدم المنطق نفسه الخاص بالنصوص البرمجية لتحديد طلب بحث GAQL لطلب بحث AWQL معيّن، أو يمكنك استخدام أداة إنشاء طلبات البحث التفاعلية للمساعدة في إنشاء طلبات البحث.
في ما يلي بعض القيود المفروضة على الترجمة التلقائية من AWQL إلى GAQL:
- لا تتم ترجمة بعض طلبات البحث في AWQL إلى طلبات البحث في GAQL بوضوح. وفي هذه الحالات، سيتم تسجيل رسالة خطأ تتضمّن بعض التفاصيل حول المشكلة التي حدثت، وذلك بهدف مساعدتك في حلّها يدويًا.
- لا تتوفّر بعض أنواع التقارير من AWQL في GAQL.
- لا تتوافق GAQL مع "صفر مرات ظهور". سيؤدي تحديد أنّه ينبغي أن يتضمّن التقرير عددًا صفريًا من مرات الظهور إلى حدوث خطأ.
- لا يمكن استخدام بعض الحقول المتعدّدة المعاني في الفلاتر. على سبيل المثال، يمكن أن يشير الحقل "العنوان" إلى أي عدد من حقول الإعلانات المختلفة.
- قد تعرض بعض الحقول نتائج بتنسيق مختلف، على سبيل المثال، تقسيم نتيجة واحدة إلى عدة أعمدة.
جارٍ تنظيم أدوات الاختيار
عند جلب الموارد باستخدام النصوص البرمجية، من الشائع استخدام طلبات
withCondition وorderBy لتقييد النتائج أو ترتيبها في
المكرّر. تستخدم الحقول في هذه الطلبات الآن أسماء Google Ads API الجديدة. على سبيل المثال، للفلترة حسب اسم الحملة، كان عليك في السابق استخدام:
.withCondition('CampaignName = "SOME_CAMPAIGN_NAME"')
الآن، يجب استخدام أسماء الحقول الجديدة لهذه الشروط كلما أمكن ذلك:
.withCondition('campaign.name = "SOME_CAMPAIGN_NAME"')
ومع ذلك، بذلنا جهدًا لتضمين عملية ربط الأسماء القديمة للأسماء الجديدة، وبالتالي إذا كان النص البرمجي لا يزال يستخدم CampaignName، سيتم استبداله تلقائيًا بـ campaign.name في وقت التشغيل لضمان استمرار عمل النص البرمجي. إذا
واجهت أي مشاكل في أسماء الأنماط القديمة، عدِّل نصوصك البرمجية ل
استخدام أسماء الأنماط الجديدة كخطوة أولى في تحديد المشاكل وحلّها.
الحدود
إنّ العديد من الحدود هي نفسها في البنية الأساسية القديمة، وتهدف المناقشة التالية إلى توضيح التغيُّرات التي تم إجراؤها هنا والتي ستساعد بشكل عام في تحسين الأداء.
- الحدود الزمنية متطابقة. يمكن تنفيذ نص برمجي لمدة 30 دقيقة.
- يعرض العنصر التكراري الواحد 50,000 عنصر تلقائيًا، ولكن يمكن تجاوز هذا العدد. في السابق، لم يكن بإمكانك تخصيص هذا الحدّ الأقصى البالغ 50,000.
- يمكن أن يعالج أداة اختيار واحدة 10,000 معرّف كحدّ أقصى (بدون تغيير).
- ما من حدّ أقصى لعدد الكيانات التي يمكن معالجتها في نص برمجي واحد في البنية الأساسية الجديدة. وكان الحدّ الأقصى السابق 250,000.
- لا تفرض البنية الأساسية الجديدة أيّ قيود على عدد الكلمات الرئيسية أو الإعلانات التي يمكن إنشاؤها لكلّ تنفيذ. وكان الحدّ الأقصى السابق 250,000.
- يتم اقتطاع مخرجات التسجيل عند 100 كيلوبايت (بدون تغيير).
- لم يتم إجراء أي تغييرات على حصص خدمات Apps Script (SpreadsheetApp وMailApp وما إلى ذلك).
- وسيتم فرض الحصص في "إعلانات Google" كما لو كنت تستخدِم واجهة برمجة التطبيقات. وهذا يعني أنّ النص البرمجي سيخضع لحدود معدّل الزحف إلى واجهة برمجة التطبيقات، ولكنّه يتيح مزيدًا من المرونة للوصول إلى المزيد من التقارير أو إجراء المزيد من التغييرات في كل عملية تنفيذ.
التغييرات الأخرى
ولم يعُد getRemainingCreateQuota() أو getRemainingGetQuota() معروضَين في ExecutionInfo
، لأنّ هذه الحصص لم تعُد سارية في التجربة الجديدة.