はじめに：返品はコストだが原因が見えにくい

ECを運営していると、売上の数字は毎日のように追いかけるのに、返品の数字はなんとなく後回しになりがちです。返品が発生すると、商品が戻ってくるだけでなく、返送送料・検品の手間・再販できない在庫といった負担が一度に押し寄せます。返品は静かに利益を削るコストなのですが、損益のどこに効いているかが見えにくいのが厄介なところです。

さらに困るのは、「返品が多い」という感覚はあっても、「どのカテゴリの、どんな理由の返品が多いのか」を数字で説明しようとすると途端に難しくなる点です。受注データはカートシステム、返品データは別の管理台帳やスプレッドシート、ユーザーの行動データはGA4と、必要な情報がバラバラに散らばっているからですね。

この記事では、これらのデータをBigQueryで商品カテゴリ別に結合し、返品率を集計したうえで、返品の原因仮説を立てて打ち手につなげるまでの流れを紹介します。中小ECや個人事業主の方でも、手元のデータで再現できる構成を意識しました。

なお、この記事のSQLや数字はすべて「考え方を示すための例」です。実際のテーブル名・カラム名・しきい値は、お使いのカートシステムやGA4のエクスポート設定に合わせて読み替えてください。

返品率の定義とデータの持ち方

返品率の定義をそろえる

分析を始める前に、まず「返品率とは何か」を社内で1つに決めておく必要があります。定義があいまいなまま集計すると、後から数字の解釈で迷うことになります。代表的な定義は次のとおりです。

  • 数量ベース返品率 ＝ 返品数量 ÷ 出荷（販売）数量
  • 金額ベース返品率 ＝ 返品金額 ÷ 売上金額
  • 注文ベース返品率 ＝ 返品を含む注文数 ÷ 全注文数

どれが正しいというわけではなく、目的によって使い分けます。利益へのインパクトを見たいなら金額ベース、商品の品質や表記の問題を探したいなら数量ベースが向いています。この記事では、カテゴリ別に商品の問題を見つけることが目的なので、数量ベースを中心に進めます。

集計期間のそろえ方に注意する

返品は、購入した月とは別の月に発生します。1月に売れた商品が2月に返品される、ということは普通に起こります。そのため、返品率を計算するときは「いつの売上に対する返品か」をそろえないと、数字が実態からずれてしまいます。

おすすめは、返品を「元の注文日」にひも付けて集計するやり方です。返品が発生した日ではなく、その商品が売れた日を基準にすることで、「2026年1月に売れたぶんのうち、最終的に何パーセントが返品されたか」という素直な指標になります。ただし直近の売上は返品がまだ出きっていないので、集計対象は少し前の期間（たとえば60日以上前まで）に区切ると安定します。

必要なデータの持ち方

カテゴリ別に返品率を出すには、最低限つぎの3種類のデータが必要です。

  • 受注（売上）データ：注文番号・注文日・SKU・カテゴリ・数量・金額
  • 返品データ：元の注文番号・SKU・返品数量・返品金額・返品理由
  • 行動データ（GA4）：商品ページの閲覧、サイズ表やレビューの閲覧、購入イベント

ここで一番のポイントは、返品データに「元の注文番号」と「返品理由コード」が入っているかです。元の注文番号があれば受注データと正確に結合でき、返品理由があれば原因分析の精度が一段上がります。理由が自由記述になっている場合は、「サイズ」「イメージ違い」「不良」「お客様都合」程度のざっくりした分類でもよいので、コード化しておくと後がぐっと楽になります。

受注×返品データ×GA4行動をBigQueryで結合する

結合の全体像

3つのデータをいきなり1本のクエリで結合しようとすると複雑になりすぎるので、段階を分けて考えます。

  1. 受注データと返品データを元の注文番号＋SKUで結合し、「売れた数」と「返品された数」を商品の明細単位でそろえる
  2. その明細にカテゴリを付与する（受注データにカテゴリが無ければ商品マスタから引く）
  3. 必要に応じてGA4の行動データをカテゴリ単位で横に並べ、返品率と行動指標を見比べられるようにする

受注データと返品データの結合キーは、注文番号と注文行を一意に特定できる単位にします。1つの注文の中に同じSKUが複数行に分かれることがあるので、注文明細IDのような行レベルのキーがあればそれを使うのが確実です。

受注と返品を結合して明細をそろえる

まずは受注明細に返品数量を貼り付けます。返品が無い明細は返品数量がゼロになるよう、左結合（LEFT JOIN）で受注側を残すのがコツです。

-- 受注明細に返品数量・返品金額を結合する
-- orders: 受注明細（1行＝1注文の1SKU）
-- returns: 返品明細（元の注文番号＋SKUで受注にひも付く）
WITH order_lines AS (
  SELECT
    o.order_id,
    o.order_date,
    o.sku,
    o.category,
    o.quantity      AS sold_qty,
    o.amount        AS sold_amount
  FROM `myproject.ec.orders` AS o
  WHERE o.order_date BETWEEN DATE '2026-01-01' AND DATE '2026-04-30'
),
return_lines AS (
  SELECT
    r.order_id,
    r.sku,
    SUM(r.return_quantity) AS returned_qty,
    SUM(r.return_amount)   AS returned_amount
  FROM `myproject.ec.returns` AS r
  GROUP BY r.order_id, r.sku
)
SELECT
  ol.order_id,
  ol.order_date,
  ol.sku,
  ol.category,
  ol.sold_qty,
  ol.sold_amount,
  COALESCE(rl.returned_qty, 0)    AS returned_qty,
  COALESCE(rl.returned_amount, 0) AS returned_amount
FROM order_lines AS ol
LEFT JOIN return_lines AS rl
  ON ol.order_id = rl.order_id
  AND ol.sku = rl.sku

COALESCE を使って、返品が無い明細の返品数量をゼロに埋めているのがポイントです。これをしないと、返品の無い商品が集計から消えてしまい、返品率が高く見える方向にゆがみます。

GA4の行動データを取り込む

GA4からBigQueryにエクスポートされた events_YYYYMMDD テーブルには、商品ページの閲覧（view_item）やサイズ表クリックといったイベントが入っています。これをカテゴリ単位で集計しておくと、後で返品率と並べて見られます。GA4側のイベントにカテゴリ情報（item_category など）が入っていることが前提です。

GA4と受注データの細かい結合の考え方については、BigQueryでEC受注データ×GA4データを結合して正確な売上帰属分析をする で詳しく解説しているので、流入経路まで踏み込みたい場合はあわせて読んでみてください。

カテゴリ別の返品率を集計するSQL

明細がそろったら、カテゴリ単位で返品率を計算します。先ほどの結合結果を order_return というCTEとして受け取る前提で書きます。

-- カテゴリ別の返品率を集計する
WITH order_return AS (
  -- 前項の受注×返品結合の結果をここに置く（再掲は省略）
  SELECT
    category,
    sold_qty,
    sold_amount,
    returned_qty,
    returned_amount
  FROM `myproject.ec.order_return_lines`
)
SELECT
  category,
  SUM(sold_qty)                                   AS total_sold_qty,
  SUM(returned_qty)                               AS total_returned_qty,
  SUM(sold_amount)                                AS total_sold_amount,
  SUM(returned_amount)                            AS total_returned_amount,
  -- 数量ベース返品率（％）
  ROUND(SAFE_DIVIDE(SUM(returned_qty), SUM(sold_qty)) * 100, 2)
                                                  AS return_rate_qty_pct,
  -- 金額ベース返品率（％）
  ROUND(SAFE_DIVIDE(SUM(returned_amount), SUM(sold_amount)) * 100, 2)
                                                  AS return_rate_amount_pct
FROM order_return
GROUP BY category
HAVING total_sold_qty >= 30
ORDER BY return_rate_qty_pct DESC

ポイントをいくつか補足します。

  • SAFE_DIVIDE を使うことで、販売数量がゼロのときにエラーで止まらず、結果がNULLになります。割り算は常にこれを使うのが安全です。
  • HAVING total_sold_qty >= 30 で、販売数量が少なすぎるカテゴリを除外しています。3個売れて1個返品されると返品率33％になりますが、これはサンプルが少なすぎて判断材料になりません。母数のしきい値は商品単価や販売規模に合わせて調整してください。
  • 数量ベースと金額ベースを両方出しておくと、「件数は多いが安い商品」と「件数は少ないが利益への打撃が大きい商品」を見分けられます。

返品理由のコードがある場合は、GROUP BY category, return_reason のようにもう一段ブレイクダウンすると、「このカテゴリはサイズ理由の返品が突出している」といった解像度の高い表が得られます。原因の特定に直結するので、理由が取れるならぜひ加えたいところです。

原因仮説と打ち手

返品率の高いカテゴリが見えてきたら、つぎは「なぜ返品されるのか」の仮説を立てます。返品理由とGA4の行動データを照らし合わせると、当てずっぽうではなく根拠のある仮説が立てられます。代表的なパターンを3つ紹介します。

サイズ表記の問題

アパレルや靴、家具など、サイズが関わる商品で返品率が高い場合、まず疑うのはサイズ表記です。「サイズが合わない」という返品理由が多く、なおかつGA4でサイズ表の閲覧率が低いなら、お客様が十分な情報を得ないまま購入している可能性があります。

打ち手としては、実寸（身幅・着丈・ヒールの高さなど）をミリ単位で明記する、平置きの採寸写真を載せる、「身長◯◯cmの私が着るとこう」といった着用イメージを補う、などが効きます。サイズ表をページ下部から上部に移すだけで閲覧率が変わることもあります。施策の前後で、対象カテゴリのサイズ理由の返品率が下がるかを同じSQLで追いかければ、効果を数字で確認できます。

商品画像とのイメージ違い

「イメージと違った」「色が思っていたのと違う」という理由が多いカテゴリは、画像の問題が疑われます。照明やモニター環境で色味がずれる、質感が写真から伝わらない、サイズ感が分かる比較対象が写っていない、といったことが原因になりがちです。

打ち手は、自然光に近い環境での撮影、手や定番アイテムと並べた比較カット、複数アングルや動画の追加など。GA4で「画像の拡大やサムネイル切り替えがほとんど使われていない」といった行動が見えれば、そもそも画像が見られていないのか、見たうえでギャップが生じているのかを切り分けられます。

商品説明の不足

機能性商品や家電、食品などで「思っていた機能が無かった」「使い方が分からなかった」という返品が多い場合は、商品説明の不足が原因のことが多いです。スペックの羅列だけで、実際の使い勝手や向き不向きが書かれていないケースですね。

打ち手としては、「こんな人に向いています／向いていません」を正直に書く、よくある質問を商品ページに先回りで載せる、使用シーンを具体的に描写する、などが有効です。期待値を正しく設定することは、短期的には一部の購入を取りこぼすように見えても、返品コストを減らし、結果的に利益とレビュー評価を守ることにつながります。

なお、返品の改善はそのまま在庫の健全化にも効いてきます。返品された商品が再販できずに滞留すれば、それは死に筋在庫の予備軍になります。在庫の回転という観点もあわせて見たい場合は、ECの在庫回転率をGA4×BigQueryで商品別に可視化して死に筋を特定する も参考になります。

まとめ

返品は、売上の裏側で静かに利益を削るコストです。原因が見えにくいまま放置されがちですが、データをそろえれば「どのカテゴリの、どんな理由の返品が多いか」は十分に特定できます。この記事のポイントを整理しておきます。

  • 返品率は定義を1つに決め、返品を元の注文日にひも付けて集計すると実態に近づく
  • 受注データと返品データは元の注文番号＋SKUで左結合し、返品の無い明細をゼロで残す
  • カテゴリ別集計では SAFE_DIVIDE と母数のしきい値で数字のゆがみを防ぐ
  • 返品理由とGA4の行動を照らし合わせ、サイズ表記・画像・説明のどこに原因があるかの仮説を立てる
  • 施策の前後を同じSQLで追えば、改善効果を数字で確認できる

まずは返品データに「元の注文番号」と「返品理由」が入っているかを確認するところから始めてみてください。そこさえそろえば、あとは手元のデータで少しずつ解像度を上げていけます。