定義
データウェアハウス（DWH）とは、複数のソースシステムからデータを抽出・変換・統合し、分析やレポーティングのために時系列で蓄積する集中型のデータ基盤です。DTC・EC業界では、ShopifyやAmazon、楽天、Instagram広告、Klaviyo、Shopify POS、在庫管理システム（WMS）など、バラバラのチャネルから発生するデータを1か所に集約する役割を担います。
トランザクション処理用のデータベース（OLTP）が「今この瞬間の注文処理」を担うのに対し、DWHは「過去3年間のLTV推移」「チャネル別CAC」「コホート別リピート率」といった横断的・歴史的な問いに答えるために設計されています。
たとえるなら「EC企業の中央図書館」
各チャネル（Shopify、Amazon、Meta広告、メルマガ）はそれぞれ独自の「日記」をつけています。Shopifyは注文を、Metaはインプレッションを、Klaviyoは開封率を記録します。しかし日記はバラバラで、同じ顧客がどのチャネルから来て、どの商品を買い、その後どれだけLTVを生んだかは誰にもわかりません。
DWHは、これら全チャネルの日記を同じ顧客IDで名寄せし、時系列で並べ直して保管する中央図書館です。司書（ELT/ETLパイプライン）が毎晩データを整理し、アナリストやBIツールが自由に蔵書を引き出せる状態にします。
公式・基本構造
DWHのデータ量と鮮度は次の式で見積もります。
年間データ量 = 日次イベント数 × 365 × 1レコード平均サイズ
具体例：
- 日次イベント数：120,000件（セッション＋注文＋メール開封＋広告クリック）
- 1レコード平均サイズ：2.5KB
- 年間データ量 = 120,000 × 365 × 2.5KB ≒ 約109GB/年
さらにスター・スキーマの結合コストは：
クエリコスト ∝ ファクトテーブル行数 × ディメンション結合数
例：ファクト8,400万行（3年分注文明細）× ディメンション6個（顧客・商品・日付・チャネル・キャンペーン・地域）＝ スキャン対象は実質数億セル。ここにクラウドDWHの従量課金（BigQueryで$6.25/TBスキャン等）が効いてきます。
比較表：DWH vs データレイク vs OLTP
| 観点 | データウェアハウス | データレイク | OLTP（本番DB） |
|---|---|---|---|
| 主目的 | 分析・BI・レポート | 生データの長期保管 | 注文処理・在庫更新 |
| スキーマ | 書き込み時に定義（Schema-on-Write） | 読み込み時に定義（Schema-on-Read） | 厳格に正規化 |
| データ形式 | 構造化（テーブル） | 構造化・半構造化・非構造化 | 構造化 |
| 典型ツール | BigQuery, Snowflake, Redshift | S3, GCS, Databricks Lakehouse | MySQL, PostgreSQL |
| 更新頻度 | バッチ〜準リアルタイム | 任意 | ミリ秒単位 |
| DTCでの用途 | LTV/CAC分析、コホート、RFM | 生ログ・クリックストリーム保管 | カート・決済処理 |
| クエリ速度 | 秒〜分（大規模集計） | 分〜時間 | ミリ秒（単一レコード） |
DTC・ECでの具体的な活用シーン
1. チャネル別CACとLTVの突合
Meta・Google・TikTok・インフルエンサーの広告費を、Shopifyの注文データと顧客IDで結合。初回購入CACと12か月LTVをチャネル別に算出し、予算配分を最適化します。
2. RFMセグメントとKlaviyo連携
Recency（最終購入日）・Frequency（購入回数）・Monetary（累計購入額）をDWHで計算し、優良顧客セグメントをKlaviyoへ書き戻してセグメント配信。リピート率が平均18%→27%に改善した事例も一般的です。
3. 在庫回転と欠品損失の可視化
WMS・Shopify・広告データを統合し、SKU別の在庫回転日数と広告経由の欠品損失を同時に把握。欠品による逸失売上が月商の3〜5%に達するケースも珍しくありません。
4. コホート別リテンション分析
初回購入月ごとに顧客をグループ化し、3か月後・6か月後・12か月後の継続購入率を追跡。サブスクECではM3リテンション65%以上が健全性の目安とされます。
よくある誤解・落とし穴
- 「DWHさえ作れば分析できる」 → 実は最大の工数は名寄せ（同一顧客のID統合）とデータ品質管理です。顧客IDの紐付け精度が低いとLTVが過小評価されます。
- 「リアルタイムでなくては意味がない」 → DTCの意思決定の大半は日次〜週次で十分。準リアルタイム要件は在庫や不正検知など限定的です。
- 「データレイクで代替できる」 → 生データを貯めるだけでは、BIツールから高速に集計できません。DWH層でのモデリングが不可欠です。
- 「コストはストレージが支配する」 → 実際はクエリ課金が支配的。パーティション分割とクラスタリングでスキャン量を最大90%削減できます。
- 「一度作れば終わり」 → チャネル追加・KPI変更のたびにスキーマ進化が必要。dbt等でのバージョン管理が推奨されます。
関連用語
- ETL / ELT：DWHへのデータ取り込み方式。近年はELTが主流。
- データマート：DWH内の部門別サブセット（マーケ用、経営用など）。
- スター・スキーマ：ファクト＋ディメンションの標準モデリング。
- dbt（data build tool）：DWH内の変換をSQLで管理するツール。
- CDP：顧客データを統合しマーケ施策に直結させる基盤。DWHと補完関係。
- BIツール：Looker Studio、Tableau、Metabaseなど。DWHの可視化層。
- Reverse ETL：DWHの分析結果をKlaviyoやCRMへ書き戻す仕組み。
DWHは「作って終わり」のプロジェクトではなく、DTCのグロースを支える継続的な分析基盤です。まずはShopify＋広告＋メールの3ソースを顧客IDで結合するところから始めると、投資対効果を早期に実感できます。