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

คู่มือนี้อธิบายวิธีใช้ Google Play Developer API เพื่อสร้างและจัดการแคตตาล็อกสินค้าสำหรับแอป Google 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

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

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

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

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

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

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

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

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

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

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