วิธีเลือก API ติดตามพัสดุสำหรับการจัดส่งข้ามพรมแดนในตะวันออกกลาง
เลือก API ติดตามพัสดุสำหรับการจัดส่งข้ามพรมแดนในตะวันออกกลาง โดยทดสอบเส้นทางการจัดส่งจริง การส่งต่อระหว่างผู้ให้บริการขนส่ง และเวิร์กโฟลว์กรณีผิดปกติของคุณ ไม่ใช่เปรียบเทียบเพียงจำนวนผู้ให้บริการขนส่งเท่านั้น สำหรับทีมปฏิบัติการอีคอมเมิร์ซและทีมวิศวกรรม ตัวเลือกที่ดีที่สุดคือ API ที่รักษาเอกลักษณ์ของพัสดุไว้ตลอดระหว่างผู้ให้บริการขนส่ง ส่งมอบเหตุการณ์การติดตามที่ใช้งานได้ และทำให้การอัปเดตที่ขาดหายหรือล่าช้ามองเห็นได้ ยืนยันความสามารถเหล่านี้ด้วยโครงการนำร่องที่เป็นตัวแทนก่อนตัดสินใจทำสัญญา
มองตะวันออกกลางเป็นกลุ่มตลาดปลายทางและรูปแบบการจัดส่งหลายรูปแบบ ไม่ใช่หมวดหมู่ความครอบคลุมเดียวกันทั้งหมด การผสานรวมที่ประสบความสำเร็จกับผู้ให้บริการขนส่งรายหนึ่งซึ่งให้บริการในสหรัฐอาหรับเอมิเรตส์ ไม่ได้ยืนยันว่าจะได้ผลลัพธ์เทียบเท่ากับบริการอื่นที่จัดส่งไปยังซาอุดีอาระเบียหรือจอร์แดน กระบวนการคัดเลือกของคุณควรเชื่อมโยงประสิทธิภาพทางเทคนิคกับผลลัพธ์ที่ใช้งานได้จริง: ทีมของคุณสามารถอธิบายได้หรือไม่ว่าพัสดุอยู่ที่ใด ระบุได้หรือไม่ว่าใครต้องดำเนินการ และให้ข้อมูลอัปเดตที่ถูกต้องแก่ลูกค้าได้หรือไม่
เริ่มจากแผนผังเส้นทาง ไม่ใช่รายชื่อผู้ให้บริการ
ก่อนประเมินผู้ให้บริการ ให้จัดทำรายการเส้นทางการจัดส่งที่ API ต้องรองรับ เส้นทางหนึ่งควรอธิบายมากกว่าประเทศต้นทางและปลายทาง รวมถึงบริการจัดส่ง ผู้ดำเนินการช่วงต้นทาง ผู้รวบรวมพัสดุ (ถ้ามี) ผู้ให้บริการจัดส่งปลายทาง และระบบที่จัดเก็บข้อมูลคำสั่งซื้อและข้อมูลพัสดุ
ตัวอย่างเช่น พัสดุสองชิ้นที่เดินทางจากต้นทางเดียวกันไปยังซาอุดีอาระเบียอาจมีเส้นทางการติดตามต่างกัน หากชิ้นหนึ่งใช้บริการด่วน ขณะที่อีกชิ้นผ่านผู้รวบรวมพัสดุก่อนการจัดส่งในประเทศ ทั้งสองกรณีถือเป็นกรณีทดสอบแยกกัน แม้ว่ารายงานของคุณจะแสดงอยู่ภายใต้คู่ประเทศเดียวกันก็ตาม
- ต้นทางและปลายทาง: บันทึกตลาดที่คุณให้บริการจริง รวมถึงแผนขยายธุรกิจที่อาจส่งผลต่อการตัดสินใจซื้อ
- ผู้ให้บริการขนส่งและบริการ: ระบุบริการตามสัญญา แทนการพึ่งพาเพียงชื่อแบรนด์ของผู้ให้บริการขนส่ง
- ตัวระบุการติดตาม: บันทึกว่าพัสดุใช้หมายเลขเดิมตลอดหรือได้รับตัวระบุใหม่ระหว่างการส่งต่อ
- ผู้รับผิดชอบด้านปฏิบัติการ: ระบุว่าใครรับผิดชอบคำถามเกี่ยวกับศุลกากร ปัญหาที่อยู่ ความพยายามจัดส่งที่ไม่สำเร็จ และการคืนสินค้า
- ผลกระทบต่อธุรกิจ: ระบุปริมาณพัสดุ ภาระงานฝ่ายบริการลูกค้า และผลกระทบจากการสูญเสียการมองเห็นในแต่ละเส้นทาง
ใช้แผนผังนี้เพื่อแยกความครอบคลุมที่จำเป็นออกจากความครอบคลุมที่เป็นทางเลือก ผู้ให้บริการไม่ควรชนะเพียงเพราะรองรับผู้ให้บริการขนส่งจำนวนมากที่คุณไม่ได้ใช้ ขณะที่ยังไม่ได้ทดสอบพันธมิตรจัดส่งที่สำคัญ
ตรวจสอบความครอบคลุมในระดับบริการและการส่งต่อ
รายชื่อผู้ให้บริการขนส่งเป็นเพียงจุดเริ่มต้น ไม่ใช่หลักฐานว่ามองเห็นข้อมูลได้ครบถ้วน ขอให้ผู้ให้บริการสาธิตการติดตามสำหรับคู่ผู้ให้บริการและบริการที่คุณใช้งานจริง โดยใช้พัสดุที่คุณได้รับอนุญาตให้แชร์ รวมพัสดุที่สร้างขึ้นล่าสุด พัสดุที่จัดส่งเสร็จแล้ว และพัสดุที่มีเหตุการณ์ผิดปกติด้านปฏิบัติการ
ทดสอบสิ่งที่เกิดขึ้นเมื่อผู้ให้บริการขนส่งปลายทางเข้ามารับผิดชอบการจัดส่ง การผสานรวมยังคงรักษาข้อมูลอ้างอิงเดิมไว้หรือไม่ สามารถเชื่อมโยงหมายเลขติดตามที่สองกับพัสดุเดียวกันได้หรือไม่ เหตุการณ์จากแต่ละช่วงสามารถแยกแยะได้หรือไม่ หรือไทม์ไลน์ที่ลูกค้าเห็นจะสับสน
การตรวจจับผู้ให้บริการขนส่งก็ต้องให้ความสนใจเช่นกัน รูปแบบหมายเลขติดตามอาจไม่เพียงพอที่จะระบุผู้ให้บริการที่ถูกต้องในทุกกรณี ตรวจสอบว่าคุณสามารถระบุผู้ให้บริการ แก้ไขการระบุ และกู้คืนพัสดุที่เดิมลงทะเบียนไว้กับบริการที่ไม่ถูกต้องได้หรือไม่
เงื่อนไขการยอมรับในทางปฏิบัตินั้นตรงไปตรงมา: ทีมปฏิบัติการของคุณควรติดตามพัสดุผ่านรูปแบบการจัดส่งที่ใช้งานจริงได้ หากไม่สามารถยืนยันช่วงใดระหว่างการทดสอบ ให้บันทึกว่าเป็นประเด็นที่ยังไม่คลี่คลาย แทนการสันนิษฐานว่ารองรับทั้งหมดหรือไม่รองรับเลย
ประเมินเหตุการณ์การติดตาม ไม่ใช่เพียงป้ายสถานะ
สถานะมาตรฐานช่วยให้ระบบจัดการคำสั่งซื้อทำงานข้ามผู้ให้บริการขนส่งได้ แต่จะมีประโยชน์น้อยลงเมื่อซ่อนเหตุการณ์ต้นฉบับหรือสื่อถึงความแน่นอนมากกว่าข้อมูลที่ผู้ให้บริการขนส่งให้มา ขอ payload ตัวอย่างและตรวจสอบความสัมพันธ์ระหว่างสถานะที่ทำให้เป็นมาตรฐานกับข้อความการติดตามพื้นฐาน
| ด้านการประเมิน | สิ่งที่ต้องตรวจสอบ | เหตุผลที่สำคัญ |
|---|---|---|
| เอกลักษณ์ของพัสดุ | ตัวระบุผู้ให้บริการขนส่ง หมายเลขติดตาม และข้อมูลอ้างอิงพัสดุที่เกี่ยวข้อง | ป้องกันไม่ให้เหตุการณ์ระหว่างการส่งต่อกลายเป็นระเบียนที่ขาดการเชื่อมโยง |
| ความหมายของเหตุการณ์ | หมวดหมู่มาตรฐานควบคู่กับข้อความต้นฉบับของผู้ให้บริการขนส่ง | รองรับระบบอัตโนมัติโดยไม่สูญเสียบริบท |
| ฟิลด์เวลา | เวลาที่เกิดเหตุการณ์ การจัดการเขตเวลา และเวลาที่ผู้ให้บริการอัปเดต หากมี | ช่วยแยกแยะการสแกนล่าช้ากับการอัปเดต API ล่าช้า |
| สถานที่ | ข้อมูลประเทศ เมือง หรือสถานที่ปฏิบัติการที่มีการระบุจริง | หลีกเลี่ยงการสื่อถึงตำแหน่งที่แม่นยำกว่าข้อมูลต้นทางรองรับ |
| เหตุการณ์ผิดปกติด้านการจัดส่ง | ความพยายามจัดส่งที่ล้มเหลว ปัญหาที่อยู่ การพักพัสดุ และเหตุการณ์การคืนสินค้าเมื่อมีข้อมูล | เชื่อมโยงการมองเห็นพัสดุเข้ากับคิวสนับสนุนที่สามารถดำเนินการได้ |
อย่าถือว่าเหตุการณ์ทั่วไปที่เกี่ยวข้องกับศุลกากรเป็นคำอธิบายที่แน่ชัดของความล่าช้า เหตุการณ์ดังกล่าวอาจไม่ระบุเอกสารที่ขาดหาย ผู้รับผิดชอบ หรือจำเป็นต้องชำระเงินหรือไม่ API ติดตามพัสดุควรช่วยให้คุณตรวจสอบได้ แต่ไม่ควรสร้างคำแนะนำที่ไม่มีหลักฐานรองรับให้ลูกค้าโดยอัตโนมัติ
แยกการสื่อสารภาษาอาหรับออกจากความพร้อมใช้งานของเหตุการณ์
สำหรับลูกค้าที่พูดภาษาอาหรับ ให้ทดสอบชั้นการนำเสนอทั้งหมด ตรวจสอบการจัดการข้อความภาษาอาหรับ การแสดงผลจากขวาไปซ้าย ตัวระบุภาษาอาหรับและละตินที่อยู่ร่วมกัน และถ้อยคำการแจ้งเตือนที่แปลแล้ว เหตุการณ์ของผู้ให้บริการขนส่งที่เป็นภาษาอังกฤษไม่ได้ยืนยันว่า API มีคำแปลภาษาอาหรับ เช่นเดียวกับอินเทอร์เฟซติดตามภาษาอาหรับไม่ได้ยืนยันว่าข้อมูลเหตุการณ์พื้นฐานมีรายละเอียดมากกว่า
ใช้ข้อความที่ควบคุมได้สำหรับลูกค้าในสถานะทั่วไป ขณะเดียวกันให้เจ้าหน้าที่ฝ่ายสนับสนุนตรวจสอบถ้อยคำต้นฉบับของผู้ให้บริการขนส่งได้ แปลความไม่แน่นอนอย่างถูกต้อง: พัสดุที่ไม่มีการอัปเดตล่าสุดไม่ควรถูกอธิบายว่าสูญหายโดยไม่มีหลักฐานเพิ่มเติม
ทำให้การตรวจสอบ API เป็นส่วนหนึ่งของการคัดเลือก
การตอบกลับ API ที่สำเร็จไม่ได้หมายความว่าพัสดุมีข้อมูลล่าสุดเสมอไป ตรวจสอบสถานะการผสานรวมและการมองเห็นพัสดุแยกจากกัน ระบบของคุณอาจได้รับการตอบกลับที่ถูกต้องขณะที่ผู้ให้บริการขนส่งไม่มีเหตุการณ์ใหม่ หรือผู้ให้บริการ API อาจมีข้อมูลใหม่แต่ปลายทาง webhook ของคุณไม่สามารถประมวลผลได้
สำหรับเวิร์กโฟลว์ที่ใช้ webhook ให้สอบถามเกี่ยวกับการยืนยันตัวตน พฤติกรรมการลองใหม่ บันทึกการส่ง ตัวระบุเหตุการณ์ และการกู้คืนหลังระบบขัดข้อง ยืนยันพฤติกรรมตามเอกสารแทนการสันนิษฐานว่า webhook จะมาถึงเพียงครั้งเดียวหรือตามลำดับเวลา ออกแบบตัวรับข้อมูลให้รองรับข้อมูลซ้ำและเหตุการณ์ล่าช้า เว้นแต่สัญญาการผสานรวมจะระบุไว้ชัดเจนว่าไม่เกิดขึ้น
- การลงทะเบียนล้มเหลว: ระบุพัสดุที่ไม่เคยเข้าสู่เวิร์กโฟลว์การติดตามได้หรือไม่
- การประมวลผล webhook ล้มเหลว: ทีมของคุณค้นหา ตรวจสอบ และเล่นซ้ำหรือดึงการอัปเดตที่พลาดไปได้หรือไม่
- พัสดุไม่มีการอัปเดต: ตรวจจับการไม่มีเหตุการณ์ล่าสุดตามเกณฑ์ที่เหมาะสมกับเส้นทางและระยะของพัสดุได้หรือไม่
- การกระทบยอด: สอบถามสถานะพัสดุเพื่อแก้ช่องว่างระหว่างฐานข้อมูลของคุณกับระเบียนของผู้ให้บริการได้หรือไม่
- การควบคุมวงจรชีวิต: จะเกิดอะไรขึ้นหลังการจัดส่ง การคืนสินค้า การยกเลิก หรือสิ้นสุดระยะเวลาการติดตาม
หลีกเลี่ยงการแจ้งเตือนเมื่อไม่มีการเคลื่อนไหวแบบเดียวสำหรับพัสดุทุกชิ้น ป้ายกำกับที่รอการรับกับพัสดุที่รอความพยายามจัดส่งเป็นสถานการณ์ด้านปฏิบัติการที่แตกต่างกัน กำหนดกฎการแจ้งเตือนร่วมกับทีมที่รับผิดชอบดำเนินการ
ตรวจสอบสถาปัตยกรรม ความปลอดภัย และต้นทุนการดำเนินงานทั้งหมด
ตัดสินใจว่าความต้องการหลักของคุณคือการมองเห็นข้อมูลจากผู้ให้บริการหลายราย หรือเวิร์กโฟลว์การจัดส่งที่ครอบคลุมกว่านั้น การติดตาม การสร้างฉลาก เอกสารศุลกากร การกำหนดเวลาจัดส่ง และการแก้ไขที่อยู่เป็นข้อกำหนดแยกกัน อย่าสันนิษฐานว่า API ติดตามพัสดุจะทำหน้าที่ทั้งหมดนี้
การผสานรวมกับผู้ให้บริการขนส่งโดยตรงอาจเป็นทางเลือกที่เหมาะสมเมื่อธุรกิจของคุณใช้ผู้ให้บริการจำนวนน้อยและคงที่ และต้องการเวิร์กโฟลว์เฉพาะของผู้ให้บริการ การใช้ API สำหรับผู้ให้บริการหลายรายคุ้มค่าที่จะทดสอบเมื่อการดูแลการผสานรวมแยกกันสร้างภาระด้านปฏิบัติการหรือวิศวกรรม ไม่ว่าสถาปัตยกรรมแบบใดก็ไม่ลดความจำเป็นในการตรวจสอบแต่ละเส้นทางที่สำคัญ
สำหรับการตรวจสอบด้านความปลอดภัย ให้ทำแผนผังข้อมูลที่ตั้งใจจะส่งก่อนเปิดใช้งานการเข้าถึงระบบจริง พิจารณาว่าจำเป็นต้องใช้ชื่อ หมายเลขโทรศัพท์ ที่อยู่จัดส่ง หรือรายละเอียดคำสั่งซื้อหรือไม่ ยืนยันการจัดการข้อมูลรับรอง การควบคุมการเข้าถึง ระยะเวลาเก็บรักษา การลบข้อมูล ผู้ประมวลผลช่วงต่อ และรูปแบบการโฮสต์กับผู้ให้บริการ ให้ผู้รับผิดชอบด้านกฎหมายหรือความเป็นส่วนตัวที่เหมาะสมประเมินภาระผูกพันเฉพาะปลายทาง ความครอบคลุมในภูมิภาคไม่ได้เป็นหลักฐานว่าเหมาะสมตามข้อกำหนดด้านกฎระเบียบ
ขอคำอธิบายเป็นลายลักษณ์อักษรเกี่ยวกับหน่วยการเรียกเก็บเงิน ชี้แจงว่าค่าบริการเกี่ยวข้องกับหมายเลขติดตามที่ลงทะเบียน พัสดุ คำขอ การสมัครสมาชิก หรือมาตรวัดอื่น สอบถามวิธีจัดการการลงทะเบียนซ้ำ การติดตามซ้ำ การคืนสินค้า การใช้งานเกินกำหนด และพัสดุที่ไม่มีการใช้งาน รวมงานติดตั้ง ความต้องการด้านการสนับสนุน การตรวจสอบ และการบำรุงรักษาต่อเนื่องไว้ในการเปรียบเทียบต้นทุน
บทบาทของ 17TRACK ในการประเมิน
สำหรับทีมที่กำลังพิจารณาการผสานรวมการติดตามจากผู้ให้บริการหลายราย 17TRACK's Tracking API page และ official API documentation เป็นจุดเริ่มต้นที่เกี่ยวข้อง ประเมิน API โดยใช้แผนผังเส้นทาง ข้อกำหนดเหตุการณ์ และสถานการณ์การกู้คืนเดียวกับที่อธิบายไว้ข้างต้น
ขอการยืนยันเกี่ยวกับผู้ให้บริการขนส่งปลายทาง ชุดบริการที่รองรับ ข้อกำหนด payload เงื่อนไขทางการค้า และรูปแบบการสนับสนุน อย่าสรุปรายละเอียดเหล่านั้นจากการที่มีหน้าติดตามสำหรับผู้บริโภคหรือคำอธิบายผลิตภัณฑ์ทั่วไป เครื่องมือติดตามที่ลูกค้าใช้งานและการผสานรวม API สำหรับปฏิบัติการควรได้รับการประเมินตามข้อกำหนดของแต่ละส่วน
ดำเนินโครงการนำร่องที่ช่วยให้ตัดสินใจได้อย่างชัดเจน
วางโครงการนำร่องโดยยึดคำถามด้านปฏิบัติการจริง ไม่ใช่เพียงการสาธิตการจัดส่งที่สำเร็จ ใช้กลุ่มตัวอย่างที่สะท้อนสัดส่วนผู้ให้บริการขนส่งของคุณ และรวมกรณีการส่งต่อ ช่วงที่ไม่มีการอัปเดต ความพยายามจัดส่งที่ล้มเหลว และการคืนสินค้า หากสถานการณ์เหล่านี้เกิดขึ้นในธุรกิจของคุณ พัสดุในอดีตช่วยตรวจสอบโครงสร้างเหตุการณ์ได้ ส่วนพัสดุจริงจำเป็นต่อการสังเกตการส่งมอบการอัปเดต
- กำหนดเกณฑ์การยอมรับก่อน: ระบุเส้นทางที่จำเป็น ฟิลด์ที่ต้องมี ความล่าช้าของการอัปเดตที่ยอมรับได้ ข้อกำหนดการกู้คืน และเงื่อนไขด้านความปลอดภัย
- จัดทำข้อมูลอ้างอิง: เปรียบเทียบเหตุการณ์จาก API กับระเบียนการติดตามอย่างเป็นทางการของผู้ให้บริการขนส่งที่เกี่ยวข้อง พร้อมบันทึกเวลาที่สังเกตแต่ละครั้ง ระเบียนของผู้ให้บริการเป็นข้อมูลอ้างอิงที่มีประโยชน์ ไม่ใช่การรับประกันตำแหน่งจริง
- แยกแหล่งที่มาของความล่าช้า: แยกเวลาที่เกิดเหตุการณ์จากผู้ให้บริการขนส่ง เวลาที่ผู้ให้บริการ API ทำให้เหตุการณ์พร้อมใช้งานหากตรวจสอบได้ และเวลาที่แอปพลิเคชันของคุณประมวลผล
- ทดสอบการจัดการความล้มเหลว: ส่งตัวระบุที่ไม่ถูกต้อง ขัดจังหวะปลายทางรับข้อมูล และตรวจสอบกระบวนการกู้คืนตามเอกสาร
- ทบทวนร่วมกับฝ่ายปฏิบัติการ: ขอให้เจ้าหน้าที่ฝ่ายสนับสนุนอธิบายเหตุการณ์ผิดปกติและระบุการดำเนินการถัดไปโดยใช้ข้อมูลที่ผสานรวมแล้ว
- แก้ไขช่องว่างเป็นลายลักษณ์อักษร: บันทึกบริการที่ยังไม่ได้ตรวจสอบ ข้อกำหนดที่ไม่รองรับ วิธีแก้ไขที่เสนอ และผู้รับผิดชอบปัญหาที่เหลือแต่ละรายการ
เลือกผู้ให้บริการที่ผ่านข้อกำหนดด้านปฏิบัติการที่จำเป็นของคุณ ด้วยความพยายามติดตั้งและเงื่อนไขทางการค้าที่ยอมรับได้ ให้ถือว่าการมองเห็นที่ยังไม่คลี่คลายในเส้นทางสำคัญต่อธุรกิจเป็นเหตุผลให้เลื่อนหรือจำกัดการใช้งาน แม้ส่วนอื่นของการสาธิตจะทำงานได้ดี ฟีเจอร์เสริมควรใช้แยกผู้สมัครที่ผ่านเกณฑ์ ไม่ใช่ชดเชยข้อกำหนดที่ล้มเหลว
คำถามที่พบบ่อย
ความครอบคลุมระดับประเทศหมายความว่ารองรับผู้ให้บริการขนส่งท้องถิ่นทุกรายหรือไม่
ไม่ใช่ คำกล่าวในระดับประเทศไม่ได้ยืนยันว่ารองรับผู้ให้บริการขนส่ง บริการ หรือรูปแบบการส่งต่อทุกรายในตลาดนั้น ยืนยันพันธมิตรจัดส่งเฉพาะที่พัสดุของคุณใช้งานและทดสอบเหตุการณ์ของพวกเขาก่อนพึ่งพาความครอบคลุมดังกล่าวในทางปฏิบัติ
API ติดตามพัสดุสามารถแก้ไขการกักพัสดุที่ศุลกากรได้หรือไม่
ข้อมูลการติดตามอาจแสดงเหตุการณ์ที่เกี่ยวข้องกับศุลกากร แต่การแสดงเหตุการณ์นั้นไม่ได้ทำให้พัสดุผ่านการตรวจโดยตัวมันเอง การแก้ไขอาจต้องดำเนินการโดยผู้ให้บริการขนส่ง นายหน้า ผู้จัดส่ง หรือผู้รับ ส่งต่อกรณีไปยังผู้รับผิดชอบและหลีกเลี่ยงการรับปากวันที่ปล่อยพัสดุจากสถานะการติดตามเพียงอย่างเดียว
Webhook เพียงพอหรือควรใช้การ polling ด้วย
Webhook รองรับการอัปเดตที่ขับเคลื่อนด้วยเหตุการณ์ ขณะที่ปลายทางการสอบถามที่ได้รับอนุญาตช่วยกระทบยอดระเบียนที่ขาดหายได้ การออกแบบที่เหมาะสมขึ้นอยู่กับการรับประกันการส่งมอบ ขีดจำกัดอัตราการเรียก และทางเลือกการกู้คืนตามเอกสาร ตรวจสอบเส้นทางการกู้คืนแทนการสันนิษฐานว่าการแจ้งเตือนทุกครั้งจะมาถึงแอปพลิเคชันของคุณ
ควรประเมินความใหม่ของข้อมูลการติดตามอย่างไร
เปรียบเทียบเวลาและการสังเกตในแต่ละขั้นตอน ได้แก่ เหตุการณ์จากผู้ให้บริการขนส่ง การพร้อมใช้งานของผู้ให้บริการหากวัดได้ และการรับข้อมูลโดยแอปพลิเคชัน พัสดุที่ไม่มีการสแกนใหม่จากผู้ให้บริการขนส่งแตกต่างจากการผสานรวมที่ไม่สามารถส่งมอบเหตุการณ์ที่มีอยู่แล้ว รายงานเงื่อนไขเหล่านี้แยกจากกัน
ควรกำหนดการรองรับภาษาอาหรับเป็นข้อกำหนดบังคับหรือไม่
กำหนดให้การสื่อสารกับลูกค้าภาษาอาหรับเป็นข้อบังคับเมื่อกลุ่มเป้าหมายต้องการ แต่ระบุให้ชัดเจนว่าความสามารถดังกล่าวต้องอยู่ในส่วนใด หน้าร้านหรือระบบแจ้งเตือนของคุณอาจรองรับการแปลภาษาได้ แม้เหตุการณ์ต้นทางจะเป็นภาษาอื่น ทดสอบข้อความที่แปลแล้วและการแสดงผลจากขวาไปซ้ายร่วมกัน
แหล่งข้อมูล
- 17TRACK Tracking API — แหล่งอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับจุดเริ่มต้นการประเมิน API ที่กล่าวถึงในคู่มือนี้
- 17TRACK API documentation — แหล่งอ้างอิงทางเทคนิคอย่างเป็นทางการสำหรับตรวจสอบข้อกำหนดการผสานรวมและพฤติกรรมตามเอกสารก่อนการติดตั้ง
