觸發器如何運作

只要了解扳機採用的是這四種機制中的哪一種,幾乎就能解答所有關於時機、設定,以及為何會或不會扣動扳機的問題。

四種機制

運作機制 觸發條件 延遲 需要一個基準 配送
Shopify webhook 26 近即時 保證
Webhook + 變更偵測 52 近即時 是的 保證
民意調查 6 最多一個調查週期 是的 保證
店面像素 14 盡最大努力

1. Shopify webhook

Shopify 在事件發生的一瞬間即通知應用程式,而應用程式會將該事件直接轉發至 Shopify Flow。「**折扣建立」**與「**地點刪除」**便是以此方式運作。

這些觸發器除了權限設定外無需其他設定,且每個觸發器在「**觸發器」**頁面中都有專屬的開關。

2. Webhook 加上變更偵測

這是規模最大的群組,也正是這款應用程式的實用之處。Shopify 的 products/update webhook 會在_任何_產品編輯時觸發,但並不會說明具體的變更內容。因此,這款應用程式會:

  1. 儲存您所關注的欄位的快照
  2. 將每個傳入的 webhook 與該快照進行比對,並
  3. 僅在該特定欄位實際發生變更時,才會觸發該特定觸發器。

這就是為什麼「**產品標題變更」**會在編輯標題時觸發,但在編輯價格時卻不會觸發,即使這兩者都是透過相同的 Shopify webhook 傳遞而來。

3. 投票

Shopify 針對部落格、部落格文章、頁面、訂單顯示狀態、折扣到期日或公司所在地稅務設定,本應用程式不會發送任何 webhook。針對這 6 項觸發條件,本應用程式會依照排程進行檢查,並在偵測到差異時觸發通知。

與其他觸發器一樣,輪詢觸發器可透過「觸發器」頁面啟用。它們會消耗一個輪詢週期的延遲時間,而非立即觸發。

4. 店面像素

Shopify 不會針對購物者的行為發送任何 Webhook:例如瀏覽商品頁面、將商品加入購物車、搜尋未找到結果,或是結帳時出現錯誤。針對這 14 種觸發條件,該應用程式會在您的線上商店安裝一個 Web 像素,用以從購物者的瀏覽器回報相關事件。

由此可得出三點結論,這些特徵使這些觸發機制有別於其他三種機制:

  • **主動加入。**他們需要「Storefront 行為存取」權限,且「開始」開關已開啟 關閉。啟用一個使用該觸發器的 Flow 工作流程,即會將其開啟,這與任何觸發器一樣。該 當第一個燈開啟時,pixel 便會啟動;在所有燈都關閉時,則不會發送任何訊號。
  • **需經同意方可進入。**尚未同意分析追蹤的購物者將被移至 瀏覽器,而該事件永遠不會傳遞到我們這裡,既不產生任何成本,也不會觸發任何工作流程。
  • **盡力而為。**若因關閉分頁、連線中斷或廣告攔截程式等因素,該活動 永遠不會到達,且不會重試。請將它們用於訊號與反應,切勿用於 錯過事件將構成正確性問題。

此外,這類事件的發生頻率也遠高於管理事件。在啟用此功能之前,請先參閱 Storefront 觸發器

工作流程中會收到哪些內容

欄位層級觸發器會傳回舊值與新值,因此您可以根據變更本身進行分支處理,而無需進行後續查詢:

yaml
Old price: 19.99
New price: 24.99
SKU:       WIDGET-BLUE-M
Flow 的「新增變數」面板中顯示 oldPrice、newPrice、delta、percentChange 和 direction
傳入 `Shopify Flow` 的價格變動參數包含:價格變動前後的數值、差額、百分比以及變動方向。

清單形式的變更會以結構化物件的形式傳送,而非以逗號分隔的文字,因此您可以在 Flow 中對其進行迭代和分支處理。訂單明細變更、出版物變更以及公司據點稅務豁免皆採用此種方式處理。

排序與重複項

  • 事件會根據Shopify的事件 ID 進行去重,因此重新傳送並不會觸發您的 執行工作流程兩次。
  • 該應用程式對每間商店設有短期的速率限制,因此無法對數千項商品進行批量編輯 不會對您的工作流程造成過大負擔。事件會被排入佇列,而非被丟棄。
  • 一項修改 5,000 項產品的批次操作會產生 5,000 個事件,並消耗 5,000 您的每月配額。請參閱 方案與使用方式
  • Storefront 活動會將短時間內重複出現的相同頁面瀏覽次數進行彙總,並且 這兩個造訪觸發條件會將整個造訪過程,針對每位客戶或每家公司,彙整為單一事件。