ECサイトのKPIダッシュボード作り方｜日次・週次・月次の指標

帆布ポーチ24商品を扱い、月約1,200注文を受ける架空のEC店舗を想定します。この店舗では、運営担当者1名が数字の確認に使える時間を日次20分、週次90分、月次2時間、既存ツール以外の追加予算を月3,000円の作業枠と定めています。日々の運営で迷わないよう、ユーザー・セッション・イベント・注文という単位を区別し、数字が変わったときに誰がどこを確認するかまでを決めていきます。

何を決めるための数字を置く？

ECサイトの運営においてKPI（重要業績評価指標）とは、目標への進み具合や店舗の状態を把握し、次の行動を一つ選ぶための数字です。画面に多くの数字が並んでいても、何を確認してどう判断するかが決まっていなければ、日々の確認作業は形だけで終わってしまいます。

売上やアクセスの数字を日々の判断へ結び付けるため、確認する目的を日次・週次・月次に整理し、それぞれの数字に次の確認手順を一つ定めます。

限られた時間で運用を進めるため、最初は日次3つ、週次2つ、月次3つの合計8指標に絞り込みます。

• 日次：システム障害、発送の滞留、在庫切れといった店舗の異常を早期に見つけ、顧客対応や販売停止を判断する。
• 週次：商品閲覧から購入手続きに至る流れを比べ、変化の理由を調べる。
• 月次：販売レポート、決済残高、銀行入金、実在庫のズレを整理し、店舗運営の土台を点検する。

これは自店で何を確認するかを決めるための仮案であり、決まった万能ルールではありません。自店の運営実態に合わせて、次の判断に直結する数字を配置します。

ユーザー・セッション・イベント・注文は何が違う？

GA4とカートで取得される数値は、人の推定値、訪問のまとまり、操作の記録、取引の受付というように計測対象が異なるため、同じ件数として単純に足したり割ったりしてはいけません。それぞれの計算の分母と取得元を別欄で管理する必要があります。

まず、標準レポートの中心となる指標は「アクティブユーザー」であり、単純な利用者総数とは異なります（詳細はGoogle アナリティクスのユーザー指標を参照）。

セッションはサイトやアプリでの利用のまとまりを指します。アクティブなセッションがない状態でのページ表示などで開始され、既定では30分間操作がないと終了します。セッションは訪問の単位であり、人数でも注文数でもありません（詳細はGA4のセッションに関する公式ヘルプを参照）。

イベントは、所定の条件に応じて送信される操作や出来事の記録です。同一セッション内で同じイベントが複数回発生することもあるため、イベントの回数をそのまま人数や注文件数に読み替えることはできません（詳細はGoogle アナリティクスのイベントに関する開発者向けガイドを参照）。

さらにECの購入経路を追うには、対応するイベントやパラメータを正しく実装する必要があります。ただし、ブラウザ上で購入イベント（purchase）が送信されたとしても、それが決済完了や注文確定、出荷完了を保証するわけではありません（詳細はGA4 eコマース実装ガイドおよびGA4 eコマース購入レポートに関する公式ヘルプを参照）。

架空店の同じ7日間の集計例では、これらを別欄に記録し、分母と取得元を明記します。

• 全セッション数：4,000（GA4）
• 購入イベントが1回以上あったセッション数：120（GA4）
• 計測された取引ID（transaction_id）数：118（GA4）
• 店舗のカート管理画面で確認した注文件数：116（カート管理画面）

購入イベントがあったセッション（120）、取引ID数（118）、実際の受注数（116）の間には差異が生じます。これらは集計の単位が異なるため、重複送信や未払いといった単一の原因を決めつけず、別々の事象として並べて確かめます。

日次は、どの異常を先に見る？

日次の20分では、売上の細かな分析ではなく、受注の停止、決済の失敗、未出荷の急増、在庫切れなど、顧客対応や販売停止が必要となる異常から優先して確認します。ここでいう異常とは、前日との微小な差ではなく、処理が止まり速やかな対応を要する状態を指します。

架空店の日次確認では、カートの管理画面などで以下の3指標を点検します。

1. 決済失敗件数（未決済エラーが急増していないか）
2. 未出荷注文件数（出荷作業の滞留や出荷遅延が発生していないか）
3. 販売可能在庫ゼロのSKU数（主力商品が意図せず在庫切れになっていないか）

ここでいうSKU（Stock Keeping Unit）とは、色やサイズごとに商品を区別する在庫管理単位のことです。ポーチ24商品であっても、色や仕様の違いによってSKU数は24より多くなる場合があります。

日次の確認でアクセス解析側の数値が急減していたとしても、その画面だけで直ちにサーバー障害やサイト破損と決めつけてはいけません。まずはカート管理画面を開き、実際の注文受付が動いているか、決済エラーログが発生していないかを確かめます。

また、Shopify 販売レポート公式マニュアルに記載されているように、販売レポートの集計は注文の発生や売上取消を示すものであり、顧客との実際の資金移動そのものを追跡するものではありません。日次レポートの売上金額をそのまま当日の銀行着金額とみなして資金判断を行うことは避けてください。

原因がその場で特定できない数値の落ち込みを発見した場合は、勝手に誤差やゼロと処理せず、記録欄に「調査中」と残して確認を進めます。

週次は、購入までの流れをどう比べる？

週次の90分では、同じ期間・同じセッション条件で商品閲覧、カート追加、購入手続き開始、購入イベント発生を並べ、どこで利用者が離脱しているかを確認します。広告媒体別や端末別で比べる場合も、比率だけでなく母数となるセッション数を必ず添えます。

指標の呼び方にも注意が必要です。「購入イベントが1回以上あったセッション数 ÷ 全セッション数」で算出される数値は、「購入イベントのあるセッション率」と呼び、カート側の注文転換率と区別します。

架空店における直近7日間のセッション推移例は以下のとおりです。すべて同一セッション内で指定の順序に進んだセッション数を集計しています。

この集計において、全体の購入イベントのあるセッション率は 3.0%（120 ÷ 4,000）となります。これはセッション単位に条件をそろえた独自の説明集計であり、GA4標準のユーザー単位の経路レポートとは集計基準が異なります。

確認の際は、1セッション内で複数回発生する生のイベント回数をステップの通過人数として割らないようにします。また、あるステップの通過率が前週より変動していたとしても、直ちに特定のデザイン変更などを唯一の原因と断定せず、複数の要素を点検します。

月次は、注文・入金・在庫をどう分ける？

月次の2時間では、販売レポートの売上、決済残高、銀行入金、実在庫を別々に確認し、それぞれの差異を説明できる状態を整えます。

店舗運営において「売上＝銀行入金＝利益」ではありません。また、販売レポートの金額から送料や税、返金を一律に引けば入金額になるわけでもありません。採用する売上指標（総売上や販売合計など）によって送料や消費税がもともと含まれているかどうかが異なります。販売レポートの内訳と、決済サービス側の取引明細・決済手数料・返金・送金、そして銀行口座への実際の入金は別々に照合する必要があります。

販売レポートには売上取消は含まれますが、チャージバック（不審請求の申し立て）は含まれません。また、2026年に返品関連の指標体系が変更され、2026年5月1日以降は従来の返品指標が削除されています（詳細はShopify 販売レポート公式マニュアルを参照）。過去の数値と比較する際は、当時の定義と現在の定義を個別に確認します。

在庫についても、まずは同じ商品・場所・時点・状態における「数量同士」を確かめます。

Shopifyの月末在庫価値は、商品ごとの「アイテムあたりの費用 × 期末数量」を合計した金額です。費用は原価などであり、売価ではありません。Shopify 在庫レポートに関する公式マニュアル（2026年10月10日確認）では、2026年10月1日以降のデータは販売可能数ではなく、手元総数（On hand）を使います。注文に確保済みの在庫と販売不可の在庫も含み、未着の在庫は含みません。9月30日以前の履歴は販売可能数のままなので、月をまたいで比べるときは、この定義の違いを確かめます。管理画面の金額を税務上の棚卸評価額と同一視せず、費用単価と評価範囲をそろえて扱います。

架空店の月次確認では、以下の項目を別々に記録します。

• 店舗側で支払を確認した注文（対象月の件数と金額。後日の返金や取消は別欄で扱い、会計確定売上と分ける）
• 決済サービス内の残高（送金前の残高。取引明細と照らし合わせて確かめる）
• 追跡在庫の月末在庫価値（対象期間の数量定義と費用単価を確認）

送料や消費税の扱いを明確にし、入金待ちの残高や在庫の差異を独立した項目として把握します。

数字が動いたら、誰が何を確かめる？

指標が変動した際に調査が停滞しないよう、数字ごとに確認する画面（取得元）、担当者、確認期限、次の判断を短く定めておきます。取得元とは、その数字を確認したサービスとレポートの名称を指します。

例えば、週次の確認で購入イベントのあるセッション率が大きく低下していた場合、担当者は影響度や緊急度に応じて期限を設け、以下の順序で点検を進めます。

1. 計測の確認：直近のサイト修正やタグの変更で、計測タグの送信や反映に障害が起きていないか確認する。
2. 受注の確認：カート管理画面で実際の注文受付が止まっていないか、カート離脱エラーログが出ていないか確認する。
3. 決済の確認：決済サービスの管理画面で、システム障害や認証エラーが急増していないか速やかに確認する。

原因を広告の配信設定や商品の魅力とすぐに決めつけるのではなく、計測タグが正しく動いてデータが届いているか、システムが正常に稼働しているか、決済が受け付けられているかという客観的な障害要因から順に確かめます。

また、この画面の数字の変化だけで、原因を確かめないまま広告の停止や追加発注を判断してはいけません。見かけの数値変化だけを原因と断定せず、事実関係を確かめてから次の行動を判断します。

使わない指標を、いつ外す？

指標が増えすぎると、本来見るべき日次の異常や週次の課題が見落とされてしまいます。月に一度の月次確認の中で、ダッシュボードに置かれた指標の棚卸しを行い、必要なものだけを残します。ただし、意思決定に使わなかった運用指標を見直す作業は、帳簿付けや税務に必要な会計記録を削るものではありません。

以下のいずれかに当てはまる運用指標は、ダッシュボードから外す対象とします。

• 過去1カ月間、その数字を見て何の判断や確認も行わなかった指標
• 算出の分母や取得元、タイムゾーンなどの確認条件が曖昧になった指標
• 別の指標で十分に状況が把握でき、重複している指標

指標を管理する際は、「確認条件」を明確にそろえておく必要があります。確認条件とは、集計対象期間、タイムゾーン、計算の分母、取得元サービス、データの更新時刻のことです。もし確認条件や定義を変更した場合は、過去の推移データとそのまま並べて比較してはいけません。

架空店では、見直し後に残った指標について、「翌月もこの指標を確認する理由」を一行ずつメモとして残して運用を続けます。

---

公式仕様の確認（確認日：2026-10-09）

• GA4のセッション定義を確認する
• Shopifyの販売レポート定義を確認する

関連記事

• ECの月次締め手順｜売上・決済・在庫・広告・物流を確定する
• EC広告をROASではなく利益で管理する方法
• ECの在庫回転率と滞留在庫対策｜販売率・在庫日数の見方