EC — DTC ブランドの利益、広告、在庫
15 分。3 つの CSV。7 人組のオーツミルクブランドの ops リードを演じ、本当に重要な 4 つの質問に答える。
シナリオ
あなたは Harvest Co. の ops リード。オーツミルク、コールドブリュー、抹茶、その他いくつかの消費財を販売する 7 人の DTC ブランド。Shopify（売上の大部分）と Amazon（成長中）で販売。Google、Meta、TikTok で広告を運用。
チームに誰もアナリストがいません。以前はスプレッドシートで数字を扱っていたが、JOIN — 注文 × 返金 × 広告費 × 在庫 — が 3 週目あたりで痛くなった。共同創業者が「今週は黒字か？」と聞き続け、あなたは「後で答えるね」と言い続けています。
今日 Tablize で 4 つの質問に答えます:
- すべてのコスト後、実際に利益が出ている SKU はどれか？
- 実際の注文と JOIN したとき、広告費は効いているか？
- どの SKU が在庫切れになりそうか — そしてどれが過剰在庫か？
- あなたに頼まずにチームがこれをセルフサービスできるか？
15 分の終わりには、Report、Dashboard、Watch — すべて自分で動いている — を持っています。
サンプルデータのダウンロード
3 つの CSV。どこに保存してもよい — すぐに Tablize にドラッグします。
Tablize を開く（console.tablize.com — まだなら無料ワークスペースにサインアップ）。空のチャットに着地。
3 つの CSV をチャットウィンドウにドラッグ。Agent がインポートしながら各々を確認:
orders.csv→data.orders（7,131 行）ad-spend.csv→data.ad_spend（540 行）inventory.csv→data.inventory（12 行）
準備完了。
実際に利益が出ている SKU はどれ？
これはスプレッドシートでは答えられない質問。JOIN（注文 × 返金 × 商品）が厄介だから。Agent が一発で SQL を書きます。
表示されるもの（数字は概算 — 固定シードでも生成データにはランダム性あり）:
| SKU | 商品 | 数 | 売上 | 純利益 | マージン |
|---|---|---|---|---|---|
| SKU-1048 | Oat Milk 500ml | 1,052 | $3,620 | $1,280 | 35.4% |
| SKU-1047 | Oat Milk 1L | 759 | $4,420 | $1,310 | 29.6% |
| SKU-4006 | Almond Butter 500g | 210 | $3,360 | $980 | 29.2% |
| SKU-0912 | Cold Brew 12oz | 388 | $1,720 | $410 | 23.8% |
| SKU-3102 | Bamboo Whisk | 88 | $1,230 | $180 | 14.6% |
| SKU-3101 | Ceramic Matcha Bowl | 54 | $1,290 | $110 | 8.5% |
保存: ＋ Report として保存をクリック。「SKU 利益 — 週次」と命名し、週次スケジュール（月曜 09:00 で OK）を設定。最初の定期アセットを得ました。
フォローアップを試す（オプション）:
Agent は返金率時系列を引き出し、直近 7 日が 90 日ベースラインの約 3 倍であることに気づき、SKU-0912 + SKU-1047 + SKU-2238 に集中していることをフラグ。これら 3 SKU は一緒に出荷された — おそらく悪い出荷バッチ。
（これはサンプルデータの実際のシグナル — ジェネレータが直近 7 日にシミュレートされた悪いバッチを注入。）
広告費は実際に効いているか？
すべての広告プラットフォームは素晴らしい ROAS を主張します。合計すると売上を超えます。この質問は実際の注文との JOIN を強制します。
Agent は ad-spend.csv がプラットフォームレベルで attributed_orders を記録し、実売上が orders.csv に住むことに気づきます。2 つのクエリ — 1 つは（プラットフォーム、キャンペーン）ごとの費用集計、もう 1 つは実売上の取得 — を書き、生成:
保存: ＋ 週次 ROAS ウォッチをクリック。Agent が毎週月曜 09:00 に動き、任意のキャンペーンの ROAS が 2.0 を下回ったらメールで通知する Watch を作成。「なぜ広告費が上がっているの？」サプライズミーティングはもう不要。
どの SKU が在庫切れになりそう？
| SKU | 商品 | 手元 | 日次販売 | カバー日数 | ステータス |
|---|---|---|---|---|---|
| SKU-1048 | Oat Milk 500ml | 105 | 35.1 | 3.0 | critical |
| SKU-3102 | Bamboo Whisk | 14 | 2.8 | 5.0 | critical |
| SKU-4005 | Hemp Protein 1kg | 18 | 2.1 | 8.6 | warning |
| SKU-0913 | Cold Brew 32oz | 1,240 | 8.4 | 147.6 | 過剰在庫 |
保存: ＋ 在庫ウォッチをクリック。Agent がチェック頻度を聞きます — 在庫は早く動くので「6 時間ごと」を選択。任意の SKU がカバー 7 日を下回った瞬間に通知。
チームがこれをセルフサービスできる？
上の 3 つの質問は Report / Watch です。チームにメールします。ただしライブの「今どうなっているか」ビューには、チームが自分で開ける Dashboard が欲しい。
Agent は約 10 秒で Dashboard を生成。右パネルにスライドインするのが見えます:
公開リンクをコピー。チームの Notion、Slack、メール署名に貼り付け。指 1 本動かさずに 5 分ごとに更新。
15 分で構築したもの
- 1 Report — SKU 利益、週次実行。
- 2 Watch — ROAS アラート、在庫切れアラート。
- 1 Dashboard — ライブビュー、公開共有可能。
Dashboard は共同創業者の「黒字か？」ピンを置き換え。Watch は「夜中に何か壊れた？」チェックを置き換え。Report は月曜朝のピボットテーブル構築を置き換え。
4 つすべて自分で動き続けます。来週 Tablize を開けば、最初のコーヒー前に月曜は終わっています。
この業界の次のステップ
- 実際の Shopify を接続 — 統合 → Shopify を参照。同じ質問がライブデータで動作。
- Stripe を追加 — キャッシュフロー、返金理由内訳、紛争用。OAuth 接続をもう 1 つ、コードなし。
- Amazon SP を接続 — 実際にプラットフォーム間で分かれているセラーのマルチチャネルビュー。
- EC 業界ページを読む — より深いシナリオ: クロスボーダー通貨処理、マージン・アット・リスクアラート、サブスクライバ LTV モデリング。