← 所有文章
指南

TikTok Shop 4PL 地址遮蔽規則：客服身份唔應該綁喺訂單 PII

**直接答案：**TikTok Shop 並無喺 2026 年 7 月 13 日新增 4PL 遮蔽規則。現有 TikTok Shop Partner Center 官方說明發佈於 2025 年 5 月 28 日，原定喺 2025 年 7 月 21 日前實施。對美國本地同跨境訂單、Orders API 202309 以上版本，recipient_address 會唔會被遮蔽，取決於履約類型同 order_status。

重點係：

  • 唔係所有 4PL 訂單都會一直隱藏地址，欄位可見性會跟 order_status 改變。
  • 官方說明入面，Seller Shipping（3PL）同 TikTok Shipping（4PL）用同一套狀態遮蔽表。
  • Fulfilled by TikTok（FBT）喺更多狀態維持地址欄位遮蔽。
  • TikTok 建議按 order_status 判斷係咪履約，而唔係睇地址有無明文。

收件電話同地址係物流資料，唔係穩定客服身份或 help desk 路由主鍵。如果 TikTok Shop integration 仍然將訂單 payload 當成客服系統核心，就應該喺下一次欄位可見性調整前拆開層次。

TikTok Shop 美國地址遮蔽規則實際講咩

官方說明適用於美國本地同跨境訂單，以及 Orders API 202309 以上版本。3PL 同 4PL 喺 UNPAID、ON_HOLD、CANCELLED，以及完成超過 30 日時，會遮蔽電話、姓名、詳細地址、地址行、投遞偏好、郵編同部分地區欄位；FBT 就喺更多狀態維持遮蔽。TikTok 表示呢啲規則唔應影響 3PL 或 4PL 履約，integration 應該按 order_status 判斷係咪出貨。

細團隊入面，呢個習慣通常係咁：

訂單同步到達
  -> 讀收件電話同地址
  -> 匹配舊工單或者試算表
  -> 推斷邊位買家傳咗 TikTok 訊息
  -> 路由客服 case

佢可以運作，直到平台遮蔽欄位、買家用另一個手機號碼、一家人共用地址，或者客戶改喺 WhatsApp、LINE、Zalo 繼續跟進。客服時間線就會斷，因為身份模型建喺物流資料上，而唔係會話資料上。

對跨境賣家尤其重要。一張 TikTok Shop 訂單可能喺美國履約，買家先喺 TikTok 訊息查詢，經銷商喺 WhatsApp 升級，同事再喺 LINE 或 Zalo 確認。單一物流欄位被遮蔽，唔應該決定團隊仲可唔可以睇到完整客戶時間線。延伸閱讀：TikTok Shop 私訊 webhook 指南同 LIVE room ID integration 分析。

三種身份要分開

平台遮蔽收件人資料時，正確反應唔係再搵另一個裸露欄位，而係先講清楚你實際用緊邊種身份：

身份應該放喺邊回答咩問題
物流身份訂單同履約系統包裹送去邊，下一步承運動作係咩？
交易身份TikTok Shop、CRM、分析系統邊張訂單、SKU、活動、LIVE 場次或者換貨流程相關？
客服身份入站消息隊列邊個透過邊個渠道搵我哋，問咗咩？

三種身份可以之後再關聯。CRM 可以將會話掛到訂單；倉庫面板可以喺履約異常旁邊顯示最近客服記錄；AI 分流工具可以摘要買家退換貨前問過咩。但佢哋唔應該共用同一個主鍵。

物流 PII 尤其唔適合做客服身份，因為敏感又唔穩定。佢可以被遮蔽、修正、共用、縮寫，或者根本不存在。會話事件唔同：佢記錄客戶聯絡你嗰一刻，包括渠道、帳號、會話、發送者、訊息同時間。

將入站消息放入獨立簽名隊列

UnifyPort 標準 message.received 事件透過非官方接口接收普通消息帳號入站訊息，並統一投遞成標準 webhook 事件流，咁客服系統記錄就唔再依賴訂單 payload 有冇 PII。

先建立 webhook endpoint：

curl -X POST https://api.unifyport.ai/v1/webhook-endpoints \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://support.example.com/webhook",
  "status": "active",
  "subscribed_events": ["message.received"],
  "signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'

買家訊息到達時，接收端會攞到標準事件信封：

{
  "id": "evt_20260713_tiktok_4pl_001",
  "type": "message.received",
  "provider": "tiktok",
  "account_id": "acc_tiktok_us_shop",
  "occurred_at": "2026-07-13T02:24:18Z",
  "data": {
    "conversation": { "id": "tt_conv_71942", "type": "user", "title": "Jordan Lee" },
    "sender": { "id": "tt_user_28491", "type": "user", "name": "Jordan Lee" },
    "message": {
      "id": "tt_msg_20260713_001",
      "type": "text",
      "text": "The tracking page says my exchange is delayed. Can someone check it?",
      "direction": "inbound",
      "sent_at": "2026-07-13T02:24:15Z"
    },
    "event": { "kind": "message_received" }
  }
}

如果 endpoint 設定咗 signing_secret，每次投遞會帶 X-Device-Timestamp 同 X-Device-Signature。按 webhook 投遞同簽章驗證說明喺解析前驗簽，按事件 ID 去重；即使暫時配唔到訂單，都要先保存訊息記錄。

主要設計轉變就係：只要客戶聯絡你，入站訊息就應該持久化，而唔係等訂單欄位暴露足夠 PII 先保存。

之後關聯，明確回覆

事件入庫後，再由交易系統補上下文：

TikTok Shop 訂單同步
  -> order id、SKU、exchange status、logistics state

UnifyPort message.received webhook
  -> provider、account_id、conversation、sender、message、occurred_at

CRM 或客服後端
  -> 按已知帳號映射、近期訂單時間窗、客戶主動提供嘅訂單號或人工確認去關聯

呢個模型承受到欄位遮蔽。電話號碼唔見，工單仍然存在；地址隱藏，訊息仍然可以路由；同一買家轉去 WhatsApp 或 LINE，事件仍然用同一套結構入系統，只係 provider 唔同。

回覆亦要保持明確。工作流決定回覆時，按 POST /v1/messages 文字訊息文件用已連接帳號同收件人送出：

curl -X POST https://api.unifyport.ai/v1/messages \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "account_id": "acc_tiktok_us_shop",
  "to": { "id": "tt_user_28491", "type": "user" },
  "message": {
    "type": "text",
    "text": "We found the exchange delay and will update you here once the carrier scan refreshes."
  }
}'

訂單系統繼續做訂單工作，客服系統繼續做會話工作。物流欄位被遮蔽，就唔會變成客服事故。

實際 integration 檢查清單

將收件地址遮蔽規則當成一次快速審計：

  1. 搜尋訂單同步任務入面對 phone、address、recipient name 嘅匹配邏輯。
  2. 標出邊啲關聯係履約必需，邊啲只係客服捷徑。
  3. 將客服入站流量移到簽名 message.received 隊列。
  4. 為每個入站事件保存 id、provider、account_id、conversation、sender、message 同 occurred_at。
  5. 自動關聯唔穩時，喺會話請客戶提供訂單號。
  6. 出站回覆統一行 POST /v1/messages，唔好藏喺物流同步任務入面。

重點唔係訂單資料無用，而係訂單資料有自己嘅工作。TikTok Shop 可以喺物流 payload 入面加強私隱邊界，而你嘅客服運作唔應該因此中斷。

電話同地址遮蔽提醒團隊：客服需要自己嘅事實來源。將敏感訂單欄位放喺履約層，將客戶訊息放入簽名入站隊列。有理由先關聯，平台收緊交易 payload 時，團隊就唔使重建客服系統。

常見問題

TikTok Shop 會遮蔽所有 4PL 訂單地址嗎？

唔會。美國市場 3PL、4PL 嘅欄位可見性取決於 order_status；FBT 用更嚴格嘅遮蔽模式。

官方規則適用邊啲市場同 API 版本？

適用於美國本地同跨境訂單，以及 Orders API 202309 以上版本。

地址遮蔽會阻止訂單履約嗎？

TikTok 表示唔會改變 3PL 或 4PL 履約能力。Integration 應按 order_status 判斷係咪出貨。

客服系統可以將收件電話當客戶 ID 嗎？

唔建議。電話同地址可能被遮蔽、修改、共用或移除。應先保存入站訊息嘅 conversation 同 sender，再用可靠訂單號關聯。

來源同下一步