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

يوضّح هذا الدليل كيفية استخدام 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 للاشتراكات. لا يمكن إزالة الاشتراك بعد تفعيل خطة أساسية واحدة على الأقل.

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

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

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