La personnalisation hybride décrit le processus de récupération du contenu de personnalisation côté serveur, à l’aide de l’API Edge Network Server, et de le rendre côté client, à l’aide du SDK Web.
Vous pouvez utiliser la personnalisation hybride avec des solutions de personnalisation telles qu’Adobe Target ou Offer Decisioning, la différence étant le contenu de la payload de l’API du serveur.
Avant d’implémenter une personnalisation hybride sur vos propriétés web, assurez-vous de respecter les conditions suivantes :
Le diagramme de flux ci-dessous décrit l’ordre des étapes effectuées pour fournir une personnalisation hybride.
kndctr_
, est inclus dans la requête du navigateur.POST
au point d’entrée de la collecte de données interactive de l’API du serveur pour récupérer du contenu de personnalisation. La requête POST
contient un event
et une query
. S’ils sont disponibles, les cookies de l’étape précédente sont inclus dans le tableau meta>state>entries
.applyResponse
est appelée, en transmettant les en-têtes et le corps de la réponse de l’API du serveur de l’étape précédente.renderDecisions
est défini sur true
.applyPersonalization
, pour mettre à jour le DOM en fonction de l’offre de personnalisation.sendEvent
.Les cookies sont utilisés pour conserver l’identité de l’utilisateur et les informations de cluster. Lors de l’utilisation d’une implémentation hybride, le serveur d’applications web gère le stockage et l’envoi de ces cookies pendant le cycle de vie des requêtes.
Cookie | Rôle | Stocké par | Envoyé par |
---|---|---|---|
kndctr_AdobeOrg_identity |
Contient des détails de l’identité de l’utilisateur. | Serveur d’applications | Serveur d’applications |
kndctr_AdobeOrg_cluster |
Indique quel cluster Edge Network doit être utilisé pour répondre aux requêtes. | Serveur d’applications | Serveur d’applications |
Les requêtes d’API du serveur sont nécessaires pour obtenir des propositions et envoyer une notification d’affichage. Lors de l’utilisation d’une implémentation hybride, le serveur d’applications envoie ces requêtes à l’API du serveur.
Requête | Créée par |
---|---|
Requête d’interaction pour récupérer des propositions | Serveur d’applications |
Requête d’interaction pour envoyer des notifications d’affichage | Serveur d’applications |
Lors de l’implémentation d’une personnalisation hybride, vous devez faire particulièrement attention à ce que les accès aux pages ne soient pas comptabilisés plusieurs fois dans Analytics.
Lorsque vous configurez un flux de données dans Analytics, les événements sont automatiquement transférés afin que les accès à la page soient capturés.
L’exemple de cette mise en œuvre utilise deux flux de données différents :
Ainsi, la requête côté serveur n’enregistre aucun événement Analytics, contrairement aux requêtes côté client. Cela entraîne un comptage précis des requêtes Analytics.
L’exemple de requête ci-dessous illustre une requête d’API du serveur que votre serveur d’applications peut utiliser pour récupérer le contenu de personnalisation.
Cet exemple de requête utilise Adobe Target comme solution de personnalisation. Votre requête peut varier en fonction de la solution de personnalisation choisie.
Format d’API
POST /ee/v2/interact
curl -X POST "https://edge.adobedc.net/ee/v2/interact?dataStreamId={DATASTREAM_ID}"
-H "Content-Type: text/plain"
-d '{
"event":{
"xdm":{
"web":{
"webPageDetails":{
"URL":"http://localhost/"
},
"webReferrer":{
"URL":""
}
},
"identityMap":{
"FPID":[
{
"id":"xyz",
"authenticatedState":"ambiguous",
"primary":true
}
]
},
"timestamp":"2022-06-23T22:21:00.878Z"
},
"data":{
}
},
"query":{
"identity":{
"fetch":[
"ECID"
]
},
"personalization":{
"schemas":[
"https://ns.adobe.com/personalization/default-content-item",
"https://ns.adobe.com/personalization/html-content-item",
"https://ns.adobe.com/personalization/json-content-item",
"https://ns.adobe.com/personalization/redirect-item",
"https://ns.adobe.com/personalization/dom-action"
],
"decisionScopes":[
"__view__",
"sample-json-offer"
]
}
},
"meta":{
"state":{
"domain":"localhost",
"cookiesEnabled":true,
"entries":[
{
"key":"kndctr_XXX_AdobeOrg_identity",
"value":"abc123"
},
{
"key":"kndctr_XXX_AdobeOrg_cluster",
"value":"or2"
}
]
}
}
}'
Paramètre | Type | Obligatoire | Description |
---|---|---|---|
dataStreamId |
String |
Oui. | L’identifiant du flux de données que vous utilisez pour transmettre les interactions à Edge Network. Voir la présentation des flux de données pour savoir comment configurer un flux de données. |
requestId |
String |
Non | Un identifiant aléatoire permettant de corréler les requêtes internes du serveur. Si aucun n’est fourni, le Edge Network en génère un et le renvoie dans la réponse. |
L’exemple de réponse ci-dessous indique à quoi pourrait ressembler la réponse de l’API du serveur.
{
"requestId":"5c539bd0-33bf-43b6-a054-2924ac58038b",
"handle":[
{
"payload":[
{
"id":"XXX",
"namespace":{
"code":"ECID"
}
}
],
"type":"identity:result"
},
{
"payload":[
{
"..."
},
{
"..."
}
],
"type":"personalization:decisions",
"eventIndex":0
}
]
}
Sur la page client, la commande Web SDK applyResponse
est appelée, transmettant les en-têtes et le corps de la réponse côté serveur.
alloy("applyResponse", {
"renderDecisions": true,
"responseHeaders": {
"cache-control": "no-cache, no-store, max-age=0, no-transform, private",
"connection": "close",
"content-encoding": "deflate",
"content-type": "application/json;charset=utf-8",
"date": "Mon, 11 Jul 2022 19:42:01 GMT",
"server": "jag",
"strict-transport-security": "max-age=31536000; includeSubDomains",
"transfer-encoding": "chunked",
"vary": "Origin",
"x-adobe-edge": "OR2;9",
"x-content-type-options": "nosniff",
"x-konductor": "22.6.78-BLACKOUTSERVERDOMAINS:7fa23f82",
"x-rate-limit-remaining": "599",
"x-request-id": "5c539bd0-33bf-43b6-a054-2924ac58038b",
"x-xss-protection": "1; mode=block"
},
"responseBody": {
"requestId": "5c539bd0-33bf-43b6-a054-2924ac58038b",
"handle": [
{
"payload": [
{
"id": "XXX",
"namespace": {
"code": "ECID"
}
}
],
"type": "identity:result"
},
{
"payload": [
{...},
{...}
],
"type": "personalization:decisions",
"eventIndex": 0
}
]
}
}
).then(applyPersonalization("sample-json-offer"));
Les offres JSON basées sur des formulaires sont appliquées manuellement par l’intermédiaire de la méthode applyPersonalization
pour mettre à jour le DOM en fonction de l’offre de personnalisation. Pour les activités basées sur des formulaires, les événements d’affichage doivent être envoyés manuellement pour indiquer le moment où l’offre a été affichée. Cela s’effectue via la commande sendEvent
.
function sendDisplayEvent(decision) {
const { id, scope, scopeDetails = {} } = decision;
alloy("sendEvent", {
xdm: {
eventType: "decisioning.propositionDisplay",
_experience: {
decisioning: {
propositions: [
{
id: id,
scope: scope,
scopeDetails: scopeDetails,
},
],
},
},
},
});
}
Pour vous aider à expérimenter et à en savoir plus sur ce type de personnalisation, nous vous proposons un exemple d’application que vous pouvez télécharger et utiliser pour les tests. Vous pouvez télécharger l’application, ainsi que des instructions détaillées sur son utilisation, à partir de ce référentiel GitHub.