Workflow Trigger ExtensionsWorkflow Trigger Extensions

ストアフロントのトリガー

このアプリのその他のトリガーはすべて、管理画面で発生した事象（注文の支払い完了、商品の更新、メタフィールドの変更など）をきっかけとして起動します。Shopifyがそれを通知すると、ワークフローが実行されます。

ストアフロントのトリガーは、買い物客の行動をきっかけとして発生します。商品ページの閲覧、カートへの商品追加、検索で結果が出なかった場合、チェックアウト時に割引コードが拒否された場合などです。ShopifyはこれらのいずれについてもWebhookを送信しないため、アプリはストアフロント上で動作するWeb Pixelを使用してこれらの情報を収集します。

この違いは覚えておく価値があります。なぜなら、この違いこそが、これから説明する内容のほとんど――アプリが認識できるものとできないもの、そしてなぜこれらのトリガーが、皆さんが慣れ親しんでいるものよりもはるかに多くの量になるのか――を説明してくれるからです。

「ストアフロント・ピクセル」

最初のストアフロントトリガーがオンになると、アプリが自動的にストアフロントにWebピクセルをインストールします。テーマの編集やコードの貼り付けは一切必要ありません。

ピクセルは、有効にしたトリガーに必要なイベントのみを購読します。Storefront Search のみを有効にし、それ以外は何も有効にしない場合、商品閲覧数は送信されず、受信されず、集計されることもありません。すべてのストアフロントトリガーを再び無効にすると、ピクセルはインストールされたままですが、非アクティブ状態になります。つまり、いかなるイベントも購読せず、何も送信しません。

購入者の同意

このピクセルは、貴店の顧客プライバシー設定を尊重します。分析機能の利用には同意が必要であり、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

ストアフロントトリガーをテストする際は、まずクッキーバナーに同意し、広告ブロッカーを無効にしたブラウザを使用してください。プライベートウィンドウでは毎回同意なしに開かれるため、通常のブラウザでは正常に動作するトリガーでも、そこでは動作しないように見えることがあります。ピクセル自体が正しくインストールされているかを確認するには、Shopifyの管理画面で**「設定」＞「顧客イベント」**を開いてください。

トリガー

トリガー 開始時刻は
ストアフロントで閲覧された商品 買い物客が商品ページを開く
「Storefront」コレクションの閲覧履歴 買い物客がコレクションページを開く
ストアのカートが表示されました 買い物客がカートページを開く
店舗の商品がカートに追加されました 商品がカートに追加されました
ストアの商品がカートから削除されました カートから商品が削除されました
オンラインストアでの決済が開始されました 買い物客が会計手続きを開始する
店舗検索 検索の結果、少なくとも1件がヒットします
ストアフロント検索で結果が見つかりませんでした 検索しても何もヒットしない
在庫切れのバリエーションを閲覧しました ある買い物客が、表示されているバリエーションが売り切れとなっている商品ページを見ている
チェックアウトエラーが表示されました チェックアウト時に、購入者にエラーが表示される
決済時の割引コードが拒否されました 決済時に割引コードが受け付けられません
B2Bのバイヤーが来訪 ログイン済みのB2Bバイヤーがストアフロントにアクセスする
ログイン済みのお客様が訪問しました ログイン済みの顧客が店舗を訪れる
カスタムストアフロントトリガー テーマから公開された、あなた自身のイベント

在庫切れのバリエーションが閲覧されました

このトリガーは、その名前が示唆する動作とは異なる振る舞いをする可能性が最も高いため、注意深く読む価値があります。

これは再入荷のシグナルです。つまり、実際の買い物客が、現在販売できない商品を閲覧したことを示しています。Flowのワークフローと組み合わせることで、その商品にタグを付けたり、購買部門に通知したり、その買い物客をウェイティングリストに登録したりすることができます。

これは報告されたものではなく、推定されたものです。購入者のブラウザは、貴社の在庫状況を把握していないため、ピクセルは単純な商品閲覧情報を送信し、アプリ側が自社の在庫記録に基づいて判断を行います。

製品全体ではなく、そのバリエーションを確認します▾

このトリガーは、商品ページに表示されているバリエーションに対して発動し、商品全体に対して発動するわけではありません。在庫ありのバリエーションが4つ、売り切れのバリエーションが1つある商品の場合、売り切れのバリエーションが表示されているときにのみトリガーが発動します。

そのため、この機能は「在庫切れのバリエーションの閲覧」と呼ばれており、このトリガーによってワークフローには、そのバリエーションと、それが属する商品の両方が渡されるのです。

ページの読み込み後にバリアントを切り替えたことは検出されません▾

Shopify 買い物客がページにアクセスした際、商品ビューとして集計されます。その後、バリエーションピッカーをクリックして移動することは、ページ内での状態変化であり、新しいページビューではないため、Shopifyではこれを集計せず、アプリ側ではその事実を認識しません。

実際の動作としては、売り切れのバリエーションに直接リンクされている場合（?variant=形式のURL、またはその商品が表示されているコレクションからアクセスした場合など）はトリガーされます。在庫のあるデフォルト商品に遷移してから、売り切れの商品を選択した場合はトリガーされません。

それが必要な場合は、テーマのカスタムストアフロントのトリガーを使用して、バリアントが変更された際に独自のイベントを発行してください。

「在庫切れ」とは、すべての拠点での在庫数がゼロまたはそれ以下であることを意味します。▾

このアプリは、そのバリエーションを在庫している各店舗の在庫数を合計します。その合計がゼロ以下になると、トリガーが作動します。

事前に計画を立てておくべき2つの結果：

  • **オンラインストアで販売していない店舗も集計対象となります。**倉庫や、その商品の販売チャネルではない小売店舗に在庫があるだけで、総在庫数が良好に見えるため、購入者がその商品を購入できないにもかかわらず、トリガーは作動しません。
  • **オーバーセリングは考慮されません。**在庫切れになっても販売を継続するように設定されたバリエーションは、価格が0の状態で依然として購入可能であるため、購入者が実際に注文を完了できる間、トリガーが発動します。
これを有効にすると、「Storefront Product Viewed」も有効になります▾

そうせざるを得ない。在庫切れの判断は商品ビューに基づいて行われるため、アプリは重要な数件の商品ビューを特定するために、すべての商品ビューを受け取る必要がある。

つまり、在庫切れの商品だけでなく、すべての商品閲覧数が利用枠にカウントされるということです。アクセス数の多いストアでは、これがアプリ内で最もコストのかかる要因であり、そのコストはアクセス数によって決まるもので、在庫切れになる頻度によるものではありません。

依存関係を隠すのではなく、あえて明示的に示すことで、利用状況ページに表示される数値が予期せぬものにならないようにしています。

在庫が同期済みである必要があります▾

このアプリは、自身の在庫記録と照合を行います。あるバリエーションが一度も同期されたことがない場合、アプリはその在庫数を把握できないため、推測するのではなく何も表示しません。同期されていないバリエーションを「売り切れ」と表示してしまうことは、何も表示しないよりもさらに悪い結果を招くからです。

トリガーを有効にすると、在庫は自動的に同期されます。「トリガー」ページからいつでも再実行できます。

検索

検索では 2 つのトリガーが提供され、1 回の検索でそのうち正確に 1 つが実行されます：

  • **Storefront Searchでは、**検索結果が見つからない場合、「結果なし」と表示されます。これは多くの店舗が求めている機能であり、買い物客が店舗で販売しているものと期待していた商品のリストが表示されます。
  • 検索で結果が見つかった場合のストアフロント検索。

これらは互いに排他的であるため、重複カウントの心配なく両方を安全に有効にできます。また、Storefront Search は最初の検索結果を商品リファレンスとして保持するため、ワークフローでは、買い物客が最も目にしたと思われる結果に基づいて処理を行うことができます。

訪問トリガー

**「B2Bバイヤーによる訪問」**および「**ログイン済み顧客による訪問」**は、ログイン済みの買い物客が貴社のストアフロントにアクセスした際に発生します。これらは、顧客が再訪した際に取るべき対応（再エンゲージメント、アカウントマネージャーへの通知、記録へのメモなど）を行うための指標となります。

10ページを閲覧した買い物客は、1回の訪問とみなされ、10回のイベントとはみなされません。このアプリでは、繰り返しを「訪問」として集計し、スイッチの横にある設定アイコンからトリガーごとに選択した期間内にまとめます。その期間内での買い物客の閲覧は、1回としてカウントされます。

  • 「B2Bバイヤーの訪問数」は企業ごとに集計されるため、1つのウィンドウ内で同じ企業からのバイヤーが2名いた場合、それは1回の訪問としてカウントされます。
  • **「ログイン済み顧客による訪問」は、**顧客ごとに集計されます。

この値をゼロに設定すると、ページビューごとにイベントが発生します。ログイン済みのユーザーによるトラフィックが多いストアでは、これによりイベント数が非常に多くなるため、最初は高い値に設定し、より細かい粒度が必要な場合は徐々に下げていくことをお勧めします。

チェックアウトのトリガー

「チェックアウトエラーの表示」は、チェックアウト時に購入者にエラーが表示された際（住所の検証に失敗した場合、支払いが拒否された場合、入力内容がフィールドに受け入れられなかった場合など）に発火します。これは、サポートチケットを待つことなく、チェックアウトが失敗していることを把握するための方法です。

「チェックアウト時の割引コードが拒否されました」というメッセージは、その原因を1つのケースに絞り込みます。つまり、チェックアウト時に割引コードが拒否されたということです。これは通常、キャンペーンの有効期限が切れている、利用制限を超えてコードが共有されている、あるいはメールで送信されたコードが一度も有効化されていないといったケースが考えられます。これらはいずれも、速やかに把握しておくべき事項です。

Shopify アプリにはどのコードが入力されたかは通知されないため、トリガーにはShopifyの拒否メッセージ（購入者の言語で表示）が含まれますが、コード自体は含まれません。フィールドが空の状態で「適用」をクリックしても同じメッセージが表示されるため、両者を区別することはできません。この機能は、拒否されたコードの増加を把握するために使用し、特定のキャンペーンを特定するために使用しないでください。

今後の手順