อธิบายรูปแบบการกำหนดราคาของ Tracking API: คิดต่อการเรียกใช้ vs ต่อการจัดส่ง และวิธีประเมินต้นทุนจริงของคุณ
การกำหนดราคา Tracking API แบบต่อการเรียกเก็บค่าบริการต่อคำขอที่เรียกเก็บเงินได้ ส่วนการกำหนดราคาแบบต่อการจัดส่งจะเรียกเก็บค่าบริการสำหรับหน่วยติดตามที่กำหนดไว้ เช่น หมายเลขติดตามที่ลงทะเบียนแล้ว ไม่มีแบบใดถูกกว่าโดยอัตโนมัติ หากต้องการประมาณต้นทุนจริง ให้เปรียบเทียบทั้งสองรูปแบบโดยใช้ปริมาณการจัดส่งเดียวกัน ข้อกำหนดการอัปเดต ระยะเวลาการติดตาม และกฎการเรียกเก็บเงินเดียวกัน จากนั้นจึงบวกค่าธรรมเนียมแพลตฟอร์ม ค่าใช้บริการส่วนเกิน และต้นทุนการผสานรวม
สำหรับทีมวิศวกรรม ฝ่ายปฏิบัติการ และฝ่ายจัดซื้อ การเปรียบเทียบที่มีประโยชน์ไม่ได้มีเพียงราคาต่อการเรียกเทียบกับราคาต่อการจัดส่ง แต่คือค่าใช้จ่ายทั้งหมดในการมอบความสามารถในการมองเห็นสถานะการจัดส่งที่ธุรกิจของคุณต้องการ อัตราคำขอที่ต่ำอาจมีค่าใช้จ่ายสูงเมื่อมีการเรียกตรวจสอบบ่อยครั้ง ขณะที่อัตราต่อการจัดส่งที่ต่ำอาจทำให้เข้าใจผิด หากช่วงเวลาการติดตามหรือบริการที่รวมอยู่ไม่เหมาะกับเวิร์กโฟลว์ของคุณ
แต่ละรูปแบบการกำหนดราคาวัดอะไรจริง ๆ
ขั้นตอนแรกคือการแยกสามสิ่งออกจากกัน ได้แก่ คำขอ API การลงทะเบียนการจัดส่ง และการอัปเดตการติดตาม ทั้งหมดเป็นเหตุการณ์ที่แตกต่างกัน และสัญญาอาจกำหนดวิธีเรียกเก็บเงินสำหรับแต่ละรายการแตกต่างกัน
| ประเด็นเปรียบเทียบ | การกำหนดราคาแบบต่อการเรียก | การกำหนดราคาแบบต่อการจัดส่ง |
|---|---|---|
| ฐานการเรียกเก็บเงิน | คำขอหรือหน่วยคำขอที่กำหนดให้เรียกเก็บเงินได้ | หน่วยการจัดส่งที่กำหนดให้เรียกเก็บเงินได้ |
| ปัจจัยหลักด้านต้นทุน | ความถี่ที่แอปพลิเคชันส่งคำขอที่เรียกเก็บเงินได้ | จำนวนหน่วยติดตามที่เรียกเก็บเงินได้ซึ่งเข้าสู่หรือยังอยู่ในขอบเขต |
| คำถามด้านการเรียกเก็บเงินที่ต้องหาคำตอบ | Endpoint การตอบกลับ และรายการในชุดคำขอใดบ้างที่นับรวม | อะไรถือเป็นหนึ่งการจัดส่ง และรวมการติดตามไว้นานเท่าใด |
| ความเสี่ยงด้านต้นทุนที่อาจเกิดขึ้น | การเรียกตรวจสอบซ้ำ การลองใหม่ และการค้นหาที่ไม่จำเป็น | การลงทะเบียนซ้ำ พัสดุหลายชิ้น และข้อจำกัดของช่วงเวลาการติดตาม |
| กรณีที่เหมาะสมที่สุดตามเงื่อนไข | การค้นหาความถี่ต่ำที่ควบคุมปริมาณคำขอได้ | การตรวจสอบต่อเนื่องเมื่อมีการรวมการอัปเดตไว้ในค่าธรรมเนียมการจัดส่ง |
การคิดราคาแบบต่อการเรียกไม่ได้หมายความว่าคำขอ HTTP ทุกคำขอมีค่าใช้จ่ายเท่ากัน
ใบเสนอราคาต้องระบุ Endpoint ที่เรียกเก็บเงินได้และหน่วยของแต่ละรายการ การลงทะเบียนหมายเลขติดตาม การดึงผลลัพธ์ที่จัดเก็บไว้ การขอรีเฟรช และการจัดการการสมัครใช้งาน อาจมีวิธีคิดค่าบริการแตกต่างกัน อย่าคิดว่าคำขอที่ล้มเหลวไม่มีค่าใช้จ่าย หรือคำขอที่สำเร็จจะถูกเรียกเก็บเงินเสมอ
การส่งคำขอแบบชุดก็ต้องมีคำจำกัดความที่ชัดเจนเช่นกัน คำขอหนึ่งรายการที่มีหมายเลขติดตาม 100 หมายเลขอาจนับเป็นคำขอหนึ่งรายการ หน่วยติดตาม 100 หน่วย หรือจำนวนอื่นตามสัญญา การลดปริมาณทราฟฟิกเครือข่ายไม่ได้ยืนยันว่าจะประหยัดค่าบริการ เว้นแต่กฎการวัดปริมาณจะรองรับ
การคิดราคาแบบต่อการจัดส่งไม่ได้หมายความว่าต่อคำสั่งซื้อ
คำสั่งซื้ออีคอมเมิร์ซหนึ่งรายการอาจก่อให้เกิดพัสดุหลายชิ้น หากหน่วยที่เรียกเก็บเงินได้คือหมายเลขติดตาม คำสั่งซื้อที่แยกส่งอาจใช้หลายหน่วย การส่งคืน การจัดส่งสินค้าแทน และการส่งต่อระหว่างผู้ขนส่งก็ต้องกำหนดวิธีคิดให้ชัดเจนเช่นกัน
สอบถามว่าค่าธรรมเนียมครอบคลุมการติดตามในช่วงเวลาที่ระบุ จนถึงเหตุการณ์เสร็จสิ้นที่กำหนด หรืออยู่ภายใต้ขีดจำกัดอื่นหรือไม่ นอกจากนี้ควรยืนยันว่าการจัดส่งที่ลงทะเบียนไว้แล้วจะถูกเรียกเก็บเงินใหม่ในรอบการเรียกเก็บเงินถัดไปหรือไม่ รายละเอียดเหล่านี้สำคัญกว่าชื่อของแผนราคา
ประมาณต้นทุนจากเวิร์กโฟลว์ ไม่ใช่เพียงจำนวนคำสั่งซื้อ
ใช้ช่วงเวลาการดำเนินงานที่เป็นตัวแทนและสร้างประมาณการจากข้อมูลระดับการจัดส่ง รวมทั้งการจัดส่งใหม่และการจัดส่งเก่าที่ยังต้องติดตาม หากข้อมูลของคุณไม่ครบ ให้แสดงสมมติฐานอย่างชัดเจน แทนที่จะนำเสนอผลลัพธ์เสมือนเป็นใบเสนอราคาที่แม่นยำ
- นับพัสดุที่ติดตามได้ เริ่มจากหน่วยติดตามพัสดุที่ไม่ซ้ำกัน ไม่ใช่คำสั่งซื้อจากขั้นตอนชำระเงิน แยกพัสดุขาออก การส่งคืน และการจัดส่งสินค้าแทนออกจากกันจนกว่าจะยืนยันวิธีคิดค่าบริการ
- วัดระยะเวลาการตรวจสอบ ประมาณระยะเวลาที่การจัดส่งแต่ละรายการต้องการการอัปเดต รวมถึงช่วงก่อนการขนส่งและช่วงข้อยกเว้นตามความเหมาะสม
- กำหนดความถี่การอัปเดตที่ต้องการ ระบุว่าแอปพลิเคชันของคุณต้องการข้อมูลใหม่บ่อยเพียงใด และความถี่นั้นเปลี่ยนไปตามสถานะการจัดส่งหรือไม่
- ทำแผนผังเวิร์กโฟลว์ API ระบุการลงทะเบียน การค้นหาผลลัพธ์ คำขอรีเฟรช การแก้ไข การลองใหม่ และ Endpoint อื่น ๆ ที่การผสานรวมของคุณจะใช้
- ใช้กฎการเรียกเก็บเงิน แปลงกิจกรรมทางเทคนิคเป็นการเรียกที่เรียกเก็บเงินได้หรือหน่วยการจัดส่ง โดยใช้สัญญาที่เสนอ
- เพิ่มค่าใช้จ่ายที่ไม่เกี่ยวกับการใช้งาน รวมค่าการสมัครใช้งาน ค่าขั้นต่ำ ภาคบริการเสริม และต้นทุนการติดตั้งหรือการดำเนินงานที่เกี่ยวข้อง
สำหรับการผสานรวมแบบเรียกตรวจสอบอย่างง่ายที่ใช้หมายเลขติดตามหนึ่งหมายเลขต่อการค้นหา การประมาณการเบื้องต้นคือ:
คำขอค้นหา = การจัดส่งที่ติดตาม × จำนวนวันติดตามโดยเฉลี่ย × จำนวนการค้นหาต่อวัน
สูตรลัดนี้สมมติว่าการจัดส่งทุกครั้งมีตารางเวลาเฉลี่ยเหมือนกัน โมเดลที่แม่นยำกว่าจะรวมคำขอของการจัดส่งแต่ละรายการหรือกลุ่มการจัดส่ง จากนั้นจึงเพิ่มคำขอลงทะเบียนและกิจกรรมอื่นที่เรียกเก็บเงินได้ หากการจัดส่งยังคงใช้งานอยู่ข้ามสิ้นเดือน ให้จัดสรรคำขอไปยังรอบการเรียกเก็บเงินที่คำขอเหล่านั้นเกิดขึ้น
ตัวอย่างการคำนวณ: เมื่อรูปแบบที่ถูกกว่ามีการเปลี่ยนแปลง
ตัวเลขต่อไปนี้เป็นตัวเลขสมมติขึ้นเพื่อสาธิตการคำนวณเท่านั้น ไม่ใช่ราคาของ 17TRACK ใบเสนอราคาจากซัพพลายเออร์ หรือเกณฑ์มาตรฐานของตลาด
สมมติว่ามีพัสดุ 10,000 ชิ้นลงทะเบียนและติดตามครบถ้วนภายในช่วงเวลาที่จำลองเดียวกัน แต่ละชิ้นต้องใช้คำขอลงทะเบียนหนึ่งครั้งและคำขอค้นหาสามครั้งต่อวันเป็นเวลาแปดวัน สมมติว่าทุกคำขอเรียกเก็บเงินได้ แต่ละคำขอเกี่ยวข้องกับพัสดุหนึ่งชิ้น และไม่มีการลองใหม่ ส่วนลดการส่งแบบชุด โควตา หรือค่าธรรมเนียมคงที่
- คำขอลงทะเบียน: 10,000 รายการ
- คำขอค้นหา: 10,000 × 8 × 3 = 240,000 รายการ
- คำขอทั้งหมดที่เรียกเก็บเงินได้: 250,000 รายการ
- อัตราแบบต่อการเรียกเพื่อสาธิต: $0.002
- อัตราแบบต่อการจัดส่งเพื่อสาธิต: $0.04 รวมการติดตามที่จำเป็น
ต้นทุนการใช้งานแบบต่อการเรียกคือ 250,000 × $0.002 = $500 ต้นทุนการใช้งานแบบต่อการจัดส่งคือ 10,000 × $0.04 = $400 ภายใต้สมมติฐานนี้ การคิดราคาแบบต่อการจัดส่งมีต้นทุนการใช้งานต่ำกว่า $100
ตอนนี้เปลี่ยนเฉพาะความถี่การค้นหาเป็นวันละครั้ง จำนวนคำขอจะกลายเป็นคำขอลงทะเบียน 10,000 รายการบวกคำขอค้นหา 80,000 รายการ หรือทั้งหมด 90,000 ครั้ง ต้นทุนการใช้งานแบบต่อการเรียกลดลงเหลือ $180 ขณะที่ต้นทุนการใช้งานแบบต่อการจัดส่งเพื่อสาธิตยังคงอยู่ที่ $400 รูปแบบที่เหมาะสมจึงเปลี่ยนไปเพราะเวิร์กโหลดเปลี่ยน ไม่ใช่เพราะโครงสร้างราคาแบบใดดีกว่าโดยเนื้อแท้
หาจุดคุ้มทุน
เมื่อแผนทั้งสองไม่มีค่าธรรมเนียมคงที่ โควตา หรือค่าธรรมเนียมเพิ่มเติม ให้ใช้สูตร:
จำนวนการเรียกที่เรียกเก็บเงินได้ต่อการจัดส่ง ณ จุดคุ้มทุน = อัตราต่อการจัดส่ง ÷ อัตราต่อการเรียก
ในตัวอย่าง $0.04 ÷ $0.002 เท่ากับ 20 การเรียกที่เรียกเก็บเงินได้ต่อการจัดส่ง หากมีการเรียกมากกว่า 20 ครั้ง ค่าธรรมเนียมต่อการจัดส่งจะต่ำกว่า หากน้อยกว่า 20 ครั้ง ค่าธรรมเนียมต่อการเรียกจะต่ำกว่า คำขอลงทะเบียนจะนับรวมในเกณฑ์ดังกล่าวภายใต้สมมติฐานของตัวอย่าง
สูตรลัดนี้ไม่เพียงพอสำหรับแผนแบบขั้นบันได เครดิตแบบชำระล่วงหน้า อัตรา Endpoint ที่แตกต่างกัน หรือข้อผูกมัดขั้นต่ำ สำหรับข้อเสนอเหล่านี้ ให้คำนวณใบแจ้งหนี้ทั้งหมดที่แต่ละปริมาณคาดการณ์ แทนการเปรียบเทียบเฉพาะอัตราต่อหน่วยที่แสดงไว้
Webhook ช่วยลดการเรียกตรวจสอบซ้ำได้ แต่ยังต้องตรวจสอบการเรียกเก็บเงิน
การเรียกตรวจสอบซ้ำหมายความว่าแอปพลิเคชันของคุณส่งคำถามเกี่ยวกับข้อมูลการติดตามซ้ำ ๆ Webhook ช่วยให้บริการส่งเหตุการณ์ไปยังแอปพลิเคชันของคุณ จึงลดความจำเป็นในการค้นหาซ้ำเมื่อสตรีมเหตุการณ์ตรงตามข้อกำหนดของคุณ
อย่างไรก็ตาม คำขอค้นหาที่น้อยลงไม่ได้หมายความว่าใบแจ้งหนี้จะลดลงโดยอัตโนมัติ ยืนยันว่าการส่ง Webhook รวมอยู่ในบริการหรือไม่ การส่งหรือการลองส่งใหม่ถูกวัดปริมาณหรือไม่ และยังจำเป็นต้องมีการค้นหาเพื่อกระทบยอดหรือไม่ แอปพลิเคชันของคุณต้องจัดการเหตุการณ์ซ้ำหรือเหตุการณ์ที่มาถึงไม่เรียงลำดับอย่างปลอดภัย และกู้คืนจากความล้มเหลวในการส่งได้
มีความแตกต่างอีกประการที่ควรคำนึงถึง: การขอข้อมูลบ่อยขึ้นไม่ได้รับประกันว่าผู้ขนส่งต้นทางจะสร้างข้อมูลสแกนใหม่แล้ว สอบถามว่าการค้นหาแต่ละครั้งส่งคืนอะไรและการรีเฟรชข้อมูลทำงานอย่างไรก่อนจ่ายเงินสำหรับความถี่การเรียกตรวจสอบที่อาจเพิ่มคุณค่าด้านปฏิบัติการเพียงเล็กน้อย
ต้นทุนที่อัตราหลักอาจซ่อนอยู่
โควตาที่รวมอยู่ ขั้นต่ำ และยอดคงเหลือแบบชำระล่วงหน้า
แยกความแตกต่างระหว่างใบแจ้งหนี้ขั้นต่ำกับการสมัครใช้งานที่รวมโควตาการใช้งาน ใบแจ้งหนี้ขั้นต่ำอาจกำหนดระดับการใช้จ่ายขั้นต่ำ ส่วนโควตาอาจครอบคลุมปริมาณที่กำหนดก่อนเริ่มคิดค่าบริการส่วนเกิน เครดิตแบบชำระล่วงหน้าทำให้เกิดคำถามเพิ่มเติมเกี่ยวกับวันหมดอายุ การคืนเงิน และยอดคงเหลือที่ไม่ได้ใช้
สำหรับแผนที่หักโควตาก่อนคิดค่าบริการส่วนเกิน โครงสร้างที่มีประโยชน์คือ:
ใบแจ้งหนี้ API = ค่าธรรมเนียมแผนคงที่ + ค่าบริการส่วนเกินที่เรียกเก็บได้ + บริการเสริมที่เกี่ยวข้อง
ใช้สูตรนี้เฉพาะเมื่อสอดคล้องกับสัญญา อย่าบวกการใช้งานที่รวมอยู่ซ้ำสองครั้ง หรือสมมติว่าทุกแผนใช้การคิดราคาแบบส่วนเพิ่มในลักษณะเดียวกัน
การจัดส่งที่ใช้เวลานานและการลงทะเบียนซ้ำ
ช่วงเวลาการติดตามที่ยาวนานจะเพิ่มปริมาณการค้นหาในรูปแบบที่ใช้การเรียกตรวจสอบซ้ำ ภายใต้การกำหนดราคาแบบต่อการจัดส่ง คำถามสำคัญคือค่าธรรมเนียมเดิมครอบคลุมระยะเวลาดังกล่าวหรือไม่ ทดสอบกรณีข้อยกเว้นและการจัดส่งล่าช้า ไม่ใช่เฉพาะการจัดส่งที่เสร็จสิ้นอย่างรวดเร็ว
ยืนยันด้วยว่าเกิดอะไรขึ้นเมื่อส่งหมายเลขติดตามเดียวกันสองครั้ง แก้ไข ลบแล้วเพิ่มใหม่ หรือเชื่อมโยงกับผู้ขนส่งรายอื่น ใช้การป้องกันรายการซ้ำตามความเหมาะสม แต่อย่าสมมติว่าการขจัดรายการซ้ำในระดับแอปพลิเคชันจะตรงกับตัวตนที่ซัพพลายเออร์ใช้เรียกเก็บเงินอย่างสมบูรณ์
ขีดจำกัดอัตราและความจุช่วงสูงสุด
โควตรายเดือนที่มีราคาจับต้องได้ไม่ได้ยืนยันว่าการผสานรวมจะรองรับการนำเข้าจำนวนมากหรือทราฟฟิกที่พุ่งสูงได้ ตรวจสอบขีดจำกัดอัตราคำขอ ขีดจำกัดชุดคำขอ ข้อจำกัดการทำงานพร้อมกัน และพฤติกรรมที่คาดว่าจะเกิดขึ้นเมื่อถึงขีดจำกัด แผนที่รองรับปริมาณรายเดือนได้แต่ไม่รองรับเวิร์กโฟลว์ที่จำเป็น ไม่ใช่ทางเลือกที่เทียบเคียงกันได้อย่างแท้จริง
ต้นทุนด้านวิศวกรรมและการดำเนินงาน
แยกใบแจ้งหนี้ API ออกจากต้นทุนการเป็นเจ้าของทั้งหมด ค่าใช้จ่ายภายในอาจรวมถึงการพัฒนาการผสานรวม การโฮสต์ Webhook คิว การตรวจสอบ การตอบสนองต่อเหตุการณ์ การจัดเก็บข้อมูล และการบำรุงรักษา
ใช้ประมาณการแรงงานและโครงสร้างพื้นฐานของคุณเอง การสมัครใช้งานที่มีราคาแพงกว่าอาจยังคุ้มค่าหากลดงานด้านปฏิบัติการได้อย่างชัดเจน แต่ควรทดสอบการประหยัดนั้นแทนการสมมติ
วิธีเปรียบเทียบใบเสนอราคาและตรวจสอบตัวเลือกที่คัดกรองแล้ว
ขอให้ซัพพลายเออร์แต่ละรายกำหนดราคาจากข้อกำหนดเวิร์กโหลดเดียวกัน ได้แก่ ปริมาณพัสดุ ประเภทการจัดส่ง ระยะเวลาการติดตาม ข้อกำหนดการอัปเดต Endpoint ปริมาณสูงสุด และบริการที่ต้องการ ขอคำอธิบายเป็นลายลักษณ์อักษรเกี่ยวกับหน่วยการเรียกเก็บเงินและตัวอย่างการคำนวณใบแจ้งหนี้
สำหรับทีมที่พิจารณา 17TRACK หน้า Tracking API อย่างเป็นทางการ และ เอกสาร API คือจุดเริ่มต้นที่เกี่ยวข้องสำหรับการประเมินผลิตภัณฑ์และการผสานรวม ยืนยันราคาและคำจำกัดความด้านการเรียกเก็บเงินที่ใช้ได้โดยตรงก่อนกำหนดรูปแบบในประมาณการของคุณ บทความนี้ไม่ได้เสนอราคาหรือจัดประเภทแผน 17TRACK ในปัจจุบัน
ก่อนตัดสินใจ ให้ดำเนินการนำร่องแบบควบคุมโดยใช้การจัดส่งที่เป็นตัวแทน รวมคำสั่งซื้อที่แยกส่ง การส่งข้อมูลซ้ำ พัสดุล่าช้า การขนส่งข้ามพรมแดน และการจัดส่งที่ข้ามรอบการเรียกเก็บเงิน ทดสอบพฤติกรรมเมื่อเกิดความล้มเหลวหรือการลองใหม่เฉพาะในลักษณะที่บริการอนุญาต
- เปรียบเทียบบันทึกคำขอของคุณกับข้อมูลการใช้งานของซัพพลายเออร์
- กระทบยอดหน่วยติดตามที่ลงทะเบียนกับหน่วยการจัดส่งที่ถูกเรียกเก็บเงิน
- ตรวจสอบว่าความถี่การอัปเดตที่ต้องการเกิดขึ้นจริงหรือไม่
- วัดความต้องการสูงสุดแยกจากการใช้งานรายเดือน
- ตรวจสอบความแตกต่างที่ไม่สามารถอธิบายได้ก่อนคาดการณ์ต้นทุนต่อไป
สร้างประมาณการอย่างน้อยสามแบบ ได้แก่ การดำเนินงานปกติ ช่วงสูงสุดตามฤดูกาล และการขนส่งที่ยืดเยื้อ เปลี่ยนปัจจัยพื้นฐานแทนการบวกเปอร์เซ็นต์โดยพลการลงในใบแจ้งหนี้ ตัวอย่างเช่น จำลองพัสดุที่เพิ่มขึ้นสำหรับช่วงสูงสุด และระยะเวลาการติดตามที่นานขึ้นสำหรับสถานการณ์ล่าช้า
คุณควรเลือกรูปแบบใด
เลือกการกำหนดราคาแบบต่อการเรียก เมื่อการค้นหาเกิดขึ้นไม่บ่อย ความต้องการคำขอสามารถวัดได้ และประมาณการยังต่ำกว่าจุดคุ้มทุนหลังรวมการลงทะเบียนและกิจกรรมอื่นที่เรียกเก็บเงินได้แล้ว รูปแบบนี้น่าสนใจน้อยลงเมื่อการเรียกตรวจสอบบ่อยครั้งหรือระยะเวลาการติดตามที่คาดเดาไม่ได้ทำให้เกิดความเสี่ยงด้านคำขอจำนวนมาก
เลือกการกำหนดราคาแบบต่อการจัดส่ง เมื่อจำเป็นต้องติดตามอย่างต่อเนื่อง และค่าธรรมเนียมต่อการจัดส่งที่เสนอรวมความถี่การอัปเดต ระยะเวลาการติดตาม และกลไกการส่งมอบที่คุณต้องการ รูปแบบนี้น่าสนใจน้อยลงเมื่อคุณจ่ายค่าการติดตามที่แทบไม่ได้ใช้ หรือเมื่อคำจำกัดความของการจัดส่งก่อให้เกิดหน่วยเพิ่มเติมที่ไม่คาดคิด
การตัดสินใจขั้นสุดท้ายควรใช้ ต้นทุนรวมต่อพัสดุที่ดำเนินการ ซึ่งคำนวณจากใบแจ้งหนี้ API บวกต้นทุนการดำเนินงานที่เกี่ยวข้อง หารด้วยจำนวนพัสดุที่ไม่ซ้ำกันซึ่งธุรกิจของคุณต้องติดตาม รักษาคำจำกัดความของพัสดุภายในให้สอดคล้องกันในทุกใบเสนอราคา แม้ซัพพลายเออร์จะใช้หน่วยการเรียกเก็บเงินที่แตกต่างกัน
คำถามที่พบบ่อย
คำขอ API ที่ไม่สำเร็จจะถูกเรียกเก็บเงินหรือไม่
อย่าสมมติว่าเป็นกรณีใดกรณีหนึ่ง ให้สอบถามวิธีจัดการกับข้อผิดพลาดในการตรวจสอบ ความล้มเหลวในการยืนยันตัวตน การตอบกลับเมื่อเกินขีดจำกัดอัตรา ข้อผิดพลาดของเซิร์ฟเวอร์ และไทม์เอาต์ ไทม์เอาต์ยังอาจทำให้ไม่แน่ใจว่าคำขอถูกประมวลผลแล้วก่อนที่แอปพลิเคชันจะลองใหม่หรือไม่
หนึ่งคำสั่งซื้อจะนับเป็นหนึ่งการจัดส่งเสมอหรือไม่
ไม่ คำสั่งซื้อหนึ่งรายการอาจมีพัสดุหลายชิ้นที่ติดตามแยกกัน สำหรับการจัดทำงบประมาณ ให้จับคู่คำสั่งซื้อกับหน่วยติดตาม แล้วใช้คำจำกัดความของซัพพลายเออร์ ยืนยันวิธีนับการส่งคืน การจัดส่งสินค้าแทน และการส่งต่อระหว่างผู้ขนส่ง
คำขอแบบชุดจะลดใบแจ้งหนี้ของฉันหรือไม่
เฉพาะเมื่อกฎการเรียกเก็บเงินให้ประโยชน์กับการส่งแบบชุดเท่านั้น การส่งแบบชุดอาจลดคำขอเครือข่ายโดยไม่ลดหน่วยติดตามที่เรียกเก็บเงินได้ ตรวจสอบขีดจำกัดของชุดคำขอ และดูว่าการเรียกเก็บเงินคิดต่อคำขอ ต่อรายการ หรือผ่านหน่วยถ่วงน้ำหนัก
Webhook จะกำจัดคำขอค้นหาทั้งหมดได้หรือไม่
Webhook อาจยกเลิกการเรียกตรวจสอบตามปกติได้มาก แต่การออกแบบของคุณอาจยังต้องมีการดึงข้อมูลครั้งแรก การกู้คืนหลังพลาดเหตุการณ์ หรือการกระทบยอดเป็นระยะ รวมคำขอเหล่านั้นไว้ในประมาณการ และยืนยันค่าธรรมเนียมสำหรับการส่ง Webhook หากมี
ฉันควรจัดทำงบประมาณสำหรับการจัดส่งที่ยังใช้งานอยู่ในเดือนหน้าอย่างไร
สำหรับการกำหนดราคาแบบต่อการเรียก ให้คาดการณ์คำขอที่การจัดส่งเหล่านั้นจะสร้างขึ้นในรอบถัดไป สำหรับการกำหนดราคาแบบต่อการจัดส่ง ให้ยืนยันว่าการติดตามยังครอบคลุมอยู่หรือก่อให้เกิดค่าธรรมเนียมเพิ่มเติม อย่านับเฉพาะการจัดส่งที่สร้างใหม่เมื่อประมาณการเวิร์กโหลดต่อเนื่อง
แหล่งข้อมูล
การคำนวณข้างต้นใช้ข้อมูลนำเข้าที่เป็นสมมติฐานอย่างชัดเจน ไม่ใช่ราคาของซัพพลายเออร์ที่เผยแพร่ สำหรับการประเมิน 17TRACK ให้ใช้หน้าอ้างอิงอย่างเป็นทางการเหล่านี้และยืนยันเงื่อนไขทางการค้าโดยตรง:
