[Alpha]{class="badge informative"}

Personalizzazione ibrida con Server SDK

In un’implementazione di personalizzazione ibrida, il server richiede contenuti personalizzati ed è il browser del visitatore a eseguirne il rendering. Adobe Experience Platform Server SDK per JavaScript o Server SDK richiede il contenuto mentre il server crea la pagina e Web SDK la esegue nel browser.

Rispetto alla personalizzazione lato client, questo approccio offre i seguenti vantaggi:

  • Personalization è pronto prima. Il server richiede proposte durante la creazione della pagina, pertanto il browser non attende una richiesta separata all’Edge Network prima di poter eseguire il rendering del contenuto.
  • Sfarfallio ridotto. Poiché le proposte sono già presenti nella pagina, il browser può eseguirne il rendering non appena viene caricato il Web SDK.
  • Il server può utilizzare anche le decisioni. Ad esempio, il server può scegliere quali prodotti caricare in base a una proposta prima di inviare la pagina.
NOTE
Il server SDK è in modalità alfa. Rivedi le funzionalità supportate prima di pianificare un'implementazione.

Come funziona how-it-works

  1. Il browser del visitatore richiede una pagina dal server.
  2. Il server chiama sendEvent con l’opzione personalization sull’handle forRequest del visitatore. Il risultato contiene le proposte del visitatore.
  3. Il server include le proposte nel HTML restituito.
  4. Nel browser, il Web SDK esegue il rendering delle proposte con il comando applyPropositions.
  5. Il Web SDK invia un evento di visualizzazione per le proposte sottoposte a rendering.

Prerequisiti prerequisites

  • Un flusso di dati con Adobe Target o Adobe Journey Optimizer abilitato. Imposta il tipo di accesso su autenticazione mista, perché il server invia richieste autenticate e il browser invia quelle non autenticate. Vedi Autenticazione.
  • Server SDK, installato e configurato sul server.
  • Il Web SDK nelle tue pagine, configurato con gli stessi orgId e datastreamId.

Passaggio 1: richiesta di proposte sul server server

Quando il server gestisce una richiesta di pagina, richiede proposte per le superfici o gli ambiti decisionali su tale pagina. Imposta esplicitamente l’URL della pagina, perché l’intestazione Referer della richiesta contiene la pagina previous durante una navigazione. Vedi Intestazioni contestuali e inoltrate.

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 non esegue il rendering delle proposte né invia eventi di visualizzazione. Li restituisce solo. Se la richiesta non riesce, restituisce un array vuoto in modo che la pagina venga comunque riprodotta con il suo contenuto predefinito.

Passaggio 2: includere le proposte nella pagina page

Serializza le proposte nel HTML restituito dal server. Esci dal carattere < in modo che il contenuto di una proposta non possa chiudere anticipatamente l’elemento <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>`);

Passaggio 3: eseguire il rendering delle proposte nel browser browser

Dopo aver configurato il Web SDK nella pagina, passare le proposte a applyPropositions. Per le offerte HTML che non includono un selettore, utilizza metadata per indicare al Web SDK dove posizionare ciascuna di esse. Consulta Rendering offerte 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 non invia eventi di visualizzazione da solo. La seconda chiamata sendEvent registra le proposte che il visitatore ha visto. Vedi Gestione eventi di visualizzazione.

Mantieni coerente l’identità del visitatore identity

Per ottenere una reportistica e una personalizzazione accurate, il server e il browser devono identificare il visitatore nello stesso modo:

  • Identità primaria: ogni evento inviato da Server SDK deve includere un’identità primaria in xdm.identityMap. Vedere Includere un’identità primaria.
  • ECID: il Web SDK memorizza l’ECID del visitatore nel cookie kndctr_<orgId>_identity. Il Server SDK utilizza lo stesso ECID solo se è in grado di leggere il cookie tramite il servizio cookie passato a forRequest. In caso contrario, il server e il browser utilizzano ECID diversi per lo stesso visitatore. Consulta Istanze e richieste.

Il Server SDK non include un servizio cookie che legge i cookie di richiesta del visitatore. Consulta Servizi Platform per l’interfaccia che un servizio cookie deve implementare.

recommendation-more-help
experience-platform-help-collection