【Sitecore 連載第3回】Personalize と CDP で実装する 1to1 体験

はじめに

前回（第 2 回「XM Cloud の中身 — コンテンツモデルから headless 配信まで」）では、コンテンツの編集と配信を担う XM Cloud の輪郭を追った。今回（第 3 回）は配信の上に乗る「1to1 体験」を扱う。かつての Sitecore で「パーソナライゼーション」と言えば、xDB に貯めた訪問者プロファイルを xConnect から引き出し、Pattern Cards と Rules Engine で表示を切り替える、という流れだった。現在のコンポーザブル Sitecore では、その役割はほぼ別の 2 つの SaaS 製品に切り出されている。Sitecore Personalize（旧 Boxever）と Sitecore CDP だ。本稿では、両者の関係と、フロントエンドからどう叩いて 1to1 配信を実装するかをまとめる。

役割分担 — Personalize と CDP

Web・モバイル・メールから CDP の Guest プロファイルへ集約、Personalize の Decisioning を経て各チャネルへ配信される流れ — イベント取り込みは CDP、決定の発行は Personalize、配信は各チャネル。プロファイルは Guest 単位で一本化される。

ふたつの製品は密接に連動するが、責務は分かれている。CDP は 1st-party データの保管所で、Web/モバイル/メール/CRM から流れ込むイベントを「Guest（個人）」単位に束ね、属性（attributes）と興味（interests）と行動履歴（events）を持たせる。プロファイルそのものを管理するレイヤだ。Personalize は配信レイヤで、CDP の Guest プロファイルと、リアルタイムの訪問コンテキストを入力に、その瞬間に何を出すかを決める。Decisioning エンジンと、A/B/n の Experimentation 機能、Web 用の Web Experiences、API 経由の Interactive Experiences が一体になっている。

XP 時代の xDB と Pattern Cards をまとめて SaaS に切り出した、と捉えるとイメージしやすい。違いは、CDP/Personalize は Web に閉じない点で、メール（Sitecore Send や Marketo）、モバイルアプリ、店頭 POS まで含めて同じプロファイルでパーソナライズできるよう設計されている。

イベント送信 — まずはここから

すべての出発点は、フロントエンドから CDP/Personalize へイベントを送ることだ。Sitecore が提供する Boxever JS SDK（または Engage SDK）をページに読み込ませ、ページビュー、商品閲覧、購入完了などのタイミングで JSON を送る。

// Next.js のレイアウトで初期化
import { init } from "@sitecore-cdp/sitecore-personalization-tracker";

init({
  clientKey: process.env.NEXT_PUBLIC_PERSONALIZE_CLIENT_KEY!,
  apiTargetEndpoint: process.env.NEXT_PUBLIC_PERSONALIZE_API_ENDPOINT!,
  pointOfSale: "withnextdotnet.jp"
});

// 商品詳細ページで購入意欲の高さを伝える
trackEvent({
  type: "VIEW",
  channel: "WEB",
  pointOfSale: "withnextdotnet.jp",
  product: { id: "SKU-1024", name: "OrderGrain T-Shirt", price: 3500 }
});

送られたイベントは CDP 側で Guest にひも付けられる。匿名訪問者はブラウザのクッキー単位の Guest として始まり、ログインやメール開封など別経路の identity と紐づくたびに Guest が「同一人物」として統合される。

Decisioning — 何を出すかを決めるロジック

Personalize の中で、配信内容を決める部分が Decisioning だ。Decision Model はノードベースの設定 UI で、「セグメント条件で分岐」「スコアで並べ替え」「在庫やビジネスルールでフィルタ」「最終的に 1 つを返す」というフローを描いて作る。簡単なものはコードを書かずに完結し、複雑な決定は JavaScript を埋め込んで自由に書ける。

たとえば「ログイン済みでカートに金融商品 A がある Guest にはバナー B を、それ以外には季節キャンペーンを返す」という決定モデルは、フロントエンドから次のように呼べる。

const decision = await fetch(`/api/personalize/decision`, {
  method: "POST",
  body: JSON.stringify({
    friendlyId: "homepage-hero-banner",
    guestRef: getGuestRef(),
    channel: "WEB",
    params: { season: "summer" }
  })
}).then(r => r.json());

// decision.banner に { headline, imageUrl, ctaHref } が入ってくる
return <HeroBanner {...decision.banner} />;

Decisioning は完全に API ドリブンなので、フロントエンドが Next.js でも Nuxt でも React Native でも構わない。レンダリング側は決定結果を受けて表示するだけだ。

Experimentation — A/B/n とリフト計測

Personalize は決定モデルに直接組み込める Experimentation を備えており、同じ意思決定ポイントで複数バリアントを並走させて結果のリフトを比較できる。トラフィック割合、勝者条件、有意水準を指定すると、Personalize 側が自動で配分を制御する。チャンピオン候補の昇格も UI から行える。

CDP の Audience と外部チャネル

CDP には Audience Builder があり、属性と行動条件で動的セグメントを作れる。たとえば「過去 30 日にカート放棄したが購入完了していない Guest」のようなセグメントを定義し、これをメール（Sitecore Send）や広告プラットフォーム（Google Ads、LINE 公式アカウント）にエクスポートできる。同じ Audience が Web の Personalize Decision にもそのまま条件として使えるため、チャネルをまたいで一貫した訴求が組める。

1st-party データを束ねる以上、プライバシー設計は必須だ。日本国内であれば改正個人情報保護法と、サードパーティクッキー段階的廃止後のブラウザ事情の両方を見る必要がある。Personalize SDK は Consent Mode を備えており、訪問者の同意状態に応じて identification を抑制したり、属性収集をブロックしたりできる。実装側では、Consent Management Platform（OneTrust、TrustArc など）と連動して、同意取得後にだけ identify を呼ぶ、という形を標準パターンとして組んでおく。

XP からの移行で押さえるべき点

既存 XP の Pattern Cards と Engagement Plan を Personalize/CDP に持っていく場合、1 対 1 の写像は基本的に取れない。Pattern Cards 的な「行動パターンへの近さ」は CDP の Persona Pattern（Audience の組み合わせと振る舞いスコア）で再構成する。Engagement Plan 的なシナリオ遷移は、Personalize の Connection（外部ジョブ起動）と Decisioning の組み合わせ、もしくは Sitecore Send 側の Journey で表現する。

大事なのは、XP 時代の概念を 1:1 で再現しようとしないことだ。SaaS 側で素直に表現できる範囲に寄せて再設計したほうが、結果として運用が軽くなる。

次回

次回（第 4 回）は「JSS と Next.js で組む headless 開発実践」。ここまで配信側に偏ってきた話を開発側に戻し、JSS と Next.js App Router を中心に headless フロントエンドを組む実装の中身に入る。

記事一覧に戻る