Fermer la logique des événements / Blogs / Perficient

Sitecore Personalize dispose de plusieurs composants prêts à l’emploi qui informent l’utilisateur, tels que la prise de contrôle des fenêtres contextuelles, les fenêtres contextuelles d’angle, la barre latérale et la barre d’alerte. Ces composants comportent tous une icône de fermeture qui masquera le composant de l’écran. Mais il n’existe aucune logique prête à l’emploi pour empêcher leur réaffichage.

Imaginez que nous ayons une bannière d’alerte qui apparaît en haut de la page. Vous utilisez le ciblage de pages pour exécuter l’expérience sur toutes les pages. Cela garantira que l’utilisateur voit les informations lorsqu’il accède au site, quelle que soit la page sur laquelle il arrive en premier. L’utilisateur arrive sur la page Contactez-nous et voit la bannière d’alerte. Ils cliquent sur l’icône X pour fermer la bannière et accéder à une autre page. La bannière apparaît à nouveau. Ils cliquent sur l’icône X pour fermer la bannière et accéder à une autre page. La bannière réapparaît ! Quelle expérience frustrante ! L’utilisateur pense, je ne veux plus voir cette bannière !

Voici deux manières de suivre l’événement de rejet et d’empêcher l’apparition de la bannière après son rejet.

Utilisation d’événements et de conditions

Les conditions vous permettent de contrôler le moment où une expérience est affichée, un peu comme le ciblage de pages. Une condition est simplement un bloc de code javascript qui peut accéder aux données et événements des invités. Une condition renvoie vrai si l’expérience doit s’afficher et faux si elle ne doit pas s’afficher. Ce javascript s’exécute côté serveur. Vous avez accès au contexte complet de l’invité, mais pas à la fenêtre du navigateur du client. Vous pouvez utiliser le même [[parameter | type | default value ]]comme dans la variante d’expérience ou le modèle Web pour créer un formulaire modifiable par l’utilisateur permettant de personnaliser la condition.

Imaginez notre exemple de bannière d’alerte. Nous souhaitons créer une condition qui recherche les événements de l’invité pour voir si la bannière d’alerte a été précédemment ignorée. CDP conserve toutes les données d’événement des 1 000 dernières sessions (https://doc.sitecore.com/cdp/en/users/sitecore-cdp/data-availability-in-sitecore-cdp.html). Notez que si vous disposez d’une longue expérience sur un site où les utilisateurs ont un nombre élevé de sessions, il est possible que la bannière d’alerte réapparaisse après que la session contenant l’événement de rejet ait quitté le stockage. En général, cette solution fonctionnera sur tous les appareils une fois que l’utilisateur sera connecté et pourra lier sa session à son profil d’invité.

(function () {
  var session = guest.sessions[0];
  if (!session) {
    return true;
  }
  for (var j = 0; j < session.events.length; j++) {
    var data = session.events[j];
    if (data.type === "[[Event Name | string | ALERT_BAR_DISMISSED]]") {
      return false;
    }
  }
  return true;
})();

Dans la section sortie de l’onglet de configuration, nous souhaitons modifier la description. Incluez les paramètres dans la description afin que l’utilisateur puisse personnaliser la condition de cette expérience. La description s’affiche lorsque l’utilisateur sélectionne la condition dans l’écran d’expérience. Les champs paramétrés s’afficheront en gras.

L’onglet de configuration d’une condition

Dans la section d’aperçu en bas de l’écran, vous pouvez voir comment la description textuelle sera affichée avec les champs en gras ainsi qu’un aperçu du mode de saisie.

La section d’aperçu du texte de l’onglet de configuration des conditions

La section d’aperçu des entrées de l’onglet de configuration des conditions

Dans le modèle Web, nous créerons un paramètre qui permettra à l’utilisateur de donner à cette expérience un identifiant unique. Ceci est important, donc ignorer BannerA n’empêche pas l’affichage de toutes les futures bannières. Notez dans ce code que nous ajoutons un écouteur d’événement sur le bouton de fermeture. Lorsque vous cliquez sur le bouton de fermeture, nous renvoyons un événement dans Personnaliser afin que la condition puisse le trouver au prochain chargement de la page. Notez que nous pouvons utiliser Engage.settings.pointOfSale afin de ne pas avoir à coder en dur cette valeur. Cette valeur est lue à partir du SDK Engage dans le navigateur du client.

document.body.classList.add("show-TopBanner");
insertHTMLBefore('body', 'pers-');
// Declarations
const persExperience = document.querySelector("#pers-"+variant.ref+ ' #pers_TopBanner');
const persCloseButton = document.querySelector("#pers-"+variant.ref+ ' .pers__btn-close');

// Declare Pers function event
const sendInteractionToPersonalize = function(interactionType){
    const type = "[[ Experience ID | String | ALERT_BAR | {required: true}]]_" + interactionType;
    const eventData = {
        "channel": "WEB",
        "pointOfSale": Engage.settings.pointOfSale,
    };
    window.engage.event(type, eventData);
}

//Listen on X button
persCloseButton.addEventListener("click", function(){
    persExperience.style.display = "none";
    document.body.classList.remove("show-TopBanner");
    sendInteractionToPersonalize("DISMISSED")
});

Lorsque vous prévisualisez l’expérience avec la condition, l’outil qa affiche une marque jaune indiquant qu’il a arrêté le traitement à l’étape de filtrage.

L’outil d’assurance qualité affichant l’icône jaune des personnes

L’outil QA s’arrête à l’étape de filtrage

Cela améliore les performances car le modèle de décision n’est pas exécuté et l’étape html/css n’est pas rendue.

Utiliser des cookies

Imaginons notre même bannière d’alerte mais cette fois en utilisant des cookies pour savoir si la bannière a été ignorée. Lorsque nous créerons notre expérience, nous n’aurons pas besoin de poser de condition cette fois-ci. Au lieu de cela, nous modifierons le modèle Web pour inclure une vérification permettant de voir si le cookie existe. Nous écrirons également un cookie lorsque la bannière d’alerte sera fermée. Remarquez ici que j’encapsule tout le bloc javascript d’avant dans une instruction if qui vérifie le cookie. Vous pouvez utiliser la variable variant.ref pour obtenir dynamiquement le GUID de la variante actuelle. Nous utiliserons variant.ref comme nom de notre cookie, donc rejeter BannerA n’empêche pas l’affichage de toutes les futures bannières.

if (!document.cookie.split(";").some((item) => item.trim().startsWith('pers-' + variant.ref + '='))) {
    document.body.classList.add("show-TopBanner");
    insertHTMLBefore('body', 'pers-');
    // Declarations
    const persExperience = document.querySelector("#pers-" + variant.ref + ' #pers_TopBanner');
    const persCloseButton = document.querySelector("#pers-" + variant.ref + ' .pers__btn-close');
    // Declare Pers function event
    const sendInteractionToPersonalize = function (interactionType) {
        const type = "[[ Experience ID | String | ALERT_BAR | {required: true}]]_" + interactionType;
        const eventData = {
            "channel": "WEB",
            "pointOfSale": Engage.settings.pointOfSale,
        };
        window.engage.event(type, eventData);
    }
    //Listen on X button
    persCloseButton.addEventListener("click", function () {
        persExperience.style.display = "none";
        document.body.classList.remove("show-TopBanner");
        sendInteractionToPersonalize("DISMISSED")
        document.cookie="pers-" + variant.ref + '=clicked; max-age=31536000; path=/'
    });
}

Lorsque vous prévisualisez cette expérience, l’outil d’assurance qualité affichera une coche verte indiquant qu’il a traité toutes les étapes, y compris le modèle de décision et les étapes HTML. Soyez conscient que cela pourrait rendre plus difficile le débogage de vos expériences. Si le cookie n’existe pas, l’expérience est ajoutée à la page. Si le cookie n’existe pas, l’expérience n’est pas ajoutée à la page. Il n’y a pas de scintillement de l’interface utilisateur ici car il n’affiche/masque pas l’expérience. Assurez-vous d’envelopper l’intégralité de votre bloc javascript dans la vérification des cookies afin de ne pas obtenir d’erreurs de référence nulle si votre code tente de lire des éléments du DOM.

Outils de développement affichant le cookie défini pour l’expérience

Cette solution améliore les performances car elle ne vous oblige pas à rechercher une session invité pour trouver un événement spécifique. Cependant, le cookie réside sur le navigateur du client. Dans cet exemple, j’ai défini l’expiration des cookies sur un an (31536000). Mais l’expérience peut s’afficher à nouveau si l’utilisateur bloque les cookies ou s’il efface ses cookies. C’est également spécifique à l’appareil. Si l’utilisateur passe à un autre appareil, l’expérience s’affichera à nouveau. Pour cette raison, il est important de mettre fin aux expériences qui ne sont plus utilisées afin que les utilisateurs ne voient pas d’expériences contenant des informations obsolètes ou incorrectes.

Conclusion

La méthode que vous choisirez de mettre en œuvre dépendra de ce qui convient le mieux à votre cas d’utilisation. Si vous souhaitez implémenter l’une de ces options sur les composants prêts à l’emploi, vous souhaiterez créer des modèles Web personnalisés en copiant/collant le code html/css/javascript du composant prêt à l’emploi. Les composants prêts à l’emploi ne peuvent pas être modifiés ou dupliqués.