আপনার পণ্য ক্যাটালগ পরিচালনা করুন

এই নির্দেশিকাটি ব্যাখ্যা করে যে কীভাবে আপনার প্লে অ্যাপের জন্য একটি পণ্য ক্যাটালগ তৈরি এবং পরিচালনা করতে Google Play বিকাশকারী API ব্যবহার করতে হয়।

Google Play এর বিলিং সিস্টেমের মাধ্যমে আপনার অ্যাপে পণ্য বিক্রি করতে আপনাকে আপনার ব্যবহারকারীদের দ্বারা কেনার জন্য উপলব্ধ করতে চান এমন সমস্ত পণ্যগুলির সাথে একটি ক্যাটালগ সেট আপ করতে হবে৷ এটি প্লে কনসোলের মাধ্যমে করা যেতে পারে, অথবা আপনি Google Play বিকাশকারী API ব্যবহার করে ক্যাটালগ পরিচালনা স্বয়ংক্রিয় করতে পারেন। অটোমেশন নিশ্চিত করতে সাহায্য করতে পারে আপনার ক্যাটালগ সর্বদা আপ-টু-ডেট, এবং বড় ক্যাটালগগুলিতে স্কেল করুন যেখানে ম্যানুয়াল সমন্বয় অব্যবহার্য। এই নির্দেশিকাটিতে আপনি দেখতে পাবেন কিভাবে আপনার প্লে অ্যাপের জন্য একটি পণ্য ক্যাটালগ তৈরি এবং পরিচালনা করতে Play Developer API ব্যবহার করবেন। আপনার ব্যাকএন্ড ইন্টিগ্রেশনের জন্য Google Play Developer API কিভাবে সেট আপ করতে হয় তার নির্দেশাবলীর জন্য আমাদের প্রস্তুত গাইডটি পর্যালোচনা করুন।

ক্যাটালগ ব্যবস্থাপনা API

আপনি Google Play এর বিলিং সিস্টেমের সাথে বিক্রি করতে পারেন এমন বিভিন্ন ধরণের পণ্য সম্পর্কে পড়তে, অ্যাপ-মধ্যস্থ পণ্যের ধরন এবং ক্যাটালগ বিবেচনাগুলি পড়ুন। Google Play-তে ক্যাটালগ পরিচালনার জন্য API-এর দুটি প্রধান সেট অফার করে, দুটি প্রধান পণ্য বিভাগের সাথে সম্পর্কিত:

• এককালীন পণ্য
• সদস্যতা পণ্য

এককালীন পণ্য

inappproducts এন্ডপয়েন্ট আপনাকে আপনার ব্যাকএন্ড থেকে এককালীন পণ্য পরিচালনা করতে দেয়। এর মধ্যে পণ্য তৈরি করা, আপডেট করা এবং মুছে ফেলা এবং দাম এবং প্রাপ্যতা পরিচালনা করা অন্তর্ভুক্ত। আপনি কীভাবে এককালীন পণ্য কেনাকাটা পরিচালনা করেন তার উপর নির্ভর করে, আপনি ব্যবহারযোগ্য পণ্যের মডেল করবেন (যতবার ইচ্ছা ততবার কেনা যাবে) বা স্থায়ী এনটাইটেলমেন্ট (একই ব্যবহারকারীর দ্বারা দুবার করা যাবে না)। আপনি সিদ্ধান্ত নিতে পারেন যে কোন এক-সময়ের পণ্যগুলি ব্যবহারযোগ্য হবে না।

সদস্যতা পণ্য

monetization.subscriptions এন্ডপয়েন্ট আপনাকে আপনার ডেভেলপার ব্যাকএন্ড থেকে সাবস্ক্রিপশন পণ্য পরিচালনা করতে সাহায্য করে। আপনি সাবস্ক্রিপশন তৈরি, আপডেট এবং মুছে ফেলার মতো কাজ করতে পারেন অথবা তাদের আঞ্চলিক প্রাপ্যতা এবং মূল্য নিয়ন্ত্রণ করতে পারেন। monetization.subscriptions এন্ডপয়েন্ট ছাড়াও, আমরা সাবস্ক্রিপশনের বেস প্ল্যান এবং অফারগুলি পরিচালনা করার জন্য যথাক্রমে monetization.subscriptions.basePlans এবং monetization.subscriptions.basePlans.offers প্রদান করি।

ব্যাচ পদ্ধতি

inappproducts এবং monetization.subscriptions এন্ডপয়েন্টগুলি অনেকগুলি ব্যাচ পদ্ধতি প্রদান করে যা একই সময়ে একই অ্যাপের অধীনে 100টি পর্যন্ত সত্ত্বা পুনরুদ্ধার বা পরিচালনা করার অনুমতি দেয়৷

ব্যাচ পদ্ধতি, যখন সক্রিয় লেটেন্সি সহনশীলতার সাথে ব্যবহার করা হয়, তখন উচ্চতর থ্রুপুট সমর্থন করে এবং প্রাথমিক ক্যাটালগ তৈরি বা ক্যাটালগ পুনর্মিলনের জন্য বড়-ক্যাটালগ বিকাশকারীদের জন্য বিশেষভাবে উপযোগী।

থ্রুপুট বনাম প্রচার লেটেন্সি আপডেট করুন

একটি পণ্য তৈরি বা পরিবর্তনের অনুরোধ সম্পূর্ণ হওয়ার পরে, নেটওয়ার্ক বা ব্যাকএন্ড প্রক্রিয়াকরণ বিলম্বের কারণে তাদের ডিভাইসে শেষ ব্যবহারকারীদের কাছে পরিবর্তনগুলি অবিলম্বে দৃশ্যমান নাও হতে পারে। ডিফল্টরূপে, সমস্ত পণ্য পরিবর্তনের অনুরোধ বিলম্ব-সংবেদনশীল। এর মানে তারা ব্যাকএন্ড সিস্টেমের মাধ্যমে দ্রুত প্রচারের জন্য অপ্টিমাইজ করা হয়েছে, সাধারণত মিনিটের মধ্যে শেষ-ব্যবহারকারীর ডিভাইসগুলিতে প্রতিফলিত হয়। যাইহোক, এই ধরনের পরিবর্তনের অনুরোধের সংখ্যার উপর একটি ঘন্টা সীমা আছে। এমন ক্ষেত্রে যেখানে আপনাকে অনেকগুলি পণ্য তৈরি বা আপডেট করতে হবে (উদাহরণস্বরূপ, প্রাথমিক বড় ক্যাটালগ তৈরির সময়), আপনি PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT এ সেট করা latencyTolerance ফিল্ড সহ ব্যাচ পদ্ধতি ব্যবহার করতে পারেন। এটি উল্লেখযোগ্যভাবে আপডেট থ্রুপুট বৃদ্ধি করবে। লেটেন্সি-সহনশীল আপডেটগুলি শেষ-ব্যবহারকারী ডিভাইসগুলিতে প্রচারিত হতে 24 ঘন্টা পর্যন্ত সময় নেবে৷

কোটা কনফিগারেশন

আপনার পণ্যের ক্যাটালগ পরিচালনা করার জন্য প্লে ডেভেলপার API ব্যবহার করার সময় আপনার সচেতন হওয়া উচিত এমন বেশ কয়েকটি কোটা সীমা রয়েছে:

1. Google Play Developer API-এ প্রতিদিন 200,000 প্রশ্নের ডিফল্ট সীমা রয়েছে। এই কোটা সীমা ক্যাটালগ পরিচালনা API সহ সমস্ত শেষ পয়েন্টে ব্যবহারের সমষ্টির ক্ষেত্রে প্রযোজ্য।
2. পণ্য পরিবর্তনের শেষ পয়েন্টগুলি প্রতি ঘন্টায় 7,200 প্রশ্নের একটি সীমা প্রয়োগ করে৷ এটি এক-কালীন পণ্য এবং সদস্যতা উভয়ের জন্যই একটি একক সীমা এবং তৈরি, আপডেট, সক্রিয়, মুছে ফেলা সহ সমস্ত পরিবর্তনের অনুরোধ জুড়ে। ব্যাচ পরিবর্তন পদ্ধতি কলগুলি এই কোটার জন্য একটি ক্যোয়ারী হিসাবে গণনা করে, ব্যক্তিগত অনুরোধের সংখ্যা বা তাদের লেটেন্সি সংবেদনশীলতা নির্বিশেষে।
3. লেটেন্সি সংবেদনশীল পরিবর্তনগুলিরও প্রতি ঘন্টায় 7,200টি পরিবর্তনের সীমা রয়েছে৷ ব্যাচ পদ্ধতির জন্য, প্রতিটি নেস্টেড পরিবর্তনের অনুরোধ এই কোটার উদ্দেশ্যে আলাদাভাবে গণনা করা হয়। এই কোটার ব্যবহারিক প্রভাব আছে শুধুমাত্র ব্যাচ API-এর ব্যবহারকারীদের জন্য যারা লেটেন্সি সংবেদনশীল আপডেটগুলি সম্পাদন করে, যেমন অন্যান্য ক্ষেত্রে কোটা 2 এই কোটার আগে বা একই সময়ে শেষ হয়ে যাবে।

বিভিন্ন অনুরোধের কোটা ব্যবহার বোঝার জন্য এখানে বেশ কয়েকটি দৃষ্টান্তমূলক উদাহরণ রয়েছে:

• একটি আইটেম আনার জন্য একটি একক get কোটা 1-এর 1 টোকেন এবং কোটা 2 এবং 3-এর কোনও টোকেন গ্রহণ করবে না (যেহেতু তারা শুধুমাত্র পরিবর্তনের শেষপয়েন্টগুলির সাথে সম্পর্কিত)।
• 100টি পর্যন্ত আইটেম আনার জন্য একটি ব্যাচ get অনুরোধ কোটা 1 এর 1 টোকেন এবং কোটা 2 এবং 3 এর কোন টোকেন ব্যবহার করবে না।
• একটি আইটেমের জন্য একটি একক modification অনুরোধ কোটা 1-এর 1 টোকেন, কোটা 2-এর 1 টোকেন ব্যবহার করবে। অনুরোধটি যদি লেটেন্সি সংবেদনশীল হয়, তাহলে এটি কোটা 3-এর 1 টোকেনও ব্যবহার করবে। কারণ কোটা C-এর কোটা 2-এর সমান সীমা রয়েছে, এটি শুধুমাত্র একক পরিবর্তন পদ্ধতি ব্যবহার করে ব্যবহারকারীদের জন্য কোন ব্যবহারিক প্রভাব নেই।
• 100টি লেটেন্সি সহনশীল আইটেমের জন্য একটি ব্যাচ modification অনুরোধ কোটা 1-এর 1 টোকেন, কোটা 2-এর 1 টোকেন ব্যবহার করবে। এই কোটা সেটআপটি আপনার ক্যাটালগ আপডেট রাখতে যথেষ্ট মার্জিনের অনুমতি দেবে, কিন্তু যদি আপনার অ্যালগরিদম এই কোটা সম্পর্কে সচেতন না হয় এবং এর বাইরে চলে যায় এই হারে আপনি অতিরিক্ত কল প্রতি একটি ত্রুটি পেতে পারেন।
• 100টি লেটেন্সি সংবেদনশীল আইটেমের জন্য একটি ব্যাচ modification অনুরোধ কোটা 1-এর 1 টোকেন, কোটা 2-এর 1 টোকেন এবং কোটা 3-এর 100 টোকেন খরচ করবে৷

ক্যাটালগ ব্যবস্থাপনা API ব্যবহারের সুপারিশ

এই নির্দেশিকাগুলি মেনে চলার মাধ্যমে, আপনি একটি মসৃণ এবং দক্ষ ক্যাটালগ পরিচালনার অভিজ্ঞতা নিশ্চিত করে API-এর সাথে আপনার মিথস্ক্রিয়াগুলি অপ্টিমাইজ করেন।

আপনার ব্যবহার নিরীক্ষণ

আপনার ভারী ব্যবহারের প্রক্রিয়া সম্পর্কে সচেতন হওয়া উচিত। উদাহরণস্বরূপ, আপনার ইন্টিগ্রেশনের শুরুতে আপনার ক্যাটালগ ম্যানেজমেন্ট এন্ডপয়েন্টগুলি আপনার সম্পূর্ণ প্রাথমিক ক্যাটালগ তৈরি করতে আরও বেশি কোটা গ্রহণ করার সম্ভাবনা বেশি এবং আপনি যদি সামগ্রিক ব্যবহারের সীমার কাছাকাছি থাকেন তবে এটি ক্রয় স্থিতি API-এর মতো অন্যান্য এন্ডপয়েন্টের উত্পাদন ব্যবহারকে প্রভাবিত করতে পারে . আপনি API কোটা অতিক্রম করছেন না তা নিশ্চিত করতে আপনার কোটা খরচ নিরীক্ষণ করতে হবে। ব্যবহার নিরীক্ষণ করার বিভিন্ন উপায় আছে। উদাহরণস্বরূপ, আপনি Google ক্লাউড APIs কোটা ড্যাশবোর্ড, বা আপনার পছন্দের অন্য কোনো ইন-হাউস বা তৃতীয় পক্ষের API পর্যবেক্ষণ টুল ব্যবহার করতে পারেন।

API কোটা ব্যবহার অপ্টিমাইজ করুন

API ত্রুটির সম্ভাবনা কমাতে রেট খরচ অপ্টিমাইজ করা অত্যন্ত সুপারিশ করা হয়। এটি কার্যকরভাবে বাস্তবায়ন করার জন্য, আমরা আপনাকে সুপারিশ করছি:

• সঠিক ক্যাটালগ পরিচালনার কৌশল বেছে নিন। একবার আপনি API কোটা বুঝতে পারলে, আপনার ক্যাটালগ পরিচালনার লক্ষ্যগুলি দক্ষতার সাথে অর্জন করতে আপনাকে আপনার অ্যাপ্লিকেশনের জন্য সঠিক কৌশল বেছে নিতে হবে।
• আপনার পরিবর্তনগুলি প্রতিফলিত করার জন্য আপনার প্রয়োজন ন্যূনতম পরিমাণ কল করুন৷
• API-এ অপ্রয়োজনীয় বা অপ্রয়োজনীয় পরিবর্তন কল পাঠাবেন না। এর জন্য আপনাকে আপনার ব্যাকএন্ড ক্যাটালগে একটি চেঞ্জলগ রাখতে হবে।
• প্রতি ঘণ্টায় 7,200 প্রশ্নের পণ্য পরিবর্তনের সীমার অধীনে থাকুন। আপনি সিঙ্ক প্রক্রিয়াগুলি তৈরি করতে চাইতে পারেন যার জন্য আপনাকে অল্প সময়ের মধ্যে প্রচুর পরিমাণে পণ্য পরিবর্তন করতে হবে (উদাহরণস্বরূপ, একটি প্রাথমিক ক্যাটালগ তৈরি)। আপনি যদি এই প্রক্রিয়াগুলি প্রতি ঘন্টার সীমা অতিক্রম করার আশা করেন, তাহলে ব্যবহারকে নিরাপদ স্তরে ধীর করার জন্য প্রয়োজনীয় অপেক্ষা বাস্তবায়ন করুন। উচ্চতর থ্রুপুট অর্জনের জন্য লেটেন্সি সহনশীল আপডেট সহ ব্যাচ পদ্ধতি ব্যবহার করার কথা বিবেচনা করুন।
• সক্রিয়ভাবে স্কেল প্রস্তুত. আপনার অ্যাপ্লিকেশন বাড়ার সাথে সাথে, আপনাকে আপনার API এবং বিভিন্ন শেষ পয়েন্টের ব্যবহার বাড়াতে হবে। আপনি যখন সর্বাধিক ব্যবহারের কাছাকাছি যাচ্ছেন তখন কীভাবে আপনার কোটা বাড়ানো যায় তার বিশদ বিবরণের জন্য Google Play বিকাশকারী 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 এর মধ্যে তাদের ক্যাটালগ সিঙ্ক্রোনাইজ রাখতে Google Play Developer API পণ্য প্রকাশনার শেষ পয়েন্ট ব্যবহার করে। আপনার ব্যাকএন্ডের ক্যাটালগ সর্বশেষ তথ্যের সাথে আপনার Google Play ক্যাটালগ সর্বদা আপ টু ডেট আছে তা নিশ্চিত করা আরও ভাল ব্যবহারকারীর অভিজ্ঞতা তৈরি করার সুবিধা রয়েছে৷ যেমন:

• আপনি উপলব্ধ অফারগুলির সম্পূর্ণ তালিকার সাথে পরামর্শ করতে সক্ষম হবেন এবং আপনার নিজের যোগ্যতাকে প্রভাবিত করতে অফার এবং বেস প্ল্যান ট্যাগগুলি পরিচালনা করতে পারবেন এবং সার্ফেসিং লজিক অফার করতে পারবেন।
• আপনি প্ল্যাটফর্ম জুড়ে ব্যবহারকারীরা দেখতে পাচ্ছেন বিভিন্ন মূল্য পয়েন্ট এবং পণ্যের বিবরণ পরীক্ষা করতে পারেন এবং নিশ্চিত করুন যে সেগুলি সামঞ্জস্যপূর্ণ।
• ব্যবহারকারীর ক্রিটিক্যাল ফ্লো চলাকালীন Google Play Developer API এ অতিরিক্ত কল করে লেটেন্সি এবং ব্যর্থতার ঝুঁকি বাড়ানোর প্রয়োজন ছাড়াই নতুন কেনাকাটা প্রক্রিয়া করার সময় আপনার ব্যাকএন্ডে পণ্যের বিবরণ থাকবে।

Google Play-তে আপনার পণ্যের ক্যাটালগ তৈরি করার সময় আপনার কিছু সীমা এবং বিবেচনার কথা মাথায় রাখা উচিত। একবার আপনি এই সীমাগুলি বুঝতে পারলে এবং আপনি কীভাবে আপনার ক্যাটালগ গঠন করতে চান তা জানলে, এটি আপনার সিঙ্ক্রোনাইজেশন কৌশল সম্পর্কে সিদ্ধান্ত নেওয়ার সময়।

ক্যাটালগ সিঙ্ক্রোনাইজেশন কৌশল

Google Play Developer API প্রকাশনার এন্ডপয়েন্ট আপনাকে পরিবর্তনের সাথে সাথে আপনার ক্যাটালগে আপডেট করতে দেয়। উপলক্ষ্যে, আপনাকে একটি পর্যায়ক্রমিক আপডেট পদ্ধতি গ্রহণ করতে হতে পারে, যেখানে আপনি একই প্রক্রিয়ায় পরিবর্তনের একটি ব্যাটারি পাঠান। প্রতিটি পদ্ধতির জন্য বিভিন্ন নকশা পছন্দ প্রয়োজন। প্রতিটি সিঙ্ক্রোনাইজেশন কৌশল অন্যদের তুলনায় কিছু ব্যবহারের ক্ষেত্রে ভালভাবে ফিট করবে এবং পরিস্থিতির উপর নির্ভর করে আপনার কাছে প্রয়োজনের একটি সেট থাকতে পারে যা উভয়ের জন্যই প্রয়োজন। কখনও কখনও আপনি একটি পণ্যের আপডেট করতে চাইতে পারেন যে মুহূর্তে আপনি একটি নতুন পরিবর্তন সম্পর্কে সচেতন হন, উদাহরণস্বরূপ একটি জরুরী পণ্য আপডেট প্রক্রিয়া করার জন্য (যেমন একটি ভুল মূল্য যত তাড়াতাড়ি সম্ভব সংশোধন করা প্রয়োজন)। অন্য সময় আপনি আপনার ব্যাকএন্ড এবং প্লে ক্যাটালগ সবসময় সামঞ্জস্যপূর্ণ হয় তা নিশ্চিত করতে একটি পর্যায়ক্রমিক পটভূমি সিঙ্ক ব্যবহার করতে পারেন। কিছু সাধারণ ব্যবহারের ক্ষেত্রে পড়ুন যেখানে আপনি এই বিভিন্ন ক্যাটালগ পরিচালনার কৌশলগুলি বাস্তবায়ন করতে চাইতে পারেন।

আপনার স্থানীয় ক্যাটালগ পরিবর্তনের সাথে সাথে আপডেটগুলি কখন পাঠাতে হবে৷

আদর্শভাবে, আপনার ব্যাকএন্ডের পণ্য ক্যাটালগে কোনো পরিবর্তন হওয়ার সাথে সাথেই আপডেট হওয়া উচিত, অসঙ্গতি কমাতে।

এই ধরনের আপডেট একটি ভাল বিকল্প যখন:

• আপনাকে অবশ্যই নিশ্চিত করতে হবে যে আপনার পণ্যগুলি সর্বদা আপ টু ডেট।
• আপনাকে প্রতিদিন আপনার পণ্যগুলিতে কিছু পরিবর্তন করতে হবে।
• আপনাকে এমন পণ্য আপডেট করতে হবে যা ইতিমধ্যেই উৎপাদনে আছে এবং বিক্রি হচ্ছে।

এই পদ্ধতিটি বাস্তবায়ন করা সহজ, এবং আপনাকে আপনার ক্যাটালগকে সর্বনিম্ন পরিমাণের অসঙ্গতি উইন্ডোর সাথে সিঙ্কে রাখতে দেয়।

কখন পর্যায়ক্রমিক আপডেট ব্যবহার করবেন

পর্যায়ক্রমিক আপডেটগুলি আপনার ব্যাকএন্ডে পণ্য সংস্করণে অ্যাসিঙ্ক্রোনাসভাবে চালানো হয় এবং সেগুলি একটি ভাল বিকল্প যখন:

• আপনার পণ্যগুলি একটি সংক্ষিপ্ত বিজ্ঞপ্তিতে আপডেট করা হয়েছে তা নিশ্চিত করতে হবে না।
• আপনাকে বাল্ক আপডেট বা সমঝোতা প্রক্রিয়ার পরিকল্পনা করতে হবে।
• আপনার ডিজিটাল পণ্যগুলি পরিচালনা করার জন্য আপনার কাছে ইতিমধ্যেই একটি বিষয়বস্তু বা ক্যাটালগ ম্যানেজমেন্ট সিস্টেম রয়েছে এবং এটি আপনার ক্যাটালগ ক্রমাগত আপডেট করে

বড় ক্যাটালগের ক্ষেত্রে, সর্বাধিক থ্রুপুট অর্জনের জন্য লেটেন্সি সহনশীল আপডেট সহ ব্যাচ পদ্ধতি ব্যবহার করার কথা বিবেচনা করুন।

আপনার পণ্য ক্যাটালগ তৈরি করুন

Google Play-তে আপলোড করার জন্য আপনার কাছে একটি বড় ক্যাটালগ থাকলে, আপনি প্রাথমিক লোড স্বয়ংক্রিয় করতে চাইতে পারেন। এই ধরনের ভারী প্রক্রিয়া সবচেয়ে ভালো কাজ করে যদি লেটেন্সি সহনশীল ব্যাচ পদ্ধতির সাথে মিলিত একটি পর্যায়ক্রমিক কৌশল অনুসরণ করা হয়।

এককালীন পণ্য তৈরি করুন

প্রাথমিক এক-কালীন পণ্যের বড় ক্যাটালগ তৈরির জন্য, আমরা allowMissing ক্ষেত্রটি true সেট করে এবং PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT তে সেট করা latencyTolerance ক্ষেত্র সহ inappproducts.batchUpdate পদ্ধতি ব্যবহার করার পরামর্শ দিই। এটি কোটা সীমার মধ্যে ক্যাটালগ তৈরি করতে যে সময় নেয় তা কমিয়ে দেবে।

ছোট ক্যাটালগের জন্য, আপনি inapp_products.insert পদ্ধতি ব্যবহার করতে পারেন। বিকল্পভাবে আপনি পণ্য আপডেট বিভাগে বর্ণিত allowMissing প্যারামিটার সহ inappproducts.update পদ্ধতি ব্যবহার করতে পারেন। এই পদ্ধতিতে আপনার স্ক্রিপ্টের স্টেটফুল হওয়ার প্রয়োজনীয়তা দূর করার সুবিধা রয়েছে এবং কিছু ভুল হলে স্ক্র্যাচ থেকে পুনরায় চালু করা যেতে পারে।

সাবস্ক্রিপশন পণ্য তৈরি করুন

প্রাথমিক সাবস্ক্রিপশনের বড় ক্যাটালগ তৈরির জন্য, আমরা monetization.subscriptions.batchUpdate পদ্ধতিটি ব্যবহার করার পরামর্শ দিই যার সাথে allowMissing ক্ষেত্রটি true সেট করা হয়েছে এবং latencyTolerance ক্ষেত্রটিকে PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT এ সেট করা হয়েছে। এটি কোটা সীমার মধ্যে ক্যাটালগ তৈরি করতে যে সময় নেয় তা কমিয়ে দেবে।

ছোট সাবস্ক্রিপশন ক্যাটালগের জন্য Play Developer API monetization.subscriptions.create পদ্ধতি প্রদান করে। বিকল্পভাবে আপনি পণ্য আপডেট বিভাগে বর্ণিত allowMissing প্যারামিটার সহ monetization.subscriptions.update পদ্ধতি ব্যবহার করে সদস্যতা তৈরি করতে পারেন।

পূর্ববর্তী সমস্ত পদ্ধতি তাদের বেস প্ল্যানের সাথে সাবস্ক্রিপশন তৈরি করে (সাবস্ক্রিপশন অবজেক্টের মধ্যে সরবরাহ করা হয়)। এই ভিত্তি পরিকল্পনা প্রাথমিকভাবে নিষ্ক্রিয়. বেস প্ল্যানের স্ট্যাটাস ম্যানেজ করতে, আপনি monetization.subscriptions.basePlans এন্ডপয়েন্ট ব্যবহার করতে পারেন, এটি কেনার জন্য উপলব্ধ করার জন্য একটি বেস প্ল্যান সক্রিয় করা সহ। উপরন্তু, monetization.subscriptions.basePlans.offers এন্ডপয়েন্ট আপনাকে অফার তৈরি এবং পরিচালনা করতে দেয়।

পণ্য আপডেট

নিম্নলিখিত পদ্ধতিগুলি আপনাকে আপনার বিদ্যমান পণ্যগুলিকে দক্ষতার সাথে সংশোধন করতে সক্ষম করে, আপনার অফারগুলি আপনার সাম্প্রতিক সামঞ্জস্যের সাথে সারিবদ্ধ করা নিশ্চিত করে৷

এককালীন পণ্য আপডেট করুন

বিদ্যমান ওয়ান-টাইম প্রোডাক্ট আপডেট করতে আপনার কাছে তিনটি পদ্ধতি উপলব্ধ।

• inappproducts.patch : প্যাচ এন্ডপয়েন্ট আংশিকভাবে একটি সম্পদ আপডেট করতে ব্যবহৃত হয়। এর মানে হল আপনি নির্দিষ্ট ক্ষেত্রগুলি আপডেট করতে পারেন যা আপনি অনুরোধের বডিতে উল্লেখ করেছেন। প্যাচ এন্ডপয়েন্টটি সাধারণত ব্যবহার করা হয় যখন আপনাকে শুধুমাত্র একটি সম্পদের কয়েকটি ক্ষেত্র আপডেট করতে হবে।
• inappproducts.update : আপডেট এন্ডপয়েন্ট একটি রিসোর্সকে সম্পূর্ণরূপে আপডেট করতে ব্যবহৃত হয়। এর মানে হল যে আপনাকে অনুরোধের বডিতে সম্পূর্ণ রিসোর্স অবজেক্ট পাঠাতে হবে। আপডেট এন্ডপয়েন্ট সাধারণত ব্যবহার করা হয় যখন আপনি একটি সম্পদের সমস্ত ক্ষেত্র আপডেট করতে হবে। allowMissing প্যারামিটারটি true হিসাবে সেট করা হলে এবং সরবরাহকৃত পণ্য আইডি ইতিমধ্যেই বিদ্যমান না থাকলে, শেষপয়েন্ট ব্যর্থ হওয়ার পরিবর্তে পণ্যটি সন্নিবেশ করবে।
• inappproducts.batchUpdate : এটি আপডেট এন্ডপয়েন্টের একটি ব্যাচ সংস্করণ, যা আপনাকে একক প্রশ্নের সাথে একাধিক পণ্য পরিবর্তন করতে দেয়। উচ্চতর থ্রুপুট অর্জন করতে PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT এ সেট করা latencyTolerance ফিল্ডের সাথে একসাথে এটি ব্যবহার করুন৷

সদস্যতা পণ্য আপডেট

বিদ্যমান সদস্যতা আপডেট করতে, আপনি monetization.subscriptions.patch পদ্ধতি ব্যবহার করতে পারেন। এই পদ্ধতি নিম্নলিখিত প্রয়োজনীয় পরামিতি লাগে:

• packageName : সাবস্ক্রিপশনের অন্তর্গত অ্যাপটির প্যাকেজের নাম।
• productId : সাবস্ক্রিপশনের অনন্য পণ্য আইডি।
• regionsVersion : অঞ্চল কনফিগারেশন সংস্করণ ।

আপনি allowMissing প্যারামিটার ব্যবহার করে একটি নতুন সাবস্ক্রিপশন তৈরি না করলে, আপনাকে অবশ্যই updateMask প্যারামিটার প্রদান করতে হবে। এই প্যারামিটারটি হল একটি কমা দ্বারা পৃথক করা ক্ষেত্রগুলির তালিকা যা আপনি আপডেট করতে চান৷

উদাহরণস্বরূপ, যদি আপনি শুধুমাত্র একটি সাবস্ক্রিপশন পণ্যের একটি তালিকা আপডেট করতে চান, তাহলে আপনি updateMask প্যারামিটারে listings ক্ষেত্রটি নির্দিষ্ট করবেন।

আপনি একই সময়ে একাধিক সদস্যতা আপডেট করতে monetization.subscriptions.batchUpdate ব্যবহার করতে পারেন। উচ্চতর থ্রুপুট অর্জন করতে PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT এ সেট করা latencyTolerance ফিল্ডের সাথে একসাথে এটি ব্যবহার করুন৷

বেস প্ল্যানগুলি সক্রিয় করতে, নিষ্ক্রিয় করতে, মুছে ফেলতে বা সর্বশেষ বেস প্ল্যান মূল্য সংস্করণে গ্রাহকদের স্থানান্তর করতে monetization.subscriptions.basePlans এন্ডপয়েন্ট ব্যবহার করুন৷

উপরন্তু, আপনি monetization.subscriptions.basePlans.offers.patch পদ্ধতির মাধ্যমে আপনার বেস প্ল্যানের অফার আপডেট করতে পারেন।

ক্যাটালগ পুনর্মিলন

আপনি প্রতিবার আপনার ব্যাকএন্ডের ক্যাটালগ পরিবর্তন করার সময় বা পর্যায়ক্রমে আপনার Google Play ক্যাটালগ আপডেট করতে পছন্দ করুন না কেন, আপনার যদি Google Play-এর ক্যাটালগের বাইরে একটি ক্যাটালগ ব্যবস্থাপনা সিস্টেম বা একটি ডাটাবেস থাকে তবে এমন পরিস্থিতি হতে পারে যেখানে এটি আপনার অ্যাপস কনফিগারেশনের ক্যাটালগের সাথে সিঙ্কের বাইরে চলে যায়। খেলায় এটি কনসোলে জরুরী ম্যানুয়াল ক্যাটালগ পরিবর্তনের কারণে হতে পারে, আপনার ক্যাটালগ ম্যানেজমেন্ট সিস্টেমে একটি বিভ্রাট বা আপনি যদি আপনার সাম্প্রতিক ডেটা হারিয়ে ফেলে থাকেন।

আপনি একটি দীর্ঘায়িত অসঙ্গতি উইন্ডো এড়াতে একটি ক্যাটালগ পুনর্মিলন প্রক্রিয়া তৈরি করতে পারেন।

ভিন্ন সিস্টেম বিবেচনা

আমরা অসঙ্গতি সনাক্ত করতে এবং দুটি সিস্টেমের সমন্বয় করতে একটি ভিন্ন সিস্টেম তৈরি করার পরামর্শ দিই। আপনার ক্যাটালগগুলিকে সিঙ্কে রাখতে সাহায্য করার জন্য একটি ডিফ সিস্টেম তৈরি করার সময় এখানে কিছু বিষয় বিবেচনা করতে হবে:

• ডেটা মডেলগুলি বুঝুন: প্রথম ধাপ হল ডেভেলপার CMS এবং Google Play Developer API-এর ডেটা মডেলগুলি বোঝা৷ এর মধ্যে প্রতিটি সিস্টেমে সংরক্ষিত বিভিন্ন ধরণের ডেটা এবং কীভাবে বিভিন্ন ডেটা উপাদান একে অপরের সাথে মানচিত্র তৈরি করে তা জানা অন্তর্ভুক্ত।
• পার্থক্য নিয়মগুলি সংজ্ঞায়িত করুন: একবার আপনি ডেটা মডেলগুলি বুঝতে পারলে, আপনাকে আলাদা নিয়মগুলি সংজ্ঞায়িত করতে হবে। এই নিয়মগুলি নির্ধারণ করবে কিভাবে দুটি সিস্টেমের ডেটা তুলনা করা হয়। উদাহরণ স্বরূপ, আপনি পণ্যের আইডি মেলাতে চাইতে পারেন এবং সাবস্ক্রিপশনের মূল বৈশিষ্ট্য এবং এর সাথে সম্পর্কিত বেস প্ল্যান এবং অফারগুলির তুলনা করতে পারেন।
• একটি ডিফ অ্যালগরিদম প্রয়োগ করুন: একবার আপনি ভিন্ন নিয়মগুলি সংজ্ঞায়িত করলে, আপনাকে ডিফ অ্যালগরিদম বাস্তবায়ন করতে হবে। এই অ্যালগরিদম দুটি সিস্টেম থেকে ডেটা নেবে এবং আপনার সংজ্ঞায়িত নিয়ম অনুযায়ী এটি তুলনা করবে। Google Play থেকে ক্যাটালগ ডেটা পেতে, আপনি inappproducts.list , inappproducts.batchGet , monetization.subscriptions.list এবং monetization.subscriptions.batchGet পদ্ধতিগুলি ব্যবহার করতে পারেন৷
• ডিফ রিপোর্ট তৈরি করুন: ডিফ অ্যালগরিদম একটি ভিন্ন প্রতিবেদন তৈরি করবে। এই প্রতিবেদনটি উভয় সিস্টেমের মধ্যে পার্থক্য দেখাবে।
• পার্থক্য মিটমাট করুন: একবার আপনি ডিফ রিপোর্ট তৈরি করলে, আপনাকে পার্থক্যগুলি সমাধান করতে হবে। এতে আপনার CMS-এ ডেটা আপডেট করা জড়িত হতে পারে, অথবা আপনি সাধারণত কীভাবে আপনার ক্যাটালগ আপডেট করেন তার উপর নির্ভর করে ডেভেলপার API ক্যাটালগ ম্যানেজমেন্ট এন্ডপয়েন্ট ব্যবহার করে Google Play-এর পক্ষের ডেটা আপডেট করা জড়িত হতে পারে। সিঙ্ক পণ্যগুলির মধ্যে সমন্বয় করতে, পণ্য আপডেট বিভাগে বর্ণিত আপডেটের শেষ পয়েন্টগুলি ব্যবহার করুন৷

পণ্য অবচয়

Google Play Developer API ডেভেলপারদের তাদের পণ্যগুলিকে অবমূল্যায়ন করতে সহায়তা করার জন্য বিভিন্ন পদ্ধতি অফার করে: এককালীন পণ্যের জন্য inappproducts.delete এবং inappproducts.batchDelete এবং সদস্যতার জন্য monetization.subscriptions.delete ৷ একটি পণ্যের অবমূল্যায়ন বিভিন্ন পরিস্থিতিতে প্রয়োজনীয় হতে পারে, যেমন:

• ভুল করে সৃষ্টি।
• একটি বৈশিষ্ট্য বা পরিষেবা বন্ধ করা।

আমরা আপনার ক্যাটালগ পরিচালনার কৌশলে পণ্য অবচয় অন্তর্ভুক্ত করার পরামর্শ দিই।

এককালীন পণ্য অবমূল্যায়ন করুন

Google Play Developer API দিয়ে এক-কালীন পণ্য মুছে ফেলতে, আপনাকে inappproducts.delete বা inappproducts.batchDelete পদ্ধতি ব্যবহার করতে হবে।

সদস্যতা পণ্য বাতিল করুন

আপনি monetization.subscriptions.delete পদ্ধতি ব্যবহার করে সদস্যতা মুছে ফেলতে পারেন। অন্তত একটি বেস প্ল্যান সক্রিয় হয়ে গেলে সাবস্ক্রিপশন সরানো যাবে না।