閲覧協調 vs 購入協調:どちらのレコメンドを先に試すべきか
閲覧協調(collaborative_view)と購入協調(collaborative_purchase)は、ショップの規模によって「先に入れるべきロジック」が変わります。トラフィックと注文数を基準に、どちらを優先するかを具体的なラインで整理しました。

結論:データ量で優先順位が決まる(ざっくり指針)
- 毎日のセッション数がまだ少ない(目安:1日あたり数百未満)なら、まず 閲覧協調(collaborative_view) を優先
- 閲覧は多いが、購入はまだ少ない・偏っているストアも 閲覧協調 を先に
- 毎日の注文数が安定してある(例:1日あたり数十件以上)なら、重要導線には 購入協調(collaborative_purchase) を優先
- 最終的には「回遊を増やしたい場所=閲覧協調」「カート・購入直前でのアップセル=購入協調」という役割分担がおすすめ
以下では、
- 閲覧協調(collaborative_view) と 購入協調(collaborative_purchase) の違い
- トラフィック規模・注文数ごとの優先パターン
- ページ別の使い分け
を順番に整理します。
閲覧協調(collaborative_view)とは何か
閲覧協調(collaborative_view) は、「この商品を見た人は、他にこんな商品も見ています」という形で、閲覧ログだけ をもとにレコメンドする協調フィルタリングです。
- ベースになるデータ:商品ページ閲覧履歴
- 使われる典型的な表示ラベル:「この商品を見ている人はこちらも閲覧」「他にチェックされている商品」など
- 強み:アクセスがあるだけで学習が進む(購入が少なくても動きやすい)
- 弱み:「なんとなく見ただけ」のノイズも混ざりやすい ため、購入意図とのズレが出ることがある
閲覧ログは、購入よりも圧倒的に母数が多くなりやすいため、立ち上げ初期〜成長途中のストアでも安定して学習させやすいのが閲覧協調の強みです。
購入協調(collaborative_purchase)とは何か
購入協調(collaborative_purchase) は、「この商品を買った人は、他にこんな商品も買っています」という形で、注文データ をもとにレコメンドする協調フィルタリングです。
- ベースになるデータ:注文履歴(同一注文内の商品セット)
- 使われる典型的な表示ラベル:「一緒に購入されている商品」「よく一緒に買われる商品」など
- 強み:実際に売れた組み合わせに基づくため、アップセル・クロスセルの精度が高い
- 弱み:注文数が少ないと「一緒に買われたパターン」がなかなか溜まらない
- もう1つの弱み:単品購入が多いストアでは、そもそも「一緒に買われる」データが少ない
購入協調は、ある程度注文数があることが前提です。その代わり、十分なデータが溜まると、客単価アップに直結しやすいというメリットがあります。
ショップ規模別:どちらを先に使うか
ここでは「トラフィック規模」と「注文数」から、閲覧協調 と 購入協調 の優先度を整理します。数値はあくまで目安ですが、レコメンド戦略を組むときの基準として役立ちます。
- フェーズ1:立ち上げ〜初期(セッション少なめ・注文も少ない)
- 状況イメージ:1日のセッションがまだ安定せず、注文も日によってまちまち
- 優先:閲覧協調(collaborative_view)を先に
- 理由:
- 購入データだけでは、ロジックがほぼ動かない/似た商品ばかり出る
- まずは閲覧ログをもとに、「似た商品を回遊してもらう」ことを重視 - フェーズ2:トラフィックは増えてきたが、注文はまだ少なめ
- 状況イメージ:ブログ・広告で集客が増え、閲覧はあるがコンバージョン率が低い
- 優先:引き続き 閲覧協調をメイン にしつつ、一部導線で 購入協調をテスト
- 理由:
- トラフィックが増える=閲覧協調の精度が安定しやすい
- 購入協調は、まずはカートページやサンクスページなど一部で試し、データが溜まるかを確認 - フェーズ3:日々の注文が安定(例:1日あたり数十件以上)
- 状況イメージ:広告やリピーターで、毎日コンスタントに売れている
- 優先:購入協調(collaborative_purchase)を主力ロジックに昇格
- 理由:
- 注文データが溜まり、同時購入パターンが増えてくる
- 商品詳細下部・カート・サンクスページなど、売上への近道となる場所には購入協調を優先して置く - フェーズ4:SKU数・注文数ともに多い中〜大規模ストア
- 状況イメージ:SKUが多く、カテゴリも細かく分かれている
- 優先:
- 回遊強化エリア:閲覧協調
- 単価アップエリア:購入協調
- 理由:
- 規模が大きくなるほど、「どのページでどのロジックを使うか」の分業が効く
- 一律ではなく、ページ役割ごとにロジックを使い分けた方が成果が出やすい
ページ別のおすすめ使い分け

同じストア内でも、ページごとに「どの行動を増やしたいか」が違います。以下は、一般的なShopifyストアでのおすすめ組み合わせです。
- トップページ・コレクションページ
- 目的:とにかく多くの商品を知ってもらう・回遊を増やす
- 推奨ロジック:閲覧協調(collaborative_view) を基本に
- 「最近よく見られている商品」「このカテゴリを見ている人が他に見ている商品」など
- 理由:
- 購入より閲覧データの方が多いため、広く動くロジックが向いている - 商品詳細ページ(商品ページ)
- 目的:
- まだ決めきれていない人の比較先を出す
- すでに買う気がある人にセット買いを提案
- 推奨ロジック:
- 比較・回遊用:閲覧協調(「この商品を見ている人は他に…」系)
- セット提案用:購入協調(「一緒に買われている商品」系)
- 規模が小さいうちは:まずは 閲覧協調だけ に絞ってもよい - カートページ・ミニカート
- 目的:客単価アップ(アップセル・クロスセル)
- 推奨ロジック:購入協調(collaborative_purchase) を優先
- 理由:
- すでに買う気の高い顧客に対し、「一緒に買われる鉄板セット」を出すのが効果的
- ここで閲覧協調を使うと、「なんとなく見た商品」が混ざりやすく、カートとの関連が薄くなりがち - 注文完了ページ(サンクスページ)・購入後メール
- 目的:リピートや追加購入のきっかけ作り
- 推奨ロジック:
- メイン:購入協調(購入商品に紐づく関連アイテム)
- サブ:閲覧協調(閲覧履歴からの興味関心ベース)
- 理由:
- すでに1回購入をしているため、購入履歴ベースのレコメンドが動きやすい
よくある失敗と避け方
- 失敗1:注文数が少ないのに購入協調だけに頼る
- 状況:
- リリース直後のストアで、いきなり collaborative_purchase だけを商品詳細やカートに入れる
- 起きがちな問題:
- レコメンド枠が「同じ商品だけが出る」「ほぼ空欄になる」
- 回避策:
- まずは collaborative_view をメインにして、購入協調はデータが貯まり始めてから徐々に導入 - 失敗2:全ページで同じロジックだけを使う
- 状況:
- 便利だからと、サイト全体を collaborative_view 一色 にする
- 起きがちな問題:
- カートやサンクスページなど、本来はアップセルしたい場所でも「ただの閲覧ベースのおすすめ」になってしまう
- 回避策:
- 少なくとも、カート・サンクスページは購入協調優先に切り替える - 失敗3:短期間で成果を判断してしまう
- 状況:
- レコメンドを入れて数日で「クリック率が低いからやめる」と判断
- 起きがちな問題:
- 学習が安定する前に止めてしまい、本来の力が見えない
- 回避策:
- フェーズに応じて、最低1〜2週間はロジックを固定して様子を見る - 失敗4:高単価ストアで閲覧協調だけに偏る
- 状況:
- 高価格帯で、1人あたりの閲覧数が少ない(じっくり比較してから買う)ストアで閲覧協調だけを使う
- 起きがちな問題:
- 閲覧データが少なく、閲覧協調も安定しない
- 回避策:
- 受注が出始めたら、早めに collaborative_purchase を併用して「よく一緒に買われる保証商品・メンテナンス品」などを出す
RecoBoost での次の一歩
RecoBoost を利用する場合、まずは自分のストアが「フェーズ1〜4」のどこに近いかを確認したうえで、以下のように進めるのがおすすめです。
- Shopify管理画面 → アプリ → RecoBoost を開く
- 左メニューから レコメンドウィジェット(名称は仮)を開き、既存ウィジェットを選択するか 新規作成 をクリック
- 配置ページ で、まずは 商品ページ と カートページ の2箇所に絞って設定
- 商品ページ用ウィジェット のロジックを collaborative_view に設定し、タイトルを「この商品を見た人はこちらもチェック」にする
- カートページ用ウィジェット のロジックを collaborative_purchase に設定し、タイトルを「一緒に購入されている商品」にする
- 1〜2週間ほど表示を継続し、RecoBoost の レポート からそれぞれのウィジェットの 表示回数・クリック率・経由売上 を比較して、次の調整(ロジックの入れ替え・ページ追加)を行う
