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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الاختلاف في التفكير في الشراء

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

• فهم نماذج البيانات: تتمثل الخطوة الأولى في فهم البيانات. نماذج نظام إدارة المحتوى للمطورين وواجهة برمجة التطبيقات للمطوّرين في Google Play. وتشمل هذه المعلومات ما يلي: ومعرفة الأنواع المختلفة من البيانات المخزنة في كل نظام، وكيف ربط عناصر البيانات المختلفة ببعضها البعض.
• تحديد قواعد الاختلافات: بعد فهم نماذج البيانات، عليك تحدد قواعد الاختلاف. ستحدّد هذه القواعد كيفية وصول البيانات في المقارنة بين الأنظمة. على سبيل المثال، قد ترغب في مطابقة معرّفات المنتجات ومقارنة السمات الرئيسية للاشتراك والخطط الأساسية المرتبطة به على مستوى خدمات Google.
• تنفيذ خوارزمية الاختلاف: بعد تحديد قواعد الاختلاف، يمكنك بحاجة إلى تنفيذ خوارزمية الاختلاف. ستأخذ هذه الخوارزمية البيانات من بين النظامين ومقارنته وفقًا للقواعد التي حددتها. للحصول على وبيانات الكتالوج من Google Play، يمكنك استخدام inappproducts.list، inappproducts.batchGet, monetization.subscriptions.list أو monetization.subscriptions.batchGet.
• إنشاء تقارير الاختلاف: ستنشئ خوارزمية الاختلاف تقرير اختلاف. وسيوضّح هذا التقرير الاختلافات بين كلا النظامين.
• تسوية الاختلافات: بعد إنشاء تقرير الاختلافات، ستحتاج إلى لحلّ الاختلافات قد يتضمن ذلك تحديث البيانات في نظام إدارة المحتوى قد يشمل ذلك تعديل البيانات من جانب 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 . لا يمكن إزالة الاشتراك بعد إكمال خطة أساسية واحدة على الأقل. تم تفعيل.