「自社ECとモールの売上を横断で見たいが、粗利まで揃えようとすると毎月Excelで力技になる」。そんな相談を月に何件かいただきます。
モールごとに管理画面もCSVの形も違い、手数料・値引き・ポイント原資の扱いもバラバラです。楽天・Amazon・自社ECを単純合算しただけの数字は経営判断に使いにくく、SKU別粗利やチャネル別LTVまで出そうとすると、名寄せや広告費の突合で手が止まります。
そこで本記事では、EC・D2Cのデータ統合を進める判断軸と実現アプローチを、EC事業責任者・情シスの担当者がそのまま稟議に使える形で整理しました。データ基盤構築の費用の内訳はすでにデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説で扱っているので、こちらはモール横断特有の難しさと、進め方の判断に軸足を置いています。
EC・D2Cで売上データの統合が特に大変なのは、他業種と比べても「販売チャネルの数」と「データの出方の差」が噛み合わないからです。まず、この構造から見ていきます。
図のように、EC・D2Cの経営指標を正確に把握するには、次のデータを突き合わせる必要があります。
これが1商品ぶん、1日ぶんです。SKUが1,000点あり、4モール展開していれば、単純計算で1日4,000通りのデータをすり合わせる必要があります。ここがEC・D2C特有の「チャネル×商品×日次の掛け算のつらさ」です。
さらに厄介なのが、次の3点です。
モールごとに手数料・値引き・ポイントの扱いが違うのがECの特徴です。楽天は月額固定＋ロイヤリティ＋広告費、Amazonはカテゴリ別販売手数料＋FBA手数料、Yahoo!はストアポイントとPayPayポイントの原資負担、自社ECは決済手数料と送料負担がそれぞれ違います。純粋な「モール別粗利率」を出すには、これらを注文単位で控除して計算する層が必要です。管理画面の「売上」を単純合算しただけでは、実態と大きくズレます。
同じ顧客が別モールで別IDになるのも見落としやすいポイントです。楽天とAmazonでは購入者情報が一部マスクされ、メールアドレスもモール中継アドレスが渡ってきます。自社ECの顧客と同一人物かの名寄せは、名前・電話番号・住所での確率マッチが必要で、簡単ではありません。ここが揃わないと、真のLTVもリピート率も出せません。
在庫がリアルタイムで動くという制約もあります。同じSKUが4モールに引き当てられていて、どこかで注文が入ると即座に他モールの表示在庫を減らさないと、売り越しや欠品が発生します。この在庫連動と、事後の売上・粗利分析を同じ基盤で扱えるかどうかで、運用の難易度が変わります。
こうした構造があるため、モール数が増えるほど集計と経営判断はスケールせず、SKU別粗利もチャネル別LTVも「なんとなく」でしか語れなくなります。データ基盤の全体像そのものを押さえたい方は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説を先に読んでいただくと、この記事の話がより具体的に感じ取れます。
「うちはまだExcelとネクストエンジンで回せている」と言うEC責任者は多いのですが、じわじわとひずみが出ているケースがほとんどです。次の3つのサインで、統合検討の時期を判断できます。
これが最もはっきりした判断基準です。EC事業部の担当者や経理が、モール別CSVのダウンロードと粗利計算だけで月20時間以上使っているなら、人件費換算で月6万〜10万円分の工数が集計に消えています。年商10億円規模で4モール展開のD2Cだと月30〜50時間、年商30億円規模だと月60時間以上に達するのが実務での実感です。
この工数は、モール数×SKU数×キャンペーン頻度で比例して増えます。手を動かす作業を減らさない限り、新商品開発や広告運用の改善にリソースを回せません。
「Shopifyの管理画面上は売上30%増だが、値引きと広告費を引いた粗利がいくらかは月末までわからない」「楽天のスーパーセール期間中は売上急伸するが、ロイヤリティとポイント原資を引くと実は赤字だった」という声はEC事業でよく聞きます。
原因は、モールの手数料構造・広告費・値引き・送料負担が別々の場所にあり、注文単位で1つに寄せるロジックが誰の頭の中にもないためです。「粗利率が正確に出せない」まま次のキャンペーンや新規モール出店を決めるのは、EC事業のリスクとして最も大きい部類に入ります。
自社ECのShopifyに登録した顧客が、次は楽天でリピート購入した。あるいはAmazonで初回購入した顧客が、2回目からは自社ECに移った。こうした動きが追えないと、真のLTVも、顧客獲得コスト（CAC）の回収期間も計算できません。
「Google広告経由のLTVがMeta広告経由の1.5倍」といった媒体別LTV差も、注文データと広告データを紐付けないと出せません。ここが出せないと、広告予算の配分は「昨日のCPAが低かった媒体」に流れがちで、長期の投資効率は改善しません。
3つのうち2つ以上に当てはまれば、データ統合を検討するフェーズに入っています。逆に、モールが1〜2社に絞られていてSKU数も100点以下なら、モール一元管理SaaSと標準レポートでしばらく戦えます。業種横断でのExcel限界サインについては、小売の小売・多店舗のPOSデータを本部に統合する方法｜2026年版、リユース業のリユース業の値付け・相場調べをデータ化する方法｜2026年版にも近い構造で整理しています。
「統合」といっても、実現手段はいくつかあります。EC・D2Cでよく検討されるのは、次の3つです。それぞれ狙う範囲と費用感がまったく違います。
ネクストエンジン、GoQSystem、クロスモール、TEMPOSTARといった受注・在庫の一元管理SaaSを使う方法です。日次の受注取り込み、在庫連動、出荷指示までを1画面で回すのが本来の役割で、基本的なモール別売上レポートも用意されています。
弱点は、SKU別粗利率・チャネル別LTV・広告データとの突合など、経営分析の深いところは基本的に範囲外なことです。将来的にCACとLTVを比較したり、SKUごとの利益率で品揃えを判断したいなら、別途データ基盤が必要になります。多くのD2C企業は、日次オペレーションはネクストエンジン、経営分析はBigQuery、という2階建てで運用しています。
各モールから日次で受注・広告CSVをダウンロードし、Google Driveやスプレッドシートに集約して、Looker StudioやTableauで可視化する方法です。BIツールの月額は数千円〜と安く、既存のExcel運用に近い形で始められます。
弱点は、SKU数×日数が数万行を超えるとスプレッドシートのパフォーマンスが落ちること、そしてスプレッドシートの管理が属人化しやすいことです。特にD2Cで新商品リリースの頻度が高い企業では、マスタ整備の追いつきが遅れて数字がずれていく現象が起きがちです。BI選定はPower BI・Tableau・Looker比較｜5軸の違いと選び方【2026年版】にまとめています。
自社EC・モール・広告・在庫・会員データを本部のクラウドDWH（BigQuery・Snowflake・Redshift）に自動集約し、dbtで統合モデル（注文・商品・顧客）に変換し、BIで可視化する方法です。もっとも柔軟で、SKU別粗利・チャネル別LTV・広告ROAS・需要予測までカバーできます。
費用は3アプローチで最も高く見えますが、年商10億円を超えるD2Cでは、集計工数の削減と広告投資効率の改善で1〜2年で投資回収するのが実務での目安です。データ基盤構築の見積もりの内訳はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でくわしく整理しています。GA4のデータをBigQueryにExportして分析基盤に組み込む具体的な手順はGA4のBigQueryエクスポート・活用ガイド｜手順・料金・実務SQLを参考にしてください。
3つのアプローチの選び方は、将来LTV分析・広告最適化・需要予測まで載せる可能性があるかどうかで決めるのが後悔の少ない判断です。日次オペレーションだけを楽にしたいならアプローチ1で十分。SKU別粗利と広告ROIまで見たいならアプローチ2、経営分析で継続的にPDCAを回すならアプローチ3を最初から選ぶほうが総額を抑えられます。
「初期400万円」と聞くと大きく感じますが、Excel運用と経営判断の遅れで払っている見えないコストと比べると、判断は変わります。
EC事業部の担当者が月40時間をモール別CSV集計と粗利計算に使っているとします。人件費を時給換算で3,500〜4,500円とすると、月14万〜18万円相当の工数が集計だけに消えている計算です。年間にすると170万〜220万円。3年で500万〜660万円になります。
さらに、経理や情シスも締め処理や月次レポート作成で月10〜20時間を使っているとすれば、あわせて年間で300万〜500万円が「モール横断の数字を作る」ためだけに発生していることになります。
加えて、EC・D2Cのデータ統合には人件費削減以外に、経営判断のROI改善というインパクトがあります。
これらは営業利益率で1〜3ポイントの改善につながり、400万〜1,200万円の初期投資は年商10億円規模のD2Cなら1年以内、年商5億円規模でも2年以内で回収できるレンジです。
内製と外注のどちらで進めるかは、データ基盤は内製と外注どっち？判断基準とハイブリッドの進め方で判断軸を整理しています。EC・D2Cの場合、社内にデータエンジニアがいることは稀なので、モールAPIとECドメインの知識を持つ外部パートナーと組んで立ち上げ、運用に入ってから内製に移すハイブリッド型が現実的です。
具体的なイメージを持てるように、Evastが実際に構築した事例を紹介します。
年商約12億円、自社EC＋楽天＋Amazon＋Yahoo!の4モールで展開するアパレルD2CのG社では、EC責任者と経理担当が毎月80時間かけて各モールCSVを突き合わせ、Excelで粗利表を作る運用が続いていました。売上速報は日次で出せるものの、広告費と値引きを控除した真の粗利は月次締め後にしか出せず、SKU絞り込みの判断が常に1か月遅れていました。会員リピートも自社ECのShopify内でしか追えず、楽天で買った顧客が2回目に自社ECに来ているかは不明のままでした。
Evastが構築したのは、Google Cloud上のD2Cデータ基盤です。おおまかな構成は次のとおりです。
構築期間は約3か月、使ったスタックはBigQuery・dbt・Fivetran・Cloud Functions・Cloud Storage・Looker Studio・Terraform・GitHub Actionsが中心です。GA4のBigQueryエクスポートを活用した実装ノウハウはGA4のBigQueryエクスポート・活用ガイド｜手順・料金・実務SQLにまとめています。
成果としては、モール横断集計にかかっていた月40時間がほぼゼロになりました。データは毎日自動で更新され、日次でSKU別粗利率とモール別ROASを確認できるようになっています。
さらに、真の粗利で見たSKUランキングをもとに定番と季節商品の在庫配分を見直した結果、全社の粗利率が約2ポイント改善、LTVの高いチャネル（自社ECリピーター）への広告予算配分を強化したことで、CAC回収期間が180日から120日に短縮しました。月次締めも翌月10日から翌月3日に早まり、経営会議のリズムそのものが変わっています。
「EC×データ基盤×多モール」の類似構造は、実店舗を持つ小売チェーンでも起こります。実店舗中心の小売・多店舗のPOSデータを本部に統合する方法｜2026年版、一点物と日次相場が動くリユース業での進め方はリユース業の値付け・相場調べをデータ化する方法｜2026年版も参考になります。
EC・D2Cのデータ統合は、いきなり全モール・全システム・全指標を対象にすると要件が膨らんで頓挫します。最初の運用開始までを4〜8週間に区切ったスモールスタートで進めるのが、実務では失敗しにくい進め方です。
ここで欲張らないことが最大のコツです。最初は「モール別粗利率を日次で出す」を1つ自動化する、と決め打ちします。
この段階でデータの品質チェック（欠損・重複・異常値・返品差額）まで組み込んでおくと、後戻りが少なくなります。データパイプラインの考え方はデータパイプラインとは？ETLとの違いと仕組みを図解で解説で整理しています。
このタイミングで、実際の日次・月次締めを新旧併走で回します。Excelと自動化の数字が一致することを確認してから、Excelを卒業します。
ここまでで最初の運用が回り始めます。その後、モール横断のLTV分析、広告データとの突合、AI需要予測と、段階的にスコープを広げていくのが、無理のない進め方です。需要予測フェーズに進む際の必要データ・基盤構成・費用感はAI需要予測を始めるためのデータ基盤と進め方、DWHから在庫システムや広告配信ツールにデータを戻す仕組みはリバースETLとは？DWHのデータを業務ツールに戻す仕組みと使い方で整理しています。
EC・D2Cの売上データ統合について、要点を整理します。
EC・D2Cのデータ統合で本当に効いてくるのは、集計時間が浮くことよりも、経営会議でSKU別・チャネル別の真の粗利率を見ながら、翌週の広告予算配分と在庫配分を決められる状態を作れることではないでしょうか。日次で意思決定が回り始めると、営業利益率の改善は同じ広告費のまま数か月で表れます。
まずは自社が「モール別粗利率を正確に出すのに何時間かかっているか」を棚卸ししてみるところから、検討を始めてみてください。
株式会社Evastでは、EC・D2C事業者のモール横断データ統合と本部データ基盤の構築を、実際の事例をベースにご支援しています。アパレルD2C G社では約3か月で自社EC＋楽天＋Amazon＋Yahoo!のデータをBigQueryで統合し、月40時間のモール横断集計を解消、SKU別粗利の可視化と広告予算配分の見直しで粗利率を約2ポイント改善しました。
現状の集計工数の棚卸しや、ネクストエンジンなどのSaaSで足りるのか本部データ基盤が必要なのかの判断からでも構いません。スモールスタートのロードマップまで一緒に描きます。
データ基盤外食チェーン本部の売上集計、POSとデリバリーが分散しExcel手作業で月20〜40時間消えていませんか。3つの自動化アプローチと費用感、月30時間削減＆来店予測でフードロス10%減を実現した40店舗チェーンの事例、4〜8週間の始め方を本部マネージャー向けに整理。
データ基盤freee会計・マネーフォワード クラウド会計のデータをBigQueryに載せる方法を、trocco・Fivetran・Airbyte・Cloud Run内製・特化型SaaSの5パターンで費用比較。月額0円〜月30万円まで、freeeプラン別のAPI制限差、非同期ジョブや締め後修正の実装落とし穴、Shopifyや広告費との突合ユースケースを稟議に使える形で整理した2026年版です。
データ基盤Shopifyの注文・顧客・在庫データをBigQueryで分析する方法を、Fivetran・trocco・Airbyte・Cloud Run内製・Stitch/Hevoの5パターンで費用比較。月0円〜月20万円まで、月商1,000万〜10億円規模のD2Cケースを想定した費用相場と、GraphQL calculated cost・Bulk Operations API・多店舗・多通貨・返品遅延・メタフィールドの実装落とし穴を整理した2026年版です。
