Utiliser des événements

Un événement est l’un des trois éléments de la configuration Interact dans l’environnement de conception qui interagissent directement avec l’API d’Interact. Lorsque vous codez votre point de contact pour qu’il fonctionne avec l’API d’Interact, vous utilisez la méthode postEvent pour faire référence à des événements. Le nom d’un événement utilisé dans l’API d’Interact doit être identique au nom de l’événement configuré dans l’environnement de conception. Ce nom n’est pas sensible à la casse.

Un événement déclenche une ou plusieurs des actions prédéfinies suivantes :

Déclencher la resegmentation : l’environnement d’exécution exécute à nouveau tous les diagrammes temps réel du référentiel actuel associés au canal interactif à l’aide des données actuelles de la session du visiteur.

Lors de la conception de votre interaction, n’oubliez pas qu’à moins d'indiquer un diagramme spécifique, la resegmentation exécute à nouveau tous les diagrammes temps réel associés au canal interactif du référentiel actuel et que toute demande d’offres doit attendre la fin de leur exécution. Une resegmentation excessive au cours d’une seule visite peut entraîner pour le client une baisse visible des performances du point de contact.

Placez le client dans de nouveaux segments lorsque des données significatives ont été ajoutées à l’objet de session d’exécution. Ces nouvelles données peuvent provenir de demandes de l’API d’Interact (comme une modification du référentiel) ou d’actions du client (comme l’ajout de nouveaux articles à une liste cadeaux ou au panier).

Journaliser le contact de l’offre : l’environnement d’exécution signale les offres recommandées afin que le service de la base de données historise les offres dans l’historique des contacts.

Pour les intégrations Web, il est conseillé d’historiser les contacts d’offre au cours de l’appel demandant l’offre afin de minimiser le nombre de demandes entre le point de contact et le serveur d’exécution.

Si le point de contact ne renvoie pas les codes de traitement des offres présentées au visiteur, l’environnement d’exécution historise la dernière liste d’offres recommandées.

Journaliser l’acceptation de l’offre : l’environnement d’exécution signale les offres sélectionnées afin que le service de la base de données historise les offres dans l’historique des réponses.

Journaliser le refus de l’offre : l’environnement d’exécution signale les offres sélectionnées afin que le service de la base de données historise les offres dans l’historique des réponses.

Lorsque vous créez un événement comprenant plusieurs actions d’offres, gardez à l’esprit que l’API d’Interact procède à la même action pour l’offre associée. C’est pourquoi vous ne devez pas créer d’événement qui historise à la fois les acceptations et les refus d’offre, car ces deux éléments sont contraires. Toutefois, la création d’un événement unique historisant les contacts et l’acceptation d’offres ou les contacts et refus d’offres peut être utile dans votre environnement.

Par défaut, l’environnement d’exécution peut suivre deux types de réponses : l’acceptation et le refus d’offres. Vous pouvez modifier les types de réponse enregistrés par les événements d’historisation d’acceptations ou de refus d’offres à l’aide des propriétés de configuration accept et reject.

L’API d’Interact peut également utiliser des événements pour déclencher des actions définies à l’aide des paramètres d’événement de l’API. Ces événements comprennent l’historisation dans une table personnalisée, le suivi de plusieurs types de réponse et la spécification d’un diagramme spécifique à exécuter. Vous devrez peut-être créer certains événements avec une réaction du système non définie, ou plusieurs événements avec la même réaction du système, par exemple l’historisation des contacts, afin de pouvoir les utiliser avec les paramètres d’événement réservés.

Vous souhaiterez peut-être créer plusieurs événements avec l’action d’historisation des acceptations d’offres, soit un événement par type de réponse à historiser, soit un événement unique avec l’action d’historisation des acceptations d’offres utilisée pour chaque appel postEvent en vue d’historiser des types de réponse distincts.

Créez par exemple un événement avec l’action d’historisation des acceptations d’offres pour chaque type de réponse. Les réponses personnalisées suivantes sont définies dans la table UA_UsrResponseType [nom (code)] : Explore (EXP), Consider (CON) et Commit (CMT). Créez ensuite trois événements que vous nommerez LogAccept_Explore, LogAccept_Consider et LogAccept_Commit. Ces trois événements sont identiques (ils reposent sur l’action d’historisation des acceptations d’offres), mais leurs noms sont différents afin de permettre à la personne chargée de l’API d’Interact de les distinguer.

Vous avez également la possibilité de créer un événement unique avec l’action d’historisation des acceptations d’offres utilisée pour tous les types de réponse personnalisés. Nommez-le par exemple LogCustomResponse.

L’API d’Interact ne fait aucune différence fonctionnelle entre les événements, mais les conventions d’appellation peuvent apporter une clarification quant au code. Par ailleurs, si vous donnez un nom distinct à chaque réponse personnalisée, le rapport Synthèse de l’activité des événements du canal affiche les informations de façon plus précise.

Pour en savoir plus sur les paramètres réservés et la méthode postEvent, consultez le Guide administrateur d’Interact.

Événements définis par le système

L’onglet Événements contient la catégorie par défaut, Catégorie définie par le système. Il n’est pas possible de modifier, ajouter ou supprimer des événements de cette catégorie. Elle contient des événements qui correspondent à l’API d’Interact. Vous pouvez surveiller la fréquence d’occurrence de ces événements sur votre point de contact à l’aide du rapport µµµSynthèse de l'activité des événements du canal.

Ces événements comprennent :

Terminer la session : Marquer la fin de la session interactive d’un visiteur.

Obtenir l’offre : Demander une liste d’offres recommandées à présenter à un visiteur.

Obtenir le profil : Demander les données de profil du visiteur enregistrées dans la session. Ces données incluent des données temporelles ainsi que des données de la table de profils.

Définir référentiel : Modifier le référentiel d’un visiteur dans sa session interactive.

Définir le débogage : Outrepasser le niveau d’historisation actuel de la session interactive d’un visiteur.

Démarrer session : Marquer le début de la session interactive d’un visiteur.