[Alpha]{class="badge informative"}
Server SDKによるハイブリッド型パーソナライゼーション
ハイブリッドパーソナライゼーションの実装では、サーバーがパーソナライズされたコンテンツをリクエストし、訪問者のブラウザーがレンダリングします。 Adobe Experience Platform Server SDK for JavaScriptまたはServer SDKは、サーバーがページを構築する間にコンテンツをリクエストし、Web SDKはブラウザーでコンテンツをレンダリングします。
クライアントサイドのパーソナライゼーションと比較して、このアプローチには次のような利点があります。
- Personalizationの準備が早くなりました。 サーバーはページの構築中に提案をリクエストするので、ブラウザーはEdge Networkへの個別のリクエストを待たずにコンテンツをレンダリングできます。
- ちらつきの減少。 提案は既にページ内にあるので、Web SDKが読み込まれたらすぐにレンダリングできます。
- サーバーは決定も使用できます。 例えば、サーバーは、ページを送信する前に、提案に基づいて読み込む製品を選択できます。
仕組み how-it-works
- 訪問者のブラウザーは、サーバーからページをリクエストします。
- サーバーは
sendEventを呼び出し、訪問者のforRequestハンドルにpersonalizationオプションを指定します。 結果には、訪問者の提案が含まれます。 - サーバーには、返されるHTML内の提案が含まれています。
- ブラウザーで、Web SDKは
applyPropositionsコマンドを使用して提案をレンダリングします。 - Web SDKは、レンダリングした提案に対して表示イベントを送信します。
前提条件 prerequisites
- Adobe TargetまたはAdobe Journey Optimizerが有効になっているデータストリーム。 サーバーが認証済みの要求を送信し、ブラウザーが未認証の要求を送信するため、アクセスの種類を 混合認証 に設定します。 認証を参照してください。
- サーバーSDK、がサーバーにをインストールし、構成しました。
- 同じ
orgIdとdatastreamIdで構成された、ページ上のWeb SDK。
手順1：サーバーでの提案のリクエスト server
サーバーがページリクエストを処理する場合は、そのページのサーフェスまたは決定範囲に対する提案をリクエストします。 リクエストのReferer ヘッダーには、ナビゲーション中に前 ページが含まれているため、ページ URLを明示的に設定します。 コンテキストと転送ヘッダーを参照してください。
async function getPropositions(req) {
const visitor = alloy.forRequest({ request: req });
try {
const { propositions = [] } = await visitor.sendEvent({
xdm: {
eventType: "decisioning.propositionFetch",
web: {
webPageDetails: {
URL: `https://www.example.com${req.url}`
}
},
identityMap: {
Email: [{ id: "visitor@example.com", primary: true }]
}
},
personalization: {
surfaces: ["web://www.example.com/home#hero"],
decisionScopes: ["daily-special"]
}
});
return propositions;
} catch (error) {
// Render the default experience if personalization isn't available
console.error("Failed to fetch propositions", error);
return [];
}
}
Server SDKは、提案をレンダリングしたり、表示イベントを送信したりしません。 返すだけです。 リクエストが失敗した場合は、空の配列を返して、ページがデフォルトコンテンツでレンダリングされるようにします。
ステップ 2：ページに提案を含める page
サーバーが返すHTMLに提案をシリアル化します。 提案内のコンテンツが<script>要素を早期に閉じることができないように、<文字をエスケープします。
const propositions = await getPropositions(req);
const serialized = JSON.stringify(propositions).replace(/</g, "\\u003c");
res.end(`<!DOCTYPE html>
<html>
<head>
<script>window.serverPropositions = ${serialized};</script>
<!-- Web SDK base code and library -->
</head>
<body>
<div id="hero">Default hero content</div>
<div id="daily-special">Default special</div>
</body>
</html>`);
手順3：ブラウザーで提案をレンダリングする browser
Web SDKがページ上で設定されたら、提案をapplyPropositionsに渡します。 セレクターを含まないHTML オファーの場合は、metadataを使用して、Web SDKに各オファーをどこに配置するかを指定します。 HTML オファーのレンダリング を参照してください。
alloy("applyPropositions", {
propositions: window.serverPropositions || [],
metadata: {
"daily-special": { selector: "#daily-special", actionType: "setHtml" }
}
}).then(({ propositions: renderedPropositions = [] }) => {
if (!renderedPropositions.length) { return; }
return alloy("sendEvent", {
xdm: {
eventType: "decisioning.propositionDisplay",
_experience: {
decisioning: {
propositions: renderedPropositions.map(({ id, scope, scopeDetails }) => ({
id,
scope,
scopeDetails
})),
propositionEventType: { display: 1 }
}
}
}
});
});
applyPropositionsは、単独では表示イベントを送信しません。 2番目のsendEvent呼び出しレコードは、訪問者が見た提案を記録します。 表示イベントの管理を参照してください。
訪問者のIDの一貫性を維持する identity
正確なレポートとパーソナライゼーションを行うには、サーバーとブラウザーが同じ方法で訪問者を識別する必要があります。
- プライマリ ID: Server SDKが送信するすべてのイベントには、
xdm.identityMapにプライマリ IDを含める必要があります。 「 プライマリ IDを含める」を参照してください。 - ECID: Web SDKは、訪問者のECIDを
kndctr_<orgId>_identityCookieに保存します。 Server SDKは、ユーザーがforRequestに渡すcookie サービスを通じてそのcookieを読み取ることができる場合にのみ、同じECIDを使用します。 それ以外の場合、サーバーとブラウザーは同じ訪問者に対して異なるECIDを使用します。 インスタンスとリクエスト を参照してください。
Server SDKには、訪問者のリクエスト Cookieを読み取るCookie サービスは含まれていません。 Cookie サービスが実装する必要があるインターフェイスについては、Platform サービス を参照してください。