Transmettre le contexte client à un chatbot IA pour l'e-commerce
Permettez à une page de commande connectée de fournir l'ID de commande actuel, prouvez que le connecteur l'utilise, remplacez-le lorsque le visiteur change de commande et sécurisez le modèle en production.
Pour transmettre le contexte client à un chatbot IA en toute sécurité, laissez la page sélectionner l'enregistrement actuel pendant qu'une API autorisée par le serveur reste la source de vérité.
Une page e-commerce avec utilisateur connecté sait déjà quel client et quelle commande le visiteur consulte. Le contexte de session permet à cette page de transmettre un petit ensemble de valeurs actuelles à l'assistant, afin que le visiteur puisse demander “Where is my order?” sans avoir à saisir à nouveau l'ID de commande.
Ce tutoriel utilise le portail de commandes fictif Northstar, le widget réel WebChatAgent et un point de terminaison HTTP contrôlé DummyJSON. La page fournit `order_id` ; un API Connector en lecture seule fournit le statut fictif et l'ETA. Aucun client, expédition, boutique, compte de paiement ou identifiant réel n'est impliqué.
Vous allez valider trois états distincts : sans contexte, l'assistant demande un ID, `A-1023` devient automatiquement l'argument du connecteur, et un événement d'exécution le remplace par `A-2048`. Vous comparerez également l'attribut HTML, la variable globale JavaScript, l'événement d'exécution, les interfaces WordPress et les alias en marque blanche.
Le contexte du navigateur améliore le confort d'utilisation mais ne constitue pas une authentification. Le modèle de production restreint les domaines autorisés et transmet un jeton opaque à courte durée de vie que votre API valide côté serveur avant de renvoyer la réponse minimale nécessaire.
Lecteur vidéo respectueux de la vie privée (en deux clics)
Chatbot IA pour l'e-commerce : il connaît la commande avant même que vous ne posiez la question
Transmettez le contexte client et commande à un chatbot e-commerce et utilisez-le de façon sécurisée avec l'API Connector.
Le lecteur YouTube reste bloqué jusqu'à ce que vous cliquiez sur Lecture. Son chargement connecte votre navigateur à YouTube et peut transmettre des données techniques à Google.
Ouvrir directement sur YouTubeCe que vous maîtriserez à la fin
- Une base de référence vérifiée sans contexte
- Une intégration avec `context-data` qui fournit la commande actuelle
- Un résultat de connecteur réel en lecture seule pour A-1023
- Un remplacement à l'exécution qui utilise uniquement A-2048 par la suite
- Options d'implémentation pour JavaScript, WordPress et marque blanche
- Une liste de contrôle pour la production basée sur les domaines, les jetons opaques et la validation côté serveur
Avant de commencer
- Un assistant WebChatAgent de préproduction avec accès à l'API Connector
- Une page de test en anglais en Light Mode sur un domaine autorisé
- Un point de terminaison fictif en lecture seule avec des données fictives
- L'accès au code d'intégration du widget ou au placement WordPress
- Une trace écrite des attentes pour la référence, le contexte initial et le contexte de remplacement
- Pour la production : un backend capable de générer et de valider des jetons opaques à courte durée de vie
Le contexte de page sélectionne l'enregistrement ; l'API fournit la vérité
La page intégratrice envoie un enregistrement plat clé-valeur avec chaque requête de chat. Les clés correspondantes peuvent renseigner les champs requis de l'API Connector, mais elles ne deviennent pas des connaissances permanentes. Le connecteur effectue toujours la requête HTTP en direct et sa réponse reste la référence pour le statut et l'ETA.
Un événement `webchatagent:context` remplace l'intégralité de l'enregistrement actuel. Le remplacement évite qu'un ancien ID de commande ne subsiste discrètement aux côtés d'un nouveau. Effacez le contexte avec un objet vide ou `null` lorsque le visiteur se déconnecte.
Considérez chaque valeur du navigateur comme une entrée modifiable. Les restrictions de domaine contrôlent les endroits où le widget se charge ; un jeton signé, à courte durée de vie ou opaque associé à une autorisation côté serveur contrôle quel enregistrement privé peut être renvoyé.
01–08
Configuration pas à pas
Créer un connecteur d'état de commande en lecture seule
La clé de contexte et le champ requis du connecteur doivent porter exactement le même nom.
Créez le connecteur sur un assistant dédié aux tests (TEST). Utilisez GET et le point de terminaison contrôlé `https://dummyjson.com/http/200/Order_{order_id}_is_in_transit_eta_August_8`. Ajoutez un champ obligatoire Text nommé `order_id` ; le placeholder et le nom du champ doivent correspondre caractère pour caractère.
Indiquez à l'outil de s'exécuter uniquement pour la question fictive sur le statut de commande, d'utiliser la valeur actuelle exacte de `order_id` issue du contexte visiteur et de renvoyer uniquement l'ID de commande, le statut normalisé et l'ETA. Le point de terminaison est une simulation publique, pas une intégration de boutique. Ne placez jamais de jeton de production ou d'enregistrement client dans le prompt du connecteur.
- Méthode : GET uniquement
- Champ obligatoire : `order_id`
- Données : simulation fictive DummyJSON
Enregistrer la référence de base sans contexte
L'assistant doit demander l'ID de commande manquant et ne doit pas inventer de statut.
Intégrez le widget sans `context-data`, démarrez une nouvelle conversation et demandez exactement : “Where is my order?” Bien que le portail affiche visiblement A-1023, le widget ne peut pas lire le texte arbitraire de la page et doit demander l'ID de commande.
Arrêtez-vous si la réponse indique déjà A-1023, en transit ou le 8 août. Cela signale un état de conversation obsolète, des données ayant fuité du prompt ou une supposition non sécurisée. Effacez la conversation et le contexte du navigateur avant de continuer.
Transmettre A-1023 avec l'attribut context-data
Utilisez un petit enregistrement plat qui ne contient que les valeurs nécessaires pour cette session.
Pour une page générée côté serveur, ajoutez `context-data="Customer=Jane Doe;order_id=A-1023;locale=en-US"` à `<web-chat-agent>`. Les paires séparées par des points-virgules et les objets JSON plats sont pris en charge ; les objets imbriqués ne remplacent pas une requête backend dédiée.
L'enregistrement normalisé autorise au maximum 20 clés, 64 caractères par clé, 500 par valeur et 4,000 caractères sérialisés au total. Utilisez des clés stables comme `order_id`, évitez les données secrètes et gardez les étiquettes de présentation comme Customer facultatives.
Prouver que A-1023 parvient au connecteur
La même question renvoie maintenant le statut sans redemander l'ID.
Démarrez une nouvelle conversation avec le contexte activé et répétez “Where is my order?” L'assistant doit utiliser A-1023 pour l'argument d'outil obligatoire `order_id`, appeler le point de terminaison GET et répondre que la commande fictive est en transit avec une ETA au 8 août.
La preuve repose sur trois observations : l'intégration contient A-1023, l'URL du connecteur contient le placeholder `{order_id}` et la réponse simulée en direct contient A-1023 ainsi que le texte de statut. Le contexte sélectionne l'enregistrement ; la réponse du point de terminaison fournit le statut.
Remplacer le contexte après connexion ou navigation
L'événement d'exécution remplace l'intégralité de l'enregistrement pendant que le widget reste ouvert.
Lorsque le visiteur passe à A-2048, déclenchez `new CustomEvent('webchatagent:context', { detail: { Customer: 'Jane Doe', order_id: 'A-2048', locale: 'en-US' } })`. Ne faites cela qu'après que l'état de la page et la session autorisée concordent sur le nouvel enregistrement.
Le remplacement est total : les clés omises disparaissent au lieu de subsister. Lors de la déconnexion, émettez un objet vide ou `null`. Ne fusionnez pas les anciennes valeurs client et commande dans le code applicatif à moins que ce comportement ne soit explicitement requis et testé.
Vérifier que seul A-2048 est utilisé ensuite
Le prochain appel de connecteur ne doit pas réutiliser l'ancien ID de commande de l'historique du chat.
Laissez le widget ouvert et demandez : “What is the status of the order now shown on this page?” La réponse suivante doit contenir A-2048 et le statut simulé, sans mentionner A-1023.
Conservez ce test à trois états sous forme de non-régression : contexte manquant, contexte initial et remplacement à l'exécution. Répétez-le après toute modification du connecteur, du prompt système, du modèle, du widget ou de l'application hôte. Notez la question, le contexte actuel, l'argument de l'outil, la réponse du point de terminaison et l'horodatage.
Choisir l'attribut, la variable globale, l'événement ou l'intégration de plateforme
Tous les points d'entrée pris en charge se normalisent dans le même contexte de visiteur actuel.
Utilisez l'attribut HTML pour les valeurs générées côté serveur. Définissez `window.webchatagentContext` avant le script asynchrone du widget lorsque JavaScript gère la session initiale. Utilisez `webchatagent:context` pour les changements de connexion, déconnexion, compte, panier, produit ou route après le chargement.
Dans WordPress, utilisez le filtre `webchatagent_context_data` pour les valeurs générées de manière centralisée ou `[webchatagent_inline context-data="order_id=A-1023"]` pour un placement inline. Les clients en marque blanche utilisent `window.chatWidgetContext` et l'événement `chat-widget:context` avec une sémantique de remplacement identique.
Sécuriser la recherche en production
Le contexte du navigateur est une entrée modifiable, jamais une preuve d'identité client.
Restreignez `allowedDomains` aux hôtes exacts de production et de préproduction. N'autorisez pas une recherche de commande simplement parce que le contexte contient un nom, un e-mail ou un numéro de commande ; un visiteur peut modifier chaque valeur dans les DevTools.
Faites en sorte que votre backend génère un jeton opaque à courte durée de vie pour la session connectée, transmettez uniquement ce jeton en tant que contexte et laissez le connecteur appeler un point de terminaison de lecture avec les privilèges minimaux. Le point de terminaison valide côté serveur le jeton, la propriété du client, l'expiration et le périmètre demandé, puis renvoie uniquement l'ID de commande, le statut et l'ETA. Révoquez ou faites expirer le jeton lors de la déconnexion.
Exemple et résultat
Découvrez le test pratique et son résultat
Chaque tutoriel présente une saisie précise, le résultat attendu et le récapitulatif transparent des vérifications effectuées localement.
Exemple pratique : Transmettre le contexte client à un chatbot IA pour le suivi de commande
Ce cas d'usage exact a été exécuté sur un compte de démonstration temporaire.
Données de test exactes
Ask “Where is my order?” first without context and then with `order_id=A-1023`. In the same context-enabled widget, dispatch `webchatagent:context` with `order_id=A-2048` and ask for the order now shown.
Résultat attendu
Sans contexte, l'assistant demande un ID de commande. Avec le contexte, le connecteur utilise A-1023 et renvoie en transit avec une ETA au 8 août. Après remplacement, la réponse suivante utilise A-2048 et ne mentionne pas A-1023.
Ce qui a été réellement vérifié
L'exécution isolée en anglais et Light Mode a validé les trois états face à la simulation contrôlée DummyJSON. La référence a demandé l'ID manquant ; le contexte initial a produit A-1023, en transit et le 8 août ; le remplacement à l'exécution a produit A-2048 sans mention de A-1023 dans la dernière réponse. Le contrat du connecteur exigeait `order_id`, et le nettoyage final a rapporté exactement 0 utilisateurs de tutoriel.
Conseils et astuces
Rendre la configuration fiable et pérenne
Testez toujours avec des cas réalistes, documentez votre état de référence et n'appliquez qu'un changement à la fois. C'est la seule façon de mesurer de réels progrès.
Conserver des clés stables entre la page et le connecteur
Utilisez un seul nom technique documenté comme `order_id` partout. Une simple différence d'orthographe ou de casse empêche la réutilisation automatique du champ.
Séparer le confort d'utilisation de l'autorisation
Le contexte peut sélectionner ce que le visiteur regarde. Seul votre backend peut décider de ce que le visiteur connecté est autorisé à lire ou à modifier.
Effacer le contexte lors de la déconnexion
Émettez un objet vide ou null avant que le visiteur suivant ne puisse utiliser le widget, et démarrez une nouvelle conversation lorsque le titulaire du compte change.
Que faire en cas de problème ?
Dépannage
Vérifiez méthodiquement l'état du service, les autorisations d'accès et les données de test avant de modifier le modèle ou le prompt.
Le bot continue de demander l'ID de commande
Vérifiez le code `context-data` final généré, l'orthographe exacte de `order_id`, l'ordre de chargement des scripts et le domaine autorisé. Démarrez une nouvelle conversation afin qu'un ancien échange sans contexte ne fausse pas la comparaison.
Le connecteur reçoit l'ancienne commande
Vérifiez que l'événement d'exécution se déclenche après le changement de page et remplace la totalité de l'objet de détails. Effacez l'état applicatif obsolète et vérifiez que la carte visible ainsi que la charge utile émise indiquent toutes deux A-2048.
L'assistant mentionne un statut sans résultat d'outil
Interrompez le déploiement. Renforcez le rôle système, gardez le statut hors du contexte et du prompt, et rendez obligatoire l'utilisation du connecteur en lecture seule pour chaque réponse liée au statut de commande.
Les données de commande privées sont visibles après modification de la valeur dans le navigateur
Traitez cela comme une faille d'autorisation. Supprimez l'accès direct basé sur l'ID, exigez un jeton validé par le serveur à courte durée de vie, renouvelez les identifiants exposés et auditez les logs du point de terminaison.
Prêt pour un test en conditions réelles ?
Utilisez la vidéo publiée comme guide, puis remplacez l'URL fictive en production par un point de terminaison en lecture seule qui valide un jeton de session opaque. Rejouez les trois états de contexte et ajoutez les résultats à votre suite de tests de non-régression.
Ressources complémentaires
Intégration de chatbot CRM
Utilisez le contexte client avec un CRM propriétaire et des limites d'autorisation strictes.
Connecter un chatbot à une API REST
Créez et validez le connecteur en lecture seule utilisé par ce modèle de contexte.
Référence développeur pour le contexte du widget
Consultez les interfaces actuelles, les alias, le comportement de remplacement et les limites.