วิธีผสานรวม API ติดตามการจัดส่งเข้ากับร้านค้าอีคอมเมิร์ซของคุณ
ในการผสานรวม API ติดตามพัสดุเข้ากับร้านค้าอีคอมเมิร์ซของคุณ ให้เชื่อมต่อระบบคำสั่งซื้อกับผู้ให้บริการติดตาม ส่งข้อมูลพัสดุและผู้ให้บริการขนส่งผ่านคำขอฝั่งเซิร์ฟเวอร์ที่ปลอดภัย บันทึกเหตุการณ์การติดตามที่ทำให้เป็นมาตรฐาน และแสดงสถานะที่ได้ในอินเทอร์เฟซสำหรับลูกค้าและฝ่ายสนับสนุน การใช้งานที่เชื่อถือได้ไม่ได้มีเพียงการเพิ่มช่องหมายเลขติดตามเท่านั้น แต่ต้องรองรับการเลือกผู้ให้บริการขนส่ง การอัปเดตสถานะ ข้อยกเว้นในการจัดส่ง การลองใหม่ ความเป็นส่วนตัว และวิธีที่ลูกค้าใช้งานข้อมูลหลังการซื้อจริง
คู่มือนี้อธิบายแนวทางการผสานรวมที่ใช้งานได้จริงสำหรับเจ้าของร้านค้า นักพัฒนา และทีมปฏิบัติการ โดยใช้เอกสารอย่างเป็นทางการของ Tracking API ของ 17TRACK เป็นจุดอ้างอิง แต่หลักการวางแผนเดียวกันนี้สามารถใช้ได้เมื่อประเมินผู้ให้บริการแบบหลายผู้ให้บริการขนส่งรายอื่น
กำหนดสิ่งที่การผสานรวมต้องบรรลุ
เริ่มจากผลลัพธ์ทางธุรกิจแทนที่จะเริ่มจาก API endpoint ร้านค้าส่วนใหญ่ต้องการลดการติดต่อในลักษณะ “คำสั่งซื้อของฉันอยู่ที่ไหน” ให้ผู้ซื้อเห็นข้อมูลการจัดส่งที่ชัดเจน และช่วยให้ฝ่ายปฏิบัติการตรวจพบพัสดุที่ล่าช้าก่อนที่ลูกค้าจะร้องเรียน เป้าหมายเหล่านี้ต้องใช้ข้อมูลและเวิร์กโฟลว์ที่แตกต่างกัน
- การมองเห็นสำหรับลูกค้า: แสดงสถานะพัสดุปัจจุบัน ข้อมูลการจัดส่งโดยประมาณเมื่อมีข้อมูล ผู้ให้บริการขนส่ง และเหตุการณ์ล่าสุดที่มีความหมาย
- การมองเห็นสำหรับฝ่ายปฏิบัติการ: ให้พนักงานค้นหาพัสดุที่ล่าช้า หยุดนิ่ง ถูกส่งคืน หรือมีข้อยกเว้นได้จากผู้ให้บริการขนส่งหลายราย
- การสื่อสารอัตโนมัติ: เรียกใช้อีเมล SMS หรือการแจ้งเตือนรูปแบบอื่นที่ได้รับอนุมัติ เมื่อพัสดุเข้าสู่สถานะที่กำหนด
- ความสอดคล้องของข้อมูล: แปลงป้ายกำกับเหตุการณ์ที่แตกต่างกันของผู้ให้บริการขนส่งให้เป็นสถานะจำนวนน้อยที่ร้านค้าของคุณสามารถใช้งานได้อย่างสม่ำเสมอ
กำหนดผลลัพธ์เหล่านี้ก่อนเลือกวิธีการใช้งาน API ติดตามสามารถให้ข้อมูลพัสดุได้ แต่ไม่ได้ตัดสินใจโดยอัตโนมัติว่าเหตุการณ์ใดควรแจ้งลูกค้า หรือร้านค้าของคุณควรจัดการกับปัญหาที่อยู่อย่างไร
เลือกสถาปัตยกรรมการผสานรวมที่เหมาะสม
สถาปัตยกรรมทั่วไปมีสี่ชั้น ได้แก่ แพลตฟอร์มอีคอมเมิร์ซ บริการผสานรวม ผู้ให้บริการติดตาม และประสบการณ์สำหรับลูกค้า บริการผสานรวมอาจเป็นแอปพลิเคชันแบ็กเอนด์ ระบบจัดการคำสั่งซื้อ หรือเวิร์กโฟลว์แบบ serverless โดยทั่วไปการเก็บตรรกะนี้ไว้บนเซิร์ฟเวอร์จะปลอดภัยกว่าการใส่ข้อมูลรับรอง API ไว้ในโค้ดเบราว์เซอร์
โฟลว์พื้นฐานมีลักษณะดังนี้:
- คำสั่งซื้อที่ชำระเงินแล้วได้รับการจัดส่งและได้รับหมายเลขติดตามกับผู้ให้บริการขนส่ง
- แบ็กเอนด์ของคุณส่งรายละเอียดพัสดุไปยังผู้ให้บริการติดตาม
- ผู้ให้บริการส่งตัวระบุการติดตามหรือข้อมูลการติดตามกลับมาตามรูปแบบ API ของตน
- ระบบของคุณจัดเก็บข้อมูลอ้างอิงของผู้ให้บริการและจับคู่เหตุการณ์พัสดุกับสถานะภายใน
- กระบวนการอัปเดตตามกำหนดเวลาหรือการแจ้งเตือนเหตุการณ์ที่รองรับจะรีเฟรชข้อมูลพัสดุ
- หน้าร้านค้า หน้าคำสั่งซื้อ เครื่องมือสนับสนุน และบริการแจ้งเตือนของคุณอ่านข้อมูลจากข้อมูลมาตรฐานของคุณเอง
อย่าให้ทุกการเปิดหน้าเรียกผู้ให้บริการขนส่งหรือ tracking API การออกแบบเช่นนั้นอาจทำให้ประสบการณ์ลูกค้าช้า เกิดคำขอซ้ำ ปัญหาเกินขีดจำกัดอัตราการเรียก และผลลัพธ์ไม่สอดคล้องกัน ให้จัดเก็บสถานะการติดตามล่าสุดที่ยอมรับไว้ในฐานข้อมูล และรีเฟรชผ่านงานเบื้องหลังที่ควบคุมได้หรือกลไกการอัปเดตที่ผู้ให้บริการรองรับ
ตรวจสอบเอกสารของผู้ให้บริการก่อนเขียนโค้ด
ก่อนเริ่มใช้งาน ให้ตรวจสอบเอกสาร API อย่างเป็นทางการของผู้ให้บริการเกี่ยวกับการยืนยันตัวตน รูปแบบคำขอ ฟิลด์การตอบกลับ ผู้ให้บริการขนส่งที่รองรับ พฤติกรรมเมื่อเกิดข้อผิดพลาด กลไกการอัปเดต และข้อกำหนดของบัญชี 17TRACK มีหน้าผลิตภัณฑ์ Tracking API โดยเฉพาะ และมีเอกสารสำหรับนักพัฒนา ให้ถือว่าหน้าเหล่านี้เป็นแหล่งอ้างอิงหลักสำหรับพฤติกรรม API ปัจจุบัน แทนการพึ่งพาตัวอย่างที่คัดลอกจากฟอรัมหรือบทช่วยสอนการผสานรวมเก่า
จัดทำรายการตรวจสอบข้อกำหนดสั้น ๆ จากเอกสาร:
- ข้อมูลรับรอง API ออกให้ จัดเก็บ หมุนเวียน และเพิกถอนอย่างไร
- คำขอต้องใช้รหัสผู้ให้บริการขนส่งหรือไม่ หรือบริการสามารถระบุผู้ให้บริการขนส่งจากหมายเลขติดตามได้
- ฟิลด์การตอบกลับใดระบุพัสดุ สถานะ ตำแหน่ง เวลา และข้อความข้อยกเว้น
- หากบัญชีรองรับ การอัปเดตแบบอะซิงโครนัสจะถูกส่งมาอย่างไร
- ขีดจำกัดคำขอ กฎการเรียกเก็บเงิน ระยะเวลารอคอย และรหัสข้อผิดพลาดที่ระบุไว้มีอะไรบ้าง
- ควรจัดการกับหมายเลขติดตามซ้ำ หมายเลขไม่ถูกต้อง ผู้ให้บริการขนส่งที่ไม่รู้จัก และพัสดุที่จัดส่งแล้วอย่างไร
อย่าคาดเดาคุณสมบัติจากชื่อผลิตภัณฑ์ ตัวอย่างเช่น “เรียลไทม์” อาจเป็นเพียงคำอธิบายการวางตำแหน่งผลิตภัณฑ์ ไม่ใช่การรับประกันว่าเหตุการณ์ของผู้ให้บริการขนส่งทุกเหตุการณ์จะแสดงทันที การใช้งานของคุณควรอธิบายว่าการสแกนของผู้ให้บริการขนส่งอาจล่าช้า และ API ไม่สามารถสร้างข้อมูลการสแกนที่ผู้ให้บริการขนส่งยังไม่ได้รายงานได้
เตรียมข้อมูลคำสั่งซื้อและพัสดุ
โดยปกติช่วงเวลาที่เหมาะสมที่สุดในการสร้างข้อมูลติดตามคือเมื่อจัดส่งพัสดุ ไม่ใช่เมื่อสร้างคำสั่งซื้อ คำสั่งซื้ออาจชำระเงินแล้วแต่ยังไม่ได้บรรจุ และหมายเลขติดตามอาจถูกสร้างขึ้นก่อนที่พัสดุจะถูกรับโดยผู้ให้บริการขนส่ง ให้ตัดสินใจว่าเหตุการณ์ใดในเวิร์กโฟลว์การจัดส่งของคุณควรสร้างระเบียนการติดตาม
อย่างน้อย ระเบียนพัสดุภายในของคุณควรแยกแยะค่าต่อไปนี้:
- รหัสคำสั่งซื้อภายในและรหัสการจัดส่ง
- หมายเลขติดตาม
- ชื่อหรือรหัสผู้ให้บริการขนส่ง
- ประเทศหรือภูมิภาคปลายทาง เมื่อจำเป็นต่อการดำเนินงาน
- รหัสติดตามของผู้ให้บริการหรือข้อมูลอ้างอิงการสมัคร หากมีการส่งกลับมา
- สถานะปัจจุบันที่ทำให้เป็นมาตรฐาน
- เวลาของเหตุการณ์ล่าสุดและเวลาซิงโครไนซ์ล่าสุด
- การตอบกลับดิบของผู้ให้บริการหรือข้อมูลอ้างอิงการตรวจสอบที่ควบคุมได้
แยกข้อมูลคำสั่งซื้อออกจากข้อมูลพัสดุ คำสั่งซื้อหนึ่งรายการอาจมีหลายหีบห่อ การจัดส่งแยกส่วน หรือผู้ให้บริการขนส่งหลายราย สมมติฐานว่าหนึ่งคำสั่งซื้อมีหมายเลขติดตามหนึ่งหมายเลขมักใช้ไม่ได้เมื่อคลังสินค้าจัดส่งสินค้าแยกกัน
ใช้กระบวนการแบบ idempotent หากระบบจัดส่งลองส่งคำขอเดิมซ้ำ การผสานรวมควรอัปเดตพัสดุเดิมแทนการสร้างการสมัครซ้ำหรือข้อความถึงลูกค้าซ้ำ คีย์ idempotency ที่ใช้งานได้จริงอาจรวมรหัสการจัดส่งภายใน ตัวระบุผู้ให้บริการขนส่ง และหมายเลขติดตาม ทั้งนี้ขึ้นอยู่กับข้อกำหนดของผู้ให้บริการเอง
ทำให้สถานะของผู้ให้บริการขนส่งเป็นมาตรฐานสำหรับลูกค้า
ผู้ให้บริการขนส่งใช้ป้ายกำกับและลำดับเหตุการณ์แตกต่างกัน ร้านค้าของคุณควรมีโมเดลสถานะภายในขนาดเล็ก เช่น ได้รับข้อมูลแล้ว อยู่ระหว่างการขนส่ง กำลังนำจ่าย จัดส่งแล้ว มีข้อยกเว้น และ ส่งคืนแล้ว เก็บเหตุการณ์ดั้งเดิมของผู้ให้บริการไว้สำหรับเจ้าหน้าที่สนับสนุน แต่ใช้สถานะมาตรฐานกับตรรกะของหน้าร้าน
ควรกำหนดกฎการทำให้เป็นมาตรฐานอย่างชัดเจน เหตุการณ์ “สร้างใบจ่าหน้าแล้ว” ไม่ควรถูกนำเสนอเป็นหลักฐานว่าพัสดุกำลังเคลื่อนที่ “จัดส่งแล้ว” ควรถือเป็นเหตุการณ์ที่ผู้ให้บริการขนส่งรายงาน ไม่ใช่การรับประกันว่าลูกค้าได้พบพัสดุทางกายภาพแล้ว ไม่ควรเปลี่ยนข้อยกเว้นเป็น “อยู่ระหว่างการขนส่ง” อย่างเงียบ ๆ เพียงเพราะพัสดุอาจเดินทางต่อในภายหลัง
กำหนดลำดับความสำคัญของสถานะและการจัดการสถานะถอยกลับด้วย ฟีดข้อมูลของผู้ให้บริการขนส่งที่ล่าช้าอาจมาถึงไม่เรียงลำดับ ให้เปรียบเทียบเวลาของเหตุการณ์เมื่อมีข้อมูล บันทึกเหตุการณ์ดิบ และหลีกเลี่ยงการแทนที่สถานะจัดส่งแล้วที่ใหม่กว่าด้วยสถานะอยู่ระหว่างการขนส่งที่เก่ากว่า หากไม่มีเวลาเหตุการณ์หรือเวลาไม่ชัดเจน ให้ทำเครื่องหมายระเบียนเพื่ออัปเดตอย่างระมัดระวัง แทนการสร้างลำดับเหตุการณ์ขึ้นเอง
สร้างโฟลว์คำขอฝั่งเซิร์ฟเวอร์
แบ็กเอนด์ของคุณควรตรวจสอบข้อมูลการจัดส่งที่เข้ามาก่อนเรียกผู้ให้บริการติดตาม ตรวจสอบว่ามีหมายเลขติดตาม ตัดช่องว่างที่เกิดขึ้นโดยไม่ตั้งใจ ตรวจสอบรูปแบบที่คาดไว้เมื่อเหมาะสม และยืนยันว่าค่าผู้ให้บริการขนส่งยอมรับได้ อย่าปฏิเสธหมายเลขติดตามที่ผิดปกติแต่ถูกต้องเพียงเพราะไม่ตรงกับรูปแบบภายในที่แคบเกินไป
โฟลว์คำขอที่ไม่ผูกกับผู้ให้บริการรายใดรายหนึ่งสามารถแสดงได้ดังนี้:
receive fulfillment event
validate order and shipment fields
check for an existing idempotency key
send the documented tracking request from the server
store the provider response and internal shipment record
queue a refresh or process the supported update event
publish only approved fields to the storefrontใช้ระยะเวลารอคอยสั้น การลองใหม่ที่มีขอบเขต และ exponential backoff สำหรับความล้มเหลวชั่วคราว อย่าลองใหม่กับข้อผิดพลาดทุกประเภท ความล้มเหลวในการยืนยันตัวตน คำขอไม่ถูกต้อง หรือผู้ให้บริการขนส่งที่ไม่รองรับ มักต้องแก้ไขแทนการเรียกซ้ำ บันทึกรหัสสหสัมพันธ์ ผลลัพธ์ของคำขอ และหมวดหมู่ข้อผิดพลาดของผู้ให้บริการ แต่หลีกเลี่ยงการเขียน API key ที่อยู่ลูกค้าแบบเต็ม หรือข้อมูลส่วนบุคคลที่ไม่จำเป็นลงในบันทึกแอปพลิเคชัน
แยกการตอบกลับของผู้ให้บริการออกจากโมเดลที่แสดงต่อลูกค้า วิธีนี้ทำให้เปลี่ยนผู้ให้บริการ แก้ไขกฎการจับคู่ และจำกัดข้อมูลที่เปิดเผยผ่านหน้าคำสั่งซื้อสาธารณะได้ง่ายขึ้น
ออกแบบประสบการณ์การติดตามสำหรับลูกค้า
หน้าติดตามควรตอบคำถามสามข้อได้อย่างรวดเร็ว: สถานะปัจจุบันคืออะไร เกิดอะไรขึ้นล่าสุด และลูกค้าควรทำอะไรต่อ แสดงข้อมูลอ้างอิงคำสั่งซื้อ หมายเลขพัสดุในรูปแบบที่คำนึงถึงความเป็นส่วนตัว ชื่อผู้ให้บริการขนส่ง เวลาของเหตุการณ์ล่าสุด และคำอธิบายข้อยกเว้นที่ชัดเจน
อย่าแสดงไทม์ไลน์ว่างเหมือนเป็นความล้มเหลวทางเทคนิค ก่อนการสแกนครั้งแรกของผู้ให้บริการขนส่ง ให้อธิบายว่าได้รับข้อมูลการจัดส่งแล้ว และอาจยังไม่เห็นการเคลื่อนที่ สำหรับข้อยกเว้น ให้คำอธิบายภาษาที่เข้าใจง่ายเฉพาะเมื่อข้อมูลต้นทางรองรับ หากผู้ให้บริการขนส่งรายงานปัญหาที่อยู่ ให้เชื่อมโยงไปยังกระบวนการสนับสนุนหรือการดำเนินการฝ่ายบริการลูกค้าที่ธุรกิจของคุณสามารถให้บริการได้จริง
สำหรับร้านค้าที่สร้างบน Shopify หรือแพลตฟอร์มอีคอมเมิร์ซอื่น ให้ตรวจสอบว่าแพลตฟอร์มเปิดเผยเหตุการณ์การจัดส่ง บัญชีลูกค้า หน้าสถานะคำสั่งซื้อ และเทมเพลตการแจ้งเตือนอย่างไร เอกสารสำหรับนักพัฒนาอย่างเป็นทางการของ Shopify มีแหล่งข้อมูลสำหรับเว็บฮุก และข้อมูลการจัดส่ง API ของแพลตฟอร์มและเอกสารที่แบ่งตามเวอร์ชันอาจเปลี่ยนแปลงได้ ดังนั้นให้ยืนยันเวอร์ชันที่แอปพลิเคชันของคุณใช้ก่อนดำเนินงานบนสภาพแวดล้อมจริง
ใช้การแจ้งเตือนอย่างระมัดระวัง
เหตุการณ์พัสดุเป็นตัวกระตุ้นที่มีประโยชน์ แต่การส่งข้อความสำหรับการสแกนของผู้ให้บริการขนส่งทุกครั้งอาจทำให้เกิดความเหนื่อยล้าจากการแจ้งเตือน กำหนดกฎทางธุรกิจ เช่น แจ้งเตือนเมื่อสร้างพัสดุ เมื่อมีความคืบหน้าระหว่างการขนส่งที่มีความหมาย เมื่อกำลังนำจ่าย เมื่อจัดส่งแล้ว และเมื่อเกิดข้อยกเว้นบางประเภท ระงับการแจ้งเตือนซ้ำและกำหนดช่วงเวลาขั้นต่ำสำหรับข้อความแจ้งเตือนความล่าช้าที่เกิดซ้ำ
แยกการแจ้งเตือนด้านปฏิบัติการออกจากการแจ้งเตือนลูกค้า ทีมสนับสนุนอาจจำเป็นต้องทราบว่าพัสดุไม่มีการเปลี่ยนแปลงมาหลายวัน ขณะที่ลูกค้าอาจต้องการข้อความเฉพาะเมื่อผู้ให้บริการขนส่งรายงานข้อยกเว้นที่ชัดเจน เกณฑ์เวลา ควรสะท้อนระดับการให้บริการ ปลายทาง ผู้ให้บริการขนส่ง และวิธีการจัดส่ง แทนที่จะใช้ตัวเลขสากลที่ไม่มีพื้นฐานด้านการดำเนินงาน
ทดสอบด้วยสถานการณ์การจัดส่งจริง
การได้รับการตอบกลับที่สำเร็จสำหรับหมายเลขติดตามหนึ่งหมายเลขยังไม่เพียงพอสำหรับการเปิดใช้งานจริง จัดทำเมทริกซ์การทดสอบที่ครอบคลุมผู้ให้บริการขนส่งหลายราย ประเทศ ประเภทพัสดุ และสถานะเหตุการณ์ ทดสอบอย่างน้อย:
- พัสดุที่เพิ่งสร้างและยังไม่มีการสแกนจากผู้ให้บริการขนส่ง
- พัสดุที่อยู่ระหว่างการขนส่งตามปกติ
- พัสดุที่กำลังนำจ่าย
- พัสดุที่จัดส่งแล้ว
- เหตุการณ์ข้อยกเว้นหรือเหตุการณ์เกี่ยวกับที่อยู่
- พัสดุที่ถูกส่งคืน
- หมายเลขติดตามที่ไม่ถูกต้อง
- เหตุการณ์การจัดส่งซ้ำ
- การตอบกลับของผู้ให้บริการล่าช้าหรือหมดเวลา
- เหตุการณ์ที่มาถึงไม่เรียงลำดับ
วัดผลมากกว่าความพร้อมใช้งานของ API ตรวจสอบว่ามีการอัปเดตคำสั่งซื้อที่ถูกต้องหรือไม่ ลูกค้าเห็นภาษาที่เข้าใจได้หรือไม่ การแจ้งเตือนซ้ำถูกระงับหรือไม่ และเจ้าหน้าที่สนับสนุนสามารถระบุเหตุการณ์ดั้งเดิมของผู้ให้บริการขนส่งได้หรือไม่ เริ่มใช้งานแบบจำกัดก่อน มีทางเลือกสำรองด้านปฏิบัติการ และติดตามหมวดหมู่ข้อผิดพลาดหลังเปิดตัว
ความปลอดภัย ความเป็นส่วนตัว และการบำรุงรักษา
จัดเก็บข้อมูลรับรองใน secrets manager หรือตัวแปรสภาพแวดล้อมที่ได้รับการปกป้อง ไม่ใช่ในโค้ดธีม โค้ดมือถือ ระบบควบคุมซอร์ส หรือคำขอจากเบราว์เซอร์ จำกัดการเข้าถึงข้อมูลพัสดุตามบทบาท ใช้ HTTPS และทบทวนระยะเวลาที่เก็บการตอบกลับดิบและฟิลด์ที่เกี่ยวข้องกับลูกค้า
ทบทวนเอกสารของผู้ให้บริการและเวอร์ชัน API ของแพลตฟอร์มอีคอมเมิร์ซอย่างสม่ำเสมอ การรองรับผู้ให้บริการขนส่ง ชื่อเหตุการณ์ ข้อกำหนดการยืนยันตัวตน และพฤติกรรมเว็บฮุกของแพลตฟอร์มอาจเปลี่ยนแปลงได้ ทำให้กฎการจับคู่สถานะสามารถกำหนดค่าได้ จัดทำเอกสารสมมติฐานที่อยู่เบื้องหลัง และทำให้สามารถเล่นซ้ำหรือกระทบยอดพัสดุได้โดยไม่ส่งข้อความถึงลูกค้าอีกครั้ง
API ของ 17TRACK เป็นตัวเลือกที่ควรประเมินเมื่อร้านค้าของคุณต้องการการผสานรวมการติดตามโดยเฉพาะสำหรับผู้ให้บริการขนส่งหลายราย อย่างไรก็ตาม ตัวเลือกที่เหมาะสมยังขึ้นอยู่กับผู้ให้บริการขนส่งที่คุณใช้ ประเทศที่คุณให้บริการ พฤติกรรมการอัปเดตที่ระบุไว้สำหรับบัญชีของคุณ ปริมาณคำขอที่คาดไว้ และการควบคุมด้านปฏิบัติการที่ทีมของคุณต้องการ ยืนยันประเด็นเหล่านี้ในเอกสารอย่างเป็นทางการและการทดสอบแนวคิดที่ควบคุมได้ก่อนตัดสินใจใช้การออกแบบสำหรับสภาพแวดล้อมจริง
คำถามที่พบบ่อย
ควรสร้างข้อมูลติดตามเมื่อมีการสั่งซื้อหรือไม่
โดยทั่วไปไม่ควร สร้างหรือเปิดใช้งานระเบียนพัสดุเมื่อเวิร์กโฟลว์การจัดส่งของคุณมีผู้ให้บริการขนส่งและหมายเลขติดตามแล้ว การสร้างตั้งแต่ขั้นตอนชำระเงินอาจทำให้เกิดระเบียนสำหรับคำสั่งซื้อที่ถูกยกเลิก ยังไม่ได้จัดส่ง หรือถูกแยกภายหลัง
API ติดตามสามารถรับประกันข้อมูลการจัดส่งแบบเรียลไทม์ได้หรือไม่
ไม่มี API ใดรับประกันได้ว่าการสแกนของผู้ให้บริการขนส่งทุกครั้งจะมองเห็นได้ทันที ผู้ให้บริการต้องพึ่งพาข้อมูลจากผู้ให้บริการขนส่ง และระบบของผู้ให้บริการขนส่งอาจรายงานเหตุการณ์ล่าช้าหรือมีช่องว่าง แสดงเวลาและภาษาของสถานะอย่างถูกต้อง และหลีกเลี่ยงการรับประกันเวลารีเฟรชที่แน่นอน เว้นแต่เอกสารและข้อตกลงการให้บริการที่เกี่ยวข้องจะรองรับคำรับประกันนั้น
เบราว์เซอร์ควรเรียก tracking API โดยตรงหรือไม่
ในการใช้งานส่วนใหญ่ไม่ควร ใช้การผสานรวมฝั่งเซิร์ฟเวอร์เพื่อรักษาข้อมูลรับรองให้ปลอดภัย ทำให้สามารถทำข้อมูลตอบกลับให้เป็นมาตรฐาน ควบคุมการลองใหม่ และกรองข้อมูลที่แสดงต่อลูกค้าได้ โดยปกติหน้าร้านค้าควรอ่านมุมมองพัสดุที่ได้รับอนุมัติจากแอปพลิเคชันของคุณ
ร้านค้าควรจัดการหลายหีบห่อในคำสั่งซื้อเดียวอย่างไร
จำลองการจัดส่งหรือแต่ละหีบห่อเป็นพัสดุแยกกัน โดยเก็บรหัสคำสั่งซื้อหลักไว้ หน้าคำสั่งซื้อสามารถแสดงสรุปโดยรวมและไทม์ไลน์แยกสำหรับแต่ละหีบห่อ วิธีนี้ป้องกันไม่ให้พัสดุที่ล่าช้าถูกซ่อนอยู่หลังสถานะจัดส่งแล้วของพัสดุอีกชิ้น
เมตริกแรกที่ควรติดตามในสภาพแวดล้อมจริงคืออะไร
ติดตามโฟลว์ทั้งหมดตั้งแต่การสร้างการจัดส่งจนถึงการอัปเดตที่ถูกต้องและลูกค้ามองเห็นได้ ความสำเร็จของ API เพียงอย่างเดียวไม่เพียงพอ ติดตามระเบียนซ้ำ พัสดุที่ไม่มีการอัปเดต เหตุการณ์ที่ไม่สามารถจับคู่ได้ ความล้มเหลวในการแจ้งเตือน และเปอร์เซ็นต์ของพัสดุที่ต้องแก้ไขด้วยตนเอง
