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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

استفاده خود را نظارت کنید

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

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

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

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

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

توسعه دهندگان از نقاط پایانی انتشار محصول 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. این ممکن است به دلیل تغییرات اضطراری کاتالوگ دستی در کنسول، اختلال در سیستم مدیریت کاتالوگ شما یا شاید اگر آخرین اطلاعات خود را از دست داده باشید.

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

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

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

• مدل‌های داده را بشناسید: اولین قدم این است که مدل‌های داده CMS توسعه‌دهنده و Google Play Developer API را درک کنید. این شامل دانستن انواع مختلف داده‌هایی است که در هر سیستم ذخیره می‌شوند و اینکه چگونه عناصر داده‌های مختلف به یکدیگر نگاشت می‌شوند.
• تعریف قوانین تفاوت: هنگامی که مدل های داده را درک کردید، باید قوانین تفاوت را تعریف کنید. این قوانین نحوه مقایسه داده ها در دو سیستم را تعیین می کند. برای مثال، ممکن است بخواهید شناسه‌های محصول را مطابقت دهید و ویژگی‌های کلیدی اشتراک و طرح‌ها و پیشنهادات پایه مرتبط با آن را مقایسه کنید.
• پیاده سازی یک الگوریتم diff: هنگامی که قوانین diff را تعریف کردید، باید الگوریتم diff را پیاده سازی کنید. این الگوریتم داده ها را از دو سیستم گرفته و طبق قوانینی که شما تعریف کرده اید مقایسه می کند. برای دریافت داده‌های کاتالوگ از Google Play، می‌توانید از روش‌های inappproducts.list ، inappproducts.batchGet ، monetization.subscriptions.list و monetization.subscriptions.batchGet استفاده کنید.
• ایجاد گزارش تفاوت: الگوریتم diff یک گزارش تفاوت ایجاد می کند. این گزارش تفاوت های بین هر دو سیستم را نشان می دهد.
• آشتی دادن تفاوت ها: پس از ایجاد گزارش تفاوت، باید تفاوت ها را حل کنید. این ممکن است شامل به‌روزرسانی داده‌ها در 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 حذف کنید. یک اشتراک پس از فعال شدن حداقل یک طرح پایه قابل حذف نیست.