จัดการแคตตาล็อกผลิตภัณฑ์

คำแนะนำนี้จะอธิบายวิธีใช้ Google Play Developer API เพื่อสร้างและจัดการแคตตาล็อกผลิตภัณฑ์สำหรับแอป Play

หากต้องการขายผลิตภัณฑ์ในแอปผ่านระบบการเรียกเก็บเงินของ Google Play คุณต้องสร้างแคตตาล็อกที่มีผลิตภัณฑ์ทั้งหมดที่ต้องการให้ผู้ใช้ซื้อได้ ซึ่งทำได้ผ่าน Play Console หรือจะจัดการแคตตาล็อกแบบอัตโนมัติโดยใช้ Google Play Developer API ก็ได้ การทำงานอัตโนมัติจะช่วยให้แคตตาล็อกเป็นปัจจุบันอยู่เสมอและปรับขนาดให้เหมาะกับแคตตาล็อกขนาดใหญ่ที่การประสานงานด้วยตนเองไม่สามารถทำได้ ในคู่มือนี้ คุณจะเห็นวิธีใช้ Play Developer API เพื่อสร้างและจัดการแคตตาล็อกผลิตภัณฑ์สำหรับแอป Play ของคุณ อ่านคู่มือการเตรียมพร้อมเพื่อดูวิธีการตั้งค่า Google Play Developer API สำหรับการผสานรวมแบ็กเอนด์

API การจัดการแคตตาล็อก

หากต้องการอ่านเกี่ยวกับผลิตภัณฑ์ประเภทต่างๆ ที่คุณขายได้โดยใช้ระบบการเรียกเก็บเงินของ Google Play โปรดอ่านทำความเข้าใจประเภทของไอเทมที่ซื้อในแอปและข้อควรพิจารณาเกี่ยวกับแคตตาล็อก Google มีชุด API หลัก 2 ชุดสำหรับการจัดการแคตตาล็อกใน Play ซึ่งสอดคล้องกับหมวดหมู่ผลิตภัณฑ์หลัก 2 หมวดหมู่ ดังนี้

• ผลิตภัณฑ์แบบเรียกเก็บเงินครั้งเดียว
• ผลิตภัณฑ์ที่ต้องสมัครใช้บริการ

ผลิตภัณฑ์แบบเรียกเก็บเงินครั้งเดียว

ปลายทาง 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 Developer API เพื่อจัดการแคตตาล็อกผลิตภัณฑ์

1. Google Play Developer API มีขีดจํากัดเริ่มต้นอยู่ที่ 200,000 การค้นหาต่อวัน ขีดจํากัดโควต้านี้มีผลกับการรวมการใช้งานในอุปกรณ์ปลายทางทั้งหมด รวมถึง API การจัดการแคตตาล็อก
2. นอกจากนี้ ปลายทางการแก้ไขผลิตภัณฑ์ยังมีขีดจํากัดที่ 7,200 คําค้นหาต่อชั่วโมงด้วย ซึ่งขีดจำกัดนี้มีผลกับทั้งผลิตภัณฑ์แบบครั้งเดียวและการสมัครใช้บริการ รวมถึงคำขอแก้ไขทั้งหมด ซึ่งรวมถึงการสร้าง การอัปเดต การเปิดใช้งาน และการลบ การเรียกใช้เมธอดการแก้ไขแบบเป็นกลุ่มจะนับเป็นการค้นหา 1 ครั้งสำหรับโควต้านี้ โดยไม่คำนึงถึงจำนวนคำขอแต่ละรายการที่รวมอยู่หรือความไวในการตอบสนองของคำขอ
3. การแก้ไขที่ไวต่อเวลาในการตอบสนองยังมีขีดจํากัดอยู่ที่ 7,200 ครั้งต่อชั่วโมงด้วย สําหรับเมธอดแบบเป็นกลุ่ม คําขอแก้ไขที่ฝังอยู่ทุกรายการจะนับแยกกันเพื่อวัตถุประสงค์ของโควต้านี้ โควต้านี้มีผลในทางปฏิบัติต่อผู้ใช้ Batch 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 รายการ โควต้า 2 รายการ และโควต้า 3 รายการ 100 รายการ

คําแนะนําในการใช้ Catalog Management API

การปฏิบัติตามหลักเกณฑ์เหล่านี้จะช่วยเพิ่มประสิทธิภาพการโต้ตอบกับ API เพื่อให้คุณได้รับประสบการณ์การจัดการแคตตาล็อกที่ราบรื่นและมีประสิทธิภาพ

ตรวจสอบการใช้งาน

คุณควรคำนึงถึงกระบวนการที่มีการใช้งานมาก ตัวอย่างเช่น ในช่วงเริ่มต้นของการผสานรวม ปลายทางการจัดการแคตตาล็อกมีแนวโน้มที่จะใช้โควต้ามากขึ้นเพื่อสร้างแคตตาล็อกเริ่มต้นที่สมบูรณ์ และอาจส่งผลต่อการใช้งานปลายทางอื่นๆ ในเวอร์ชันที่ใช้งานจริง เช่น API สถานะการซื้อ หากคุณใกล้ถึงขีดจำกัดการใช้งานโดยรวม คุณต้องตรวจสอบการใช้โควต้าเพื่อให้แน่ใจว่าคุณไม่ได้ใช้โควต้า API เกิน การตรวจสอบการใช้งานทำได้หลายวิธี เช่น คุณสามารถใช้แดชบอร์ดโควต้าของ Google Cloud API หรือเครื่องมือตรวจสอบ API อื่นๆ ที่คุณมีหรือของบุคคลที่สาม

เพิ่มประสิทธิภาพการใช้โควต้า API

เราขอแนะนําอย่างยิ่งให้เพิ่มประสิทธิภาพอัตราการใช้เพื่อลดโอกาสที่จะเกิดข้อผิดพลาด API เราขอแนะนําให้คุณทําดังนี้เพื่อให้ใช้งานฟีเจอร์นี้ได้อย่างมีประสิทธิภาพ

• เลือกกลยุทธ์การจัดการแคตตาล็อกที่เหมาะสม เมื่อเข้าใจโควต้า API แล้ว คุณจะต้องเลือกกลยุทธ์ที่เหมาะสมสําหรับแอปพลิเคชันเพื่อให้บรรลุเป้าหมายการจัดการแคตตาล็อกได้อย่างมีประสิทธิภาพ
• โทรเพียงจำนวนครั้งที่จําเป็นเพื่อแสดงการเปลี่ยนแปลง
• อย่าส่งการเรียกให้แก้ไขที่ซ้ำซ้อนหรือไม่จำเป็นไปยัง API ซึ่งอาจทำให้คุณต้องเก็บบันทึกการเปลี่ยนแปลงไว้ในแคตตาล็อกแบ็กเอนด์
• ดำเนินการแก้ไขผลิตภัณฑ์ไม่เกินขีดจำกัด 7,200 คำค้นหาต่อชั่วโมง คุณอาจต้องสร้างกระบวนการซิงค์ที่คุณต้องทำการแก้ไขผลิตภัณฑ์จํานวนมากในระยะเวลาสั้นๆ (เช่น การสร้างแคตตาล็อกเริ่มต้น) หากคาดว่ากระบวนการเหล่านี้จะเกินขีดจำกัดรายชั่วโมง ให้ใช้การรอตามที่จำเป็นเพื่อลดการใช้งานให้อยู่ในระดับที่ปลอดภัย ลองใช้วิธีการแบบเป็นกลุ่มกับการอัปเดตที่ยอมรับเวลาในการตอบสนองสูงเพื่อให้ได้อัตราผ่านข้อมูลสูงขึ้น
• เตรียมพร้อมเพื่อปรับขนาด เมื่อแอปพลิเคชันเติบโตขึ้น คุณอาจต้องปรับขนาดการใช้งาน API และปลายทางต่างๆ ให้มากขึ้น อ่านเอกสารประกอบเกี่ยวกับโควต้าของ Google 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 ช่วยให้คุณอัปเดตแคตตาล็อกได้เมื่อมีการเปลี่ยนแปลง ในบางครั้ง คุณอาจต้องใช้แนวทางการอัปเดตเป็นระยะ ซึ่งคุณส่งการเปลี่ยนแปลงหลายรายการในกระบวนการเดียวกัน แต่ละแนวทางต้องใช้ตัวเลือกการออกแบบที่แตกต่างกัน กลยุทธ์การซิงค์แต่ละกลยุทธ์จะเหมาะกับบางกรณีการใช้งานมากกว่ากรณีอื่นๆ และคุณอาจมีชุดความต้องการที่ต้องใช้ทั้ง 2 กลยุทธ์ ทั้งนี้ขึ้นอยู่กับสถานการณ์ บางครั้งคุณอาจต้องการอัปเดตผลิตภัณฑ์ทันทีที่ทราบถึงการเปลี่ยนแปลงใหม่ เช่น เพื่อดำเนินการอัปเดตผลิตภัณฑ์อย่างเร่งด่วน (เช่น ต้องแก้ไขราคาที่ไม่ถูกต้องโดยเร็วที่สุด) ในกรณีอื่นๆ คุณสามารถใช้การซิงค์เบื้องหลังเป็นระยะๆ เพื่อให้มั่นใจว่าแบ็กเอนด์และแคตตาล็อก Play ของคุณจะสอดคล้องกันเสมอ อ่านกรณีการใช้งานทั่วไปที่อาจทำให้คุณต้องใช้กลยุทธ์การจัดการแคตตาล็อกต่างๆ เหล่านี้

กรณีที่ควรส่งการอัปเดตเมื่อแคตตาล็อกในเครื่องมีการเปลี่ยนแปลง

โดยปกติแล้ว การอัปเดตควรเกิดขึ้นทันทีที่มีการเปลี่ยนแปลงแคตตาล็อกผลิตภัณฑ์ของแบ็กเอนด์ เพื่อลดความคลาดเคลื่อน

การอัปเดตประเภทนี้เป็นตัวเลือกที่ดีในกรณีต่อไปนี้

• คุณต้องตรวจสอบว่าผลิตภัณฑ์เป็นข้อมูลล่าสุดอยู่เสมอ
• คุณต้องเปลี่ยนแปลงผลิตภัณฑ์ 2-3 อย่างในแต่ละวัน
• คุณต้องอัปเดตผลิตภัณฑ์ที่ผลิตและจำหน่ายอยู่แล้ว

วิธีนี้ใช้งานได้ง่ายกว่าและช่วยให้แคตตาล็อกของคุณซิงค์กันอยู่เสมอโดยมีกรอบเวลาความคลาดเคลื่อนของจำนวนเงินน้อยที่สุด

กรณีที่ควรใช้การอัปเดตเป็นระยะ

การอัปเดตเป็นระยะจะทำงานแบบไม่สอดคล้องกันกับรุ่นผลิตภัณฑ์ในแบ็กเอนด์ และเป็นตัวเลือกที่ดีในกรณีต่อไปนี้

• คุณไม่จำเป็นต้องอัปเดตผลิตภัณฑ์ในระยะเวลาอันสั้น
• คุณต้องวางแผนการอัปเดตแบบเป็นกลุ่มหรือกระบวนการไกล่เกลี่ย
• คุณมีระบบการจัดการเนื้อหาหรือแคตตาล็อกเพื่อจัดการผลิตภัณฑ์ดิจิทัลอยู่แล้ว และระบบดังกล่าวอัปเดตแคตตาล็อกอยู่ตลอดเวลา

ในกรณีที่แคตตาล็อกมีขนาดใหญ่ ให้ลองใช้วิธีการเป็นกลุ่มที่มีการอัปเดตที่ยอมรับเวลาในการตอบสนองสูงเพื่อให้ได้อัตราการผลิตสูงสุด

สร้างแคตตาล็อกผลิตภัณฑ์

หากมีคอลเล็กชันขนาดใหญ่ที่จะอัปโหลดไปยัง 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.patch พร้อมพารามิเตอร์ allowMissing ตามที่อธิบายไว้ในส่วนอัปเดตผลิตภัณฑ์ก็ได้

วิธีการก่อนหน้านี้ทั้งหมดจะสร้างการสมัครใช้บริการพร้อมกับแพ็กเกจพื้นฐาน (ระบุไว้ในออบเจ็กต์การสมัครใช้บริการ) แพ็กเกจเริ่มต้นเหล่านี้จะปิดใช้งานอยู่โดยค่าเริ่มต้น หากต้องการจัดการสถานะของ Base Plan คุณสามารถใช้ปลายทาง monetization.subscriptions.basePlans รวมถึงเปิดใช้งาน Base Plan เพื่อให้พร้อมจำหน่าย นอกจากนี้ ปลายทาง monetization.subscriptions.basePlans.offers ยังให้คุณสร้างและจัดการข้อเสนอได้ด้วย

ข้อมูลอัปเดตเกี่ยวกับผลิตภัณฑ์

วิธีการต่อไปนี้ช่วยให้คุณแก้ไขผลิตภัณฑ์ที่มีอยู่ได้อย่างมีประสิทธิภาพ เพื่อให้ข้อเสนอของคุณสอดคล้องกับการปรับล่าสุด

อัปเดตผลิตภัณฑ์แบบครั้งเดียว

คุณอัปเดตผลิตภัณฑ์แบบครั้งเดียวที่มีอยู่ได้ 3 วิธี

• inappproducts.patch : ปลายทางการแพตช์ใช้เพื่ออัปเดตทรัพยากรบางส่วน ซึ่งหมายความว่าคุณจะอัปเดตฟิลด์ที่เฉพาะเจาะจงซึ่งระบุไว้ในเนื้อหาคำขอได้ โดยปกติแล้วปลายทางการแพตช์จะใช้เมื่อคุณต้องการอัปเดตเพียงไม่กี่ช่องของทรัพยากร
• inappproducts.update : ใช้ปลายทางการอัปเดตเพื่ออัปเดตทรัพยากรทั้งหมด ซึ่งหมายความว่าคุณจะต้องส่งออบเจ็กต์ทรัพยากรทั้งหมดในเนื้อหาคำขอ โดยปกติแล้วปลายทางการอัปเดตจะใช้เมื่อคุณต้องการอัปเดตช่องทั้งหมดในทรัพยากร เมื่อตั้งค่าพารามิเตอร์ allowMissing เป็น true และรหัสผลิตภัณฑ์ที่ระบุยังไม่มีอยู่ เอนทิตีปลายทางจะแทรกผลิตภัณฑ์แทนที่จะดำเนินการไม่สำเร็จ
• inappproducts.batchUpdate : นี่คือปลายทางการอัปเดตเวอร์ชันกลุ่ม ซึ่งให้คุณแก้ไขผลิตภัณฑ์หลายรายการได้ด้วยการค้นหาครั้งเดียว ใช้ร่วมกับช่อง latencyTolerance ที่ตั้งค่าเป็น PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT เพื่อให้ได้อัตราผ่านข้อมูลสูงขึ้น

อัปเดตผลิตภัณฑ์ที่ต้องสมัครใช้บริการ

หากต้องการอัปเดตการสมัครใช้บริการที่มีอยู่ ให้ใช้เมธอด monetization.subscriptions.patch เมธอดนี้ใช้พารามิเตอร์ที่จําเป็นต่อไปนี้

• packageName: ชื่อแพ็กเกจของแอปที่การสมัครใช้บริการนั้นอยู่
• productId: รหัสผลิตภัณฑ์ที่ไม่ซ้ำกันของการสมัครใช้บริการ
• regionsVersion: เวอร์ชันการกำหนดค่าภูมิภาค

คุณต้องระบุพารามิเตอร์ updateMask เว้นแต่คุณจะสร้างการติดตามใหม่โดยใช้พารามิเตอร์ allowMissing พารามิเตอร์นี้เป็นรายการช่องที่คั่นด้วยคอมมาซึ่งคุณต้องการอัปเดต

เช่น หากต้องการอัปเดตข้อมูลผลิตภัณฑ์ที่ต้องสมัครใช้บริการเท่านั้น คุณจะต้องระบุช่อง 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

เราขอแนะนำให้สร้างระบบการเปรียบเทียบเพื่อตรวจหาความไม่สอดคล้องและปรับยอดระบบ 2 ระบบ สิ่งที่ควรพิจารณาเมื่อสร้างระบบการเปรียบเทียบเพื่อช่วยให้แคตตาล็อกของคุณซิงค์กันอยู่มีดังนี้

• ทำความเข้าใจรูปแบบข้อมูล: ขั้นตอนแรกคือทำความเข้าใจรูปแบบข้อมูลของ CMS ของนักพัฒนาแอปและ Google Play Developer API ซึ่งรวมถึงการทราบข้อมูลประเภทต่างๆ ที่เก็บไว้ในแต่ละระบบ และวิธีที่องค์ประกอบข้อมูลต่างๆ เชื่อมโยงกัน
• กำหนดกฎ diff: เมื่อเข้าใจโมเดลข้อมูลแล้ว คุณจะต้องกำหนดกฎ diff กฎเหล่านี้จะกําหนดวิธีเปรียบเทียบข้อมูลใน 2 ระบบ เช่น คุณอาจต้องการจับคู่รหัสผลิตภัณฑ์และเปรียบเทียบแอตทริบิวต์หลักของการสมัครใช้บริการกับแพ็กเกจพื้นฐานและข้อเสนอที่เกี่ยวข้อง
• ใช้อัลกอริทึม Diff: เมื่อกําหนดกฎ Diff แล้ว คุณต้องใช้อัลกอริทึม Diff อัลกอริทึมนี้จะนําข้อมูลจาก 2 ระบบมาเปรียบเทียบกันตามกฎที่คุณกําหนด หากต้องการรับข้อมูลแคตตาล็อกจาก Google Play คุณสามารถใช้เมธอด inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list และ monetization.subscriptions.batchGet
• สร้างรายงานการเปรียบเทียบ: อัลกอริทึมการเปรียบเทียบจะสร้างรายงานการเปรียบเทียบ รายงานนี้จะแสดงความแตกต่างระหว่างทั้ง 2 ระบบ
• ปรับยอดความแตกต่าง: เมื่อสร้างรายงานความแตกต่างแล้ว คุณจะต้องแก้ไขความแตกต่าง ซึ่งอาจเกี่ยวข้องกับการอัปเดตข้อมูลใน 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 เมื่อเปิดใช้งานแพ็กเกจเริ่มต้นอย่างน้อย 1 แพ็กเกจแล้ว คุณจะนําการสมัครใช้บริการออกไม่ได้