Voici les informations dont vous avez besoin pour mettre en œuvre les API Experience et commencer à exécuter des campagnes. Il est essentiel que vous assuriez une mise en œuvre exhaustive et conforme avant de commencer à mener des campagnes de production. Ce guide part du principe que vous utilisez notre DYID DYID pour désigner l’utilisateur qui visite le site ou utilise l’application. Si vous planifiez une implémentation d’API uniquement avec des ID utilisateur générés de votre côté, passez à cette section.
Avant de commencer :
- Si vous envisagez de mettre en œuvre le script Dynamic Yield sur votre site Web et que vous ne l’avez pas encore fait, faites-le d’abord, puis revenez à ce guide.
-
Assurez-vous que votre flux de produits est opérationnel.
Un flux de produits est un fichier qui contient votre catalogue de produits (tous vos produits, ainsi que leurs métadonnées). Il permet une personnalisation basée sur les affinités, des recommandations de produits, des messages ayant un impact social et plus encore.
Vous pouvez créer et synchroniser votre flux de produits dans la console d’Experience OS ou à l’aide d’API.
Étape 1 : Générer des clés d’API
Créez des clés d’API pour votre application.
Si vous souhaitez appeler l’API directement du côté client, utilisez une clé d’API côté client ou demandez à votre serveur d’agir en tant que proxy pour le client, afin qu’il génère tous les rapports au nom des clients. Cette dernière option implique plus de travail, mais est en fait assez populaire : elle fonctionne bien avec la centralisation des rapports sur les actions des utilisateurs vers plusieurs systèmes en aval, et avec la dissimulation des détails d’implémentation et des clés du client.
Étape 2 : Effectuer un appel Choose pour obtenir des variantes de campagne
Toutes vos campagnes doivent avoir un Nom de Sélecteur d’API que vous utiliserez dans l’appel d’API Choose pour obtenir la variante souhaitée.
La réponse inclura les données produit nécessaires pour les campagnes de recommandation ou les variantes pour les campagnes de code personnalisées. En outre, Dynamic Yield enverra des attributs DecisionID ou SlotID (pour les campagnes de code personnalisé ou de recommandation, respectivement) dont vous nous ferez rapport ensuite dans l ’appel d’API Engagement si l’utilisateur clique sur une campagne.
Appeler Choose de manière asynchrone
Après le rendu initial de la page, vous pouvez également demander de manière asynchrone toutes les campagnes qui peuvent être affichées après le rendu de la page (en particulier, pour les éléments visuels en bas de page). Pour ces appels Choose, assurez-vous de définir "options": { "isImplicitPageview": false } dans le corps de la demande.
Étape 3 : Ajouter des ID utilisateur et de session à vos demandes d’API
Cela se fait à l’aide de cookies Dynamic Yield. Ajoutez des cookies tels que dyid, _dyid_server, et dyjsession à votre appel d’API afin que Dynamic Yield puisse reconnaître l’utilisateur.
Les cookies sont enregistrés par Dynamic Yield lorsque les scripts sont transférés en ligne. Si vous envoyez une requête Choose pour une page sur laquelle les scripts ne sont pas en cours d’exécution, et que l’utilisateur n’a pas d’ID utilisateur et de session existants sur les pages précédentes, vous devez nous envoyer des valeurs vides, et nous générerons de nouveaux ID utilisateur et de session, puis les renverrons.
Notez que si le mode Consentement actif aux Cookies est activé, vous devez inclure le paramètre active_consent_accepted. Pour plus d’informations, consultez l’article Mode de consentement actif aux cookies pour la gestion de la confidentialité des données utilisateur.
Apprenez-en plus sur les cookies Dynamic Yield et la façon de les mettre en œuvre.
Étape 4 : Signaler les événements
Signalez toute action significative qu’un utilisateur prend sur votre site ou votre application. Cela inclut généralement les opérations de panier et d’achat pour le commerce électronique, le lancement et la soumission de demandes pour les institutions financières, les vues vidéo dans le monde des médias et tout autre événement personnalisé selon vos besoins. Utilisez ces informations plus tard, pour le ciblage comportemental, la production de rapports, etc. Notez que si vous ne signalez les événements que du côté de votre serveur, il est plus facile d’éviter le « bruit » généré par les bots et autres.
Apprenez-en plus sur les événements de reporting.
Étape 4 : Suivre et signaler l’engagement des utilisateurs avec les variantes
Dans le cadre de l’exécution de campagnes d’API sur la page, vous devez stocker les identifiants uniques renvoyés dans la réponse de l’appel Choose. Cela se fait généralement du côté client. Lorsqu’un utilisateur clique sur une variante ou un produit spécifique recommandé, vous devez nous renvoyer ces identifiants.
- Pour un clic sur une variante de code personnalisé, il s’agirait de decisionId (et également des variationIds uniquement en cas de campagnes multi-variantes telles que des sliders).
- Pour un clic sur un élément recommandé, ce serait le slotId.
Sur le Web, il est fréquent de stocker cela en tant qu’attributs de données sur l’élément DOM qui effectue le rendu de la variante, par exemple <div id= ... data-dy-decision-id="d512ae8f">.
Configurez des récepteurs de clics sur toutes les variantes rendues et transmettez tout clic à Dynamic Yield en utilisant les identifiants uniques fournis. Cette étape est presque toujours initiée du côté client, mais peut être exécutée en proxy du côté serveur vers notre API pour éviter d’avoir trop de logique (ou de clés) chez les clients.
Apprenez en plus sur le reporting de l’engagement des utilisateurs.
Implémentation d’API uniquement
Identifiants utilisateur et de session
Avec l’implémentation d’API uniquement, vous devez décider quels identifiants utilisateur et de session utiliser. Existe-t-il déjà des identifiants de ce type dans votre application qui peuvent être réutilisés ? Quelle est leur durée de vie et cela correspond-il à vos attentes ?
En cas de doute, consultez nos Meilleures pratiques. Un exemple de code pour la gestion de ces identifiants est également disponible dans le tutoriel Petshop.
Rapports sur les pages vues
En mode API uniquement, vous devez signaler une nouvelle page vue pour toutes les pages de votre site. Pour une latence minimale, cela se fait généralement en récupérant les variantes de campagne d’API choisies pour cette page, en un seul aller-retour vers notre endpoint d’API Choose.
Intégrez un appel Choose dans tous les types de pages de votre application avec le contexte de page approprié, même sans faire référence à aucune campagne.
Activer la prise en charge de la prévisualisation
Bien que cela ne soit pas techniquement nécessaire, nous vous recommandons fortement d’ajouter également le code pour prendre en charge la prévisualisation du contenu directement depuis la console d’Experience OS.