【ITニュース解説】Calculate average order value from Shopify orders with the Admin GraphQL API

ECサイト運営において、Average Order Value（AOV）、つまり「平均注文額」は、ビジネスの健全性を測る上で欠かせない指標だ。AOVは総売上を注文数で割ることで算出され、顧客が一度の注文で平均いくら使っているかを示す。この値が高いほど効率的な売上向上に繋がるが、Shopifyから得られる生データには、正確なAOV計算を妨げる「落とし穴」が存在する。具体的には、テスト注文、キャンセルされた注文、返金、送料、税金などが含まれてしまうと、実際のビジネス状況と異なるAOVが算出されかねない。本稿では、ShopifyのAdmin GraphQL APIを利用して注文データを取得し、Node.jsというプログラミング環境でこれらの落とし穴を回避しつつ、正確なAOVを計算する方法について解説する。システムエンジニアを目指す方にとって、APIの利用方法やデータ処理の基本的な考え方を学ぶ良い機会となるだろう。

このデータ分析を行うには、Shopifyストア（試行錯誤には開発ストアが安全）、Admin APIアクセストークンを持つカスタムアプリ、そしてNode.js 18以降の環境が必要だ。カスタムアプリにはread_ordersスコープ（過去60日間）または承認済みのread_all_ordersスコープ（全履歴）が必要となる。APIトークンはセキュリティのため、ソースコードに直接書かずに環境変数として管理することが重要である。

まず、Shopifyから注文データを取得するために「GraphQLクエリ」を作成する。GraphQLは、必要なデータ項目を効率的に指定して取得できるAPI技術だ。このクエリでは、ordersフィールドを使って注文データを要求し、first: 250で一度に取得する件数を指定する。after: $cursorは、データが大量にある場合に、次のページのデータを取得するための「ページネーション」という仕組みで使われる目印だ。query: $queryには、created_at:>=${from} created_at:<${to}のように、注文の作成日による期間指定などの検索条件を指定する。

取得するデータ項目には、id（注文識別子）、test（テスト注文かどうか）、cancelledAt（キャンセル日時）が含まれる。これらは後で、AOV計算から除外すべき注文を特定するために使用する。金額に関する項目としては、currentTotalPriceSetとcurrentSubtotalPriceSetが重要だ。currentTotalPriceSetは送料や税金を含む注文の合計金額で、返金や返品があった場合でも、その情報が反映された「現在の」合計額を提供する。一方、currentSubtotalPriceSetは、送料や税金を含まず、割引適用後の商品小計金額を指し、こちらも返金が反映済みだ。これらの「current」と付くフィールドを使用することで、返金が自動的に考慮され、正確なAOV計算が可能になる。

次に、Node.jsスクリプトによるデータ取得とAOV計算の具体的な流れを説明する。スクリプトは、API通信、注文データ取得、AOV計算の三つの主要な部分から構成される。

まず、環境変数からShopifyストアのURL、Admin APIアクセストークン、APIバージョンを読み込む。graphqlという非同期関数を定義し、ShopifyのGraphQL APIエンドポイントへfetch関数を使ってHTTP POSTリクエストを送信する。リクエストヘッダーには認証のためにX-Shopify-Access-Tokenを設定し、ボディにはGraphQLクエリと変数をJSON形式で含める。APIからの応答にエラーがなければ、注文データが返される。

次にgetOrdersという非同期関数は、指定された開始日から終了日までのすべての注文を取得する。Shopify APIのデータ取得上限に対応するため、whileループとGraphQLのページネーション機能を利用する。graphql関数を繰り返し呼び出し、pageInfo.hasNextPageがtrueである限り次のページのデータをendCursorを使って要求し続け、すべての注文データをorders配列に収集する。

そして、AOVを計算するaov関数が中核を担う。この関数では、まず取得したorders配列の中から、filterメソッドを使ってテスト注文（o.testがtrue）とキャンセルされた注文（o.cancelledAtが存在）を除外する。これにより、AOV計算に含めるべき「リアルな」注文のみが抽出される。リアルな注文が一つもない場合はnullを返す。次に、reduceメソッドを使って、抽出されたリアルな注文の合計金額を算出する。ここでの特徴は、2種類のAOVを計算することだ。一つはaovTotalで、これはcurrentTotalPriceSet（送料・税金込み）に基づき、顧客が実際に支払った金額を反映する。もう一つはaovProductsで、currentSubtotalPriceSet（商品小計のみ）に基づき、送料や税金の変動に影響されず、アップセルやバンドル効果の測定に適している。それぞれの合計金額をリアルな注文数で割ることで、AOVが算出される。最終的に、注文数、通貨、およびこれら2つのAOVを含むオブジェクトが結果として返される。

AOV計算における注意点、いわゆる「トラップ」について再度強調する。テスト注文とキャンセル注文の除外は必須だ。返金・返品はcurrent...PriceSetを使うことで自動的に反映されるため便利だが、もし別の初期金額フィールドを使う場合は手動で調整が必要となる。また、非常に高額な大口注文などの「外れ値」が一つでもあると、平均値が大きく変動し、実態を反映しなくなる可能性がある。このような場合、平均値だけでなく「中央値」も合わせて確認することで、より正確なビジネス状況を把握できる。複数通貨で販売しているストアでは、通貨ごとにAOVを計算し、異なる通貨の金額を混合しないよう注意が必要だ。比較を行う際には、必ず同じ期間長に揃え、セール期間や祝日といったイベントがAOVに与える影響も考慮すべきである。

AOVは単独で全てを判断する指標ではない。例えば、AOVが上がっても、コンバージョン率が下がれば総売上は伸び悩む可能性がある。そのため、AOVは「コンバージョン率」「1日あたりの注文数」「利益率」といった他のビジネス指標と常に組み合わせて分析することが重要だ。これにより、AOVの変化がビジネス全体にどのような影響を与えているかを正確に理解し、より効果的な戦略を立てるための具体的な根拠を得られる。AOVを単に測定するだけでなく、それをどのように向上させるかという視点を持つことが、ECビジネスの成長には不可欠である。