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

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

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

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

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

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

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

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

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

อุปกรณ์ปลายทาง monetization.subscriptions จะช่วยคุณจัดการการสมัครใช้บริการ จากแบ็กเอนด์ของนักพัฒนาซอฟต์แวร์ได้ คุณสามารถทำสิ่งต่างๆ เช่น สร้าง อัปเดต และลบการสมัครใช้บริการ หรือควบคุมความพร้อมจำหน่ายสินค้าและการกำหนดราคาระดับภูมิภาค นอกจากปลายทาง monetization.subscriptions แล้ว เรายังมี monetization.subscriptions.basePlans และ monetization.subscriptions.basePlans.offers เพื่อจัดการตามลำดับ การสมัครใช้บริการ แพ็กเกจเริ่มต้นและข้อเสนอ

วิธีการแบบกลุ่ม

inappproducts และ monetization.subscriptions อุปกรณ์ปลายทางมอบวิธีแบบกลุ่มที่ทำให้สามารถเรียกข้อมูลหรือจัดการ เป็น 100 รายการภายใต้แอปเดียวกันได้ในเวลาเดียวกัน

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

อัปเดตเวลาในการตอบสนองของการนำไปใช้งานเทียบกับอัตราการส่งข้อมูล

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

การกำหนดค่าโควต้า

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

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

ต่อไปนี้เป็นภาพตัวอย่างที่ช่วยให้คุณเข้าใจการใช้โควต้าของ คำขอต่างๆ:

• คำขอ get รายการเดียวเพื่อดึงข้อมูล 1 รายการจะใช้โทเค็น 1 รายการจากโควต้า 1 และ ไม่มีโทเค็นของโควต้า 2 และ 3 (เนื่องจากเกี่ยวข้องกับปลายทางการแก้ไขเท่านั้น)
• คำขอ get แบบกลุ่มเพื่อดึงข้อมูลสูงสุด 100 รายการจะใช้โทเค็น 1 รายการด้วย โควต้าที่ 1 และไม่มีโทเค็นของโควต้า 2 และ 3
• คำขอ modification รายการเดียวสำหรับ 1 รายการจะใช้โทเค็น 1 โทเค็นจากโควต้าที่ 1 1 โทเค็นของโควต้า 2 หากคำขอมีความละเอียดอ่อนด้านเวลาในการตอบสนอง ระบบจะยัง ใช้โทเค็นที่ 3 จำนวน 1 โทเค็น เนื่องจากโควต้า C มีขีดจำกัดเท่ากับโควต้า 2 ไม่มีผลกระทบในทางปฏิบัติสำหรับผู้ใช้ที่แก้ไขได้เพียงครั้งเดียว
• คำขอ modification แบบกลุ่มสำหรับรายการที่ทนต่อเวลาในการตอบสนอง 100 รายการจะใช้ 1 รายการ โทเค็นของโควต้า 1, 1 โทเค็นของโควต้า 2 การตั้งค่าโควต้านี้น่าจะช่วยให้ เพื่ออัปเดตแคตตาล็อกของคุณอยู่เสมอ แต่ถ้าอัลกอริทึมไม่ได้พิจารณา และเกินกว่าอัตรานี้ คุณอาจพบข้อผิดพลาดต่อการโทรเพิ่มเติม
• ระบบจะใช้คำขอ modification แบบกลุ่มสำหรับรายการที่ละเอียดอ่อนเวลาในการตอบสนอง 100 รายการ 1 โทเค็นจากโควต้า 1, 1 โทเค็นจากโควต้า 2 และ 100 โทเค็นจากโควต้า 3

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

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

ติดตามการใช้งาน

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

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

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

กลยุทธ์การซิงค์แคตตาล็อก

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

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

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

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

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

• 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 ซึ่งอาจเกิดจากการเปลี่ยนแปลงแคตตาล็อกฉุกเฉินในคอนโซล การหยุดทำงาน ในระบบการจัดการแคตตาล็อก หรือในกรณีที่คุณทำข้อมูลล่าสุดหาย

คุณสามารถสร้างกระบวนการปรับยอดแคตตาล็อกเพื่อหลีกเลี่ยงความคลาดเคลื่อนเป็นเวลานานได้

สร้างความแตกต่างระหว่างการพิจารณาของระบบ

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

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

การเลิกใช้งานผลิตภัณฑ์

API สำหรับนักพัฒนาซอฟต์แวร์ Google Play มีวิธีช่วยเหลือนักพัฒนาในด้านต่างๆ ดังต่อไปนี้ ระบบจะเลิกใช้งานผลิตภัณฑ์ต่อไปนี้ inappproducts.delete และ inappproducts.batchDelete สำหรับผลิตภัณฑ์แบบเรียกเก็บเงินครั้งเดียวและ monetization.subscriptions.delete สำหรับการสมัครใช้บริการ การเลิกใช้งานผลิตภัณฑ์อาจจำเป็นในสถานการณ์ต่างๆ เช่น

• สร้างโดยไม่ได้ตั้งใจ
• การปิดฟีเจอร์หรือบริการ

เราขอแนะนำให้คุณรวมการเลิกใช้งานผลิตภัณฑ์เข้ากับการจัดการแคตตาล็อก ของคุณ

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

หากต้องการลบผลิตภัณฑ์แบบเรียกเก็บเงินครั้งเดียวด้วย Google Play Developer API คุณต้องใช้ เวลา inappproducts.delete หรือ inappproducts.batchDelete

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

คุณลบการสมัครใช้บริการได้โดยใช้ monetization.subscriptions.delete ไม่สามารถนำการสมัครใช้บริการออกได้เมื่อมีแพ็กเกจเริ่มต้นอย่างน้อย 1 แพ็กเกจ เปิดใช้งาน แล้ว