کاتالوگ محصولات خود را مدیریت کنید

این راهنما نحوه استفاده از API توسعه‌دهندگان گوگل پلی برای ایجاد و مدیریت کاتالوگ محصولات برای برنامه پلی شما را توضیح می‌دهد.

برای فروش محصولات در برنامه خود از طریق سیستم پرداخت گوگل پلی، باید کاتالوگی با تمام محصولاتی که می‌خواهید برای خرید توسط کاربرانتان در دسترس قرار دهید، تنظیم کنید. این کار را می‌توان از طریق کنسول پلی انجام داد، یا می‌توانید مدیریت کاتالوگ را با استفاده از API توسعه‌دهندگان گوگل پلی خودکار کنید. خودکارسازی می‌تواند به شما اطمینان دهد که کاتالوگ شما همیشه به‌روز است و در مواردی که هماهنگی دستی عملی نیست، به کاتالوگ‌های بزرگ نیز قابل تعمیم است. در این راهنما، نحوه استفاده از API توسعه‌دهندگان گوگل پلی برای ایجاد و مدیریت کاتالوگ محصولات برای برنامه پلی خود را خواهید دید. برای دستورالعمل‌های مربوط به نحوه تنظیم API توسعه‌دهندگان گوگل پلی برای ادغام در بک‌اند، راهنمای آماده‌سازی ما را بررسی کنید.

API های مدیریت کاتالوگ

برای مطالعه در مورد انواع مختلف محصولاتی که می‌توانید با سیستم صورتحساب گوگل پلی بفروشید، به بخش «انواع محصولات درون‌برنامه‌ای و ملاحظات کاتالوگ را بشناسید» مراجعه کنید. گوگل دو مجموعه اصلی API برای مدیریت کاتالوگ در پلی ارائه می‌دهد که مربوط به دو دسته اصلی محصول هستند:

  • محصولات یکبار مصرف
  • محصولات اشتراکی

محصولات یکبار مصرف

محصولات یکبار مصرف (که قبلاً به عنوان محصولات درون برنامه‌ای شناخته می‌شدند) از مدل شیء محصول یکبار مصرف استفاده می‌کنند که به شما امکان می‌دهد چندین گزینه خرید و پیشنهاد برای محصولات یکبار مصرف خود پیکربندی کنید. مدل شیء محصول یکبار مصرف، انعطاف‌پذیری بیشتری در نحوه فروش محصولات به شما می‌دهد و پیچیدگی مدیریت آنها را کاهش می‌دهد. محصولات درون برنامه‌ای موجود شما به مدل شیء محصول یکبار مصرف منتقل می‌شوند. برای اطلاعات بیشتر به «انتقال محصولات درون برنامه‌ای» مراجعه کنید.

نقاط پایانی monetization.onetimeproducts و inappproducts به شما امکان می‌دهند محصولات یکبار مصرف را از بک‌اند خود مدیریت کنید. این شامل ایجاد، به‌روزرسانی و حذف محصولات و مدیریت قیمت‌ها و موجودی آن‌ها می‌شود. بسته به نحوه مدیریت خرید محصولات یکبار مصرف، شما محصولات مصرفی (که می‌توانند به تعداد دلخواه خریداری شوند) یا محصولات دائمی (که نمی‌توانند دو بار توسط یک کاربر ساخته شوند) را مدل‌سازی خواهید کرد. می‌توانید تصمیم بگیرید که کدام محصولات یکبار مصرف باید مصرفی باشند یا نباشند.

محصولات اشتراکی

نقطه پایانی monetization.subscriptions به شما کمک می‌کند تا محصولات اشتراکی را از طریق بخش توسعه‌دهنده خود مدیریت کنید. می‌توانید کارهایی مانند ایجاد، به‌روزرسانی و حذف اشتراک‌ها را انجام دهید یا در دسترس بودن و قیمت‌گذاری منطقه‌ای آنها را کنترل کنید. علاوه بر نقطه پایانی monetization.subscriptions ، ما monetization.subscriptions.basePlans و monetization.subscriptions.basePlans.offers را نیز برای مدیریت طرح‌های پایه و پیشنهادات اشتراک‌ها ارائه می‌دهیم.

روش‌های دسته‌ای

نقاط پایانی onetimeproducts ، inappproducts و monetization.subscriptions تعدادی متد دسته‌ای ارائه می‌دهند که امکان بازیابی یا مدیریت حداکثر ۱۰۰ موجودیت را تحت یک برنامه واحد به طور همزمان فراهم می‌کنند.

روش‌های دسته‌ای، هنگامی که با قابلیت تحمل تأخیر فعال استفاده می‌شوند، از توان عملیاتی بالاتری پشتیبانی می‌کنند و به ویژه برای توسعه‌دهندگان کاتالوگ‌های بزرگ جهت ایجاد اولیه کاتالوگ یا تطبیق کاتالوگ مفید هستند.

تأخیر انتشار به‌روزرسانی در مقابل توان عملیاتی

پس از تکمیل درخواست ایجاد یا اصلاح محصول، ممکن است تغییرات به دلیل تأخیر در پردازش شبکه یا backend، بلافاصله برای کاربران نهایی در دستگاه‌هایشان قابل مشاهده نباشند. به طور پیش‌فرض، همه درخواست‌های اصلاح محصول حساس به تأخیر هستند. این بدان معناست که آنها برای انتشار سریع از طریق سیستم‌های backend بهینه شده‌اند و معمولاً ظرف چند دقیقه در دستگاه‌های کاربر نهایی منعکس می‌شوند. با این حال، محدودیت ساعتی برای تعداد چنین درخواست‌های اصلاحی وجود دارد. برای مواردی که نیاز به ایجاد یا به‌روزرسانی بسیاری از محصولات دارید (به عنوان مثال، در طول ایجاد اولیه کاتالوگ بزرگ)، می‌توانید از روش‌های دسته‌ای با فیلد latencyTolerance تنظیم شده روی PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT استفاده کنید. این امر به طور قابل توجهی توان عملیاتی به‌روزرسانی را افزایش می‌دهد. به‌روزرسانی‌های مقاوم در برابر تأخیر تا 24 ساعت طول می‌کشد تا به دستگاه‌های کاربر نهایی منتقل شوند.

پیکربندی سهمیه

چندین محدودیت سهمیه وجود دارد که باید هنگام استفاده از Play Developer API برای مدیریت کاتالوگ محصولات خود از آنها آگاه باشید:

  1. رابط‌های برنامه‌نویسی کاربردی (API) توسعه‌دهندگان گوگل پلی در دسته‌هایی به نام «باکت» (Bucket) سازماندهی شده‌اند که هر باکت محدودیت سهمیه در دقیقه مخصوص به خود را دارد. برای اطلاعات بیشتر، به «باکت‌ها» مراجعه کنید.
  2. نقاط پایانی اصلاح محصول همچنین محدودیت ۷۲۰۰ پرس‌وجو در ساعت را اعمال می‌کنند. این محدودیت هم برای محصولات یکبار مصرف و هم برای اشتراک‌ها و هم برای همه درخواست‌های اصلاح، از جمله ایجاد، به‌روزرسانی، فعال‌سازی، حذف، اعمال می‌شود. فراخوانی‌های دسته‌ای روش اصلاح، صرف نظر از تعداد درخواست‌های جداگانه یا حساسیت به تأخیر آنها، به عنوان یک پرس‌وجو برای این سهمیه محسوب می‌شوند.
  3. تغییرات حساس به تأخیر نیز محدودیت ۷۲۰۰ تغییر در ساعت را دارند. برای روش‌های دسته‌ای، هر درخواست اصلاح تو در تو برای این سهمیه جداگانه محاسبه می‌شود. این سهمیه فقط برای کاربران API دسته‌ای که به‌روزرسانی‌های حساس به تأخیر را انجام می‌دهند، پیامدهای عملی دارد، زیرا در موارد دیگر، سهمیه ۲ قبل یا همزمان با این سهمیه تمام می‌شود.

در اینجا چندین مثال توضیحی برای درک استفاده از سهمیه در درخواست‌های مختلف آورده شده است:

  • یک درخواست get برای دریافت یک مورد، ۱ توکن از سهمیه ۱ را مصرف می‌کند و هیچ توکنی از سهمیه‌های ۲ و ۳ مصرف نمی‌کند (زیرا آنها فقط مربوط به نقاط پایانی اصلاح هستند).
  • یک درخواست get دسته‌ای برای دریافت حداکثر ۱۰۰ آیتم، ۱ توکن از سهمیه ۱ را نیز مصرف می‌کند و هیچ توکنی از سهمیه ۲ و ۳ مصرف نمی‌کند.
  • یک درخواست modification واحد برای یک آیتم، ۱ توکن از سهمیه ۱ و ۱ توکن از سهمیه ۲ را مصرف می‌کند. اگر درخواست به تأخیر حساس باشد، ۱ توکن از سهمیه ۳ را نیز مصرف خواهد کرد. از آنجا که سهمیه C محدودیتی مشابه سهمیه ۲ دارد، هیچ پیامد عملی برای کاربرانی که فقط از روش‌های اصلاح واحد استفاده می‌کنند، ندارد.
  • یک درخواست modification دسته‌ای برای ۱۰۰ مورد با تحمل تأخیر، ۱ توکن از سهمیه ۱ و ۱ توکن از سهمیه ۲ را مصرف می‌کند. این تنظیم سهمیه باید حاشیه کافی برای به‌روزرسانی کاتالوگ شما را فراهم کند، اما اگر الگوریتم شما از این سهمیه آگاه نباشد و از این نرخ فراتر رود، ممکن است در هر فراخوانی اضافی با خطا مواجه شوید.
  • یک درخواست modification دسته‌ای برای ۱۰۰ مورد حساس به تأخیر، ۱ توکن از سهمیه ۱، ۱ توکن از سهمیه ۲ و ۱۰۰ توکن از سهمیه ۳ را مصرف خواهد کرد.

توصیه‌های استفاده از API مدیریت کاتالوگ

با رعایت این دستورالعمل‌ها، تعاملات خود را با API بهینه می‌کنید و یک تجربه مدیریت کاتالوگ روان و کارآمد را تضمین می‌کنید.

میزان استفاده خود را زیر نظر داشته باشید

شما باید از فرآیندهای مصرف سنگین آگاه باشید. به عنوان مثال، در ابتدای ادغام، نقاط پایانی مدیریت کاتالوگ شما احتمالاً سهمیه بیشتری را برای ایجاد کاتالوگ اولیه کامل شما مصرف می‌کنند و این امر می‌تواند به طور بالقوه بر مصرف تولید سایر نقاط پایانی مانند API وضعیت خرید تأثیر بگذارد، اگر به محدودیت کلی مصرف نزدیک باشید. شما باید مصرف سهمیه خود را نظارت کنید تا مطمئن شوید که از سهمیه API تجاوز نمی‌کنید. روش‌های مختلفی برای نظارت بر مصرف وجود دارد. به عنوان مثال، می‌توانید از داشبورد سهمیه APIهای Google Cloud یا هر ابزار نظارت بر API داخلی یا شخص ثالث دیگری که انتخاب می‌کنید، استفاده کنید.

بهینه‌سازی استفاده از سهمیه API

بهینه‌سازی مصرف نرخ برای به حداقل رساندن احتمال خطاهای API اکیداً توصیه می‌شود. برای اجرای مؤثر این امر، توصیه می‌کنیم:

  • استراتژی مدیریت کاتالوگ مناسب را انتخاب کنید. پس از درک سهمیه API، باید استراتژی مناسبی را برای برنامه خود انتخاب کنید تا به طور موثر به اهداف مدیریت کاتالوگ خود برسید.
  • فقط حداقل تعداد تماس‌های لازم برای انعکاس تغییرات خود را انجام دهید.
  • درخواست‌های اصلاحی اضافی یا غیرضروری به APIها ارسال نکنید. این ممکن است مستلزم آن باشد که یک گزارش تغییرات در کاتالوگ backend خود نگه دارید.
  • محدودیت ساعتی اصلاح محصول را زیر ۷۲۰۰ پرس‌وجو نگه دارید. ممکن است بخواهید فرآیندهای همگام‌سازی ایجاد کنید که نیاز به انجام تعداد زیادی اصلاح محصول در مدت زمان کوتاه داشته باشند (برای مثال، ایجاد کاتالوگ اولیه). اگر انتظار دارید که این فرآیندها از محدودیت ساعتی فراتر روند، در صورت لزوم انتظارهایی را پیاده‌سازی کنید تا سرعت استفاده را به سطح ایمن کاهش دهید. برای دستیابی به توان عملیاتی بالاتر، استفاده از روش‌های دسته‌ای با به‌روزرسانی‌های تحمل‌پذیر در برابر تأخیر را در نظر بگیرید.
  • برای مقیاس‌پذیری به صورت فعال آماده شوید. با رشد برنامه‌تان، ممکن است نیاز باشد میزان استفاده از API و نقاط انتهایی مختلف را افزایش دهید. برای جزئیات بیشتر در مورد نحوه افزایش سهمیه خود، زمانی که به حداکثر استفاده نزدیک می‌شوید، مستندات سهمیه API توسعه‌دهندگان Google Play را مطالعه کنید.
  • فرآیندهای سنگین را به صورت استراتژیک برنامه‌ریزی کنید. سعی کنید فرآیندهای سنگین کاتالوگ خود را حول اوج مصرف بحرانی برنامه‌ریزی کنید، برای مثال می‌توانید از اجرای همگام‌سازی کامل کاتالوگ در زمان‌های اوج فروش هفته خودداری کنید.

منطق مدیریت خطای سهمیه‌بندی را اضافه کنید

مهم نیست که منطق مدیریت کاتالوگ خود را چقدر کارآمد بسازید، باید آن را در برابر محدودیت‌های سهمیه غیرمنتظره مقاوم کنید، با توجه به اینکه سهمیه روزانه توسط نقاط پایانی مورد استفاده در ماژول‌های مستقل ادغام شما به اشتراک گذاشته می‌شود. مطمئن شوید که خطاهای محدودکننده سهمیه را در مدیریت خطا لحاظ می‌کنید و انتظارهای مناسب را پیاده‌سازی می‌کنید. هر فراخوانی که به APIهای توسعه‌دهندگان Google Play انجام می‌شود، پاسخی ایجاد می‌کند. در صورت عدم موفقیت در فراخوانی، یک پاسخ عدم موفقیت دریافت خواهید کرد که شامل یک کد وضعیت پاسخ 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"
  } ],
}

پیاده‌سازی مدیریت کاتالوگ

توسعه‌دهندگان از نقاط پایانی انتشار محصول API توسعه‌دهندگان گوگل پلی برای همگام‌سازی کاتالوگ خود بین بک‌اند و گوگل پلی استفاده می‌کنند. اطمینان از اینکه کاتالوگ گوگل پلی شما همیشه با آخرین اطلاعات کاتالوگ بک‌اند به‌روز باشد، مزایایی برای ایجاد یک تجربه کاربری بهتر دارد. به عنوان مثال:

  • شما قادر خواهید بود کل لیست پیشنهادات موجود را بررسی کنید و برچسب‌های پیشنهاد و طرح پایه را مدیریت کنید تا بر واجد شرایط بودن خود تأثیر بگذارید و منطق ظاهری پیشنهاد را تغییر دهید.
  • شما می‌توانید قیمت‌ها و جزئیات مختلف محصول را که کاربران در پلتفرم‌های مختلف مشاهده می‌کنند، بررسی کنید و مطمئن شوید که آنها سازگار هستند.
  • هنگام پردازش خریدهای جدید، جزئیات محصول را در پشت صحنه در دسترس خواهید داشت، بدون اینکه نیازی به افزایش تأخیر و خطر خرابی با انجام فراخوانی‌های اضافی به API توسعه‌دهنده Google Play در طول جریان‌های بحرانی کاربر باشد.

محدودیت‌ها و ملاحظات خاصی وجود دارد که باید هنگام ایجاد کاتالوگ محصولات خود در گوگل پلی در نظر داشته باشید. هنگامی که این محدودیت‌ها را درک کردید و دانستید که چگونه می‌خواهید کاتالوگ خود را ساختار دهید، زمان آن رسیده است که در مورد استراتژی همگام‌سازی خود تصمیم بگیرید.

استراتژی‌های همگام‌سازی کاتالوگ

نقاط پایانی انتشار API توسعه‌دهندگان گوگل پلی به شما این امکان را می‌دهد که با وقوع تغییرات، کاتالوگ خود را به‌روزرسانی کنید. در برخی موارد، ممکن است نیاز به رویکرد به‌روزرسانی‌های دوره‌ای داشته باشید، که در آن مجموعه‌ای از تغییرات را در یک فرآیند ارسال می‌کنید. هر رویکرد نیاز به انتخاب‌های طراحی متفاوتی دارد. هر استراتژی همگام‌سازی برای برخی از موارد استفاده بهتر از سایرین مناسب است و ممکن است بسته به شرایط، مجموعه‌ای از نیازها را داشته باشید که هر دو را ایجاب می‌کند. گاهی اوقات ممکن است بخواهید به محض اطلاع از تغییر جدید، به‌روزرسانی را برای یک محصول انجام دهید، به عنوان مثال برای پردازش به‌روزرسانی فوری محصول (یعنی یک قیمت اشتباه باید در اسرع وقت اصلاح شود). در موارد دیگر، می‌توانید از یک همگام‌سازی دوره‌ای در پس‌زمینه استفاده کنید تا مطمئن شوید که کاتالوگ‌های backend و Play شما همیشه سازگار هستند. برخی از موارد استفاده رایج را که ممکن است بخواهید این استراتژی‌های مختلف مدیریت کاتالوگ را پیاده‌سازی کنید، بخوانید.

چه زمانی باید به‌روزرسانی‌ها را همزمان با تغییرات کاتالوگ محلی خود ارسال کنید؟

در حالت ایده‌آل، به‌روزرسانی‌ها باید به محض ایجاد هرگونه تغییر در کاتالوگ محصولات بک‌اند شما انجام شوند تا اختلافات به حداقل برسد.

این نوع به‌روزرسانی‌ها در موارد زیر گزینه خوبی هستند:

  • شما باید مطمئن شوید که محصولات شما همیشه به‌روز هستند.
  • شما باید هر روز چند تغییر در محصولات خود ایجاد کنید.
  • شما باید محصولاتی را که در حال حاضر در حال تولید و فروش هستند، به‌روزرسانی کنید.

این رویکرد پیاده‌سازی ساده‌تری دارد و به شما امکان می‌دهد کاتالوگ خود را با کمترین میزان اختلاف در پنجره همگام نگه دارید.

چه زمانی از به‌روزرسانی‌های دوره‌ای استفاده کنیم؟

به‌روزرسانی‌های دوره‌ای به صورت ناهمزمان با نسخه محصول در backend شما اجرا می‌شوند و در موارد زیر گزینه خوبی هستند:

  • لازم نیست مطمئن شوید که محصولاتتان در مدت زمان کوتاهی به‌روزرسانی می‌شوند.
  • شما باید به‌روزرسانی‌های عمده یا فرآیندهای تطبیق را برنامه‌ریزی کنید.
  • شما از قبل یک سیستم مدیریت محتوا یا کاتالوگ برای مدیریت محصولات دیجیتال خود دارید و کاتالوگ شما را دائماً به‌روزرسانی می‌کند.

در مورد کاتالوگ‌های بزرگ، برای دستیابی به حداکثر توان عملیاتی، استفاده از روش‌های دسته‌ای با به‌روزرسانی‌های مقاوم در برابر تأخیر را در نظر بگیرید.

کاتالوگ محصولات خود را ایجاد کنید

اگر کاتالوگ بزرگی برای آپلود در گوگل پلی دارید، ممکن است بخواهید بارگذاری اولیه را خودکار کنید. این نوع فرآیند سنگین در صورتی بهترین نتیجه را می‌دهد که از یک استراتژی دوره‌ای همراه با روش‌های دسته‌ای مقاوم در برابر تأخیر پیروی شود.

محصولات یکبار مصرف ایجاد کنید

برای ایجاد اولیه کاتالوگ محصولات یکبار مصرف، توصیه می‌کنیم از متد 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 متد monetization.subscriptions.create را ارائه می‌دهد. به عنوان یک جایگزین، می‌توانید با استفاده از متد monetization.subscriptions.patch و با پارامتر allowMissing ، همانطور که در بخش به‌روزرسانی‌های محصول توضیح داده شده است، اشتراک ایجاد کنید.

تمام روش‌های قبلی، اشتراک‌ها را به همراه طرح‌های پایه‌شان (که در شیء Subscription ارائه می‌شوند) ایجاد می‌کنند. این طرح‌های پایه در ابتدا غیرفعال هستند. برای مدیریت وضعیت طرح‌های پایه، می‌توانید از نقطه پایانی monetization.subscriptions.basePlans استفاده کنید، از جمله فعال کردن یک طرح پایه برای در دسترس قرار دادن آن برای خرید. علاوه بر این، نقطه پایانی monetization.subscriptions.basePlans.offers به ​​شما امکان ایجاد و مدیریت پیشنهادات را می‌دهد.

به‌روزرسانی‌های محصول

روش‌های زیر شما را قادر می‌سازد تا محصولات موجود خود را به طور مؤثر اصلاح کنید و اطمینان حاصل کنید که پیشنهادات شما با آخرین تنظیمات شما همسو هستند.

به‌روزرسانی محصولات یکبار مصرف

روش‌های زیر برای کمک به به‌روزرسانی محصولات یکبار مصرف موجود در دسترس شما هستند.

  • کسب درآمد.محصولات یکبار مصرف.بروزرسانی دسته ای
  • inappproducts.patch : نقطه پایانی patch برای به‌روزرسانی جزئی یک منبع استفاده می‌شود. این بدان معناست که می‌توانید فیلدهای خاصی را که در بدنه درخواست مشخص می‌کنید، به‌روزرسانی کنید. نقطه پایانی patch معمولاً زمانی استفاده می‌شود که فقط نیاز به به‌روزرسانی چند فیلد از یک منبع دارید.
  • inappproducts.update : نقطه پایانی به‌روزرسانی برای به‌روزرسانی کل یک منبع استفاده می‌شود. این بدان معناست که شما باید کل شیء منبع را در بدنه درخواست ارسال کنید. نقطه پایانی به‌روزرسانی معمولاً زمانی استفاده می‌شود که نیاز به به‌روزرسانی همه فیلدها در یک منبع دارید. وقتی پارامتر allowMissing روی true تنظیم شده باشد و شناسه محصول ارائه شده از قبل وجود نداشته باشد، نقطه پایانی به جای fail شدن، محصول را درج می‌کند.
  • 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 به‌روزرسانی کنید.

تطبیق کاتالوگ

چه بخواهید کاتالوگ گوگل پلی خود را هر بار که کاتالوگ بک‌اند شما تغییر می‌کند به‌روزرسانی کنید و چه به صورت دوره‌ای، اگر سیستم مدیریت کاتالوگ یا پایگاه داده‌ای خارج از کاتالوگ گوگل پلی دارید، ممکن است در مواقعی با کاتالوگ موجود در پیکربندی برنامه‌های شما در پلی همگام‌سازی نشود. این می‌تواند به دلیل تغییرات دستی اضطراری کاتالوگ در کنسول، قطعی سیستم مدیریت کاتالوگ یا شاید از دست دادن آخرین داده‌های شما باشد.

شما می‌توانید یک فرآیند تطبیق کاتالوگ ایجاد کنید تا از طولانی شدن زمان اختلاف جلوگیری شود.

در نظر گرفتن سیستم دیفرانسیل

ما توصیه می‌کنیم یک سیستم تفاوت‌گذاری (diff system) ایجاد کنید تا ناسازگاری‌ها را تشخیص داده و دو سیستم را با هم تطبیق دهید. در اینجا مواردی وجود دارد که باید هنگام ساخت یک سیستم تفاوت‌گذاری برای کمک به همگام‌سازی کاتالوگ‌های خود در نظر بگیرید:

  • درک مدل‌های داده: اولین قدم، درک مدل‌های داده سیستم مدیریت محتوای توسعه‌دهندگان و رابط برنامه‌نویسی کاربردی (API) توسعه‌دهندگان گوگل پلی است. این شامل شناخت انواع مختلف داده‌های ذخیره‌شده در هر سیستم و نحوه‌ی نگاشت عناصر داده‌ی مختلف به یکدیگر می‌شود.
  • تعریف قوانین تفاوت: پس از درک مدل‌های داده، باید قوانین تفاوت را تعریف کنید. این قوانین نحوه مقایسه داده‌ها در دو سیستم را تعیین می‌کنند. به عنوان مثال، ممکن است بخواهید شناسه‌های محصول را مطابقت داده و ویژگی‌های کلیدی اشتراک و طرح‌ها و پیشنهادات پایه مرتبط با آن را مقایسه کنید.
  • پیاده‌سازی الگوریتم diff: پس از تعریف قوانین diff، باید الگوریتم diff را پیاده‌سازی کنید. این الگوریتم داده‌ها را از دو سیستم دریافت کرده و آنها را طبق قوانینی که تعریف کرده‌اید مقایسه می‌کند. برای دریافت داده‌های کاتالوگ از 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) روش‌های زیر را برای کمک به شما در منسوخ کردن محصولاتتان ارائه می‌دهد:

برای محصولات یکبار مصرف:

برای محصولات اشتراکی:

منسوخ کردن یک محصول ممکن است در سناریوهای مختلفی ضروری باشد، مانند:

  • خلقت از روی اشتباه.
  • قطع ارائه یک ویژگی یا سرویس.

توصیه می‌کنیم که استهلاک محصول را در استراتژی مدیریت کاتالوگ خود بگنجانید.