أفضل الممارسات

يقدّم هذا المستند إرشادات حول أفضل الممارسات. يمكنك الاطّلاع على نصائح حول الأداء للحصول على مزيد من المعلومات.

حالات استخدام واجهة برمجة التطبيقات

لإرسال الطلبات آليًا

سواء كنت تفضّل أتمتة كل جزء من سير عملك أو إنشاء عنصر جذب في نظام تخطيط موارد المؤسسات (ERP)، تسمح لك Content API بإرسال التحديثات فور تغيير المستودع.

لتلقي ملاحظات فورية

في Content API، تحصل على ردّ على كل طلب بشكل فوري، وليس من خلال ملخّص عبر البريد الإلكتروني بعد معالجة خلاصات البيانات. من المتوقع أن يستغرق وقت الاستجابة من 5 إلى 10 ثوانٍ للطلبات الكبيرة الكبيرة.

تغيير بيانات منتجاتك بشكل متكرّر

باستخدام Content API، يمكنك إجراء تعديلات تدريجية على مستودع منتجاتك السريع التحرك عدة مرات في اليوم، بينما لا يكون من الممكن إرسال خلاصة البيانات الكاملة في كل مرة. إذا أصبحت التحديثات متاحة بشكل فردي، فأرسلها بشكل فردي، ولا تنتظر حتى يتوفر العديد من التحديثات حتى تتمكن من تجميعها. وبالمثل، في حال توفّر التحديثات على دفعات، أرسِلها على دفعات ولا تقسّمها إلى طلبات فردية.

لإدارة عدة حسابات فرعية

إنّ حسابات Merchant Center التي تم إنشاؤها حديثًا هي حسابات فردية تحتفظ بمجموعتها الخاصة من بيانات المنتجات. وهذا يعمل بشكل جيد في معظم الحالات، ولكن مع نمو حسابك، قد تجد أنك بحاجة إلى نظام إدارة أكثر تعقيدًا لمنتجاتك. إذا كان هذا الأمر ينطبق عليك، ننصحك باستخدام حساب متعدّد العملاء أو MCA. يمكن إدارة حساب متعدّد العملاء على مستوى واجهة برمجة التطبيقات من خلال خدمة "الحسابات"، ما يتيح إضافة الحسابات الفرعية وإدارتها بشكل آلي. يمكنك الاطّلاع هنا على مزيد من المعلومات حول كيفية الحصول على حساب متعدّد العملاء.

كيفية استخدام واجهة برمجة التطبيقات

عدم استخدام واجهة برمجة التطبيقات كما هو الحال عند استخدام خلاصات البيانات

تجنَّب إجراء تعديلات يومية على خلاصة المنتجات بأكملها عند استخدام مرجع products. بدلاً من ذلك، احرص على تحديث المنتجات التي تغيرت بياناتها بالفعل فقط. يؤدي إرسال خلاصة البيانات بأكملها عبر مورد products إلى استهلاك المزيد من الوقت والموارد لكل من Google وGoogle.

عدم استخدام واجهة برمجة التطبيقات لاسترداد معلومات المنتج التي حمّلتها بانتظام

إذا كنت مسؤولاً عن حفظ معلومات المنتجات في حساب معيّن على Merchant Center، تجنَّب طلب معلومات المنتجات من Content API عبر الطريقتَين products.get أو products.list بشكل منتظم. بالنسبة إلى العملاء الذين يحمّلون المعلومات، يمكن أن تساعدك هذه الطرق في تصحيح الأخطاء عند تصميم الحلول التي تستخدم Content API. ومع ذلك، فهي ليست مخصّصة لاسترجاع معلومات المنتجات بانتظام من قِبل هؤلاء العملاء. يجب أن يكون لديك مصدر آخر لمعلومات المنتجات، مثل قاعدة بيانات المنتجات المحلّية، ويجب أن تعكس المنتجات في Merchant Center محتوى ذلك المصدر.

لا تستخدِم خلاصات البيانات وContent API معًا لإرسال سلع المنتجات.

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

هل مِن طريقة لاستخدام واجهة برمجة التطبيقات وخلاصات البيانات معًا بأمان؟

يمكنك معالجة خلاصات البيانات باستخدام خدمة Datafeed الخاصة بواجهة برمجة التطبيقات. وعلى الرغم من أنّ ذلك سيسهّل إدارة خلاصة البيانات على نطاق واسع، تذكَّر أنّه يجب عدم إدراج المنتجات أو تعديلها باستخدام واجهة برمجة التطبيقات بالتزامن مع الخلاصات، لأنّه قد تحدث نتائج غير متوقَّعة.

في ما يلي بعض الأمثلة الأخرى على الطرق المقبولة لاستخدام الخلاصات وواجهة برمجة التطبيقات:

  • تنفيذ طلبات للقراءة فقط (الحصول عليها أو إدراجها) من واجهة برمجة التطبيقات: يريد بعض التجّار استخدام واجهة برمجة التطبيقات لجلب المعلومات وتحديثات الحالة الخاصة بمنتجاتهم. ويُعدّ ذلك مقبولاً لأنّه يتم تعديل معلومات المنتجات من خلال الخلاصات فقط.

  • استخدام واجهة برمجة التطبيقات لإدارة حساباتك الفرعية (خدمة الحسابات) و/أو إعدادات الضريبة والشحن على مستوى الحساب (خدمة Accounttax و خدمة Shippingsettings) وهذه ليست وظائف يمكن أن توفّرها Datafeeds، وبالتالي لن يحدث أي تعارض مع استخدام واجهة برمجة التطبيقات لإدارة هذه الدوال.

كيف يمكنني الانتقال من استخدام خلاصات البيانات إلى استخدام واجهة برمجة التطبيقات فقط أو العكس؟

إذا كنت تستخدم حاليًا خلاصات البيانات وتريد التبديل إلى استخدام واجهة برمجة التطبيقات فقط لتعديل المنتجات، عليك إعادة تحميل بيانات المنتجات باستخدام واجهة برمجة التطبيقات. عند استخدام خدمة المنتجات لتعديل منتج معيّن، تتحكّم واجهة برمجة التطبيقات في معلومات المنتج، ولن يؤدي حذف المنتج من خلاصة البيانات أو حذف خلاصة البيانات نفسها إلى إزالة معلومات المنتج من حسابك على Merchant Center. تأكَّد من عدم إجراء أيّ تعديلات على خلاصة البيانات إذا كنت تريد إزالة المنتج من خلاصة البيانات أو من خلاصة البيانات نفسها، وإلّا ستتم إعادة ملكية خلاصة البيانات وستؤدي إزالة المنتج من خلاصة البيانات إلى إزالته.

إذا كنت تستخدم حاليًا واجهة برمجة التطبيقات لمعلومات المنتجات فقط وكنت تريد استخدام خلاصات البيانات كمصدر أساسي لمعلومات المنتجات، يمكنك ببساطة إضافة خلاصة البيانات الجديدة إلى حسابك على Merchant Center وسيحصل مالك المحتوى على ملكية منتجاته المُدرجة. إذا كانت هناك منتجات تريد إزالتها قبل انتهاء صلاحيتها وتم تحميلها من واجهة برمجة التطبيقات فقط، عليك حذفها إما عبر Merchant Center أو عبر واجهة برمجة التطبيقات.

كيف أستهدف بلدانًا متعدّدة باستخدام منتجات باستخدام Content API for Shopping؟

لاستهداف بلدان متعدّدة من خلال إعلانات وبيانات مجانية للمنتجات المرسَلة من خلال Content API، يمكنك ضبط بلدان إضافية في خلاصة Content API الأساسية في Merchant Center أو إضافة هذه البلدان الإضافية من خلال الحقل shipping في المرجع products.

في ما يلي مثال على كيفية تعديل إعدادات الخلاصة الأساسية في Content API.

للمزيد من المعلومات، يُرجى الاطّلاع على: استهداف إعلانات Shopping والبيانات المجانية في بلدان متعدّدة.

يجب أن تكون مكتبات البرامج محدَّثة.

إذا كنت تستخدم إحدى مكتبات عملاء Google للتفاعل مع Content API، تأكّد من استخدام مدير الحِزم للغة البرمجة التي اخترتها وتأكَّد من أنّ إصدار المكتبة محدَّث. لمزيد من المعلومات، اطّلِع على دليل المطوّر للّغة التي اخترتها في عيّنات والمكتبات.

تأكَّد من استخدام سمات الوجهات لتحديد المنتجات التي تظهر في برامج التسوّق المختلفة.

تستخدم Content API الإعدادات التلقائية لخلاصة Content API تلقائيًا كما تم ضبطها في Merchant Center. يمكنك استخدام سمتَي المنتج includedDestinations أو excludedDestinations للتحكّم في المشاركة في البرنامج على مستوى منتج داخل خلاصة أو عبر Content API.

إذا كانت خلاصة واجهة برمجة التطبيقات مفعّلة في أحد البرامج، مثل "الشراء على Google" (المعروف سابقًا باسم Shopping Actions)، ولكنّك تريد استبعاد منتجات معيّنة، استخدِم السمة excludedDestinations وحدِّد Shopping Actions كقيمة. سيتم استبدال إعدادات الخلاصة التلقائية في Merchant Center بشرط عدم حدوث أي أخطاء، ولن يتم عرض هذه السلعة في "الشراء على Google" (المعروفة سابقًا باسم Shopping Actions). وبالعكس، إذا لم يتم تفعيل خلاصتك في أحد البرامج، مثل Shopping، يمكنك تضمين سلع فردية باستخدام السمة includedDestinations وShopping_ads باعتبارها القيمة وستظهر السلعة في إعلانات Shopping.

لمزيد من المعلومات حول سمتَي المنتج includedDestinations وexcludedDestinations، يمكنك الانتقال إلى مركز المساعدة.

احرص على تعديل السلع قبل انتهاء صلاحيتها

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

يجب عدم حذف خلاصة Content API وإلا قد تختفي منتجاتك.

في المرة الأولى التي تحمّل فيها منتجًا من خلال channel:online عبر Content API، ستظهر خلاصة جديدة في Merchant Center بعنوان Content API. في المرة الأولى التي تحمّل فيها منتجًا من خلال channel:local عبر Content API، ستظهر خلاصة جديدة في Merchant Center بعنوان Content API مع عنوان فرعي: المنتجات المحلية. تأكَّد من عدم حذف خلاصة Content API أو خلاصة Content API المحلية عن طريق الخطأ. استنادًا إلى الخلاصة التي تحذفها، ستتم إزالة المنتجات المحلية أو الإلكترونية التي أضفتها إلى Merchant Center عبر Content API.

تجميع طلبات متعددة في الخدمة نفسها باستخدام طريقة الدفعة المخصصة

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

عدم إرسال تحديثات متعددة لعنصر واحد في دفعة واحدة

سيؤدي ذلك إلى نتائج غير متوقعة بسبب عدم التأكد من تسلسل التحديثات، وقد يؤدي إلى خطأ تعارض.

عدم إرسال تحديثات للعناصر التي لم يتم تغييرها

تأكد من إرسال طلبات لعناصر المنتجات الجديدة أو التي تم تغييرها أو حذفها فقط، إلا إذا كانت صلاحية السلع ستنتهي في الحالات الأخرى.

استخدام الخلاصات التكميلية في حال تغيّر الأسعار و/أو مدى التوفّر بسرعة

إذا كنت تواجه مشكلة في تعديل معلومات سعر المنتج أو مدى توفّره أو تخفيضه، ننصحك باستخدام الخلاصات التكميلية في مرجع products لإرسال التعديلات لهذه السمات فقط. وبما أنّ التعديلات على الخلاصات التكميلية صغيرة، يمكنك إجراء المزيد من التعديلات على الخلاصات التكميلية خلال فترة معيّنة بدلاً من إجراء تعديلات كاملة على المنتجات، ما يساعد في الحفاظ على توافق أسعار المنتجات ومدى توفّرها مع الصفحات المقصودة.

يمكنك أيضًا استخدام التعديلات التلقائية على بيانات السلع لتعديل أسعار المنتجات ومدى توفّرها. يمكن استخدام ذلك بالإضافة إلى تعديلات واجهة برمجة التطبيقات للمساعدة في تجنُّب حالات عدم التطابق بين المعلومات الواردة في Merchant Center والمعلومات الواردة في الصفحات المقصودة للمنتجات. مع ذلك، تذكَّر أنّ هذه الميزة مصمّمة لحلّ المشاكل البسيطة المتعلّقة بدقة سعر المنتج ومدى توفّره، وبالتالي لا تشكّل التعديلات التلقائية على بيانات السلع بديلاً عن تقديم المعلومات الصحيحة عبر واجهة برمجة التطبيقات.

حالات استخدام الرمز المميز للتحديث

يتم عرض الرمز المميز لإعادة التحميل في عنوان HTTP لطلبات التفويض. ويحتوي التطبيق على الكثير من المعلومات الأخرى المتعلقة بالمصادقة، غير أنّ الرمز المميّز للتحديث غالبًا ما يكون هو الجزء الذي يريد المطوّرون الحصول عليه، لأنّه يلغي الحاجة إلى طلب المصادقة من المستخدم بشكل متكرّر، لأنّ رموز الدخول لا تدوم سوى 60 دقيقة قبل انتهاء صلاحيتها.