Personnalisation hybride à l’aide du SDK Web et de l’API Edge Network Server

Présentation overview

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 comme Adobe Target, Adobe Journey Optimizer ou Offer Decisioning, la différence étant le contenu de la variable API du serveur payload.

Conditions préalables prerequisites

Avant d’implémenter une personnalisation hybride sur vos propriétés web, assurez-vous de respecter les conditions suivantes :

  • Vous avez choisi la solution de personnalisation que vous souhaitez utiliser. Cela aura un impact sur le contenu de la payload de l’API du serveur.
  • Vous avez accès à un serveur d’applications que vous pouvez utiliser pour effectuer les appels de l’API du serveur.
  • Vous avez accès a l’API Edge Network Server.
  • Vous avez correctement configuré et a déployé le SDK Web sur les pages que vous souhaitez personnaliser.

Diagramme de flux flow-diagram

Le diagramme de flux ci-dessous décrit l’ordre des étapes effectuées pour fournir une personnalisation hybride.

Diagramme de flux visuel présentant l’ordre des étapes effectuées pour fournir une personnalisation hybride.

  1. Tout cookie existant précédemment stocké par le navigateur, préfixé par kndctr_, est inclus dans la requête du navigateur.
  2. Le navigateur web client demande la page web à votre serveur d’applications.
  3. Lorsque le serveur d’applications reçoit la requête de page, il effectue une requête 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.
  4. L’API du serveur renvoie le contenu de personnalisation à votre serveur d’applications.
  5. Le serveur d’applications renvoie une réponse HTML au navigateur client, contenant les cookies d’identité et de cluster.
  6. Sur la page client, la commande Web SDK 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.
  7. La variable Web SDK effectue le rendu de Target Visual Experience Composer (VEC) offres et éléments de canal web Journey Optimizer automatiquement, car la variable renderDecisions L’indicateur est défini sur true.
  8. Basé sur les formulaires de Target HTML/JSON les offres et les expériences basées sur du code Journey Optimizer sont appliquées manuellement par le biais de la variable applyProposition pour mettre à jour la méthode DOM en fonction du contenu de personnalisation de la proposition.
  9. Pour les formulaires basés sur Target HTML/JSON offres et expériences basées sur du code Journey Optimizer, des événements d’affichage doivent être envoyés manuellement pour indiquer le moment où le contenu renvoyé a été affiché. Cela s’effectue via la commande sendEvent.

Cookies cookies

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

Demander l’emplacement request-placement

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

Implications Analytics analytics

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 :

  • Un flux de données configuré pour Analytics. Ce flux de données est utilisé pour les interactions du SDK Web.
  • Un second flux de données sans configuration Analytics. Ce flux de données est utilisé pour les demandes d’API de serveur. Vous devez configurer ce flux de données avec la même configuration de destination que celle que vous avez configurée pour Analytics.

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.

Requête côté serveur server-side-request

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.

IMPORTANT
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

Requête request

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.

Réponse côté serveur server-response

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
      }
   ]
}

Requête côté client client-request

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,
                        },
                    ],
                },
            },
        },
    });
}

Exemple d’application sample-app

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.

recommendation-more-help
ad108910-6329-42f1-aa1d-5920a2b13636