EC売上減少の「原因」を探す前に、まず疑うべきこと
「売上が減った」「流入が減った」という報告を見ると、反射的に「なぜ減ったのか」を考えたくなります。季節要因が変わったのか、競合が増えたのか、モールの検索仕様が変わったのか、広告を止めたのか。原因のリストは無限に作れます。
けれども、そのリストに入る前にやるべきことがあります。その「減少」は、本当に減少なのかを確かめることです。
私たちは実際に、この確認を飛ばして誤診したことがあります。誤診したまま打ち手を選ぶと、正しい打ち手とは逆方向の施策を実行してしまうことがわかりました。
以下の3点は、いずれも私たちが自分たちの運用データで実際に踏んだ点検です。架空の一般論ではなく、実際に起きた誤診とその修正の記録として共有します。
点検1 進行中の月を、フル月の実績と並べていないか
2026年7月29日、私たちは月次の売上推移を並べて確認していました。その際、進行中だった7月（1日から26日までの26日分）を、5月・6月というフル月の実績とそのまま同じ行に並べていました。結果、「3ヶ月連続の減少」という診断になりました。
しかし、26日分のデータを31日分に満了換算すると、実際には前月より回復していました。進行中の月は日数が少ないぶん、必ず小さい数字で出ます。補正せずに並べた時点で、下降トレンドが機械的に生成されてしまうということです。
計算例（架空の数値です）
進行中の月の26日分の売上が780,000円だったとします。これを31日分に満了換算すると、次のようになります。
780,000 ÷ 26 × 31 = 930,000円
この換算をせずに「780,000円は前月の実績を下回っている」と比べてしまうと、実態より悪い数字で判断することになります。
満了換算が使えない場合
月末セールや給料日後に売上が集中するなど、日ごとの偏りが大きい月では、単純に日数で割って引き延ばす満了換算はずれを生みます。このような場合は、日割りの代わりに、前月の同じ日数区切り（たとえば1日から26日まで）で比べる方法を使います。
進行中の月の1〜26日と、前月の1〜26日を並べれば、月末の偏りを持ち込まずに、現時点までの実態に近い比較ができます。満了換算と同じ日数区切りの比較は、どちらか一方だけでなく、両方を並べて見比べるほうが安全です。
誤診が打ち手の方向を変えてしまう
このとき、誤診のまま進んでいたら、打ち手は「集客の底上げ」、つまり流入を増やす施策になるところでした。満了換算のうえで実際の数字を見直すと、正しい打ち手は「転換率の改善」でした。
流入を増やす施策と転換率を改善する施策は、使う予算も工数も、場合によっては触るページも変わります。方向そのものが逆になる誤りだったということです。
季節性や競合と絡めた分析については、既存記事の 季節商材の在庫の引き際 で扱っていますので、交絡の切り分けが必要な場合はそちらも参照してください。
点検2 その数字は「意図した変更」の結果ではないか
2026年8月24日に実測した数字があります。楽天市場の商品ページ流入は、4月から7月の期間で一昨年度比マイナス40.8%でした。同じ期間の検索連動広告（RPP）費は、マイナス74.7%でした。流入減少のうち71.6%は、広告クリックの減少で説明できる範囲でした。
広告費の配分を見ると、ROAS100%未満の商品への配分比率は53.1%から10.6%へ縮小し、ROAS400%以上の商品への配分は43.8%まで増えていました。広告以外の売上はマイナス2.6%で、ほぼ横ばいでした。
つまり流入の減少は、事故ではありませんでした。採算の悪い広告を意図して削り、採算の良い広告に予算を寄せた結果でした。
記録していなかったことのコスト
問題は、この「意図した変更」を台帳のような形で記録していなかったことです。そのため、分析するたびに「流入が減った原因は何か」を再調査していました。毎回同じ結論に到達するのですが、そこに使った時間は毎回かかっていました。
台帳に残す最小限の項目
台帳に残す項目は、多すぎると運用が続きません。最小限は次の4つです。
- 変更した日付
- 何を・どれだけ変えたか
- 影響が出るはずの指標
- 効果を判定する日
この4項目に加えて、あらかじめ「戻す条件」を決めておく必要があります。効果を判定する日になっても指標が改善していない場合、変更前の状態に戻すのか、様子を見るのかを事前に決めておかないと、判断がそのつど先延ばしになります。
戻す条件を判定日より前に決めておけば、判定日には条件と実際の数字を照らすだけで「戻す・戻さない」が決まります。会議や検討にかける時間そのものを減らせるということです。
意図した変更を記帳しておけば、次に流入の減少を見たときに、まず台帳と突合するだけで済みます。広告予算を段階的に絞っていく運用の考え方については 広告依存から段階的に抜ける運用 で詳しく書いていますので、広告費の配分自体を見直したい場合はそちらを参照してください。
点検3 比較している2つの期間、物差し（データ構造）は同じか
私たちの手元には、一昨年度の売上CSV（ローカル保存分）が残っていました。このCSVは19列で構成されており、アクセス人数の列がありませんでした。現行のCSVヘッダは24列です。
同じ「売上CSV」という名前のファイルでも、期間によって中身の列構成が違っていたということです。このため、流入の年次比較をこのCSVだけで行うことはできませんでした。アクセス人数はスプレッドシート側の記録を使う必要がありました。
比較の前に、まず物差しを揃える
2つの期間を比較するとき、ファイル名やレポート名が同じであっても、内部の列構成やデータの取得方法が同じとは限りません。比較する前に、まず物差しが揃っているかどうかを確認する必要があります。
列構成のほかに揃えるべき物差し
列構成（スキーマ）が一致していても、集計の前提そのものが違っていることがあります。例えば、期間の切り方が受注日なのか発送日なのか、金額が税込なのか税抜なのか、キャンセルや返品を含めた数字なのかどうかです。
これらはいずれも、同じ「売上」「流入」という名前のレポートであっても、定義が違いうるということです。
複数モールのデータを横断で扱う場合は、この列構成や集計前提の違いがより起きやすくなります。モールごとにデータ形式が異なるものを一つの基準に集約する設計については 複数モールの売上データを1枚に集約する設計 で扱っていますので、複数モールを横断で見ている場合は参考にしてください。
3点をクリアしてから、EC売上減少の原因分析に進む
ここまでの3点、つまり満了換算・意図した変更との突合・物差しの統一を済ませたうえで、なお減少が残っている場合に、はじめて原因のリストに進みます。
一般的に挙げられる原因は、季節要因の変化、競合の増加、モールの検索・表示仕様の変化、広告出稿の停止や減額、セールや特売の有無、在庫切れなどです。
ここで注意したいのは、これらの原因は互いに重なって起きることが多いという点です。セールと広告強化と季節性が同時に動いていると、どの要因がどれだけ効いたのかを単純に切り分けることはできません。この交絡の扱いについても、先に触れた季節商材の在庫の引き際の記事で扱っています。
私たちが強調したいのは、原因リストそのものを否定することではありません。原因リストに進む前に、その減少が「点検済みの減少」なのかどうかを確認する順序を守ることです。順序を守らずに原因リストへ進むと、点検1のように、そもそも起きていない減少に対して打ち手を組み立ててしまいます。
自動化してよい範囲と、人が判断する範囲
3つの点検を毎回手作業でやるのは、現実的には続きません。そこで、どこまでを仕組みに任せてよいかを分けておきます。
自動化してよい範囲
- 進行中の月を満了換算する計算そのもの（日数で割って月の日数を掛け直す処理、または同じ日数区切りでの前月比較）
- 意図した変更（広告予算の変更・出品数の変更・値付けの変更など）を台帳に記帳する仕組み
- 比較する2つの期間のデータについて、列構成（スキーマ）や集計前提が一致しているかどうかを検知する仕組み
これらは判断ではなく確認作業なので、仕組みに任せて毎回同じ精度で実行させることができます。
人が判断する範囲
- 満了換算・台帳突合・物差しの統一を済ませたうえで、それでも残る減少を「異常」と呼ぶかどうかの決定
- その減少に対して、どの打ち手（集客の強化か、転換率の改善か、それ以外か）を選ぶかの決定
点検1の例のように、満了換算という計算作業は自動化できますが、「これを異常な減少と呼ぶかどうか」「集客を強化するか転換率を改善するか」は、その時点の事業判断が必要です。
仕組みで確認できることは仕組みに任せ、判断が必要なところにだけ人の時間を使う、という線引きが、原因分析の前段としては現実的だと考えています。