إدارة كتالوج المنتجات

يوضّح هذا الدليل كيفية استخدام Google Play Developer API لإنشاء كتالوج منتجات و إدارته لتطبيقك على Play.

لبيع المنتجات في تطبيقك من خلال نظام الفوترة في Google Play، عليك إعداد كتالوج يتضمّن جميع المنتجات التي تريد إتاحة شرائها للمستخدمين. ويمكن إجراء ذلك من خلال Play Console، أو يمكنك أتمتة إدارة القائمة باستخدام Google Play Developer API. يمكن أن تساعدك ميزة التشغيل الآلي في ضمان تحديث الكتالوج دائمًا، وتوسيع نطاق استخدامها في الكتالوجات الكبيرة التي يتعذّر فيها التنسيق اليدوي. في هذا الدليل، ستتعرّف على كيفية استخدام واجهة برمجة التطبيقات Play Developer API لإنشاء وإدارة قائمة منتجات لتطبيقك على Play. راجِع دليل الاستعداد للحصول على تعليمات حول كيفية إعداد واجهة برمجة التطبيقات Google Play Developer API لدمج الخلفية.

واجهات برمجة التطبيقات لإدارة الكتالوج

للاطّلاع على أنواع المنتجات المختلفة التي يمكنك بيعها باستخدام نظام الفوترة في Google Play، يمكنك قراءة مقالة فهم الأنواع المختلفة للمنتجات داخل التطبيق ومعرفة معايير الكتالوج. تقدّم Google مجموعتَين رئيسيتين من واجهات برمجة التطبيقات لإدارة الكتالوج على Play، تتطابقان مع فئتَي المنتجات الرئيسيتَين:

• منتجات يتم تحصيل سعرها مرة واحدة
• المنتجات المتوفّرة عند الدفع

منتجات يتم تحصيل سعرها مرة واحدة

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

المنتجات المتوفّرة عند الدفع

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

ملاحظة: تتضمّن inappproducts API بعض الميزات القديمة لإدارة الاشتراكات، لأنّه في السابق كانت تتم إدارة جميع منتجات Google Play من خلال نقطة نهاية هذه. يجب التوقف عن استخدام نقطة النهاية هذه لإدارة المنتجات التي تتضمّن اشتراكات، ويجب نقل أي عمليات دمج لنشر الاشتراكات لاستخدام واجهة برمجة التطبيقات monetization.subscriptions الجديدة. لمزيد من المعلومات حول هذا الإيقاف، يُرجى زيارة مشاركة المدونة.

طرق المعالجة المجمّعة

توفّر نقطتا النهاية inappproducts وmonetization.subscriptions عددًا من طرق الحِزم التي تسمح باسترداد أو إدارة ما يصل إلى 100 عنصر ضمن التطبيق نفسه في الوقت نفسه.

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

تعديل وقت استجابة النشر مقارنةً بمعدل نقل البيانات

بعد اكتمال طلب إنشاء منتج أو تعديله، قد لا تظهر التغييرات على الفور للمستخدمين النهائيين على أجهزتهم بسبب تأخّر معالجة الشبكة أو الخلفية. تكون جميع طلبات تعديل المنتجات حساسة للوقت المستغرَق في المعالجة تلقائيًا. وهذا يعني أنّه تم تحسينها للنشر السريع من خلال أنظمة الخلفية، ما يؤدي عادةً إلى ظهورها على أجهزة المستخدمين النهائيين في غضون دقائق. ومع ذلك، هناك حدّ أقصى لعدد طلبات التعديل هذه في الساعة. في الحالات التي تحتاج فيها إلى إنشاء العديد من المنتجات أو تعديلها (على سبيل المثال، أثناء إنشاء كتالوج كبير في البداية)، يمكنك استخدام طرق المعالجة المجمّعة مع ضبط الحقل latencyTolerance على PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. سيؤدي ذلك إلى زيادة كبيرة في معدل نقل البيانات للتعديلات. إنّ التحديثات التي تتيح وقت استجابة طويلًا ستستغرق مدة تصل إلى 24 ساعة للانتشار على أجهزة المستخدمين النهائيين.

ضبط الحصة

هناك العديد من حدود الحصص التي يجب أن تكون على دراية بها عند استخدام واجهة برمجة التطبيقات Play Developer API لإدارة قائمة منتجاتك:

1. تفرض واجهات برمجة التطبيقات Google Play Developer API حدًا تلقائيًا يبلغ 200,000 طلب بحث في اليوم. ينطبق حدّ الحصة هذا على تجميع الاستخدام في جميع نقاط النهاية، بما في ذلك واجهات برمجة التطبيقات لإدارة القائمة.
2. تفرض نقاط نهاية تعديل المنتجات أيضًا حدًا أقصى يبلغ 7,200 طلب بحث في الساعة. هذا الحدّ المسموح به ينطبق على كلّ من المنتجات لمرة واحدة والاشتراكات وعلى جميع طلبات التعديل، بما في ذلك الإنشاء والتعديل والتنشيط والحذف. يتم احتساب عمليات استدعاء طريقة التعديل المجمّع كطلب بحث واحد لهذه الحصة، بغض النظر عن عدد الطلبات الفردية المضمّنة أو حساسية وقت الاستجابة.
3. يُرجى العِلم أنّ التعديلات الحسّاسة للوقت المستغرَق في الردّ لها أيضًا حدّ أقصى يبلغ 7,200 تعديل في الساعة. بالنسبة إلى طرق الحِزم، يتم احتساب كل طلب تعديل متداخل بشكلٍ منفصل بغرض هذه الحصة. لا تترتّب على هذه الحصة سوى تبعات عملية عملية لمستخدمي واجهة برمجة تطبيقات الدفعات الذين يجرون تعديلات حساسة للوقت الفاصل بين إرسال الطلب وتلقّيه، لأنّه في الحالات الأخرى سيتم استنفاد الحصة 2 قبل هذه الحصة أو في الوقت نفسه.

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

• سيستهلك طلب واحد من get لجلب عنصر واحد رمزًا مميزًا واحدًا من الحصة 1 ولا يستهلك أي رموز مميّزة من الحصة 2 و3 (لأنّها تتعلّق بنقاط نهاية التعديل فقط).
• سيستهلك طلب get مجمّع لجلب ما يصل إلى 100 عنصر أيضًا رمزًا مميزًا واحدًا من الحصة 1 بدون استخدام أي رموز مميّزة من الحصة 2 والحصة 3.
• سيستهلك طلب modification واحد لعنصر واحد رمزًا مميزًا للحصة 1 ورمزًا مميزًا للحصة 2. إذا كان الطلب حسّاسًا للوقت المستغرَق في إرسال البيانات، سيستهلك أيضًا رمزًا مميزًا واحدًا من الحصة 3. بما أنّ الحصة "ج" لها الحدّ الأقصى نفسه للحصة 2، فإنه ليس لها أثر عملي على المستخدِمين الذين يستخدِمون طُرق تعديل واحدة فقط.
• سيستهلك طلب modification مجمّع لـ 100 عنصر متوافق مع وقت الاستجابة رمزًا مميّزًا واحدًا من الحصة 1 ورمزًا مميّزًا واحدًا من الحصة 2. من المفترض أن يسمح إعداد الحصة هذا بمساحة واسعة للحفاظ على تحديث الكتالوج، ولكن إذا لم تكن الخوارزمية على دراية بهذه الحصة وتجاوزت هذا المعدّل، قد تظهر لك رسالة خطأ لكلّ طلب إضافي.
• سيستهلك طلب مجمّع modification لـ 100 عنصر حسّاس للوقت الاستجابة رمزًا مميزًا للحصة 1 ورمزًا مميزًا للحصة 2 و100 رمز مميز للحصة 3.

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

من خلال الالتزام بهذه الإرشادات، يمكنك تحسين تفاعلاتك مع واجهة برمجة التطبيقات، ما يضمن لك تجربة إدارة قائمة سلع سلسة وفعّالة.

مراقبة معدّل الاستخدام

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

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

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

• اختَر استراتيجية إدارة الكتالوج المناسبة. بعد التعرّف على حصة واجهة برمجة التطبيقات، عليك اختيار الاستراتيجية المناسبة لتطبيقك لتحقيق أهداف إدارة الكتالوج بكفاءة.
• أجرِ الحد الأدنى من المكالمات اللازمة لتطبيق التغييرات.
• لا ترسِل طلبات تعديل مكرّرة أو غير ضرورية إلى واجهات برمجة التطبيقات. قد يتطلّب ذلك الاحتفاظ بسجلّ تغييرات في قائمة المنتجات في الخلفية.
• يجب ألا تتجاوز عدد طلبات البحث في الساعة 7,200 طلب، وهو الحد الأقصى المسموح به لتعديل المنتجات. قد تحتاج إلى إنشاء عمليات مزامنة تتطلّب منك إجراء أعداد كبيرة من تعديلات المنتجات في فترة زمنية قصيرة (على سبيل المثال، إنشاء كتالوج أولي). إذا كنت تتوقع أن تتجاوز هذه العمليات الحد الأقصى للساعة، طبِّق فترات الانتظار حسب الضرورة لإبطاء الاستخدام إلى مستوى آمن. ننصحك باستخدام methods المعالجة المجمّعة مع التحديثات التي تتحمّل وقت الاستجابة لتحقيق معدل نقل بيانات أعلى.
• الاستعداد بشكل استباقي للتوسّع مع نمو تطبيقك، قد تحتاج إلى توسيع نطاق استخدامك لواجهة برمجة التطبيقات ونقاط النهاية المختلفة. اطّلِع على مستندات حصص Google Play Developer API لمعرفة تفاصيل عن كيفية زيادة حصتك عند الاقتراب من الحد الأقصى للاستخدام.
• جدولة العمليات المكثفة بشكل استراتيجي حاوِل جدولة العمليات المتعلّقة بتعديل الكتالوج في أوقات ذروة الاستخدام، على سبيل المثال، يمكنك تجنُّب تنفيذ عملية تتمثّل في مزامنة الكتالوج بالكامل خلال أوقات ذروة المبيعات في الأسبوع.

إضافة منطق معالجة أخطاء الحصة

بغض النظر عن مدى كفاءة إنشاء منطق إدارة الكتالوج، يجب أن يكون منطق إدارة الكتالوج مرنًا في مواجهة حدود الحصة غير المتوقّعة، نظرًا لأنّ الحصة اليومية تتم хувّتها بين نقاط النهاية المستخدَمة في الوحدات المستقلة لعملية الدمج. تأكَّد من تضمين أخطاء الحدّ من الحصة في معالجة الأخطاء، ونفِّذ فترات الانتظار المناسبة. سيؤدي كل طلب يتم إجراؤه إلى Google Play Developer API إلى إنشاء ردّ. في حال تعذُّر إكمال المكالمة، ستتلقّى ردًا يتضمّن رمز حالة ردّ HTTP وعنصر errors، ما يقدّم المزيد من التفاصيل عن نطاق الخطأ ورسالة تصحيح الأخطاء. على سبيل المثال، إذا تجاوزت الحدّ الأقصى اليومي، قد تظهر لك رسالة خطأ مشابهة للرسالة التالية:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

تنفيذ إدارة الكتالوج

يستخدم المطوّرون نقاط نهاية نشر المنتجات في Google Play Developer API للحفاظ على مزامنة كتالوجاتهم بين الخلفية وGoogle Play. إنّ التأكّد من أنّ كتالوج Google Play محدّث دائمًا ومتوافق مع أحدث المعلومات في كتالوج الخلفية له مزايا لتقديم تجربة أفضل للمستخدم. مثلاً:

• ستتمكّن من الرجوع إلى القائمة الكاملة للعروض المتاحة وإدارة علامات العروض والخطط الأساسية للتأثير في أهليتك ومنطق عرض العروض.
• يمكنك التحقّق من نقاط الأسعار المختلفة وتفاصيل المنتجات التي يشاهدها المستخدمون على جميع المنصات والتأكّد من أنّها متسقة.
• ستتوفّر لك تفاصيل المنتجات في الخلفية عند معالجة عمليات الشراء الجديدة، بدون الحاجة إلى زيادة وقت الاستجابة وخطر حدوث خطأ من خلال إجراء طلبات إضافية إلى Google Play Developer API أثناء عمليات المستخدمين المهمة.

هناك قيود واعتبارات معيّنة يجب أخذها في الاعتبار عند إنشاء قائمة منتجاتك على Google Play. بعد فهم هذه الحدود وتحديد كيفية تنظيم الكتالوج، حان وقت تحديد استراتيجية المزامنة.

استراتيجيات مزامنة الكتالوج

تتيح لك نقاط نهاية النشر في Google Play Developer API إجراء تعديلات على كتالوجك عند إجراء تغييرات. في بعض الأحيان، قد تحتاج إلى اتّباع نهج التعديلات المبرمَجة، حيث تُرسِل مجموعة من التغييرات في العملية نفسها. يتطلّب كل أسلوب خيارات تصميم مختلفة. ستلائم كل استراتيجية مزامنة بعض حالات الاستخدام بشكل أفضل من غيرها، وقد تكون لديك مجموعة من الاحتياجات التي تتطلّب استخدام كلتا الإستراتيجيتَين، حسب الحالة. في بعض الأحيان، قد تحتاج إلى إجراء تعديل على منتج في اللحظة التي تدرك فيها حدوث تغيير جديد، على سبيل المثال لمعالجة تعديل عاجل على المنتج (أي تعديل سعر غير صحيح في أقرب وقت ممكن). وفي حالات أخرى، يمكنك استخدام مزامنة دورية في الخلفية لضمان تطابق قاعدة البيانات وكتالوجات Play دائمًا. اطّلِع على بعض حالات الاستخدام الشائعة التي قد تحتاج فيها إلى تنفيذ استراتيجيات إدارة каталог مختلفة.

حالات إرسال التعديلات عند تغيير الكتالوج المحلي

من الأفضل إجراء التعديلات فور حدوث أي تغيير في كتالوج المنتجات في الخلفية، وذلك للحد من التناقضات.

يُعدّ هذا النوع من التعديلات خيارًا جيدًا في الحالات التالية:

• يجب التأكّد من أنّ منتجاتك محدّثة دائمًا.
• عليك إجراء بعض التغييرات على منتجاتك كل يوم.
• يجب تعديل المنتجات التي يتم إنتاجها حاليًا وبيعها.

من السهل تنفيذ هذا النهج، كما أنّه يتيح لك مزامنة كتالوجك مع أقل فترة زمنية للاختلاف.

حالات استخدام التحديثات الدورية

يتم تنفيذ التعديلات الدورية بشكل غير متزامن مع إصدار المنتج في الخلفية، وهي خيار جيد في الحالات التالية:

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

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

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

إنشاء كتالوج منتجاتك

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

إنشاء منتجات يتم تحصيل سعرها مرة واحدة

لإنشاء كتالوج كبير للمنتجات لمرة واحدة، ننصحك باستخدام طريقة inappproducts.batchUpdate مع ضبط الحقل allowMissing على true والحقل latencyTolerance على PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. سيؤدي ذلك إلى تقليل الوقت الذي يستغرقه إنشاء الكتالوج ضمن حدود الحصة.

بالنسبة إلى القوائم الأصغر حجمًا، يمكنك استخدام طريقة inapp_products.insert. بدلاً من ذلك، يمكنك استخدام الطريقة inappproducts.update مع المَعلمة allowMissing كما هو موضّح في قسم "تعديلات المنتج". تعود فائدة هذا النهج إلى عدم الحاجة إلى أن يكون النص البرمجي ذي حالة، ويمكن إعادة تشغيله من البداية في حال حدوث أي خطأ.

إنشاء منتجات متوفرة عند الدفع

لإنشاء كتالوج كبير في الاشتراك الأولي، ننصحك باستخدام monetization.subscriptions.batchUpdate مع ضبط الحقل allowMissing على true وضبط الحقل latencyTolerance على PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT. سيؤدي ذلك إلى تقليل الوقت الذي يستغرقه إنشاء الكتالوج ضمن حدود الحصة.

بالنسبة إلى كتالوجات الاشتراكات الأصغر حجمًا، توفّر واجهة برمجة التطبيقات Play Developer API طريقة monetization.subscriptions.create. يمكنك بدلاً من ذلك إنشاء اشتراكات باستخدام أسلوب monetization.subscriptions.patch مع المَعلمة allowMissing كما هو موضّح في قسم "تعديلات المنتج".

تنشئ جميع الطرق السابقة اشتراكات مع خططها الأساسية (المقدَّمة ضمن عنصر الاشتراك). تكون هذه الخطط الأساسية في البداية غير مفعّلة. لإدارة حالة الخطط الأساسية، يمكنك استخدام نقطة نهاية monetization.subscriptions.basePlans، بما في ذلك تفعيل خطط dasar لإتاحتها للشراء. بالإضافة إلى ذلك، تتيح لك نقطة نهاية monetization.subscriptions.basePlans.offers إنشاء العروض وإدارتها.

آخر الأخبار حول المنتج

تتيح لك الطرق التالية تعديل منتجاتك الحالية بكفاءة، وضمان توافق عروضك مع آخر تعديلاتك.

تعديل المنتجات التي تُستخدم لمرة واحدة

تتوفّر لك ثلاث طرق للمساعدة في تعديل المنتجات الحالية التي تُستخدم لمرة واحدة.

• inappproducts.patch : تُستخدَم نقطة نهاية التصحيح لتعديل مورد جزئيًا. وهذا يعني أنّه يمكنك تعديل حقول معيّنة تحدّدها في محتوى الطلب. تُستخدَم نقطة نهاية التصحيح عادةً عندما تحتاج إلى تعديل بضعة حقول فقط في أحد الموارد.
• inappproducts.update : تُستخدَم نقطة نهاية التعديل لتعديل مورد بالكامل. ويعني ذلك أنّك ستحتاج إلى إرسال عنصر المورد بالكامل في محتوى الطلب. تُستخدَم نقطة نهاية التعديل عادةً عندما تحتاج إلى تعديل جميع الحقول في مصدر. عند ضبط المَعلمة allowMissing على true وعدم توفّر معرّف المنتج الذي تم تقديمه، ستُدرج نقطة النهاية المنتج بدلاً من تعذُّر إتمام العملية.
• ‫inappproducts.batchUpdate : هذا إصدار مجمّع من نقطة نهاية التعديل، ما يتيح لك تعديل منتجات متعددة باستخدام طلب بحث واحد. استخدِم هذا الإجراء مع الحقل latencyTolerance الذي تم ضبطه على PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT لتحقيق معدل نقل بيانات أعلى.

تعديل المنتجات المتوفّرة عند الاشتراك

لتعديل الاشتراكات الحالية، يمكنك استخدام الطريقة monetization.subscriptions.patch. تأخذ هذه الطريقة المَعلمات المطلوبة التالية:

• ‫packageName: اسم حزمة التطبيق الذي ينتمي إليه الاشتراك
• ‫productId: معرّف المنتج الفريد للاشتراك
• regionsVersion: إصدار إعدادات المنطقة

يجب تقديم المَعلمة updateMask ما لم تكن بصدد إنشاء اشتراك جديد باستخدام المَعلمة allowMissing. هذه المَعلمة هي قائمة مفصولة بفواصل للحقول التي تريد تعديلها.

على سبيل المثال، إذا كنت تريد تعديل بطاقة بيانات منتج متوفّر عند الاشتراك فقط، يمكنك تحديد الحقل listings للمَعلمة updateMask.

يمكنك استخدام monetization.subscriptions.batchUpdate لتعديل اشتراكات متعددة في الوقت نفسه. استخدِم هذا الحقل مع ضبط الحقل latencyTolerance على PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT لتحقيق معدل نقل بيانات أعلى.

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

بالإضافة إلى ذلك، يمكنك تعديل عروض الخطط الأساسية باستخدام الطريقة monetization.subscriptions.basePlans.offers.patch.

تسوية الكتالوج

سواء اخترت تعديل قائمة Google Play كلما تغيّر каталог الخلفي أو بشكل دوري، إذا كان لديك نظام لإدارة القائمة أو قاعدة بيانات خارج قائمة Google Play، قد تحدث حالات تتعذّر فيها مزامنة القائمة مع القائمة في إعدادات تطبيقاتك على Play. قد يرجع ذلك إلى تغييرات يدوية طارئة في الكتالوج في "وحدة التحكّم" أو انقطاع في الخدمة في نظام إدارة الكتالوج أو فقدان أحدث بياناتك.

يمكنك إنشاء عملية مصالحة للبيانات في القائمة لتجنُّب فترة اختلاف طويلة.

مراعاة نظام الاختلافات

ننصحك بإنشاء نظام اختلافات لرصد التناقضات وحلّ المشاكل في النظامَين. في ما يلي بعض النقاط التي يجب مراعاتها عند إنشاء نظام اختلافات للمساعدة في مزامنة القوائم:

• فهم نماذج البيانات: الخطوة الأولى هي فهم نماذج data المخصّصة للمطوّرين في نظام إدارة المحتوى (CMS) وGoogle Play Developer API. ويشمل ذلك معرفة الأنواع المختلفة من البيانات المخزّنة في كل نظام، وكيفية ربط عناصر البيانات المختلفة ببعضها.
• تحديد قواعد الاختلاف: بعد فهم نماذج البيانات، عليك تحديد قواعد الاختلاف. ستحدّد هذه القواعد كيفية مقارنة البيانات في النظامَين. على سبيل المثال، قد تحتاج إلى مطابقة معرّفات المنتجات ومقارنة السمات الرئيسية للاشتراك والخطط الأساسية والمعروضات المرتبطة به.
• تنفيذ خوارزمية الاختلاف: بعد تحديد قواعد الاختلاف، عليك تنفيذ خوارزمية الاختلاف. ستستخرج هذه الخوارزمية البيانات من النظامَين وتقارنها وفقًا للقواعد التي حدّدتها. للحصول على بيانات الكتالوج من Google Play، يمكنك استخدام الإجراءَين inappproducts.list و inappproducts.batchGet و monetization.subscriptions.list و monetization.subscriptions.batchGet.
• إنشاء تقارير الاختلافات: ستنشئ خوارزمية الاختلافات تقرير اختلافات. سيوضّح هذا التقرير الاختلافات بين النظامَين.
• تسويف الاختلافات: بعد إنشاء تقرير الاختلافات، عليك حلّ الاختلافات. قد يشمل ذلك تعديل البيانات في نظام إدارة المحتوى (CMS)، أو قد يشمل تعديل البيانات من جانب Google Play باستخدام نقاط نهاية إدارة كتالوج Developer API، وذلك استنادًا إلى الطريقة المعتادة لتعديل كتالوجك. لمطابقة المنتجات غير المتزامنة، استخدِم نقاط نهاية التعديل كما هو موضّح في قسم "تعديلات المنتجات".

إيقاف المنتج نهائيًا

توفّر واجهة برمجة التطبيقات Google Play Developer API عدة طرق لمساعدة المطوّرين في إيقاف منتجاتهم نهائيًا: inappproducts.delete و inappproducts.batchDelete للمنتجات التي يتم شراؤها لمرة واحدة و monetization.subscriptions.delete للاشتراكات. قد يكون من الضروري إيقاف منتج نهائيًا في سيناريوهات مختلفة، مثل:

• تمّ الإنشاء عن طريق الخطأ.
• إيقاف ميزة أو خدمة

ننصحك بدمج إيقاف المنتجات نهائيًا في استراتيجية إدارة الكتالوج.

إيقاف المنتجات التي يتم تحصيل سعرها مرة واحدة نهائيًا

لحذف المنتجات لمرة واحدة باستخدام Google Play Developer API، عليك استخدام inappproducts.delete أوinappproducts.batchDelete الطريقة.

إيقاف المنتجات المتوفّرة عند الاشتراك نهائيًا

يمكنك حذف الاشتراكات باستخدام الطريقة monetization.subscriptions.delete. لا يمكن إزالة اشتراك بعد فعالية خطة أساسية واحدة على الأقل.