找不到 DHL 或 DPD 追蹤資料？17TRACK API 如何運用 AI 提高追蹤成功率
為甚麼相同的追蹤號碼在一個平台上沒有結果，卻在另一個平台上顯示完整的追蹤紀錄？
當企業遇到 DHL Tracking Not Found 或 DPD Tracking Not Found 等問題時，通常會以為追蹤號碼無效，或者承運商尚未更新其紀錄。
實際上，將追蹤號碼提交至 API，並不保證一定會返回追蹤事件。
取得追蹤資訊首先取決於能否正確識別承運商，並將請求發送至正確的資料來源。如果承運商識別錯誤，即使包裹正常運送中，請求也可能返回 Not Found。
當業務規模擴大時，問題會更加明顯。例如，同時使用 DHL Tracking API 和 DPD Tracking API 的企業，必須先確定每個追蹤號碼應提交至哪個 API。
17TRACK API 結合內部 AI 識別模型、基於規則的匹配及持續監控，協助企業減少可避免的承運商匹配錯誤，並提高追蹤成功率。
1. 為甚麼追蹤號碼可能沒有返回追蹤事件？
追蹤號碼沒有統一格式。每家承運商都有自己的編號規則，而單靠追蹤號碼可能不足以識別承運商。
1.1 相似的追蹤號碼格式令承運商更難識別
不同承運商可能使用長度相同、前綴或字母與數字模式相似的追蹤號碼。
同一個追蹤號碼可能符合多家承運商的編號格式。傳統的基於規則的匹配會檢查長度、前綴及字元模式。當這些規則重疊時，單靠格式可能不足以識別正確的承運商。
格式與號碼相符的承運商只是一個候選者，實際處理包裹的可能是另一家承運商。
匹配錯誤可能會將請求發送至錯誤的資料來源，導致返回 Not Found。
1.2 提交的承運商資訊可能不準確
企業通常會透過 ERP、WMS、OMS 或其他訂單管理系統提交貨件資訊。
這些系統可能使用承運商的官方名稱、縮寫或內部代碼來表示同一家承運商。記錄也可能包含有效的追蹤號碼，但承運商欄位卻不正確。
如果追蹤系統完全依賴所提交的承運商資訊，便可能持續查詢錯誤的資料來源。
因此，追蹤系統需要識別承運商、檢查匹配結果，並修正匹配錯誤。
1.3 跨境貨件的資料可能分散於多家承運商
跨境運送通常涉及提貨、幹線運輸、清關及最後一公里派送。
多家承運商可能會先後處理同一個包裹，而途中也可能會分配一個關聯的最後一公里追蹤號碼。
只查詢其中一家承運商，可能只能返回部分紀錄，令包裹的運送歷程出現缺口。
除了廣泛的承運商覆蓋範圍外，系統還需要識別正確的資料來源並整合追蹤資料。
追蹤成功取決於 API 是否可用、追蹤號碼的品質、承運商識別、資料來源是否可用，以及是否已產生追蹤事件。
2. 17TRACK API 如何利用 AI 提高承運商識別準確度？
當號碼格式重疊或提交的承運商資訊不準確時，固定規則可能導致錯誤匹配。
AI 有助於解決這些模糊匹配問題。
17TRACK 將內部 AI 模型與傳統的基於規則的匹配相結合，利用多年累積的物流數據識別最有可能的承運商，並減少因查詢錯誤資料來源而導致的查詢失敗。
2.1 結合固定規則與 AI 輔助識別
傳統的承運商識別主要依靠預先定義的規則，根據號碼長度、前綴及字元模式匹配候選承運商。
當編號規則各不相同時，這種方法效果良好。但承運商之間的規則相似，或追蹤號碼資訊不完整時，便可能產生模糊結果。
17TRACK 結合 AI 識別與基於規則的匹配，同時利用追蹤號碼特徵及可用的承運商資訊，判斷可能的資料來源。
當系統識別出的承運商與企業提供的承運商不一致時，可以進一步檢查匹配結果。
例如：
- 企業提交 DHL 作為承運商。
- 系統根據追蹤號碼模式識別出另一個候選承運商。
- 系統可以檢查兩個匹配結果，以降低因承運商資訊不正確而導致查詢失敗的風險。
這可減少對人工選擇承運商的依賴，並減少在大量追蹤號碼中重複檢查的工作。
2.2 基於多年物流數據建立的內部 AI 模型
AI 識別效能取決於訓練數據、涵蓋的範例範圍，以及模型的改進方式。
17TRACK 自 2010 年起專注於全球貨件追蹤，目前覆蓋 3,500 多家承運商，每月累積大量物流數據。
17TRACK 利用這些數據訓練及改進自己的識別模型。持續訓練和調整有助於模型了解承運商特有的追蹤號碼模式，並改善複雜情況下的識別能力。
當承運商使用相似的編號規則，難以透過傳統匹配方式區分時，AI 可以提供額外的判斷訊號。
這種方法減少了人工維護固定規則的工作量，並為新加入的承運商及複雜的運送情況提供更靈活的識別方式。
2.3 結合 AI 識別與雙重註冊以減少匹配錯誤
17TRACK 亦提供一種在識別出候選承運商後提高追蹤成功率的方法。
如果系統識別出的承運商與提交的承運商不同，啟用了雙重註冊的企業也可以查詢 AI 識別出的承運商。
例如：
企業提交一票標記為 DHL 的貨件，但系統識別出另一家承運商更有可能匹配。
啟用雙重註冊後，系統除了執行原本的查詢外，還可以嘗試從識別出的承運商取得追蹤事件。
即使企業最初提交了錯誤的承運商，這也讓企業有機會取得正確的追蹤資料。
這些功能相互配合，有助於減少由承運商匹配錯誤引起的可避免查詢失敗。
3. 調查 Not Found 結果的成因
即使正確識別了承運商，部分查詢起初仍可能沒有返回追蹤事件。
追蹤號碼可能剛剛建立，而承運商仍在等待接收包裹。承運商的追蹤服務也可能暫時無法使用。任何一種情況都可能導致 Not Found 結果。
僅憑 Not Found 結果，並不足以斷定包裹尚未寄出或已經遺失。
要提高追蹤成功率，需要找出原因並採取適當行動。
3.1 識別原因以避免不必要的查詢
Not Found 結果或查詢失敗的常見原因包括：
| 問題類型 | 可能原因 | 建議行動 |
|---|---|---|
| 承運商匹配錯誤 | 實際承運商與所選承運商不一致。 | 重新識別並驗證承運商。 |
| 追蹤資訊不正確 | 追蹤號碼不正確或缺少必要參數。 | 驗證追蹤號碼及查詢參數。 |
| 沒有可用的追蹤更新 | 追蹤號碼已產生，但承運商尚未提供第一個追蹤事件。 | 等待承運商更新追蹤資訊。 |
| 資料來源錯誤 | 承運商 API 故障、服務限制或其他問題。 | 監控承運商 API 狀態並調查異常。 |
每種原因都需要採取不同的應對措施。
如果是承運商匹配錯誤，重新識別承運商並驗證資料來源即可解決問題。如果承運商尚未產生第一個追蹤事件，重複查詢仍可能不會返回新資訊。
區分這些情況，有助於減少不必要的請求及重複排查。
3.2 監控承運商數據以提早發現問題
除了個別查詢失敗外，企業還需要留意影響大批貨件的問題。
如果承運商通常會返回追蹤事件，但大量貨件突然顯示 Not Found，下一步便是檢查承運商的 API、網站追蹤服務或資料擷取流程。
17TRACK 持續監控承運商的數據效能。當偵測到效能下降或異常波動時，便會發出警報並通知客戶。
這讓企業可以更早了解承運商方面的問題，並在客戶投訴累積之前調整查詢及處理程序。
承運商識別、故障排查及資料來源監控，讓團隊能夠調查及跟進 Not Found 結果。
4. 客戶追蹤成功率提升案例
實際營運中的追蹤表現，展示了 AI 識別及 Not Found 管理的影響。
追蹤成功率因客戶而異，並取決於承運商覆蓋範圍、追蹤號碼品質、查詢策略及資料來源是否可用等因素。
兩個 17TRACK 客戶案例：
案例 1：全球領先的快時尚平台
- 規模：平均每日追蹤數以千萬計的訂單。
- 追蹤成功率：由 44.25% 提升至 93.29%。
案例 2：美國電子商務售後保障平台
- 規模：服務全球 5,000 多個旗艦品牌。
- 追蹤成功率：由 85% 提升至 95%。
這些結果反映了客戶整體追蹤營運的改善，不能歸因於 AI 單一因素，也不能用作 DHL 或 DPD 的特定承運商成功率。
對於處理大量跨境訂單的企業而言，更高的追蹤成功率意味着可用於訂單管理、客戶支援及售後營運的貨件資料更多。
提高為每個有效號碼取得正確追蹤事件的機會
追蹤查詢看似只是輸入一個號碼，但在幕後涉及承運商識別、資料來源匹配、資料擷取及持續監控。
號碼格式重疊、不完整的承運商資訊，以及承運商之間的交接，都可能影響結果，尤其是在跨境運送中。
17TRACK API 結合 AI 驅動的承運商識別、內部物流數據模型、雙重註冊及持續的 Not Found 管理，協助企業減少可避免的資料來源匹配錯誤，更有效率地取得追蹤資料。
