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

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

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

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

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

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

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

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

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

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

طرق التجميع

توفِّر نقطتا النهاية 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. ويبلغ الحد الأقصى للتعديلات في وقت الاستجابة 7200 تعديل في الساعة. بالنسبة لطرق الدفع، يتم احتساب كل طلب تعديل متداخل بشكل منفصل لغرض هذه الحصة. هذه الحصّة لها تأثيرات عملية فقط على مستخدمي واجهة برمجة التطبيقات المجمّعة التي تنفّذ التحديثات الحسّاسة لوقت الاستجابة، كما في حالات أخرى، سيتم استنفاد الحصة 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

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

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

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

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

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

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

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

لإنشاء كتالوج أولي لمنتج يتم تحصيل سعره مرة واحدة، ننصحك باستخدام طريقة 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.update مع المَعلمة allowMissing كما هو موضّح في قسم "تعديلات على المنتجات".

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

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