プランと利用方法
「Free」、「Starter」、「Grow」、「Unlimited」の各プラン、30日間のローリング利用枠、トリガーイベントの定義、80%および100%到達時の上限アラート、および利用量を削減する方法について。
「Workflow Trigger Extensions」は無料でインストールできます。有料プランでは、過去30日間のイベント利用上限が引き上げられます。
プラン
| プラン | 価格 | 30日あたりのトリガーイベント数 |
|---|---|---|
| 無料 | $0 | 5,000 |
| スターター | 25ドル | 25,000 |
| 成長する | 50ドル | 75,000 |
| 無制限 | 100ドル | 無制限 |
**すべてのプラン(無料プランを含みます)で、すべてのトリガーをご利用いただけます。**プランの違いは利用量のみです。
この手当は、30日間の移動期間に基づいています
「現在の使用量」とは、過去30日間にこのアプリがトリガーしたイベントの数を指します。これは暦月ではなく、リセット日もありません。各イベントはトリガーされてからちょうど30日後にカウントが停止し、その日の時点で、その分の利用枠が再び利用可能になります。
これは、利用状況が集中して発生する場合に重要になります。ある月の30日に行われた一括編集は、翌月の最初の数週間にもカウントされるため、「ホーム」画面に表示される利用状況は、1日以降に実際に発生した利用量よりも多くなる場合があります。1日が対象期間から外れると、その日に発生したイベント数分だけ、トリガーが自動的に再開されます。
何が「イベント」に該当するのか
このアプリのトリガーが発動し、Shopify Flowにデータが送信されるたびに、1回のイベントとしてカウントされます。
- Shopifyや他のアプリからのトリガーはカウントされません。このアプリからの トリガーは割り当てを消費します。
- 検出されたものの、有効になっているトリガーに一致しない変更は、カウントされません。
- 型指定されたメタフィールドのトリガー(注文、商品、商品バリエーション、および顧客メタフィールド) (更新)汎用の「**メタフィールド更新」**トリガーで単一のイベントを共有するため、それらは 重複してカウントしないようにしてください。
- ストアフロントのトリガーは、他のイベントと同様にカウントされます。つまり、 米国。購入者が分析に関する同意を拒否したため、ブラウザでイベントが記録されなかったことは一度もありませんでした。 当社にご連絡いただき、決して数に入れないでください。「**在庫切れのバリエーションの閲覧数」**を算出するには、すべての商品閲覧数が その役割を果たすため、これを有効にすると、すべての商品閲覧がカウントされます。ストアフロントのトリガー をご覧ください。

上限アラート
このアプリでは、使用量が割り当ての80%を超えたときと、**100%**に達したときにメールが届きます。通知の受信者や80%の閾値は、アプリの通知設定で変更可能です。閾値は50%から99%の間で自由に設定できます。
各アラートは、暦月ごとに1回送信されます。プランを変更すると、アラートは新しい上限値に基づいて再設定されます。「Unlimited」プランをご利用のお客様には、上限に関するメールは一切送信されません。
100%になるとどうなるのでしょうか
割り当てが使い切られると、30日間の期間から十分な数のイベントが除外されるか、アップグレードを行うまで、トリガーの実行は停止します。設定内容は一切変更されません。設定、権限、ワークフローはすべて保持され、割り当てが再び利用可能になった瞬間に、トリガーの実行は自動的に再開されます。
これは、元に戻すことができないため、正確に理解しておく価値があります:
- **何も再実行されることはありません。**処理待ちのタスクもありません。処理中に変更された注文については、 上限を超えていた場合、アップグレードしても発動しません。
- **「イベント履歴」では、このギャップは表示されません。**ブロックされたイベントは、履歴行として記録されることはありません。 ですから、後で振り返って、見逃してしまったものがあるかどうかを確認することはできません。
- **変更検出は、それとは関係なく実行されます。**フィールドレベルのトリガーの場合、アプリは依然として トリガーが作動しなかった場合でも、新しい値を基準値として記録します。その後、 アップグレードの際、次の変更点は、その新しい値と比較されるため、見落とされた変更点は 後で再び表示されることはありません。ただし、1つの例外があります。それは、バリエーションのトリガー(価格、SKU、バーコード)の場合です。 (および単価)、古いイベントが30日間の期間を過ぎることで、割り当て枠が空き始める場合 アップグレードによるものではなく、制限を超えていた間に実施されたバリエーションの変更が、 その製品の次回のアップデート時に、一度だけ報告されることになります。
具体例です。現在「Free (5,000)」プランをご利用中で、20日に上限に達した場合:
- 22日に、お客様が注文の配送先住所を変更されました。注文の配送先住所 「Changed」イベントが発火せず、そのイベント自体がなくなっています。
- 23日に「スターター」プランにアップグレードされます。トリガーは直ちに再開されます。
- 24日に、誰かがその注文の配送先住所を再度編集しました。これにより、通常通り処理が実行され、 22日の住所と照らし合わせてみます。
22日の変更は、ステップ2でも、それ以降のどの時点でも、決して反映されません。
使用量を抑える
予想以上にリソースを消費している場合、その原因は、ほぼ間違いなく、編集のたびに発動する広範囲な... Updateトリガーのいずれか、あるいはアクセスが集中しているストアのストアフロントトリガーによるものです:
- **「Home」**を開き、トリガーごとの内訳をご確認ください。
- **「トリガー」**ページを開き、
... Updateという広範なトリガーを無効にしてください。 ワークフローでは使用されません。 - トリガーは広範囲のものより、範囲が狭いものをお選びください。「**商品バリエーションの価格変更」は、**はるかに遠くまで発動します。 **「製品アップデート」**よりも頻度は低いです。
- **「ストアフロントで閲覧された商品」**および「**在庫切れのバリエーションが閲覧された」**を、以下の場合にのみ有効にする それらを必要とするワークフローです。アクセス数の多いストアでは、これらが最も発生頻度の高いトリガーとなります アプリ内で。
- 数千件のレコードに影響を与える一括インポートや在庫同期を行う前に、 レコードごとに1回ずつ発動し、その後再び有効にするトリガーです。在庫 トリガーは、バリエーションやロケーションが変更されるたびに1回ずつ発動するため、ストック同期では全体を 1日あたりの無料利用枠です。
