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

این راهنما توضیح می‌دهد که چگونه از Google Play Developer API برای ایجاد و مدیریت کاتالوگ محصول برای برنامه Play خود استفاده کنید.

برای فروش محصولات در برنامه‌تان ازطریق سیستم صورت‌حساب Google Play، باید کاتالوگی با همه محصولاتی که می‌خواهید برای خرید توسط کاربران دردسترس قرار دهید راه‌اندازی کنید. این کار را می‌توانید ازطریق «کنسول Play» انجام دهید، یا می‌توانید مدیریت کاتالوگ را بااستفاده از Google Play Developer API خودکار کنید. خودکارسازی می‌تواند کمک کند مطمئن شوید کاتالوگتان همیشه به‌روز است و به کاتالوگ‌های بزرگ مقیاس‌بندی شود که هماهنگی دستی در آن‌ها غیرعملی است. در این راهنما خواهید دید که چگونه از Play Developer API برای ایجاد و مدیریت کاتالوگ محصول برای برنامه Play خود استفاده کنید. راهنمای آماده شدن ما را برای دستورالعمل‌های مربوط به نحوه راه‌اندازی Google Play Developer API برای ادغام پشت‌صحنه خود مرور کنید.

Catalog Management APIs

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

  • محصولات یک‌باره
  • محصولات آبونه‌ای

محصولات یک‌باره

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

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

محصولات آبونه‌ای

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

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

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

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

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

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

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

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

  1. Google Play Developer APIs در دسته‌هایی به‌نام «بخش» سازمان‌دهی شده‌اند، که هر بخش حد سهمیه دقیقه‌ای خودش را دارد. برای اطلاعات بیشتر، سهمیه‌ها را ببینید.
  2. نقاط پایانی اصلاح محصول نیز محدودیت ۷۲۰۰ پُرسمان در ساعت را اعمال می‌کنند. این حد واحدی برای محصولات یک‌باره و اشتراک‌ها و برای همه درخواست‌های اصلاح، ازجمله ایجاد، به‌روزرسانی، فعال‌سازی، و حذف است. فراخوانی‌های روش اصلاح دسته‌ای به‌عنوان یک پُرسمان برای این سهمیه محسوب می‌شوند، صرف‌نظر از تعداد درخواست‌های تکی موجود یا حساسیت تأخیر آن‌ها.
  3. اصلاحات حساس به تأخیر نیز محدودیتی برابر با ۷٬۲۰۰ اصلاح در ساعت دارند. برای روش‌های دسته‌ای، هر درخواست اصلاح تودرتو به‌طور جداگانه برای این سهمیه محاسبه می‌شود. این سهمیه فقط برای کاربران API دسته‌ای که به‌روزرسانی‌های حساس به تأخیر را انجام می‌دهند، پیامدهای عملی دارد، زیرا در موارد دیگر، سهمیه ۲ قبل یا هم‌زمان با این سهمیه تمام می‌شود.

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

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

توصیه‌های استفاده از Catalog Management API

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

پایش مصرف

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

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

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

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

افزودن منطق رسیدگی به خطای سهمیه

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

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

ملاحظات سیستم Diff

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

  • آشنایی با مدل‌های داده: اولین قدم آشنایی با مدل‌های داده CMS توسعه‌دهنده و Google Play Developer API است. این شامل دانستن انواع مختلف داده‌هایی است که در هر سیستم ذخیره می‌شود و اینکه چگونه عناصر مختلف داده با یکدیگر مطابقت دارند.
  • تعریف قوانین diff: پس‌از درک مدل‌های داده، باید قوانین diff را تعریف کنید. این قوانین تعیین می‌کنند که داده‌های دو سیستم چگونه باهم مقایسه شوند. برای مثال، ممکن است بخواهید شناسه‌های محصول را مطابقت دهید و مشخصه‌های کلیدی اشتراک و طرح‌های پایه و پیشنهادهای مرتبط با آن را مقایسه کنید.
  • پیاده‌سازی الگوریتم diff: پس‌از تعریف قوانین diff، باید الگوریتم diff را پیاده‌سازی کنید. این الگوریتم داده‌ها را از دو سیستم می‌گیرد و آن‌ها را براساس قوانینی که تعریف کرده‌اید مقایسه می‌کند. برای دریافت داده‌های کاتالوگ از Google Play، می‌توانید از روش‌های monetization.onetimeproducts.list، monetization.onetimeproducts.batchGet، inappproducts.list، inappproducts.batchGet، monetization.subscriptions.list و monetization.subscriptions.batchGet استفاده کنید.
  • تولید گزارش‌های diff: الگوریتم diff یک گزارش diff تولید خواهد کرد. این گزارش تفاوت‌های بین هر دو سیستم را نشان می‌دهد.
  • حل‌وفصل تفاوت‌ها: پس‌از تولید گزارش تفاوت، باید تفاوت‌ها را حل‌وفصل کنید. این کار ممکن است شامل به‌روزرسانی داده‌ها در CMS شما باشد، یا ممکن است شامل به‌روزرسانی داده‌ها در سمت Google Play بااستفاده از پایانه‌های مدیریت کاتالوگ Developer API باشد، بسته به اینکه معمولاً چگونه کاتالوگ خود را به‌روزرسانی می‌کنید. برای تطبیق محصولات غیرهمگام، از نقاط پایانی به‌روزرسانی همان‌طور که در بخش به‌روزرسانی‌های محصول شرح داده شده است استفاده کنید.

منسوخ شدن محصول

Google Play Developer API روش‌های زیر را برای کمک به شما در منسوخ کردن محصولاتتان ارائه می‌دهد:

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

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

  • monetization.subscriptions.delete برای اشتراک‌ها. وقتی حداقل یک طرح پایه فعال شده باشد، اشتراک را نمی‌توان برداشت.

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

  • ایجاد اشتباهی.
  • توقف دائم ویژگی یا سرویس.

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