広告費とフルフィルコストを突合し、「LTVから見た本当の採算」を出す
広告費は広告管理ツール、売上はカート、物流費は3PLの請求書。CPAは下がった。それでも利益は増えていない。継続率と獲得コストとフルフィルコストを、同じ物差しに載せる。
業界に共通する課題
CPAとLTVが別管理
広告費は広告管理ツール、売上・継続はカート。獲得チャネル別のLTVが出せず、広告予算配分が勘に頼っている。
フルフィルコストが読めない
3PLの請求書は月次の合計。「定期1件を届けるのにいくらかかっているか」が分からず、単品リニューアルの原価計算もできない。
定期の解約予兆を掴めない
解約は「次回配送のスキップ→停止」の順に進むが、その兆候をリアルタイムに検知する仕組みがない。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 定期通販カート（受注・継続）
- CRM（顧客・問い合わせ）
- 広告管理ツール（CPA）
- LP・アフィリエイト実績
- 委託3PLのWMS
- 3PL請求書（月次合計）
- 配送実績（送り状）
- 返品・不良の処理
症状：獲得コストは広告管理ツールにキャンペーン単位で、売上と継続はカートに顧客ID単位で、物流費は3PLの請求書に月次合計で存在する。粒度が3種類とも違うため、顧客単位でCPAとLTVとフルフィルコストを同じ行に並べられない。獲得チャネルの情報も初回受注時点にしか残っておらず、継続の実績と結びついていない。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
定期通販カート・CRM・広告管理ツール・委託3PLのWMSと配送実績を接続。広告側のCSV／APIも同じ基盤に取り込みます。
揃える
顧客IDで名寄せし、獲得チャネル→初回→継続→解約の時系列に、配送1件あたりの実コストを紐づけます。LTVとCPA、フルフィルコストを同一粒度に。
使う
獲得チャネル別のLTV/CPA、定期1件あたりの実コスト、解約予兆スコアとCS自動通知、在庫の欠品予兆（定期の次回配送数から逆算）。
定期通販は、次回配送予定から需要がほぼ確定的に読めます。予測ではなく逆算になるため、欠品予兆の精度が上がります。需要予測がいちばん当たりやすい業態であり、そのぶん早く効果が出ます。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
広告費、カートの継続実績、3PLの作業明細を顧客IDで名寄せし、獲得チャネル別のユニットエコノミクスを算出しました。
| 獲得チャネル | CPA | 12ヶ月LTV | フルフィル/件 | CPA回収 |
|---|---|---|---|---|
| アフィリエイトA | ¥ 6,800 | ¥12,400 | ¥612 | 9.2ヶ月 |
| SNS広告 | ¥ 4,200 | ¥14,800 | ¥598 | 4.1ヶ月 |
| 検索広告 | ¥ 3,600 | ¥18,200 | ¥584 | 2.8ヶ月 |
アフィリエイトAはCPA回収に9.2ヶ月かかっています。要因は「3回目継続率が48%（他チャネル平均72%）」。① アフィリエイトAの訴求内容と初回同梱物の見直し、② 予算をSNS・検索へ再配分（想定 同予算で年間LTV総額+8,400万円）を提示します。あわせて定期の次回配送予定から、主力SKUが18日後に欠品見込みと算出しました。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.customer_unit_economics- 顧客コード
customer_id - 獲得チャネル
acq_channel - 顧客獲得単価（CPA）
cpa - 累計注文回数
orders - 顧客生涯価値（LTV）
ltv - フルフィルメント費
fulfill_cost - スキップ回数
skip_count - 解約リスクスコア
churn_score - 獲得月（コホート）
cohort_month
獲得チャネル・売上・継続・フルフィルコストを顧客IDで1本に。「CPAは下がったが利益が増えない」の原因がチャネル×継続率×物流費に分解できます。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 9:00マーケ
前日までのコホート別ユニットエコノミクスを確認。予算の付け替え判断が日次で回る。
- 昼 13:00CS
解約予兆（スキップ2回連続など）の顧客リストが理由付きで届く。先手のフォローができる。
- 夕 17:00生産・調達
定期の次回配送予定から逆算した必要在庫と発注案を承認。欠品も過剰も抑えられる。
- 月次経営
チャネル別の投資回収を同じ物差しで比較。広告予算の配分に根拠が持てる。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
3つの使い方のうち、どれを使うか
3つは排他ではありません。Cだけで始めて、あとからBへ広げることもできます。
W3 WMS × AI照会併用
弊社WMS（W3 sirius / W3 mimosa）のデータをデータレイクに取り込み、MCP経由でAIが直接参照します。SQLの記述もBIツールの操作教育も要りません。聞けば返ってきます。
データレイク蓄積（データ基盤 格納型）このモデルケースの主軸
他社システムのデータ連携サーバー、基幹DB、ECカートなどをCDC（変更差分取得）で接続し、毎日流れてくるデータをraw／mart 2層に溜め込みます。既存システムは無改修です。溜まったデータを、自然言語の指示で分析・加工できる状態にします。
ETL単体（システム直接連携）
データレイクを作らないまま、「抽出→変換→格納」だけのシステム間インターフェースとして使えます。個別IF開発をノーコードのGUI設定に置き換えることで、IF開発費が従来比 1/3〜1/2 になります。ここから始めて、あとからBへ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。