เมตริกสำหรับประเมิน API ติดตามการจัดส่ง: 8 KPI ที่ควรวัดในการทำ Proof of Concept

ประเมินการทดสอบแนวคิดของ Shipment Tracking API โดยใช้ KPI 8 รายการ ได้แก่ ความครอบคลุมของการติดตามที่ใช้งานได้ ความครบถ้วนของเหตุการณ์ ความถูกต้องของสถานะ ความล่าช้าในการอัปเดต ความน่าเชื่อถือในการส่ง webhook ความน่าเชื่อถือของคำขอ API ความพยายามในการผสานรวม และต้นทุนต่อการจัดส่งที่ติดตามได้และใช้งานได้ วัดผลเทียบกับสัดส่วนการจัดส่งจริงของคุณและข้อมูลอ้างอิงที่ตกลงร่วมกัน ไม่ใช่เพียงคำขอเดโมที่สำเร็จเท่านั้น กำหนดเกณฑ์การยอมรับก่อนการทดสอบ เพื่อให้ผลลัพธ์สนับสนุนการตัดสินใจที่ชัดเจนว่าจะเปิดใช้งาน แก้ไข หรือปฏิเสธ

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

สร้างการทดสอบที่สะท้อนสภาพการใช้งานจริง

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

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

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

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

1. ความครอบคลุมของการติดตามที่ใช้งานได้

คำถาม: API สามารถส่งข้อมูลการติดตามที่มีประโยชน์สำหรับการจัดส่งที่ธุรกิจของคุณส่งจริงได้หรือไม่

สูตร: ความครอบคลุมของการติดตามที่ใช้งานได้ = จำนวนการจัดส่งทดสอบที่เข้าเกณฑ์และมีผลการติดตามที่ใช้งานได้ ÷ จำนวนการจัดส่งทดสอบที่เข้าเกณฑ์ทั้งหมด × 100

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

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

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

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

2. ความครบถ้วนของเหตุการณ์ที่จำเป็น

คำถาม: API จับเหตุการณ์สำคัญของการจัดส่งที่ฝ่ายปฏิบัติการของคุณต้องการได้หรือไม่

สูตร: ความครบถ้วนของเหตุการณ์ที่จำเป็น = เหตุการณ์อ้างอิงที่จำเป็นซึ่งจับคู่ได้ ÷ เหตุการณ์อ้างอิงที่จำเป็นทั้งหมดที่สังเกตระหว่างการทดสอบ × 100

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

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

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

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

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

3. ความถูกต้องของสถานะที่ทำให้เป็นมาตรฐาน

คำถาม: API แปลเหตุการณ์ของผู้ให้บริการขนส่งเป็นความหมายเชิงปฏิบัติการที่ถูกต้องหรือไม่

สูตร: ความถูกต้องของสถานะ = การสังเกตสถานะที่ประเมินแล้วและจัดประเภทถูกต้อง ÷ การสังเกตสถานะที่ประเมินทั้งหมด × 100

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

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

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

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

กฎการตัดสินใจ: กำหนดเงื่อนไขการยอมรับที่เข้มงวดขึ้นสำหรับข้อผิดพลาดที่ทำให้เกิดการดำเนินการซึ่งย้อนกลับไม่ได้หรือส่งผลต่อลูกค้า ความถูกต้องโดยรวมเพียงอย่างเดียวไม่เพียงพอเมื่อข้อผิดพลาดประเภทหนึ่งมีความเสี่ยงสูงกว่าประเภทอื่นอย่างมาก

4. ความล่าช้าในการอัปเดต

คำถาม: เหตุการณ์ใหม่ของผู้ให้บริการขนส่งใช้เวลานานเท่าใดกว่าจะใช้งานได้ในระบบของคุณ

การวัดหลัก: ความล่าช้าในการอัปเดตที่สังเกตได้ = เวลาที่ระบบของคุณบันทึกการอัปเดตที่ใช้งานได้อย่างถาวร − เวลาที่สังเกตเห็นเหตุการณ์ครั้งแรกในแหล่งข้อมูลอ้างอิงที่ตกลงกัน

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

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

รายงานค่ามัธยฐานและเปอร์เซ็นไทล์ส่วนหาง เช่น p95 แยกตามกลุ่มสำคัญเมื่อขนาดตัวอย่างรองรับ รวมขนาดตัวอย่างด้วย ค่ามัธยฐานที่รวดเร็วอาจซ่อนความล่าช้าที่ยาวนานซึ่งส่งผลต่อการจัดส่งกลุ่มเล็กกว่าแต่มีความสำคัญเชิงปฏิบัติการ

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

5. ความน่าเชื่อถือในการส่ง Webhook

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

สูตร: ความน่าเชื่อถือในการส่ง Webhook = การแจ้งเตือนที่คาดหวังแบบไม่ซ้ำกันและยอมรับอย่างถาวรภายในช่วงเวลาที่ตกลงกัน ÷ การแจ้งเตือนที่คาดหวังทั้งหมด × 100

จัดทำชุดการแจ้งเตือนที่คาดหวังจากกฎการสมัครใช้งานที่มีเอกสารรองรับ การเปลี่ยนแปลงของแหล่งข้อมูลที่สังเกตได้ และการทดสอบที่ควบคุม อย่าสันนิษฐานว่าการสแกนดิบทุกครั้งจากผู้ให้บริการขนส่งต้องสร้างการแจ้งเตือนแยกกัน หากไม่สามารถกำหนดชุดที่คาดหวังได้อย่างอิสระ ให้รายงานผลเป็นบางส่วน แทนการอ้างว่ามีความน่าเชื่อถือในการส่งครบถ้วน

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

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

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

กฎการตัดสินใจ: ต้องมีเส้นทางการกู้คืนสำหรับการอัปเดตที่พลาดซึ่งแสดงให้เห็นจริง ไม่ใช่เพียงการส่งสำเร็จภายใต้เงื่อนไขปกติ

6. ความน่าเชื่อถือของคำขอ API

คำถาม: API ตอบกลับสำเร็จภายใต้ปริมาณงานที่คุณคาดหวังหรือไม่

สูตร: ความน่าเชื่อถือของคำขอ API = คำขอที่ถูกต้องซึ่งส่งคืนการตอบกลับที่คาดหวังและแยกวิเคราะห์ได้ภายในเวลาหมดที่กำหนด ÷ คำขอที่ถูกต้องทั้งหมดที่พยายามส่ง × 100

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

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

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

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

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

7. ความพยายามในการผสานรวมและกู้คืน

คำถาม: ต้องใช้ความพยายามด้านวิศวกรรมมากเพียงใดเพื่อทำให้การผสานรวมปลอดภัยต่อการดำเนินงาน

การวัดหลัก: ความพยายามในการผสานรวม = ชั่วโมงการทำงานด้านวิศวกรรมที่บันทึกไว้เพื่อทำรายการตรวจสอบความพร้อมใช้งานจริงที่ตกลงกันให้เสร็จสมบูรณ์

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

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

ดำเนินการฝึกกู้คืน: หยุด Consumer ของคุณ กู้คืนระบบ และตรวจสอบว่าสถานะการจัดส่งที่ได้รับผลกระทบสามารถกระทบยอดได้หรือไม่ บันทึกเวลาที่ใช้กู้คืน การแทรกแซงด้วยตนเอง และระเบียนที่ยังหาข้อสรุปไม่ได้ ระบุว่าปัญหาใดเกิดจากแอปพลิเคชันของคุณและปัญหาใดต้องขอความช่วยเหลือจากผู้ให้บริการ

กฎการตัดสินใจ: เปรียบเทียบความพยายามเฉพาะเมื่อมีระดับความพร้อมเทียบเท่ากัน Prototype ที่ไม่มีการตรวจสอบไม่ควรดูเหมือนผสานรวมได้ง่ายกว่าการใช้งานที่พร้อมสำหรับการผลิตและผ่านการทดสอบการกู้คืนแล้ว

8. ต้นทุนต่อการจัดส่งที่ติดตามได้และใช้งานได้

คำถาม: การได้รับข้อมูลการจัดส่งที่ตรงตามข้อกำหนดของคุณจะมีต้นทุนเท่าใด

สูตร: ต้นทุนต่อการจัดส่งที่ติดตามได้และใช้งานได้ = ต้นทุนการดำเนินงานทั้งหมดที่จัดสรรได้สำหรับช่วงเวลา ÷ จำนวนการจัดส่งที่แตกต่างกันซึ่งตรงตามเกณฑ์การใช้งานที่ตกลงกันในช่วงเวลาดังกล่าว

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

รวมโครงสร้างพื้นฐานและงานปฏิบัติการที่เกิดขึ้นซ้ำเมื่อคำนวณต้นทุนภายในทั้งหมด แสดงต้นทุนการนำไปใช้งานครั้งเดียวแยกต่างหาก หรือเปิดเผยช่วงเวลาที่ใช้ในการเฉลี่ยต้นทุนดังกล่าว

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

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

เปลี่ยนผลลัพธ์ให้เป็นการตัดสินใจเปิดใช้งาน

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

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

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

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

คำถามที่พบบ่อย

การทดสอบแนวคิดของ Tracking API ควรรวมการจัดส่งกี่รายการ

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

Sandbox สามารถทดแทนการทดสอบการจัดส่งแบบสดได้หรือไม่

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

จะทำอย่างไรหากเว็บไซต์ของผู้ให้บริการขนส่งและ API ให้ข้อมูลไม่ตรงกัน

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

เหตุการณ์ที่ขาดหายควรนับเป็นการอัปเดตที่ล่าช้าหรือไม่

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

ควรทำอย่างไรหลังการทดสอบแนวคิดผ่าน

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

แหล่งข้อมูล

• Google Site Reliability Engineering: Monitoring Distributed Systems — หลักการตรวจสอบที่เป็นพื้นฐานของการอภิปรายเรื่องความน่าเชื่อถือของคำขอ รวมถึงความล่าช้า ปริมาณการรับส่งข้อมูล ข้อผิดพลาด และการอิ่มตัว
• 17TRACK Tracking API — ข้อมูลอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับทีมที่กำลังพิจารณาการประเมิน 17TRACK API
• 17TRACK API Documentation — เอกสารอ้างอิงอย่างเป็นทางการสำหรับตรวจสอบข้อกำหนดการผสานรวมก่อนออกแบบการทดสอบเฉพาะการใช้งาน