EC担当者は、ほぼ全員、売上とセッション数を日々チェックしています。自社サイトの管理画面、各モールのダッシュボード、GA4やGSCのレポート。毎日流れてくる数字に一喜一憂したり、施策の仮説検証の元にしたり。ECは購買に関わる様々なデータや数値が取りやすいことも大きな特徴です。
しかし、ある日社長や上席にこう聞かれたらどうでしょうか。
「先月、うちの商品Aは、モールで売った分と自社ECで売った分と、どちらが実際の儲けが大きかったですか」
売上の数字なら即答できますよね。しかし、販売手数料やシステム利用料、ポイント原資、キャンペーン割引原資、梱包資材を含む送料負担を引いたあとの「実質の粗利」を、商品別かつチャネル別に即座に答えられる担当者は、私が見てきた範囲ではほとんどいません。
しかし、誤解しないでいただきたいのは、答えられないのは、担当者の能力の問題ではないことです。
チャネルごとに手数料の構造がまったく違い、しかもその情報が管理画面上でバラバラに存在しているため、集計自体に手間がかかりすぎるのです。
結果として、多くの現場では「売上が伸びているチャネルに広告費を積む」という判断が、実質粗利を確認しないまま行われています。売上が伸びているチャネルほど、実は手数料や販促原資の負担も重く、増やした広告費がそのまま会社に残るお金を圧迫しているケースがあります。
この記事では、なぜ実質粗利が見えなくなるのか、見えるようになると何が変わるのか、そしてどう作れば無理なく運用できるのかを、私自身の実体験と、最近ご相談いただいた事例をもとに紹介します。
自社サイトに合わせて複数チャネルで展開するブランドのEC担当の方は、ぜひ最後までご覧ください。
私自身、ECに課題を抱える当事者です
こんにちは、テキサスアユミです。私は「コンテンツの参謀室」というサービスで、さまざまな業種のEC事業者の支援を行っています。と、同時に私自身も、味噌の食品ECを運営する事業者です。今運営しているのは、自社EC(Shopify)、Yahoo!ショッピング、Amazon、それにオフラインでは催事出店、卸、委託販売と販売チャネルは多岐に渡ります。うちだけではなく、ほとんどのECブランドが複数販売チャネルを持っていることでしょう。
EC事業の当事者として困ってきたのは次の点です。
販売チャネルは、チャネルごとに手数料の構造がまったく違うため、同じ「売上100万円」でも会社に残るお金の割合が変わります。自社ECは決済手数料だけで済みますが、モール型のチャネルは販売手数料に加えてポイント原資や送料負担が乗ってきます。催事出店は現地の手数料や交通費、卸は掛率という別の論理で利益が決まります。
これを毎月、各チャネルの管理画面からCSVを落として、Excelに手で転記し、商品別に按分して粗利を出す作業を続けてきました。作業時間は週3時間はかかっており、しかも特別なキャンペーンを行った時など、月によって集計の粒度がぶれるという副作用もありました。複雑化した継ぎ足し関数だらけのスプレッドシートはメンテナンスも大変です。
そして、何が一番モヤモヤしていたかというと、データ管理に手いっぱいで、せっかく集まるデータが正しいものかも不安なまま、次にどんな施策を打てばいいか、また打った施策が当たっているかの振り返りができなかった点でした。
多くの支援会社さんは「目に見えるECの売り上げ改善」は得意です。ただ、「生きて活用できるデータの作り方と使い方」の課題は、実際のEC事業者だからこそでてくる切実な課題だと感じています。
この課題を解決するために自社用に作ったのが、商品別×チャネル別の「実質粗利ダッシュボード」です。自分が使って効果があったので、いまは同じ悩みを持つEC事業者さん向けにも設計・構築をお請けしています。この記事では、その仕組みの中身と作り方を包み隠さず書きます。
最近の実例: 雑貨メーカーさんの場合
最近、とある雑貨メーカーさんからご相談をいただきました。具体的な数値や規模などお伝えできない部分は伏せさせていただきますが、状況を共有します。
このメーカーさんは、自社ECサイト、2個の大手モール、Amazonという4つのチャネルで販売しており、取り扱いSKUは数十、月間の注文件数は数百件という規模でした。
月次の損益は、各チャネルの管理画面から手作業でデータを集めて算出していました。しかし、モールのポイント原資や各チャネルの手数料を差し引いた後の「実質の儲け」は、全社合計でしか把握できておらず、商品別には見えていない状態でした。
つまり、「なんとなく月の売り上げは安定している」ということはわかっても、「売れているどの商品が、実際に会社の利益に貢献しているのか」まではわからない状態でした。数十のSKUの中には、売上は立っているものの、チャネル手数料を引くとほとんど利益が残っていない商品が紛れ込んでいる可能性がありますが、それを特定する手段がありませんでした。
この状態は珍しいものではありません。複数チャネルを展開しているEC事業者の多くが、同じ構造の課題を抱えています。
「実質粗利」とは何か
ここで言う「実質粗利」とは、売上から原価を引いた単純な粗利ではなく、原価に加えてチャネル固有のコストまで差し引いた後の粗利を指します。
チャネル固有のコストには、主に次のようなものがあります。
- 販売手数料（モールへの手数料）
- 決済手数料
- ポイント原資（モールのポイントプログラムの負担分）
- 送料負担（送料込み価格や送料無料施策の実質負担）
- 配送代行手数料（FBAなど）
これらの控除項目は、チャネルによってまったく違う組み合わせになります。参考までに、代表的なチャネルの控除項目の違いを整理すると、次のようになります（料率はプランやカテゴリによって変わるため、具体的な数値はここでは省略します）。
- 楽天市場: システム利用料 + ポイント原資 + その他販促関連の料率
- Amazon: 販売手数料 + FBA利用時の配送代行手数料
- 自社EC（Shopify等）: 決済手数料が中心で、控除項目としては最も軽い構成になりやすい
- 卸: 掛率（売価に対する仕切り率）という別の論理
同じ1,000円の商品を売った場合でも、どのチャネル経由かによって、手元に残る金額は1〜2割程度変わりえます。控除項目の数と料率の違いを考えると、無視できない差になりやすい構造です。
この「チャネルによる手取りの違い」を、商品単位で可視化したものが実質粗利です。売上のダッシュボードは多くの事業者が持っていますが、実質粗利のダッシュボードを商品別×チャネル別で持っている事業者は多くありません。
粗利が見えると何が変わるか
実質粗利が商品別×チャネル別に見えるようになると、主に2つのことが変わります。
1つ目は、どの商品をどのチャネルに注力するかを、粗利ベースで判断できるようになることです。
よくあるパターンとして、「売上ランキング1位の商品が、実質粗利で見ると3位だった」というような発見があります。売上を基準に広告費や在庫を配分していた場合、この発見によって配分の見直しが可能になります。逆に、売上は目立たないものの実質粗利では上位にいる商品が見つかることもあり、こうした商品にこそ注力する余地があります。
2つ目は、月次の手集計工数がほぼゼロになることです。一度ダッシュボードを構築すれば、毎月のCSV転記や按分計算といった作業を担当者が繰り返す必要がなくなります。これは、月末の締め作業に追われる時間を、商品企画や販促といった本来の業務に振り向けられることを意味します。
複数チャネルのダッシュボードの方式
実質粗利ダッシュボードの作り方には、大きく3つの方式があります。
①既存BIツール + 軽い連携
Looker Studioなど既存のBIツールに、各チャネルのデータを軽く連携させる方式です。連携の仕組みは簡易ですが初期費用は高く、チャネル追加や仕様変更への追従にも手間がかかります。
②CSVを所定フォルダに入れるだけの半自動方式
各チャネルからダウンロードしたCSVを、決まったフォルダにまとめて入れるだけで、集計から粗利計算までが自動で走る方式です。
③各チャネルAPI連携の全自動方式
各チャネルのAPIと直接連携し、CSVのダウンロードすら不要にする全自動方式です。難易度と費用感はMAX。
私が自社で取り入れているのは②の方式です。
まず、各チャネルのAPI仕様変更の影響を受けにくく、壊れにくいことです。モール側のAPI仕様は予告なく変わることがあり、API連携に全面依存する③の方式は、その都度の改修対応が発生します。次に、チャネルを追加する際の改修が軽く済むことです。CSVのフォーマットに合わせた取り込み処理を1つ追加するだけで対応できます。そして、運用が「CSVをまとめてドラッグ&ドロップするだけ」で完結し、特定の担当者しか触れないという属人化が起きにくいことです。
正直な話をすると、月千件前後・100SKU程度の規模であれば、スプレッドシートをデータベースとして使う最小構成でも十分に機能します。この場合は費用感も①の方式に近い、安い側に収まります。事業規模に対して過剰な仕組みを提案するつもりはありません。
保守については、基本的に手をかけなくても動く作りにした上で、必要な場合のみ軽い保守プラン(月数万円程度)を用意します。
完成イメージとして、実際のダッシュボードの画面をご覧ください。
既製ツールではだめなのか
先に答えを言うと、やりたいことが既製ツールで足りる場合は、既製ツールもいいでしょう。市場には利益を見るための道具がすでに3系統あります。
- 汎用BIツール（Tableau、Looker Studioなど）：描画は強力ですが、中身は空です。チャネルごとの手数料やポイント原資の計算ロジックは、自分で設計して組み込む必要があります。
- EC一元管理システム：本業は受注・在庫処理の効率化です。売上の集計機能はありますが、ポイント原資や販促原資まで差し引いた商品別の実質粗利までは踏み込まない製品が多数です。
- 利益分析アプリ（主に海外製）：自社EC（Shopify）中心の設計で、日本のモールやフリマ型ショップ、電話注文はカバー範囲の外にあります。
つまり、次の3つを同時に満たそうとすると、今の既製品の守備範囲から外れます。
- 日本のモール特有の控除まで商品別に引きたい
- 電話注文・催事・卸などモール外の売上も1枚にまとめたい
- 非エンジニアだけで運用したい
私たちが提供するダッシュボードは、この空白を埋めるための仕組みです。
逆に言えば、チャネルが自社EC1本であれば、月額制の利益分析アプリで十分なことが多いので、あくまで複数チャネルをほぼ1人などの少人数で運営している場合に限ります。
よくある質問
Q1. スプレッドシート管理じゃだめですか?
注文件数が増えてくると、手集計は遅かれ早かれ破綻します。件数とチャネルが増えるにつれて転記漏れやミスの発生率が上がり、締め作業自体にかかる時間も伸びていきます。ただし、規模によっては、スプレッドシートをデータベースとして使う最小構成で十分なケースもあります。その場合は費用も安い側に収まりますので、まず現状の件数とSKU数をお聞かせいただければ、無理に大掛かりな仕組みをすすめることはありません。
Q2. 非エンジニアでも運用できますか?
運用時にやっていただくのは、各チャネルからダウンロードしたCSVを決まったフォルダに入れることを基本にしています。集計・計算・グラフ化は自動で行われ、経営層や担当者はブラウザでダッシュボードを見るだけという設計にしています。専門知識やツールの操作習熟は前提にしていません。
Q3. どれくらいの規模で元が取れますか?
月商100万円〜規模のEC事業者こそ、元が取れやすい規模だと考えています。理由は2つあります。1つは、限られた広告費や在庫をどの商品・チャネルに配分するかという判断の誤りが、売上規模に対して相対的に大きな影響を持つことです。もう1つは、少人数体制での手集計工数の負担が、規模に対して重くのしかかっていることです。大企業であれば専任の分析担当者を置けますが、少人数運営のEC事業者ほど、この工数の圧縮効果が経営に直結します。
おわりに
実質粗利ダッシュボードは、すべてのEC事業者に必要な仕組みではありません。チャネル数が1つで、SKU数も少ない場合は、今のやり方で十分なこともあります。
一方で、複数チャネルを展開していて、月末の集計に時間がかかっている、あるいは広告費の配分を売上ベースでしか判断できていない、という状態に心当たりがあれば、一度現状を整理してみる価値はあります。
現状の管理方法と課題を30分程度お伺いし、①②③のどの方式が合うか、あるいは今は作らなくてよいかを無料でお答えします。押し売りをするつもりはなく、合わないと判断すれば、その旨を正直にお伝えします。
