コンテンツへスキップ
← Journalに戻る
ガイド
1 分で読める

商品別の返品分析:最初に何を確認するか

架空のCSVと再計算できる結果を使い、注文数・個数・観察中のコホートを区別します。申告理由を原因の証明と取り違えません。

著者 Equipo Frihet
商品別の返品分析:最初に何を確認するか

TL;DR: 返品を調べるには、同じ商品を同じ観察期間で比較し、「返品があった注文の割合」と「返品された個数の割合」を分けて残します。購入者が選んだ理由は調査の手掛かりであり、何が悪かったかを証明するものではありません。

目次

返品を調べるには、同じ商品を同じ観察期間で比較し、「返品があった注文の割合」と「返品された個数の割合」を分けて残します。購入者が選んだ理由は調査の手掛かりであり、何が悪かったかを証明するものではありません。

リュックが4個戻ってきたため、広告を止めようという話が出たとします。まだ足りないのは、配送した個数、関連する注文数、購入者が返品するまでに経過した時間です。この分析の結論は、担当者を決めた確認作業です。表の1列だけで責任の所在を決めることではありません。

何を数えるかを決める

返品申請、現物の受領、返金は別の出来事です。ここでは、元の注文明細と結び付いた、実際に戻ってきた個数を数えます。商品の返送を伴わない返金や処理待ちの申請は分子に含めません。処理待ちの申請は、別の業務リストで追跡します。

Shopifyは、キャンセルや編集を含む場合があるReversed quantityと、現物の返品を示すReturned quantityを区別しています。売上日と調整日も同じとは限りません。負の値をすべて返品と呼ぶ前に、項目の定義を確認してください。Shopify公式の定義。

この表は独自の作業形式で、Frihetのエクスポート形式や機能ではありません。他の記録との位置付けは、ECデータと連携のガイド(英語)を参照できます。

集計基準日とコホートを固定する

例はすべて架空です。基準日は2026-09-13、分析上の観察期間は配達から30日間で、30日目に受領した返品を含めます。法的期限や推奨する店舗の返品規約ではありません。実際の工程に適した期間を選び、その理由を記録してください。

SKUと配達日でグループ化します。2026-08-01のコホートは観察を終えていますが、2026-09-06のコホートはまだ7日間です。「観察完了」はこの期間を満たしたという意味で、その後の返品がないという意味ではありません。遅い返品も残し、必要に応じて別に分析します。

分割配送は配送ごとに明細を分け、注文をまとめ直せるキーを残します。配達日が欠ける記録は「分類不能」であり、「返品なし」にはしません。未処理の申請は現物の返品率から除外しつつ、担当者には見える状態にします。

表を再計算する

作業パッケージ (ZIP)にはorder-lines.csv、results.csv、recalculate.pyがあります。順に、架空の配送明細30行、計算結果、Python 3の標準ライブラリだけを使うスクリプトです。原本を残し、コピーでpython3 recalculate.pyを実行すると結果を確かめられます。

SKUとコホート注文数配達個数返品のある注文数返品個数
BAG-A、2026-08-01、観察完了102034
BAG-B、2026-08-01、観察完了101011
BAG-A、2026-09-06、観察中102011

観察完了のBAG-Aでは、注文単位で3 / 10 × 100 = 30 %、個数単位で4 / 20 × 100 = 20 %です。BAG-Bはどちらも1 / 10 × 100 = 10 %です。矛盾ではありません。BAG-Aの最初の行のように、1注文に2個含まれ、その両方が戻ることがあります。

新しいBAG-Aは注文単位10 %、個数単位5 %ですが、まだ観察中です。改善の証明にはなりません。このデータでは施策を一切シミュレーションしていません。また20 %を許容または不許容とする普遍的な基準もありません。

説明できる明細を残す

line_id,order_id,sku,cohort,channel,delivered_at,units_delivered,units_returned,return_received_at,reason_code

line_idは明細を識別し、order_idは重複しない注文数を数えるために使います。SKUごとの注文数を足して店舗全体の注文数にしないでください。実際の1注文には複数の商品が入ることがあります。この例では検算しやすいように1注文を1SKUに限定しています。

SIZEはサイズ不適合の申告、DAMAGEは損傷の申告、UNKNOWNは理由不明、NONEは現物返品の記録なしを表します。コードは倉庫での確認結果ではありません。元の文章があれば、不要な個人情報を含めず、アクセスを限定して別に保存します。

この表は1明細につき受領日と理由を1つに単純化しています。複数の日付や理由で戻る場合は、line_idで結ぶイベント表を作り、観察期間内のイベントだけを集計します。イベントごとにunits_deliveredを繰り返すと分母が膨らみます。IDの重複は行を消す前に調べてください。

理由は確認先を示す

観察完了のBAG-AはSIZEが3個、UNKNOWNが1個です。3 / 4 = 75 %は返品された個数内の理由構成比であり、商品の返品率ではありません。不明を除けば、不完全な情報から「100 %がサイズ問題」という見掛けの結論を作ってしまいます。

3個の実寸、注文されたバリエーション、購入者が見た商品ページを比較します。実寸が正しくても説明から違う期待が生まれたなら、情報の問題という仮説になります。寸法が違う個体があれば、その個体とロットを調べます。選択理由だけでは、このどちらかを判断できません。

BAG-BにはDAMAGEが1個あります。梱包、受領時の証拠、ロットを確認してください。コードだけでは配送業者が壊したと証明できません。1件では安定した傾向も判断できません。

チャネルを早まって責めない

例の返品はすべてwebにあります。調査の問いにはなりますが、チャネルを閉じる根拠にはなりません。同じSKU、バリエーション、期間で比べ、販促、ロット、記録品質も確認します。1チャネル5注文では情報は少なく、細かく分けても精度は生まれません。

レポートが一致しないときは、フィルター、基準日、項目定義を残します。Shopifyは期間や集計ロジックによる差を説明しています。まず注文の同じ部分を比較しているか確かめます。Shopifyレポートの差異。連携一覧では利用可能な情報源を確認できますが、掲載されているだけでこれらの項目が保証されるわけではありません。

担当を決めた確認で締める

次のメモをコピーします。「BAG-A、2026-08-01コホート。4/20個、3/10注文。SIZEが3個、UNKNOWNが1個。実寸と商品ページを確認。商品カタログ担当。証拠待ち。3注文から戻った4個を確認後に再検討」。

どの発見で対応を変えるかを追記し、前回の分析も保存します。数字をよく見せるために不明を削除したりコホートを変えたりしません。証拠がそろったら範囲を限定した試験を選び、同じだけ観察を終えたコホートで後から比較します。経済的な影響は利益率計算ツールで費用を別に検討してください。これらの返品率は利益を測る数字ではありません。

シェア

この記事は役に立ちましたか?

よくある質問

新しいコホートで改善を証明できますか?

観察中のコホートでは、観察期間を終えたコホートに比べて改善したとは証明できません。同じ商品を同じ観察期間で比較し、注文単位と個数単位の割合を分けて扱います。

最も多い返品理由は、原因を証明しますか?

いいえ、商品と利用できる証拠を照らし合わせて調べるための手掛かりです。その割合は返品された個数内の理由構成比であり、商品の返品率ではありませんので、理由不明の個数も残します。

Frihet — ドラマのないビジネス管理

無料で始める