EC-CUBEで購入者限定商品を販売|購入履歴の判定と付属品の追加購入

EC-CUBEで購入者限定商品を販売|購入履歴の判定と付属品の追加購入EC-CUBE
この記事は約10分で読めます。

この記事でわかること

EC-CUBEで、対象商品を購入したお客様だけに限定商品や付属品を販売する際の設計を解説します。商品の案内方法に加え、購入実績の確認、追加購入の条件、キャンセル・返品への対応、導入前の確認点を整理します。

購入者限定販売で、購入後のニーズに対応する

ECサイトでは、過去に商品を購入したお客様だけに、関連する商品を販売したい場合があります。会員登録の有無だけで判断する販売方法とは異なり、「何を購入したか」「その注文がどの状態か」を条件として扱います。

購入者向けの限定商品を案内する

対象商品を購入した人に限定品を案内する、一定の購入条件を満たした人へ関連商品を紹介する、といった使い方が考えられます。購入者にとって利用する理由がある内容なら、継続的な接点を作る施策になります。

ただし、「限定」と表示するだけで、愛着や信頼度、購入意欲が高まるとは限りません。対象となる条件を分かりやすく伝え、必要なお客様が迷わず利用できる導線を整えることが大切です。

本体購入後に、付属品やオプションを追加購入する

本体と一緒に選べる付属品を買い忘れた、利用を始めてから別のオプションが必要になった、といった場合もあります。通常は単独で販売していない付属品を、本体の購入者に限って追加購入できるようにする方法です。

この場合は、購入履歴があることに加え、その本体に対応する付属品かどうかを確認します。同じシリーズ名でも、型番や規格によって使える部品が異なることがあるためです。

会員限定販売全体の考え方は、EC-CUBEで会員限定商品を販売する際の設計で整理しています。本記事では、購入実績を条件とする販売に焦点を当てます。

URL案内・マイページ・公開ページの3つの方法

購入者限定商品への案内方法には、次のような選択肢があります。いずれも設計例であり、すべてのEC-CUBEで標準設定だけで実現できる機能を示すものではありません。利用中の機能と、必要な販売条件を照合して対応方法を決めます。

購入者限定商品への案内方法と確認点
案内方法向いている場面確認すること
商品URLを個別に案内問い合わせへの対応、対象者への個別案内。URLが転送されても、対象外の人は購入できない。
マイページに対象商品を表示購入した本体に合う付属品を、継続的に案内。現在の購入実績から対象を選び、リンク先でも資格を確認する。
サイト上で商品と条件を公開購入者向けサービスの内容を、広く知らせたい場合。公開してよい情報と購入条件を分け、対象外の人へ理由を案内する。

URLを知らせることと、購入を許可することを分ける

商品を通常の一覧や検索結果に出さず、購入者にURLを案内する方法は、商品の入口を限定するために使えます。ただし、一覧に出ないことや、URLを知る人が少ないことは、購入者だけに制限する仕組みにはなりません。

案内したURLが別の人へ転送されることも想定し、アクセスした利用者に購入資格があるかを確認します。商品そのものを非公開にしたい場合は、購入処理だけでなく、商品情報を返す段階でも条件を確認します。

購入履歴から追加購入できる商品へ案内する

EC-CUBE公式のマイページ説明では、注文履歴やその詳細、再注文の操作が紹介されています。この導線をもとに、購入済みの商品に対応する付属品や限定商品を案内する設計が考えられます。

以前と同じ商品を注文する機能と、購入実績を条件に別の商品を販売する機能は、判定する内容が異なります。マイページに表示する対象、商品との対応関係、追加購入できる条件を別途整理します。

商品を公開する場合は、条件を購入前に伝える

限定商品の内容を一般公開する方式では、「対象の本体を購入済みの会員向け」など、実際の条件を商品ページで案内します。カートに入れてから初めて対象外と分かる状態を避け、ログインや購入実績の確認が必要なことを伝えます。

何をもって「購入済み」とするかを決める

購入者限定販売では、注文履歴に対象商品が存在するだけで許可してよいかを検討します。決済が完了していない注文や、取り消した注文を、通常の購入実績と同じように扱わないためです。

  • 対象商品:どの商品・型番・規格の購入を条件にするか。
  • 判定する時点:注文成立、入金確認、発送など、いつから利用できるか。
  • 対象期間:過去の購入をすべて含めるか、一定期間の購入だけを対象にするか。
  • 必要な数量:1点以上の購入でよいか、一定数の購入を必要とするか。
  • 実績の単位:注文した会員本人か、所属する会社・事業所か。

たとえば、入金確認後を条件にする場合、未入金の銀行振込注文を対象に含めない設計が必要です。一方、掛け払いなどで発送後に代金を回収する運用では、入金だけを条件にすると想定した利用時期に合わないことがあります。決済方法と業務の流れに合わせて決めます。

注文状態の名称や更新のタイミングは、利用中の決済機能や外部連携によって確認が必要です。EC-CUBE上の状態と、販売管理システムなどで管理する状態のどちらを判定元にするかも整理します。

対象商品の照合では、表示名だけに依存せず、過去の受注明細と現在の対象商品・規格を識別できる情報を使います。商品名や商品コードの変更、商品マスタの再登録があっても、購入実績を正しく引き継げる対応関係が必要です。

付属品は、対応する本体・数量・注文方法をそろえる

本体購入者向けの付属品販売では、「本体を買っているから、すべての付属品を買える」という条件でよいとは限りません。本体の型番・規格と、追加販売する付属品の対応表を用意し、後継機種や代替品の扱いも決めます。

利用者には、どの購入商品に対応する付属品なのかを示します。互換性が確認できない組み合わせを自動で勧めず、必要に応じて問い合わせで確認できるようにします。

販売数量についても、本体1台につき1点まで、購入者であれば繰り返し購入可能、一定期間に限って追加可能などの選択肢があります。消耗品の買い足しと、1回限りの限定販売では適した条件が異なります。

回数や数量を制限する場合は、すでに購入した分に加え、注文処理中の分をどう数えるかも決めます。同じ人が複数の画面から同時に注文したときに、上限を超えて受け付けない仕組みが必要です。決済失敗や注文取り消し後に枠を戻すタイミングも確認します。

本体とは別注文として受け付けるなら、送料、支払方法、配送先、納期を改めて案内します。元の注文への同梱や請求の合算は、出荷・決済の状況を確認して対応する別の運用です。追加購入しただけで自動的に同梱されるとは限りません。

キャンセル・返品後の資格をどう扱うか

購入資格の根拠となる注文がキャンセルされたり、対象商品が返品されたりした場合、以後の限定商品の購入を許可するかを決めます。条件に合わなくなったときは、商品案内と購入処理に現在の状態を反映できるようにします。

一部返品の場合は、注文全体の状態だけでは判断しきれないことがあります。本体を2台購入して1台返品したケースなどでは、残る対象数量と追加購入の上限をどう扱うかを整理します。商品の返品と、送料など一部金額だけの返金も区別します。

また、購入実績が取り消される前に、付属品の注文がすでに確定している場合もあります。今後の購入資格を失うことと、確定済みの注文を取り消すことは別の判断です。出荷済みかどうかも含め、案内している販売条件と運用に沿って対応します。

外部システムから返品・入金情報を取り込む場合は、反映までの時間差にも注意します。更新が届く前の注文や、連携が失敗したときにどう対応するかを決め、確認できない状態のまま無条件で販売しないようにします。

商品表示から注文確定まで、同じ購入条件で確認する

購入資格は、マイページへの商品表示だけで判断を終えないようにします。商品詳細へのアクセス、カート追加、購入手続き、注文確定の各段階で、必要な条件を確認します。商品をカートへ入れた後に、元の注文がキャンセルされる場合もあるためです。

OWASPのアクセス制御に関する資料では、URLや識別子を知っていることだけでアクセスを許可せず、リクエストごとに権限を確認することが示されています。ボタンをCSSやJavaScriptで隠すだけではなく、注文を受け付けるサーバー側でも判定します。

再注文、商品一覧からの直接追加、CSV一括注文、外部連携などを利用している場合は、それぞれの経路も対象です。他の会員の注文番号や、書き換えた商品IDを指定するだけで、購入資格を取得できないことを確認します。

資格があっても、在庫、販売期間、現在価格、取引先別の価格・ロットなどは別に確認します。過去に本体を購入したときの価格や送料が、今回の追加注文にもそのまま適用されるとは限りません。

対象外の場合は、ログインが必要なのか、条件を満たす購入実績がないのか、上限に達したのかを、公開してよい範囲で案内します。購入可能な商品も同じカートに入っている場合は、その商品を残して手続きを続ける方法も決めます。

ゲスト購入・法人の履歴・旧サイトの実績を整理する

ゲストとして購入した人が、後から会員登録する場合があります。注文番号や入力したメールアドレスだけで購入実績を自由に取り込めるようにせず、本人の注文であることを確認できる手順を用意します。対象に含めるかどうかも、販売条件として決めておきます。

BtoB-ECで、同じ会社の別担当者にも付属品を購入させたい場合は、実績を会員個人・会社・事業所のどこに紐づけるかを決めます。会社名の文字列が同じという理由だけで、購入資格を共有しないことが大切です。会社への所属や担当者変更を管理する仕組みと合わせて設計します。

ECサイトの移行や会員統合がある場合は、旧サイトの注文履歴も確認対象です。現在の会員・商品と対応づけられる実績があるか、履歴を移行しない場合はどの資料で確認するかを整理します。

運営担当者が例外的に購入を許可する場合は、許可の理由、対象商品、有効期限、担当者を記録できるようにします。表示条件の管理と購入実績による自動判定を使い分けたい場合は、特定会員にカテゴリーの商品を表示する方法も参考になります。

導入前に確認したい購入履歴と注文操作

対象者が購入できることに加え、対象外の人や、条件が変わった後の操作も確認します。次の表は、サイトの販売条件に合わせて具体化する確認例です。

購入者限定販売の確認ケース
確認する状態・操作確認すること
未ログイン・未購入・対象商品の購入済み表示と購入可否が、それぞれの条件に合っている。
未入金・決済失敗・キャンセル済み資格を付ける時点と除外条件が、実際の注文状態に対応している。
全返品・一部返品・対象外商品の返品対象商品の有効な実績と数量を、決めたルールで判定する。
異なる型番・規格の本体を購入対応していない付属品を購入可能として案内しない。
上限到達・同時注文・決済の再試行数量や回数の制限を超えず、枠の重複消費や戻し忘れがない。
カート追加後に購入実績が無効になる注文確定前に再確認し、続行できない理由と次の操作を案内する。
共有URL・他人の注文番号・再注文から操作どの入口でも現在の利用者の資格を確認し、利用を許可されていない他人の実績を使えない。
旧サイト・ゲスト・法人単位の実績を利用確認済みの対応関係だけを使い、判定できない場合の対応が決まっている。

導入時には、対象商品、資格の条件、案内方法、数量制限、返品時の扱いをまとめて共有します。注文履歴が多いサイトでは判定による処理時間も確認し、利用中のEC-CUBE・決済プラグイン・既存カスタマイズに合わせて実装範囲を決めます。

よくある質問

商品URLを購入者だけに知らせれば、購入者限定にできますか?

URLの案内だけでは不十分です。URLが転送される場合もあるため、アクセスした利用者の購入実績を確認し、カート追加や注文確定でも資格を判定します。商品情報自体を非公開にする場合は、閲覧時の確認も必要です。

注文履歴に商品があれば、購入済みと判断してよいですか?

履歴の有無だけで判断せず、注文成立・入金確認・発送など、資格を付ける時点を決めます。未入金、決済失敗、キャンセル、返品の扱いと、対象商品・規格・期間・数量も合わせて整理します。

本体1台につき、付属品を1点だけ販売できますか?

そのような条件を設計できます。本体と付属品の対応関係、対象となる本体の数量、購入済み・注文処理中の付属品をどう数えるかを決めます。同時注文で上限を超えない処理と、決済失敗や取り消し後の枠の扱いも必要です。

ゲスト購入や、同じ会社の別担当者の購入も対象にできますか?

対象に含める設計は可能ですが、本人の注文であることや会社への所属を確認できる仕組みが必要です。会員・会社・事業所のどの単位で実績を共有するかを決め、入力した注文番号や会社名だけで資格を与えないようにします。

購入の根拠となる本体を返品した場合はどうしますか?

以後の限定商品の購入資格や数量上限をどう変更するか、あらかじめ決めます。一部返品では残る対象数量も確認します。すでに確定した付属品の注文をどう扱うかは、今後の購入資格とは分け、販売条件と出荷状況に沿って対応します。

購入後の案内と、販売条件の管理をそろえる

購入者限定販売では、商品を知らせる方法と、購入資格を判定する仕組みの両方が必要です。対象となる実績、付属品との対応、数量や期間、キャンセル・返品後の扱いまで整理することで、購入後のニーズに合う導線を設計できます。

サンクユーでは、既存の注文履歴と販売ルールを確認し、EC-CUBEの構築・カスタマイズをご提案します。法人の購入実績や取引先別条件を含めた運用は、BtoB-EC・卸売サイト構築もご相談ください。

購入者限定商品・付属品販売をご相談ください

対象商品と購入実績、追加購入できる条件を整理し、現在のEC-CUBEに合う案内方法と管理の仕組みをご提案します。

購入者向けの追加販売を相談する

投稿者プロフィール

Nakamura
サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。

Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。

ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。

お気軽にご相談ください

お気軽にご相談ください

タイトルとURLをコピーしました