EC事業は、データ活用の成果が売上に直結する数少ない業態です。購買履歴を分析してLTVを最大化し、在庫を最適化して欠品と過剰を減らし、顧客の行動履歴から次のマーケティング施策を設計する――これらすべてが、土台となるデータ基盤の出来不出来で決まります。本記事では、EC事業のデータ基盤設計を購買・在庫・顧客の3つのデータドメインを軸に整理し、リアルタイム在庫連携と顧客360°ビュー構築の具体策まで掘り下げて解説します。ShopifyやBASEなどのSaaSから独自ECまで、規模を問わず応用できる設計パターンをまとめました。
EC事業におけるデータ基盤の役割
EC事業のデータ基盤が担う役割は、大きく分けて3つあります。第一に売上・受注・在庫の「事業の現況」を正確に把握すること。第二に購買履歴から顧客のLTVやコホートを分析し、マーケティング施策の精度を上げること。第三に商品・在庫の需要予測と仕入れ最適化により、キャッシュフローを改善することです。これらは単独のツールでは実現できず、複数のデータソースを横断的に統合してはじめて成立します。
EC事業特有の課題は、データソースの多さと更新頻度の違いです。受注は秒単位で更新される一方、商品マスタは日次で十分、会員データはリアルタイムに近い更新が求められる――このようにデータごとに「鮮度要件」が異なります。単一のETLで全て賄おうとすると破綻するため、データ種別ごとにインジェスト方式を分ける設計が必要です。また、モール型（楽天・Amazon）と自社EC（Shopify等）のマルチチャネル運用では、データ構造が媒体ごとに異なる問題にも向き合わねばなりません。
ECデータの全体像
まずはEC事業で扱う主要データソースを俯瞰しましょう。データの種別・更新頻度・活用用途を一覧にすると、優先順位が見えてきます。
| データソース | データ種別 | 更新頻度 | 主な活用用途 |
|---|---|---|---|
| EC本体(Shopify等) | 受注、会員、商品マスタ | リアルタイム〜15分 | 売上分析、LTV算出、在庫連携 |
| 在庫管理システム | 在庫数、入出荷履歴 | 15分〜1時間 | 欠品検知、需要予測 |
| 広告プラットフォーム | インプレッション、CV | 日次〜1時間 | ROAS分析、媒体別評価 |
| Webアクセスログ | 閲覧履歴、検索キーワード | ニアリアルタイム | 行動分析、レコメンド |
| CRM/メール配信 | 配信履歴、開封率 | 日次 | 顧客セグメント、効果測定 |
| カスタマーサポート | 問い合わせ内容、CS評価 | 日次 | CX分析、顧客満足度 |
これらのデータを取り込み、統合・変換し、活用するまでの流れを図解で整理します。
【ECデータフロー全体図】
[EC本体] [在庫管理] [広告API] [Webログ] [CRM]
| | | | |
v v v v v
+---------+ +----------+ +---------+ +--------+ +---------+
| Fivetran| | Airbyte | | Fivetran| | Segment| |Airbyte |
| / CDC | | | | | |/SDK | | |
+----+----+ +----+-----+ +----+----+ +---+----+ +----+----+
| | | | |
v v v v v
+----------------------------------------+
| Raw Layer(BigQuery/Snowflake) |
+-------------------+----------------------+
|
v
+----------------------+
| Staging / dbt変換 |
+----------+-----------+
|
v
+----------------------------------------+
| Mart Layer(売上・LTV・顧客360°) |
+-------------------+----------------------+
|
+---------+---------+---------+---------+
v v v v v
[BI/Metabase][Looker][Reverse ETL][MLモデル][経営レポート]
※ インジェスト層はSaaS(Fivetran/Airbyte)で統一し、変換はdbtに集約する。この構成の利点は、パイプライン設計パターンが単純で、運用負荷が低いことです。ETLの自作は最小限にとどめ、可能な限りマネージドのインジェストツールで吸い上げて、変換層で統合する設計が主流です。詳細な設計思想はパイプライン設計パターンとCDCとはも併せてご参照ください。
購買データの統合モデリング
ECデータ基盤の中核となるのが、受注（注文）ファクトテーブルです。全ての売上分析・LTV分析・コホート分析の起点になるため、スキーマ設計は慎重に行います。一般的な設計方針は、受注明細（Line Item）単位を最小粒度とし、ヘッダー情報（注文日・会員ID・配送先など）を結合したワイドテーブルとして整備するアプローチです。
-- 受注ファクトテーブル定義（BigQuery）
CREATE OR REPLACE TABLE mart.fct_order_items (
order_item_id STRING NOT NULL,
order_id STRING NOT NULL,
order_datetime TIMESTAMP NOT NULL,
customer_id STRING,
product_id STRING NOT NULL,
quantity INT64 NOT NULL,
unit_price NUMERIC(12, 2),
discount_amount NUMERIC(12, 2),
tax_amount NUMERIC(12, 2),
channel STRING, -- ec_site, rakuten, amazon など
is_first_purchase BOOL,
_loaded_at TIMESTAMP NOT NULL
)
PARTITION BY DATE(order_datetime)
CLUSTER BY customer_id, product_id;設計のポイントは4つです。第一に、order_datetimeでのパーティション化により分析時のスキャン範囲を限定しコストを抑えること。第二に、customer_id/product_idでのクラスタリングで絞り込みクエリを高速化すること。第三に、channel列を必ず持ち自社ECとモールを同じテーブルで比較可能にすること。第四に、初回購入フラグ(is_first_purchase)を事前計算しておくことで、新規顧客分析のクエリを簡潔にできる点です。データモデリングの全般的な考え方はデータモデリングの記事でも詳しく扱っています。
リアルタイム在庫連携の設計
在庫データのインジェストは、EC基盤で最も悩ましい領域の一つです。「全てリアルタイムにすれば良い」わけではなく、用途に応じて適切な鮮度を選ぶのが現実解です。バッチとリアルタイムの特性を比較しておきましょう。
| 観点 | バッチ処理(日次/時次) | リアルタイム/ストリーミング |
|---|---|---|
| 遅延 | 数時間〜1日 | 数秒〜数分 |
| 実装コスト | 低(Fivetran/dbt で済む) | 高(Kafka+Flink等) |
| 運用負荷 | 低 | 中〜高 |
| インフラコスト | 低 | 中〜高 |
| 適するユースケース | 売上レポート、需要予測 | 欠品アラート、動的プライシング |
| 適さないユースケース | マルチチャネル在庫の即時同期 | 日次の経営ダッシュボード |
マルチチャネル販売(自社EC+楽天+Amazon)を行う場合は、在庫の即時同期がほぼ必須です。在庫切れによる機会損失と過剰在庫のバランスをリアルタイムで最適化できるかどうかで、粗利率が数ポイント変わります。この場合はKafkaを中心としたストリーミング基盤を導入し、在庫変動イベントを各チャネルに配信する設計が推奨です。一方、売上レポートや需要予測は日次バッチで十分。全てをリアルタイム化するとコストが跳ね上がるだけでなく、運用が複雑になり失敗しやすくなります。
顧客360°ビューの構築
EC事業における顧客360°ビューとは、一人の顧客に関する全情報（購買履歴・Web行動・CRM反応・問い合わせ履歴など）を一つの顧客IDで統合した状態を指します。これを作ることで、LTV分析・セグメント配信・パーソナライズレコメンドが一つのデータソースから実行できるようになります。
構築のステップは、(1)顧客IDの名寄せ、(2)各データソースと顧客IDの紐付け、(3)顧客属性テーブルの集約、の3段階です。特に難しいのがステップ1の名寄せで、非会員購買（ゲスト購入）、複数メールアドレス、モールと自社ECの別IDなどを一つのマスターIDに統合する処理が必要になります。名寄せロジックはビジネスルールに依存するため、データチームと事業部門の共同設計が欠かせません。
ステップ3の顧客属性テーブルは、顧客一人につき一行のワイドテーブルで、累計購買金額・初回購買日・直近購買日・平均購入間隔・お気に入りカテゴリなどをあらかじめ計算した「customer_features」として整備します。dbtでインクリメンタルに更新するのが定番パターンです。このテーブルがあれば、マーケティング担当者は複雑なJOINを書かずに、顧客セグメントの抽出やレコメンドモデルの特徴量生成ができるようになります。Reverse ETLでCRM・広告プラットフォームに配信することで、マーケティング施策の実行まで自動化できます。
EC特有の分析ユースケース
EC事業のデータ基盤が整ったら、取り組むべき分析テーマは山ほどあります。重要度順に挙げると、まずはRFM分析とコホート分析でLTVの実態を掴むこと。次にチャネル別貢献度分析(自社ECと各モールの利益率比較)、次にセール時の価格弾力性分析、そして離脱予兆検知と復活施策の効果測定が続きます。
最近トレンドとして定着しつつあるのが、購買履歴とWeb行動を組み合わせた「購買前行動分析」です。購入に至った顧客と離脱した顧客の閲覧パターンを比較することで、プロダクトページの改善ポイントやカート放棄の原因を特定できます。これには商品詳細ページの閲覧時間、カート投入履歴、検索キーワードなどの詳細なイベントトラッキングが必要になるため、データ基盤の設計段階で「将来の分析要件」を想定して生ログを保持しておくことが重要です。また、小売データ基盤の事例も参考になります。
まとめ
EC事業のデータ基盤設計は、購買・在庫・顧客の3ドメインの統合がゴールです。受注ファクトテーブルを中核に据え、在庫はバッチとリアルタイムを使い分け、顧客360°ビューでマーケティングと接続する――この流れを押さえれば、スモールスタートから段階的に成長させられます。SaaS型ビジネス向けの基盤と違う点や共通点は、SaaSデータ基盤やスタートアップのデータ基盤の記事も参考にしてください。
よくある質問
EC事業でデータ基盤に最初に取り込むべきデータは?
受注データと顧客データです。この2つでLTV分析・コホート分析・RFM分析が可能になり、マーケティング投資の最適化に直結します。Web行動ログや広告データは、受注データで事業の現況を把握できるようになってから追加するのが効率的です。
リアルタイム在庫連携は必要ですか?
マルチチャネル販売(自社EC+モール)を行う場合は必要です。在庫切れによる機会損失と過剰在庫のバランスをリアルタイムで最適化できるため粗利率の改善に効きます。単一チャネルのみであれば、日次〜時次のバッチ連携でも十分です。
ECデータ基盤の構築にどのくらいの期間がかかりますか?
MVP(受注分析ダッシュボード)まで2〜3ヶ月、顧客360°ビュー構築まで6ヶ月程度が目安です。チームメンバーが2〜3名確保できれば、この範囲内で実現可能です。リアルタイム在庫連携までフルスコープで含める場合は、さらに3〜6ヶ月追加で見込んでください。