「Get analytics data」 ShopifyQL で分析データを取りに行ける Flow アクション

図解 ： Shopify Flow「Get analytics data」アクション（ShopifyQL でデータ取得） Shopify Flow / 新アクション 「Get analytics data」 ShopifyQL で分析データを取りに行ける Flow アクション ワークフローの中から ShopifyQL を投げて、売上・セッション・在庫を取得。返ってきた値は変数として、後段の条件分岐やアクションに連携できる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： ワークフロー実行の流れ 公式が挙げる4つのユースケース例 従来 vs 新アクションの比較 ShopifyQL のイメージ 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか Shopify Flow に「 Get analytics data 」という新しいアクションが追加された。 ワークフローの途中で ShopifyQL を実行 → 結果を変数として取得 → そのまま条件分岐や次のアクションに使える。 従来 ： Flow は「イベント駆動」のみ 注文発生・在庫変動などのトリガーに反応する形しかなく、「ストア全体の集計値」を見ながら判断するのが難しかった。 これから ： Flow から分析を「取りに行ける」 ShopifyQL クエリ結果を変数化。閾値判定 → Slack 通知／タグ付け／管理者通知 まで一気通貫で組める。 2 仕組み図解 ： ワークフロー実行の流れ ポイント ： Flow ＝ 「イベントが起きたら何かする」だけのものから、「ストア全体の 状態 を見て判断する」エンジンに進化。Scheduled trigger と組み合わせれば、毎朝・毎週の 定期レポーティング BOT をノーコードで作れる。 3 公式が挙げる4つのユースケース例 1. Slack に定期レポート 分析データを含むレポートを Slack に自動配信。 2. 売上が閾値を下回ったらアラート 指定した金額より売上が下回った瞬間に通知。 3. マイルストーン到達で商品にタグ 「ベストセラー」など販売実績ベースの自動タグ付け。 4. セッションの増減を検知して通知 ストアフロントのトラフィック異常を即座に把握。 4 従来 vs 新アクションの比較 項目 従来の Flow Get analytics data 追加後 データ取得方法 イベント駆動 注文・在庫変動などの差分のみ クエリ駆動 ShopifyQL で集計値を能動的に取得 扱えるデータ そのイベントのオブジェクトに付随する情報 売上／セッション／在庫レベル など分析データ 後続処理での利用 イベント変数のみ クエリ結果を変数として 条件・アクションで利用可 定期実行レポート 外部ツール（BigQuery／Looker 等）で別に構築 Flow 内完結 Scheduled trigger と組み合わせ 閾値アラート Shopify 単独では実装困難 クエリ結果を Condition に渡すだけ 5 ShopifyQL のイメージ ※ クエリ構文の詳細は元記事に記載なし。ShopifyQL は SQL ライクな Shopify 専用のクエリ言語で、以下は一般的なイメージ。 -- 直近 7 日間の総売上を取得（イメージ） FROM sales SHOW total_sales SINCE -7d UNTIL today ↓ Flow がこの結果を変数に保持し、後続ステップで参照 // Condition step if result.total_sales < 1000000 { sendSlackMessage ( "⚠️ 売上が閾値を下回りました" ) } 具体的なクエリ書式・取得可能なフィールド一覧・制限事項（limitations）は 公式ドキュメントを参照 と元記事に明記。利用前に必ずドキュメントで確認すること。 6 技術者が押さえるべき5つのポイント 1. ShopifyQL がワークフロー内で発火する これまで Shopify QL Notebooks や Admin UI でしか叩けなかったクエリを、Flow ステップとして実行可能になった。クエリ結果は 後続ステップで変数として再利用 できる。 2. Scheduled trigger との合わせ技が本命 「毎日朝 9 時に売上クエリ → Slack」「毎週月曜にセッション集計 → メール」など、 定期実行 × 分析データ × 通知 の 3 段組みがノーコードで成立する。 3. 制限事項はドキュメント必読 元記事は「limitations を含めドキュメントを参照」とのみ明記。実行頻度・クエリ複雑度・返却行数などの制約は 記載なし ＝ 設計前にドキュメント確認が必須。 4. 外部 BI / ETL を置き換える可能性 「閾値アラートのためだけに BigQuery／Looker を運用していた」用途は、Flow 内に巻き取れる可能性が高い。 BI 基盤の役割再定義 のきっかけになる。 5. 「マイルストーンでタグ付け」が地味に強力 公式例の「販売数達成で商品にタグ」は、 商品コレクションの自動編成・自動バッジ表示・自動値下げ など他 Flow と連鎖させる起点になる。タグを best-seller-100 のようにマイルストーン単位で振っておけば、Liquid / Online Store エディタ側からも参照できる。 7 業務に活かせる3つのユースケース USE CASE 1 朝会用「Shopify 日次サマリ BOT」を Flow 一本で構築 課題 毎朝の社内ミーティング前に売上／セッション／在庫を手動でスクショして共有している。担当不在の日は欠落する。 打ち手 Scheduled trigger（毎日 8:50）→ Get analytics data（前日の売上・セッション・低在庫 SKU 数を取得）→ Slack の #commerce-daily に投稿。 効果 担当の作業時間ゼロ化／共有抜け解消／全員が同じ数字を朝に見られる。 技術メモ Slack 通知は既存 Flow アクションでそのまま使える。クエリ結果の差し込みはテンプレ変数で対応。 USE CASE 2 セール期間の「売上急落」を 1 時間以内に検知 課題 大型セール中の決済エラー・配送設定ミス・商品 OOS による売上急落に、翌朝の社内レポートで気付いて手遅れになる。 打ち手 Scheduled trigger（1 時間ごと）→ Get analytics data で直近 1h の sales 取得 → 同曜日同時刻の過去平均と比較 → 一定割合下回ったら Slack ＋ 担当者へ電話アラート（外部 Webhook 経由）。 効果 機会損失の最小化／障害検知 MTTD 短縮／セール期の安心感が段違いに上がる。 技術メモ 過去平均値の比較は Flow 内では難しい場合、外部 Webhook 連携で判定する設計もアリ。クエリ実行頻度の上限は要ドキュメント確認。 USE CASE 3 「販売数マイルストーン」で商品ページを自動演出 課題 「累計 100 個販売」「累計 1,000 個販売」のような社会的証明バッジを、商品ごとに手動で設定／剥がしする運用が破綻している。 打ち手 Scheduled trigger（日次）→ Get analytics data で各商品の累計販売数を取得 → 閾値ごとに milestone-100 ／ milestone-1000 タグを自動付与 → Online Store 側 Liquid でタグに応じたバッジ／コピーを出し分け。 効果 マーケのコピー運用工数ゼロ／常に最新の販売実績がページに反映／コンバージョン押し上げの A/B 仮説検証に転用可能。 技術メモ 商品単位での反復処理が必要 ＝ Flow のループ／条件設計に依存する。タグ命名規則を先に決めて Liquid 側の参照ロジックを確定させる順序が安全。 8 提案で使える1行サマリ 「Shopify Flow が ShopifyQL を叩けるエンジン に進化。 売上・セッション・在庫を 定期実行 → 閾値判定 → 通知／タグ付け までノーコードで一気通貫。 BI ツールに頼っていた “閾値アラート” と “定期レポート BOT” は、これで Shopify 内に巻き取れる。」 source ： changelog.shopify.com / flow-new-action-to-get-analytics-data-using-shopifyql 公開日 ： 2026-05-09 ／ generated 2026-05-23