[Alpha]{class="badge informative"}
Hybride Personalisierung mit dem Server SDK
Bei einer hybriden Personalisierungsimplementierung fordert Ihr Server personalisierte Inhalte an, die dann vom Browser des Besuchers gerendert werden. Der Adobe Experience Platform-Server SDK für JavaScript oder der Server SDK fordert den Inhalt an, während der Server die Seite erstellt, und der Web SDK rendert sie im Browser.
Im Vergleich zur Client-seitigen Personalisierung hat dieser Ansatz die folgenden Vorteile:
- Personalization ist früher bereit. Der Server fordert Vorschläge an, während er die Seite erstellt, sodass der Browser nicht auf eine separate Anfrage an die Edge Network wartet, bevor er Inhalte rendern kann.
- Weniger Flackern. Da sich die Vorschläge bereits auf der Seite befinden, kann der Browser sie rendern, sobald die Web-SDK geladen wird.
- Der Server kann auch die Entscheidungen verwenden. Beispielsweise kann Ihr Server vor dem Versand der Seite anhand eines Vorschlags auswählen, welche Produkte geladen werden sollen.
Funktionsweise how-it-works
- Der Browser des Besuchers fordert eine Seite von Ihrem Server an.
- Ihr Server ruft
sendEventmit der OptionpersonalizationimforRequestdes Besuchers auf. Das Ergebnis enthält die Vorschläge des Besuchers. - Ihr Server enthält die Vorschläge, die er in der HTML zurückgibt.
- Im Browser rendert die Web-SDK die Vorschläge mit dem Befehl
applyPropositions. - Web SDK sendet ein Anzeigeereignis für die Vorschläge, die es gerendert hat.
Voraussetzungen prerequisites
- Ein Datenstrom mit aktiviertem Adobe Target oder Adobe Journey Optimizer. Setzen Sie seinen Zugriffstyp auf Gemischte Authentifizierung, da der Server authentifizierte Anfragen sendet und der Browser nicht authentifizierte. Siehe Authentifizierung.
- Der Server SDK auf Server installiert konfiguriert.
- Die Web-SDK auf Ihren Seiten, konfiguriert mit demselben
orgIdunddatastreamId.
Schritt 1: Anfordern von Vorschlägen auf dem Server server
Wenn Ihr Server eine Seitenanfrage verarbeitet, fordern Sie Vorschläge für die Oberflächen oder Entscheidungsumfänge auf dieser Seite an. Legen Sie die Seiten-URL explizit fest, da die Referer-Kopfzeile der Anfrage die vorherige Seite während einer Navigation enthält. Siehe Kontext und weitergeleitete Kopfzeilen.
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 [];
}
}
Der SDK-Server rendert keine Vorschläge und sendet keine Anzeigeereignisse. Es werden nur sie zurückgegeben. Wenn die Anfrage fehlschlägt, geben Sie ein leeres -Array zurück, damit Ihre Seite weiterhin mit dem Standardinhalt gerendert wird.
Schritt 2: Vorschläge in die Seite einbeziehen page
Serialisieren Sie die Vorschläge in die HTML, die Ihr Server zurückgibt. Escape-Zeichen, < Inhalte in einem Vorschlag das <script> nicht vorzeitig schließen können.
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>`);
Schritt 3: Vorschläge im Browser rendern browser
Nachdem der Web-SDK auf der Seite konfiguriert wurde, übergeben Sie die Vorschläge an applyPropositions. Verwenden Sie bei HTML-Angeboten ohne Selektor metadata , um dem Web-SDK mitzuteilen, wo die einzelnen Angebote platziert werden sollen. Siehe Rendern von 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 sendet keine Anzeigeereignisse eigenständig. Der zweite sendEvent-Aufruf zeichnet auf, welche Vorschläge der Besucher gesehen hat. Siehe Verwalten von Anzeigeereignissen.
Die Identität des Besuchers konsistent halten identity
Für eine genaue Berichterstellung und Personalisierung müssen der Server und der Browser den Besucher auf die gleiche Weise identifizieren:
- Primäre Identität: Jedes Ereignis, das der SDK-Server sendet, muss eine primäre Identität in
xdm.identityMapenthalten. Siehe Primäre Identität einschließen. - ECID: Die Web-SDK speichert die ECID des Besuchers im
kndctr_<orgId>_identity-Cookie. Die Server-SDK verwendet dieselbe ECID nur, wenn sie dieses Cookie über den Cookie-Service lesen kann, den Sie anforRequestübergeben. Andernfalls verwenden der Server und der Browser unterschiedliche ECIDs für denselben Besucher. Siehe Instanzen und Anfragen.
Der Server-SDK umfasst keinen Cookie-Dienst, der die Anforderungs-Cookies des Besuchers liest. Siehe Platform-) für die Schnittstelle, die ein Cookie-Service implementieren muss.