Workflow Trigger ExtensionsWorkflow Trigger Extensions

Storefront 触发器

该应用中的其他所有触发器都源于管理后台发生的一些事件：订单已付款、产品已更新、元字段已更改。Shopify 会通知我们，随后您的工作流便会运行。

前端触发器源于购物者的某项操作。例如：浏览了商品页面、将商品加入购物车、搜索未找到结果、结账时优惠码被拒绝等。Shopify 不会针对上述任何情况发送 webhook，因此该应用会通过在您的前端运行的 Web Pixel 来收集这些数据。

这一区别值得留意，因为它解释了后续内容的大部分：该应用能检测到什么、无法检测到什么，以及为什么这些触发事件的数量可能会远高于你习惯看到的数量。

店面像素

当您的第一个网店触发器被开启时，该应用会自动在您的网店中安装一个 Web Pixel。无需编辑主题，也无需粘贴任何代码。

像素仅订阅您已启用的触发器所需的事件。如果您仅启用了“店面搜索”而未启用其他功能，则产品浏览事件将不会被发送、接收或计数。如果再次关闭所有店面触发器，像素虽然仍会保留在系统中，但处于闲置状态：它不会订阅任何事件，也不会发送任何数据。

购物者同意

该像素会遵守您店铺的客户隐私设置。它需要获得分析同意，且Shopify仅会在已获得该同意的购物者身上运行该像素。若未获得同意，浏览器中不会收集任何数据，也不会向我们传输任何信息，不会消耗任何配额，也不会触发任何工作流。

这在结账时同样适用，因此“显示结账错误”和“结账优惠码被拒”需要与前端触发器相同的同意权限。

这也意味着，在采用“主动同意”模式的地区，Storefront 触发器会按设计要求低报数据。这是正确的行为，而不是需要绕过的错误。

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 管理员后台中打开**“设置”>“客户事件”**。

触发条件

触发器 从……开始
网店已浏览商品 一位购物者打开了一个商品页面
已查看的“店面”系列 一位购物者打开了一个收藏页面
已浏览的网店购物车 一位购物者打开了购物车页面
网店商品已加入购物车 商品已加入购物车
网店商品已从购物车中移除 购物车中的一件商品已被移除
实体店结账已开始 一位顾客开始结账
店铺搜索 搜索返回至少一个结果
商店搜索未找到任何结果 搜索结果为空
已查看缺货的变体 一位购物者正在浏览一个商品页面，该页面上显示的该商品变体已售罄
显示的结账错误 结账时向顾客显示了错误信息
结账时折扣码被拒绝 结账时优惠码被拒绝
B2B买家到访 一位已登录的B2B买家访问了该网店
已登录客户曾访问过 一位已登录的顾客光临了实体店
自定义商店前端触发器 您自己的活动，由您的主题发布

已查看缺货的变体

这一条值得仔细阅读，因为这是最有可能与名称所暗示的行为不符的触发器。

这是一个补货需求信号：它表明有真正的顾客浏览了您无法向其销售的商品。结合 Flow 工作流，该功能可以对商品进行标记、通知采购部门，或将该顾客加入候补名单。

这是推算得出的，并非直接报告的数据。由于购物者的浏览器并不知道您的库存情况，因此像素会发送一个普通的产品浏览记录，而应用程序则会根据自身的库存记录进行判断。

它检查的是一个变体，而不是整个产品▾

该触发器针对产品页面上显示的变体触发，而非针对产品整体。如果一个产品有四个有货的变体和一个售罄的变体，则只有当显示的是那个售罄的变体时，触发器才会被触发。

这就是为什么它被称为“已查看缺货变体”，也是为什么该触发器会同时向您的工作流提供该变体及其所属的产品。

无法检测到页面加载后切换变体的情况▾

Shopify 当购物者进入页面时，系统会报告一次产品浏览。随后点击变体选择器属于页面内部的状态变更，而非新的页面浏览，因此Shopify不会报告该操作，应用程序也无法获知该情况。

实际操作中：直接链接到已售罄款式的链接（即以 ?variant= 开头的 URL，或从该款式作为展示选项的系列页面跳转而来）会触发该功能。而先进入有库存的默认款式页面，再选择已售罄款式的操作则不会触发该功能。

如果你需要这个功能，可以在主题中通过 {% doc "custom-storefront-triggers" %} 在变体发生变化时发布自己的事件。

“缺货”是指所有门店的库存均为零或低于零▾

该应用会将所有库存该商品变体的门店的可用数量相加。当该总数为零或低于零时，触发器就会被触发。

有两点后果值得提前规划：

  • **即使某些地点不面向您的网店供货，这些库存仍会被计入。**存放在仓库或零售网点（这些地点并非该产品的销售渠道）的库存会使总库存看起来充足，因此即使顾客无法购买该商品，触发条件也不会被激活。
  • **不会考虑超卖情况。**设置为“缺货时继续销售”的变体仍可按零价格购买，因此触发器会触发，而买家实际上仍可完成订单。
启用该功能还会同时启用“Storefront 已查看商品”功能▾

必须如此。缺货决策是基于商品视图做出的，因此该应用必须接收每一个商品视图，才能从中找出那几个关键的。

这意味着每次产品浏览都会计入您的配额，而不仅仅是缺货的产品。对于流量较大的店铺而言，这是该应用中成本最高的单一触发项，其成本取决于您的流量，而非商品售罄的频率。

我们刻意突出依赖关系，而非将其隐藏，这样您在使用页面上看到的数字就不会让您感到意外。

库存必须已同步▾

该应用会将其库存记录与自身数据进行比对。如果某个变体从未同步过，应用就无法得知其库存水平，此时它会保持静默，而不是进行猜测 - - 将未同步的变体报告为“售罄”比不报告任何信息还要糟糕。

启用该触发器后，库存会自动同步。您可以随时从“触发器”页面重新运行该触发器。

搜索

搜索会触发两个触发器，而单次搜索只会触发其中一个：

  • 当搜索未找到任何结果时**，Storefront 搜索会显示“无结果”**。这正是大多数商家所希望的：它列出了购物者预期您会销售的商品。
  • 当搜索结果存在时**，Storefront 的搜索功能**。

由于它们是互斥的，因此您可以放心同时启用这两项功能，而无需担心重复计数。Storefront Search 还会将第一个搜索结果作为商品引用保存下来，因此工作流可以针对购物者最有可能看到的商品采取相应操作。

访问触发器

“B2B 买家到访”和**“已登录客户到访**”会在已登录的购物者访问您的网店时触发。这些功能可用于响应客户的回访 - - 例如重新互动、向客户经理发送提醒，或在客户记录中添加备注。

一位顾客浏览十页算作一次访问，而非十次事件。该应用会将重复访问合并到一个**“访问”窗口**中，您可以通过开关旁边的设置图标，针对每个触发条件选择该窗口的范围。在此窗口内，该顾客仅计为一次。

  • “B2B 买家访问量”按公司进行汇总，因此同一窗口内来自同一公司的两名买家计为一次访问。
  • “已登录客户访问”数据按每位客户进行汇总。

将该参数设置为零，即可在每次页面浏览时触发事件。对于有已登录用户的商店而言，这会产生大量事件，因此建议先设置较高的阈值，如果需要更精细的控制，再逐步降低该值。

结账触发器

**“结账错误显示”**会在结账流程向顾客显示错误时触发：例如地址无法验证、支付被拒、或某个字段无法接受所输入的内容。这是在无需等待支持工单的情况下，发现结账失败的一种方式。

**“结账时折扣码被拒”**将问题范围缩小到一种情况：结账时系统拒绝了折扣码。这通常是由于促销活动已过期、折扣码被超额分享，或者来自一封从未激活过的电子邮件中的折扣码 - - 这些情况都值得尽快了解。

Shopify 该功能不会向应用程序透露输入了哪个代码，因此触发信息中包含Shopify的拒绝提示（以购物者的语言显示），但不包含代码本身。当字段为空时点击“应用”也会显示相同的提示，因此无法区分这两种情况。请利用此功能来发现被拒绝的代码数量是否增加，而非用于识别具体的营销活动。

下一步