Workflow Trigger ExtensionsWorkflow Trigger Extensions

Storefront 觸發器

此應用程式中的其他所有觸發器，皆源自於您的管理後台發生的事件：訂單已付款、產品已更新、元資料欄位已變更。Shopify 會通知我們，接著您的工作流程便會執行。

前端觸發條件源於購物者的某項操作。例如：瀏覽產品頁面、將商品加入購物車、搜尋未找到結果，或是結帳時折扣碼被拒絕。Shopify 不會針對上述任何情況發送 Webhook，因此該應用程式會透過在您的前端運行的 Web Pixel 來收集這些資料。

這個差異值得特別留意，因為它解釋了後續的大部分內容：應用程式能偵測到什麼、無法偵測到什麼，以及為什麼這些觸發條件的發生頻率會遠高於您慣常所見的。

店面像素

當您的第一個商店前端觸發器被啟用時，應用程式會自動在您的商店前端安裝一個 Web Pixel。無需編輯佈景主題，也無需貼上任何程式碼。

像素僅訂閱您已啟用觸發器所需的事件。若您僅啟用「店鋪搜尋」而未啟用其他功能，則產品瀏覽次數將不會被發送、接收或計數。若將所有店鋪觸發器重新關閉，像素雖仍安裝在系統中，但處於閒置狀態：它既未訂閱任何事件，也不會發送任何資料。

購物者同意

此像素會遵守貴商店的客戶隱私設定。它需要分析同意，且 Shopify 僅會針對已給予該同意的購物者執行此像素。若未獲得同意，瀏覽器中將不會收集任何資料、不會有任何資料傳送至我們、不會消耗任何配額，也不會執行任何工作流程。

這在結帳時同樣適用，因此「顯示結帳錯誤」和「結帳折扣碼遭拒」需要與商店前端觸發條件相同的同意權限。

這也意味著，在採用「主動同意」模式的地區，店鋪觸發器會按設計預設低報數據。這是正確的運作行為，並非需要繞過的問題。

Pass consent from your own banner to Shopifyjavascript
window.Shopify.loadFeatures(
  [{ name: "consent-tracking-api", version: "0.1" }],
  (error) => {
    if (error) return;
    // Call this when the shopper makes a choice in your banner.
    // Pass what they actually chose - storefront triggers need analytics.
    window.Shopify.customerPrivacy.setTrackingConsent(
      { analytics: true, marketing: false, preferences: false },
      () => {},
    );
  },
);

Shopify

測試商店前端觸發器時，請先接受 Cookie 提示，並使用未安裝廣告攔截器的瀏覽器。無需同意，系統每次都會自動開啟私密視窗，因此即使在一般瀏覽器中能正常運作的觸發器，在私密視窗中可能會看似無法運作。若要確認像素本身是否已安裝，請在 Shopify 管理後台中開啟**「設定」>「客戶事件」**。

觸發因素

觸發器 開始於
商店櫥窗中瀏覽過的商品 一位購物者開啟了產品頁面
已瀏覽的店鋪精選系列 一位購物者開啟了一個收藏頁面
商店首頁 已瀏覽的購物車 一位購物者開啟購物車頁面
商店商品已加入購物車 商品已加入購物車
商店商品已從購物車中移除 已將一項商品從購物車中移除
店鋪結帳程序已開始 一位顧客開始結帳
店鋪搜尋 搜尋結果至少有一項
Storefront 搜尋未找到任何結果 搜尋結果為空
已瀏覽缺貨款式 一名購物者正在瀏覽某商品頁面，該頁面顯示的款式已售罄
顯示結帳錯誤 結帳時向顧客顯示錯誤訊息
結帳時折扣碼遭拒絕 結帳時折扣代碼被拒絕
B2B 買家曾造訪 一位已登入的 B2B 買家造訪了該商店
已登入的顧客曾造訪 一位已登入的顧客造訪實體店面
自訂店面觸發器 您自己的活動，由您的佈景主題發佈

已瀏覽缺貨的款式

這一點值得仔細閱讀，因為這是最有可能與其名稱所暗示的行為不符的觸發器。

這是一個補貨需求訊號：它告訴您，有位真實的顧客瀏覽了您無法向其銷售的商品。若搭配 Flow 工作流程使用，即可對該商品進行標記、通知採購部門，或將該顧客加入候補名單。

這是推算出來的，並非直接回報的。由於購物者的瀏覽器並不知道您的庫存狀況，因此追蹤像素會傳送一個普通的商品瀏覽記錄，而應用程式則會根據自身的庫存紀錄來進行判斷。

它檢查的是變體，而非整個產品▾

此觸發器會針對產品頁面目前顯示的變體觸發，而非針對產品整體。若某產品有四個現貨變體和一個售罄變體，則僅當顯示的正是該售罄變體時，才會觸發此觸發器。

這就是為什麼它被稱為「已瀏覽缺貨變體」，也是為什麼此觸發器會同時將變體及其所屬的產品傳遞給您的工作流程。

無法偵測到頁面載入後變更版本的情況▾

Shopify 當購物者進入該頁面時，系統會記錄一次產品瀏覽。隨後點擊變體選擇器屬於頁面內的狀態變更，而非新的頁面瀏覽，因此 Shopify 不會記錄此操作，應用程式也永遠不會得知此事。

實際運作情況如下：若直接點擊已售罄款式的連結（例如 ?variant= 格式的網址，或從該款式為顯示選項的系列頁面進入），則會觸發此功能；但若先進入有庫存的預設款式頁面，再選擇已售罄款式，則不會觸發。

若您有此需求，請在主題中透過 {% doc "custom-storefront-triggers" %} 函式，於變體變更時發佈您自己的事件。

「缺貨」表示所有據點的庫存皆為零或少於零▾

該應用程式會將所有備有該變體商品的據點之庫存數量相加。當總數為零或低於零時，觸發機制便會啟動。

有兩項後果值得預先規劃：

  • **即使某些地點未為您的線上商店提供服務，這些地點的庫存仍會被計入。**儲存在倉庫或非該產品銷售管道之零售據點的庫存，會使總庫存量看起來相當充裕，因此即使購物者無法購買該商品，觸發機制也不會被觸發。
  • **系統不會將「超賣」納入考量。**若某款商品設定為「缺貨時仍繼續販售」，則該商品仍可設定為零價販售，因此觸發條件會被觸發，而購物者實際上仍可完成訂單。
啟用此功能也會同時啟用「Storefront 產品瀏覽紀錄」▾

這勢必如此。缺貨的判斷是基於產品檢視所做出的，因此應用程式必須接收每一筆產品檢視，才能找出其中少數關鍵的項目。

這意味著每筆產品瀏覽都會計入您的配額，而不僅僅是缺貨的商品。在流量高的商店中，這是該應用程式中最昂貴的單一觸發因素，而其成本取決於您的流量，而非商品售罄的頻率。

我們刻意凸顯依賴關係，而非將其隱藏，因此您在使用量頁面所看到的數字絕不會令您感到意外。

必須先同步過庫存資料▾

該應用程式會與其自身的庫存紀錄進行比對。如果某個變體從未同步過，應用程式便無法得知其庫存數量，此時它會保持靜默，而非進行推測 - - 將未同步的變體標示為「售罄」，其後果將比完全不顯示任何資訊更為嚴重。

啟用觸發器後，庫存資料會自動同步。您隨時可從「觸發器」頁面重新執行此操作。

搜尋

搜尋會提供兩個觸發器，而單次搜尋會精確地觸發其中一個：

  • 當搜尋未找到任何結果時**，Storefront 搜尋會顯示「無結果」**。這正是大多數商店最想要的功能：它列出了顧客預期您會販售的商品清單。
  • 當搜尋結果出現時**，Storefront 的搜尋功能**。

由於這兩項功能互不衝突，您可以放心同時啟用兩者，而不會造成重複計數。Storefront Search 還會將第一個搜尋結果作為商品參考，因此工作流程可以根據購物者最有可能看到的內容進行處理。

造訪觸發條件

**「B2B 買家造訪」**與「**已登入顧客造訪」**功能會在已登入的購物者造訪您的商店時觸發。這些功能可協助您針對顧客回訪做出相應反應 - - 例如重新建立互動、發送客戶經理通知，或在紀錄中添加備註。

一位瀏覽了十頁的購物者算作一次造訪，而非十次事件。該應用程式會將重複次數歸納到您透過開關旁的設定圖示，針對每個觸發條件所選擇的「造訪」時間窗內。在此時間窗內，該購物者僅計為一次。

  • 「B2B 買家造訪次數」會按公司進行彙總，因此同一視窗中來自同一公司的兩位買家，將被計為一次造訪。
  • 「已登入客戶造訪」的數據會按每位客戶進行捲起顯示。

將該數值設為零，即可在每次頁面瀏覽時觸發事件。對於有登入用戶流量的商店而言，這會產生大量事件，因此建議先設定較高數值，若需更細緻的控制，再逐步調低。

結帳觸發器

**「結帳錯誤顯示」**會在結帳頁面向顧客顯示錯誤時觸發：例如地址無法驗證、付款遭拒，或是某個欄位無法接受輸入的內容。這是一種無需等待技術支援工單，即可得知結帳流程出錯的方式。

**「結帳時折扣代碼遭拒」**將問題範圍縮小至一種情況：結帳時系統拒絕了折扣代碼。這通常是因促銷活動已過期、代碼分享次數超出限制，或是來自電子郵件但從未啟用的代碼 - - 這些都是值得盡快了解的情況。

Shopify 此機制不會告知應用程式輸入的是哪組代碼，因此觸發訊息會傳遞「Shopify」的拒絕訊息（以購物者的語言顯示），但不會包含代碼本身。若在欄位為空的情況下點擊「套用」，也會顯示相同的訊息，因此兩者無法區分。請利用此功能來察覺被拒絕代碼的增加趨勢，而非用來識別特定的行銷活動。

下一步