閲覧履歴でコンテンツを出し分けるときに決めること

「見ている人に合わせて、表示する内容を変えたい」という相談は多いです。仕組み自体は難しくありませんが、決めずに始めると運用で行き詰まる種類の施策でもあります。

ルールが増えて誰も全体を把握できなくなる、在庫のない商品を出し続ける、効果が測れません。よくある詰まり方は決まっています。

閲覧履歴による出し分けを、設計する側の視点で整理します。

1. 出し分けの3つの型

一括りに「パーソナライズ」と呼ばれますが、中身は3種類に分かれます。必要なデータも手間も違います。

型	内容	必要なもの	手間
ルールベース	条件を人が決めて出し分けます	条件に使うデータ	小
セグメント	利用者をいくつかの型に分け、型ごとに出します	分類の設計	中
レコメンド	行動データから機械的に推薦します	十分な行動量	大

最初に手を付けるのはルールベースです。「特定のカテゴリを3回以上見た人に、そのカテゴリの特集を出す」といった単純な条件でも、効果は出ます。

いきなりレコメンドから始めません。 データ量が足りないと、推薦の質が上がらないまま費用だけがかかります。

2. 何を履歴として持つか

出し分けの条件に使えるものを整理します。

データ	例	使いどころ
閲覧したカテゴリ	特定のカテゴリを3回見ました	興味の推定
閲覧した個別ページ	特定の商品ページを見ました	再訪時の続き表示
検索した語	サイト内検索の入力	意図が最もはっきり出ます
購入・申込の履歴	過去の注文	再購入、関連提案
来訪回数	初回、2回目以降	初回向けの案内
最終来訪からの日数	30日以上空いました	復帰の促し
流入元	広告、検索、メール	文脈に合わせた表示

サイト内検索の語は、最も強い手がかりになります。閲覧は偶然でも起きるが、検索は自分で言葉にした行動のためです。

3つの軸で考える

条件を作るときは、次の3つで整理すると迷いません。

軸	見るもの	例
直近性	いつ見たか	今日見た > 3か月前に見ました
頻度	何回見たか	5回見た > 1回見ました
意図の強さ	どんな行動か	カート投入 > 検索 > 閲覧

古い履歴を重く扱わないでください。 3か月前に一度見ただけのカテゴリを推し続けると、的外れな表示になります。

3. 実装の方式

大きく2通りあります。見た目と計測の両方に影響するため、先に決めます。

方式	やり方	長所	短所
サーバー側で出し分け	配信する時点で内容を切り替えます	ちらつかない、速いです	開発が必要
ブラウザ側で差し替え	表示後にスクリプトで書き換えます	開発なしで始められます	一瞬元の内容が見えます

ブラウザ側で差し替える方式は、接客ツールを使えばすぐ始められます。ただし注意点があります。

表示後に書き換わるため、一瞬ちらつきます（元の内容が見えてから切り替わる）
差し替えで要素の高さが変わると、画面がガタつきます。読んでいる最中に押す場所がずれます
読み込みが遅いと、切り替わる前に離脱されます

対策として、差し替える領域の高さをあらかじめ確保しておく、初期表示を空にせず共通の内容を置いておく、といった設計にします。

検証はまず差し替え方式で行い、効果が確認できたらサーバー側に移す、という進め方が現実的です。

4. ルールの例

実際に使われる条件を挙げます。

条件	出すもの
初回訪問	サービスの説明、初回向けの案内
特定カテゴリを3回以上閲覧	そのカテゴリの特集、人気順
商品ページを見たが購入なし、7日以内	その商品と関連商品
カート投入したが未購入	カートの中身の通知
購入から30日経過	消耗品の再購入、関連商品
60日以上来訪なし	更新情報のまとめ
特定の語で検索	該当カテゴリへの導線

条件は重なります。 どれを優先するかを決めておかないと、複数のルールが同時に当たって表示が競合します。

5. 事故になりやすい条件

出し分けは、間違えると何もしないより悪い結果になります。

状況	起きること	対策
在庫のない商品を出します	押した先で買えません	在庫データと突き合わせます
購入済みの商品を出し続けます	買ったものを勧められます	購入履歴で除外します
値下げ前の価格を表示	表示と実際が違います	価格は都度取得します
家族で共有している端末	別人の履歴で出し分けられます	強すぎる断定を避けます
1つの興味に寄りすぎます	同じものばかり出て飽きられます	一定割合で別の内容を混ぜます
ログイン前後で別人扱い	履歴が引き継がれません	識別子の扱いを設計します

在庫と価格は必ず突き合わせる

出し分けの仕組みが持っているデータは、たいてい少し古いです。 商品情報を出す場合は、表示の時点で在庫と価格を確認する経路を用意します。ここを省くと、機会損失ではなく信用の問題になります。

ログイン前後の扱い

同じ人でも、ログイン前は端末単位、ログイン後は会員単位で識別されます。ここをつながないと、ログインした瞬間に履歴がリセットされたように見えます。

どの識別子を主に使うか、いつ紐づけるかを最初に決めます。 あとから直すのは手間がかかります。

6. プライバシーへの配慮

閲覧履歴は個人の関心が表れるデータです。扱いには前提があります。

取得と利用の目的をプライバシーポリシーに書きます。 「閲覧履歴に基づく表示の最適化」と明記します
地域や取得方法によっては、同意の取得が必要になります。該当する場合は同意管理の仕組みを先に入れます
推測を表に出さないでください。 「〇〇に興味がありますね」のような直接的な表現は、監視されている印象を与えます
健康、信条、資産など、扱いに注意が必要な分野の推測は使いません
出し分けを停止できる導線を用意します

技術的にできることと、やってよいことは別です。迷ったら控えめにします。

7. 効果の測り方

「出し分けたら売上が上がった」は、そのままでは根拠になりません。他の要因も同時に動いているためです。

比較できる形にする

方法	内容
A/Bテスト	対象者をランダムに分け、出し分けあり/なしを比較します
期間比較	導入前後を比較します。他の施策の影響を受けるため精度は落ちます

可能ならA/Bテストにします。 一定割合を「出し分けなし」のまま残すと、効果を継続的に確認できます。

見る指標

段階	指標
表示	表示された回数
反応	クリック率
成果	遷移後のCVR、売上
全体	サイト全体のCVR、離脱率

部分の数字だけを見ません。 出し分け枠のクリック率が上がっても、他の導線を押しのけていれば全体は変わりません。サイト全体の数字と両方を見ます。

計測の設計

出し分けをした結果を測るには、どの人にどのパターンが出たかを記録する必要があります。

出し分けの識別子（どのルールが当たったか）をイベントに含めます
差し替え方式の場合、差し替え前に計測タグが動いていないかを確認します
パターンごとに集計できるよう、分析側のデータ構造を先に決めます

ここを後回しにすると、「効果があった気がする」で終わります。

8. 運用で詰まらないために

ルールは増えます。増えたあとに困らない形にしておきます。

やること	内容
一覧を作ります	条件、出す内容、開始日、担当者、狙う指標
優先順位を決めます	条件が重なったときにどれを出すか
期限を決めます	季節ものは終了日を設定します
定期的に見直します	3か月に1回、効果のないルールを止めます
数を絞ります	同時に動かすのは10本程度まで

止める作業を誰もやらないことです。 始めるときに終了条件を書いておくと、自然に止まります。

まとめ

出し分けはルールベース・セグメント・レコメンドの3種類です。最初はルールベースから
条件は直近性・頻度・意図の強さで整理します。古い履歴を重く扱わないでください
実装はサーバー側とブラウザ側の差し替えの2通りです。差し替えはちらつきと画面のガタつきに注意
在庫と価格は表示時点で突き合わせます。買えないものを出すのは信用の問題になります
ログイン前後の識別子の扱いを最初に設計します
プライバシーポリシーへの記載と、必要な場合の同意取得を先に行います
効果はA/Bテストで測ります。部分の数字だけでなく全体も見ます
ルールには終了条件を書いておきます

出し分けは、当たると効きますが、外すと何もしないより悪いです。外したときに気づける形を一緒に作っておきます。