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

project: /google/play/billing/_project.yaml book: /google/play/billing/_book.yaml

يوضّح هذا الدليل كيفية استخدام 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، وهما تتوافقان مع فئتَي المنتجات الرئيسيتَين:

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

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

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

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

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

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

طُرق الدفعات

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

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

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

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

إعدادات الحصة

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

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

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

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

اقتراحات بشأن استخدام Catalog Management API

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

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

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

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

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

  • اختيار استراتيجية إدارة الكتالوج المناسبة بعد فهم حصة واجهة برمجة التطبيقات، عليك اختيار الاستراتيجية المناسبة لتطبيقك من أجل تحقيق أهداف إدارة الكتالوج بكفاءة.
  • يجب إجراء الحدّ الأدنى من المكالمات اللازمة لعرض التغييرات.
  • لا ترسِل طلبات تعديل مكرّرة أو غير ضرورية إلى واجهات برمجة التطبيقات. وقد يتطلّب ذلك الاحتفاظ بسجلّ تغييرات في الفهرس الخلفي.
  • يجب أن يكون عدد طلبات البحث أقل من الحدّ الأقصى المسموح به كل ساعة لتعديل المنتجات، وهو 7,200 طلب. قد تحتاج إلى إنشاء عمليات مزامنة تتطلّب إجراء عدد كبير من التعديلات على المنتجات في فترة زمنية قصيرة (على سبيل المثال، إنشاء كتالوج أولي). إذا كنت تتوقّع أن تتجاوز هذه العمليات الحدّ الأقصى المسموح به في الساعة، عليك تنفيذ عمليات انتظار حسب الحاجة لتقليل معدّل الاستخدام إلى مستوى آمن. ننصحك باستخدام طرق إرسال الطلبات بشكل مجمّع مع التحديثات التي يمكن أن تتأخر قليلاً لتحقيق معدل نقل بيانات أعلى.
  • الاستعداد بشكل استباقي للتوسّع مع توسّع تطبيقك، قد تحتاج إلى زيادة استخدامك لواجهة برمجة التطبيقات ونقاط النهاية المختلفة. يمكنك الاطّلاع على مستندات حصص 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، قد يكون من الأفضل أتمتة عملية التحميل الأوّلي. يعمل هذا النوع من العمليات الثقيلة بشكل أفضل إذا تم اتّباع استراتيجية دورية مدمجة مع طرق معالجة الدُفعات التي تتحمّل وقت الاستجابة.

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

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

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

لإنشاء كتالوج كبير للاشتراك الأولي، ننصحك باستخدام طريقة 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، بما في ذلك تفعيل خطة أساسية لإتاحتها للشراء. بالإضافة إلى ذلك، تتيح لك نقطة النهاية monetization.subscriptions.basePlans.offers إنشاء العروض الترويجية وإدارتها.

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

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

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

تتوفّر لك الطرق التالية للمساعدة في تعديل المنتجات الحالية التي يتم شراؤها لمرة واحدة.

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

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

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

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

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

على سبيل المثال، إذا كنت تريد تعديل بيانات بطاقة بيانات منتج اشتراك فقط، عليك تحديد الحقل 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. قد يرجع ذلك إلى إجراء تغييرات يدوية طارئة على الكتالوج في Play Console، أو حدوث انقطاع في نظام إدارة الكتالوج، أو فقدان أحدث البيانات.

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

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

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

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

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

توفّر واجهة برمجة التطبيقات Google Play Developer API الطرق التالية لمساعدتك في إيقاف منتجاتك نهائيًا:

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

بالنسبة إلى المنتجات المتوفّرة عند الدفع:

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

قد يكون إيقاف منتج نهائيًا أمرًا ضروريًا في سيناريوهات مختلفة، مثل:

  • إنشاء حساب عن طريق الخطأ
  • إيقاف ميزة أو خدمة

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