歷史與疑難排解

複製頁面

每封電子郵件和每個 HTTP 請求都會被記錄，內容包含請求、回應、時間戳記及錯誤資訊。如何檢視歷史紀錄、重新發送操作，以及排除最常見的故障。

此應用程式執行的每項操作都會被記錄下來。當電子郵件未送達，或送達時內容有誤時，首先應查看「歷史紀錄」。

清單

欄位：ID、名稱、類型、狀態、持續時間及執行時間。

篩選條件：

動作類型 - HTTP 請求或電子郵件
狀態 - 成功、失敗、待處理或跳過（已取消訂閱）

「搜尋」功能會根據佈局或請求的名稱進行匹配。若您是透過 HTTP 請求的「請求歷史紀錄」按鈕進入此頁面，系統會預先篩選該次請求的資料；您可點擊「顯示所有事件」按鈕來清除篩選條件。

「歷史紀錄」頁面，其中包含搜尋欄位、可依動作類型、狀態、佈局及寄件者篩選的篩選器，以及清單中顯示的兩封已寄出的電子郵件 — 歷史紀錄：每封電子郵件和每個 HTTP 請求，清單上方顯示篩選條件，標題列中則有「匯出 CSV」選項。

匯出為 CSV 檔案

在「歷史紀錄」頁面頂端的**「匯出 CSV」**功能，會將清單以當前篩選後的狀態原樣匯出：您設定的搜尋條件及所有篩選條件均會套用至匯出檔案。檔案名稱將為history-<date>.csv，且最多包含最近的 50,000 筆事件。若您的篩選條件匹配的事件數量超過此上限，應用程式會在下載完成後通知您；請收窄篩選條件（例如僅限一種佈局或一種狀態），以便取得較早的事件。

欄位：日期（UTC）、ID、類型、狀態、佈局或請求、收件者、副本（CC）、密件副本（BCC）、主旨、錯誤及持續時間（毫秒）。欄位名稱與狀態標籤將顯示為您管理後台所設定的語言。收件者、副本 (CC)、密件副本 (BCC) 及主旨僅在電子郵件中填入。匯出內容包含「歷史紀錄」清單中顯示的項目：Shopify Flow 變數、請求主體及回應均不包含在內。

應注意的三件事

紅色「失敗」徽章表示傳送或請求未成功執行。請點開它以查看提供者的錯誤訊息。

琥珀色的「變數為空」標章表示電子郵件已送達，但一個或多個 {{ variables.x }} 佔位符渲染後呈現為空白 - - 因此收件者收到的郵件中出現了空白處。這正是過去難以察覺的錯誤：該行顯示為綠色，服務供應商已接受該訊息，而只有收件者會察覺到這個問題。

灰色「跳過」標籤表示，由於所有「收件人」均已取消訂閱您的行銷電子郵件，因此該行銷電子郵件未被發送。這並非發送失敗，不會佔用您的方案配額，也不會計入成功率。請參閱行銷電子郵件與取消訂閱。

詳細檢視

開啟一則記錄後顯示：

卡片	目錄
空變數警告	哪些佔位符未產生任何結果，以及 `Shopify Flow` 是傳回了空值還是根本未傳回任何值
未寄出：收件人已取消訂閱	顯示於「跳過」事件而非錯誤訊息中，並附有「取消訂閱」的連結
活動詳情	事件 ID、動作類型、狀態、持續時間、執行時間，以及「Shopify Flow」的執行 ID
錯誤訊息	當操作失敗時，服務提供者或 API 的實際錯誤
請求資料	已發送的內容 - - 收件者、寄件者、解析後的主旨、變數，或解析後的 HTTP 請求。以行銷電子郵件為例，`to` 代表移除已退訂地址後的收件者清單，而 `suppressed` 則顯示被移除的數量。若電子郵件附有來自元資料欄位的附件，`orderId` 或 `customerId` 會記錄是哪個訂單或客戶已閱讀該郵件。
回應資料	回傳的內容是 - - 服務提供者的訊息識別碼，還是 HTTP 狀態碼與內容？以行銷電子郵件為例，`recipients` 會列出所有收件人（To 欄位），並附上 `sent`、`failed` 或 `skipped` 的連結，以及其專屬的訊息識別碼或錯誤訊息。

標題會告訴您使用的是哪個寄件者，例如 Order email via support@acme.com (MICROSOFT)。

一封行銷電子郵件會以「每名『收件人』一則訊息」的形式發送，但在「歷史紀錄」中僅計為單一事件。當所有收件人均成功收到訊息時，該事件即為**「成功」；一旦在連續發送多則訊息後有任何一則發送失敗，該事件即被標記為「失敗」**；此時，錯誤訊息會列出未收到訊息的收件人，而「回應資料」中的 recipients 則會顯示確實收到訊息的收件人。

一則關於已發送電子郵件的歷史事件，其「事件詳情」欄位中包含狀態、持續時間以及語言（德語）等資訊 — 一則已開啟的活動：左側顯示已發送的內容，而在「活動詳情」下方則顯示狀態、持續時間以及電子郵件的發送語言。

重新發送一項操作

詳細資訊頁面設有**「重新發送」**按鈕。此功能會使用原始變數重新渲染版面配置，並透過相同的寄件者再次發送給原始收件者，或是完全按照原始發送方式重新執行 HTTP 請求。

該動作會立即執行，並計入您的計畫中的一次動作。若動作是透過備用預設發送者傳送的，則無法重新發送。

已跳過的事件沒有「重新發送」按鈕：由於原本就未曾發送，因此也沒有內容可以重新發送。待客戶重新訂閱後，請再次執行此工作流程。重新發送行銷電子郵件時，系統會再次檢查取消訂閱清單，並排除自原始發送以來已取消訂閱的任何人；若清單中無人符合條件，則會拒絕重新發送。

常見問題

**那封電子郵件從未送達，且「歷史紀錄」中完全沒有任何條目。**該動作從未執行過。問題出在 Shopify Flow，而非此處：請確認工作流程已啟用、觸發器是否已觸發，以及任何條件是否確實符合。標籤條件需完全吻合，因此 VIP 與 vip 是不同的。

**該項目顯示「變數為空」的標記。**您的佈局要求一個變數，而「Shopify Flow」動作並未提供該變數，或是提供了空值。請開啟該項目以查看具體情況。完整操作指南請參閱從 Shopify Flow 傳遞資料。

**該項目已被跳過。此佈局屬於行銷佈局，且所有「收件人」均在您的「取消訂閱」**清單中，因此應用程式並未發送該郵件。這表示取消訂閱功能運作正常。若該電子郵件是客戶必須收到的，例如訂單或運送更新，則應使用交易型佈局。請參閱行銷電子郵件與取消訂閱。

**測試電子郵件看起來沒問題，但實際發送的卻是空白。**佈局編輯器中的「測試變數」僅適用於預覽和測試發送。實際發送時，系統會使用「Shopify Flow」動作中的「變數 (JSON)」欄位，這與前者是完全不同的機制。這正是最常見的混淆來源。

**狀態顯示為「失敗」，並出現驗證錯誤。**若為 SMTP，可能是憑證或埠號有誤 - - 請開啟 SMTP 伺服器並按下「測試連線」。若為 Microsoft 365 或 Google，可能需要重新授權連線：請檢查「電子郵件寄件者」→「已連線的帳戶」，查看是否有「需要重新連線」的標記。

**一封電子郵件的內文顯示為 [object Object]。**您直接插入了整個物件。在電子郵件中，您必須透過 {{ variables.customer.firstName }} 存取該物件，或對其進行迴圈處理。只有 HTTP 請求才會自動將物件序列化為 JSON。

該郵件因檔案大小過大而被拒收。總大小超過 20 MB 的附件將被阻擋，而 Microsoft 365 會拒絕超過 4 MB 的內嵌附件。請將大型檔案切換至「連結模式」。請參閱附件與圖片。

**HTTP 請求因「SSRF blocked」而失敗。**目標位址解析為私有或內部網路位址，基於安全考量而被拒絕。請使用可從外部存取的端點。

**所有操作都同時失敗，並顯示「方案限額」訊息。**您已用盡 30 天的配額。請參閱方案與使用方式。

詢問 Sidekick

Shopify Sidekick 可以直接查詢此應用程式，且僅限讀取。這通常比手動篩選「歷史紀錄」更快：

「這週有沒有任何電子郵件傳送失敗？」
「為什麼我剛才寄出的那封電子郵件沒寄出去？」
「已設定哪些電子郵件寄件者？」
「我有針對 Airtable 的 HTTP 請求嗎？」

Sidekick 絕不會回傳機密值、SMTP 密碼、OAuth 憑證、HTTP 標頭值或原始有效載荷 - - 這些資訊需透過應用程式取得。

還是卡住了

請提交錯誤報告，並包含您的商店網域、佈局或請求名稱，以及執行時間戳記。請參閱「說明中心」中的**《回報錯誤》**。