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

คู่มือนี้อธิบายวิธีใช้ 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 หมวดหมู่ ดังนี้

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

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

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

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

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

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

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

ปลายทาง onetimeproducts, inappproducts และ monetization.subscriptions มีเมธอดแบบกลุ่มหลายรายการที่ช่วยให้ดึงหรือจัดการเอนทิตีได้สูงสุด 100 รายการภายใต้แอปเดียวกันในเวลาเดียวกัน

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

เวลาในการเผยแพร่ที่อัปเดตเทียบกับปริมาณงาน

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

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

เมื่อใช้ Play Developer API เพื่อจัดการแคตตาล็อกผลิตภัณฑ์ คุณควรทราบโควต้าต่อไปนี้

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

ต่อไปนี้คือตัวอย่างที่แสดงให้เห็นถึงการใช้งานโควต้าของคำขอต่างๆ เพื่อให้คุณเข้าใจได้ดียิ่งขึ้น

  • get คำขอเดียวเพื่อดึงข้อมูล 1 รายการจะใช้โทเค็น 1 รายการจากโควต้า 1 และ ไม่มีโทเค็นจากโควต้า 2 และ 3 (เนื่องจากเกี่ยวข้องกับเฉพาะปลายทางการแก้ไข)
  • คำขอแบบกลุ่ม get เพื่อดึงข้อมูลสินค้าสูงสุด 100 รายการจะใช้โทเค็น 1 รายการจาก โควต้า 1 และไม่ใช้โทเค็นจากโควต้า 2 และ 3
  • modificationคำขอเดียวสำหรับสินค้า 1 รายการจะใช้โทเค็นโควต้า 1 จำนวน 1 รายการ และโทเค็นโควต้า 2 จำนวน 1 รายการ หากคำขอมีความไวต่อเวลาในการตอบสนอง คำขอจะใช้โทเค็น 1 รายการจากโควต้า 3 ด้วย เนื่องจากโควต้า 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 เป็นข้อมูลล่าสุดของแคตตาล็อกในแบ็กเอนด์อยู่เสมอมีข้อดีในการสร้างประสบการณ์การใช้งานที่ดีขึ้น เช่น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

อัปเดตไอเทมแบบเรียกเก็บเงินครั้งเดียว

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

  • monetization.onetimeproducts.batchUpdate
  • inappproducts.patch : ใช้ปลายทาง PATCH เพื่ออัปเดตทรัพยากร บางส่วน ซึ่งหมายความว่าคุณสามารถอัปเดตฟิลด์ที่เฉพาะเจาะจงซึ่งคุณระบุใน เนื้อหาคำขอได้ โดยปกติแล้วจะใช้ปลายทาง 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 ซึ่งอาจเกิดจากการเปลี่ยนแปลงแคตตาล็อกด้วยตนเองใน Console ในกรณีฉุกเฉิน ระบบหยุดทำงานในระบบการจัดการแคตตาล็อก หรือคุณอาจสูญเสียข้อมูลล่าสุด

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

การพิจารณาระบบ Diff

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

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

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

Google Play Developer API มีวิธีการต่อไปนี้เพื่อช่วยคุณในการ เลิกใช้งานผลิตภัณฑ์

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

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

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

การเลิกใช้งานผลิตภัณฑ์อาจจำเป็นในสถานการณ์ต่างๆ เช่น

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

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