ヘッドレスCMSのパーソナライゼーション：コンポーザブルなスタックでコンテンツをパーソナライズする方法

ヘッドレス／コンポーザブルなスタックでは、コンテンツ（APIファーストのCMS）と、それを表示するフロントエンドが分離されています。柔軟性の面では素晴らしい構成です——1つのコンテンツソースでウェブサイト、アプリ、エッジをまかなえます——が、パーソナライゼーションは難しくなります。これまでは、1つのページと、ブラウザで要素を差し替えるスクリプトタグに頼っていたからです。

ヘッドレス構成では、パーソナライゼーションは意思決定レイヤーにならなければなりません。つまり、特定の枠で誰に何を見せるかを決め、その決定をレンダリングを担うフロントエンドに渡す仕組みです。ここでは、Personyzeを使ったヘッドレスCMSパーソナライゼーションの実践的なアーキテクチャ——構成要素、2つの連携方法、構築前に決めておくべきこと——を紹介します。

ヘッドレスでパーソナライゼーションが変わる理由

従来のCMSはページをレンダリングし、読み込み後にパーソナライゼーションのスクリプトがDOMを書き換えます。ヘッドレスはこのモデルを崩します。CMSは単なるコンテンツAPIであり、フロントエンド——Next.js、Nuxt、モバイルアプリ、エッジ関数——がコンテンツを取得してレンダリングします。何かを差し込める単一のページはもう存在しません。

そのため、パーソナライゼーションは3つの仕事に分かれます。オーディエンス（誰）の定義、この訪問者と枠に対するコンテンツまたはバリエーション（何）の決定、そしてフロントエンドがどこにあってもそれをレンダリングすることです。Personyzeは最初の2つを担い、決定をサーバーまたはブラウザ上のスタックに渡します。

構成要素：オーディエンス、プレースメント、意思決定

オーディエンスは「誰」を定義します。最も簡単なのは、PersonyzeのAudience Builderを自社UIのiframeに埋め込む方法です。編集者が自社の顧客・アカウントのフィールドでルールを定義すると、PersonyzeがコンパイルされたオーディエンスのIDまたは定義を返します。オーディエンスのUIやロジックを自前で作り直さなくても、完全なルールエンジンが手に入ります。オーディエンスでは、サイト上の行動、CRMデータ、 ファーストパーティシグナルを組み合わせられます。

プレースメントは、パーソナライズされたコンテンツを表示する場所を示します。各プレースメントはplacement_idで識別され——サイト共通のプレースメントも、特定のページやURLに限定したプレースメントも作成できます。

意思決定がすべてを結びつけます。visitor_idと、ページ上のplacement_idをもとに、Personyzeは訪問者のオーディエンスを判定し、表示すべきcontent_idとバリエーションを返します。同じ意思決定フローがA/Bテストも動かすため、テストが別システムになることはありません。

2つの連携方法

唯一の「正しい」連携方法はありません——主に、サーバーでレンダリングするかブラウザでレンダリングするかで決まります。

オプションA——サーバー間連携（推奨）

CMSまたはバックエンドには、content_id、placement_id（共通またはページ限定）、そしてオーディエンスのIDまたは定義を保存します。リクエストのたびに、サーバーはvisitor_idと、ページ上のplacement_idをPersonyzeに送信し、Personyzeがcontent_idとバリエーションを返し（A/Bテストと同じフロー）、アプリがコンテンツをレンダリングします。

メリット：コンテンツタイプに縛られず、コンテンツ管理をより細かく制御でき、更新でコンテンツの編集が必要になってもワークフローはシンプルなままです。サーバーレンダリング、SSR、エッジにもすっきり適合します。

トレードオフ：サーバー間連携では、あなたが判断に必要な訪問者コンテキストをPersonyzeに送る必要があります——現在のページとURL、リファラー、ユーザーエージェント、そして訪問者プロファイルを形作る行動イベントです。クライアントサイドのオプションなら、1つのPersonyzeタグでこれらすべてを自動的に収集します（標準で70以上の属性）。サーバー間連携はその手軽さと引き換えに制御性を得て、判断をバックエンドに留めます。多くのチームにとって正しい選択ですが——追加の連携作業は見込んでおきましょう。

オプションB——クライアントサイドレンダリング

フロントエンドが実際のコンテンツをPersonyzeに送り、Personyzeがブラウザ上でページに配置します。クライアントのみでレンダリングしたい場合や、サーバー側のフックなしでUIの実験を素早く回したい場合に使います。

Personyzeタグを通じて動くため、訪問者コンテキスト——ページ、リファラー、デバイス、サイト上の行動——も自動で取得でき、サーバー間連携に比べて接続すべきものがはるかに少なくなります。

A/Bテストも追加の手間なし

意思決定フローは「visitor_id + placement_id→ バリエーション」なので、同じ仕組みで A/Bテストや多変量テストも実行できます。プレースメントとオーディエンスごとにコンテンツのバリエーションをテストし、Personyzeに負けたバリエーションの停止と勝者へのトラフィック配分を任せましょう——テスト用の別連携は不要です。

サーバーサイドとクライアントサイド、どちらでレンダリングするか

どちらも機能し、PersonyzeはサーバーサイドのREST APIとクライアントサイドのJSON APIの両方を提供しています。サーバーサイド（ページ生成時、SSR、またはエッジ）はレンダリング前に判断するため、ちらつきがなく、SEO、アプリ、メールにも対応できます。クライアントサイドはブラウザで判断するため、SPAの実験を素早く繰り返せます。多くのチームは両方を組み合わせています。

ダイナミックコンテンツ、レコメンド、JSON

同じ意思決定レイヤーは、静的なブロックを差し替える以上のことができます。ダイナミックコンテンツ——ヒーロー、バナー、メッセージ、CTA——はオーディエンス別にパーソナライズでき、独自のフィールド（名前、業界、所在地、アカウント種別）をパーソナライゼーションタグとして、コンテンツやレコメンドセットに直接挿入できます。

また、 レコメンドについては、Personyzeは商品とコンテンツの両方のJSONを返します。 アルゴリズムを選んで必要なフィールドをマッピングすると、Personyzeは訪問者ごとにパーソナライズされたJSONセットを返します。フロントエンドはそれをJavaScript変数から読み取り、カード、カルーセル、ウィジェットなど独自のレイアウトでレンダリングします。SPA、モバイルアプリ、独自のフロントエンドに最適です。表示部分を作りたくない場合は、マネージドのレスポンシブウィジェットも利用できます。

しかも、先ほどのどちらのレンダリング方法にも対応します。クライアントサイドでは、ブラウザやアプリで読み取るクライアントサイドJSON APIを使います。サーバーサイドでは、バックエンドから訪問者のID——CRMのIDやメールアドレスでも可——を指定してPersonyzeのAPIを呼び出し、レコメンドを取得します。完全なREST APIとiOS／Android向けネイティブSDKがあり、同じ 多言語ロジックが適用されるため、コンテンツもレコメンドも訪問者の言語で届きます。

2つの簡単な例

1. B2Bホームページのヒーロー（サーバー間連携）

構築：Audience BuilderでCRMと企業属性のフィールドを使い、「製造業アカウント」オーディエンスを定義します。プレースメント——home-hero——を作成し、CMSにヒーローのバリエーションを2つ保存します。ホームページへのリクエストのたびに、サーバーはvisitor_id、home-hero、そして訪問者コンテキスト（ページ、リファラー、自社データから得た企業情報）をPersonyzeに送り、content_idを受け取って、そのヒーローをサーバーサイドでレンダリングします。

成果：典型的な B2Bパーソナライゼーションの手法です——製造業アカウントの訪問者は、製造業向けに書かれたヒーローとCTAを目にし（サーバーレンダリングでちらつきなし）、それ以外の人にはデフォルトが表示されます。同じプレースメントを2つのバリエーションに向ければ、そのまま A/Bテストになります。

2. SPAの「あなたへのおすすめ」レール（クライアントサイドJSON）

構築：コンテンツレコメンドのJSONアクションを設定し、「この記事を読んだ人はこちらも」や「関心に基づく最多閲覧」といった アルゴリズムを選び、必要なフィールド（タイトル、画像、URL）をマッピングして、結果をJavaScript変数に代入します。記事ページでその変数を読み取り、独自のカードレイアウトでレンダリングします——サーバー側の変更は不要です。

成果：すべての読者が、自社デザインのパーソナライズされたレールを目にします——これこそ パブリッシャー・メディア向けパーソナライゼーションの核心です。新規や匿名の読者にはトレンドや人気の記事を表示し、関心が分かり次第、関心ベースのレコメンドに切り替わります——すべてクライアントサイドで、訪問者の言語で。

構築前にすり合わせておくこと

簡単なディスカバリーのチェックリストで、ヘッドレス連携の範囲をすばやく固められます：

• レンダリング方法：ページ生成時にサーバーサイドで行うか、クライアントサイドで行うか？
• 技術スタック：レンダリング層を支える言語とフレームワークは何か？
• 認証とイベント：希望する認証方式（APIキーまたはOAuth）は何か。また——サーバー間連携の場合——判断に必要な訪問者コンテキスト（現在のページ／URL、リファラー、ユーザーエージェント）をPersonyzeに送れるか、さらにリアルタイムの閲覧・クリックイベント（visitor_id + placement_id）も送信できますか？
• キャッシュ／CDN：サーバー間の呼び出しについて考慮すべき制約——TTL、エッジキャッシュ、パーソナライゼーションとキャッシュの優先ルールなど——はあるか？

あらゆるヘッドレスCMSに対応

この意思決定レイヤーはCMSに依存しません。特定の製品ではなく、content_idとplacement_idを扱います。そのため、Contentful、Sanity、Strapi、Contentstack、ButterCMSといったAPIファーストのプラットフォームと並べて使えるほか、SegmentのようなCDPや、すでに運用している連携から統合プロファイルを取り込むこともできます。

ヘッドレス・パーソナライゼーション：よくある質問

ヘッドレスCMSパーソナライゼーションとは何ですか？

ヘッドレス（APIファースト）CMSが分離されたフロントエンドに届けるコンテンツをパーソナライズすることです。レンダリング済みのページをスクリプトで書き換えるのではなく、意思決定レイヤーが特定の枠で各訪問者に見せるべきコンテンツやバリエーションを決め、フロントエンドがそれをサーバーまたはブラウザでレンダリングします。

フロントエンドを作り直さずにヘッドレスサイトをパーソナライズできますか？

ほぼ可能です。サーバー間連携のパターンでは、バックエンドがcontent_id、placement_id、オーディエンスを保存し、visitor_id + placement_idsを送信して、Personyzeが返したものをレンダリングします。コンテンツタイプに縛られないため、作業の大半はイベントと意思決定の呼び出しを接続することです。

パーソナライゼーションはサーバーサイドとクライアントサイドのどちらでレンダリングすべきですか？

サーバーサイド（SSRまたはエッジ）はレンダリング前に判断するためちらつきがなく、SEO、アプリ、メールにも対応できます。クライアントサイドはSPAの実験をより素早く繰り返せます。PersonyzeはサーバーサイドのREST APIとクライアントサイドのJSON APIの両方を提供しており、多くのチームが両方を組み合わせています。

ヘッドレス構成ではオーディエンスをどのように定義しますか？

Personyze Audience Builderを自社UIのiframeに埋め込み、編集者が自社の顧客・アカウントのフィールドでルールを定義して、Personyzeがコンパイル済みのオーディエンス定義を返す形にできます。あるいはPersonyze上で直接オーディエンスを作成することもできます。どちらの場合も、オーディエンスのロジックを作り直す必要はありません。

ヘッドレス・アーキテクチャでA/Bテストは機能しますか？

はい。同じ意思決定フロー（visitor_id + placement_idでバリエーションを返す）がA/Bテストと多変量テストを実行し、勝者も自動的に選ばれます。テストのための別連携は不要です。

どのヘッドレスCMSに対応していますか？

APIファーストのCMSであれば、どれでも対応します。意思決定レイヤーは特定の製品ではなくcontent_idsとplacement_idsを扱うため、Contentful、Sanity、Strapi、Contentstack、ButterCMSなどに適合し、SegmentのようなCDPとも組み合わせられます。

始める

スタックを作り直さずに、ヘッドレス環境をパーソナライズしましょう。デモを予約して連携の範囲を検討するか、 プランをご覧ください。

関連記事

• レコメンドアルゴリズムを解説——エンジンが配信するアイテムを選ぶ仕組み。
• 多言語パーソナライゼーション——あらゆる言語でコンテンツとレコメンドを。
• ウェブサイトパーソナライゼーション——すべてを支えるターゲティングとコンテンツのエンジン。