Fonctions de plan payants

Les fonctions suivantes ne sont disponibles que pour les utilisateurs d'un plan Plus ou d'un plan supérieur. Plus

• Intégration Téléphonique
• Nœuds finaux privés
• Recherche
• APIwatsonx Assistant v2
• Historique webhook

L' API de journauxv2 est disponible avec un essai gratuit du plan Plus.

Les fonctions suivantes sont uniquement disponibles pour les utilisateurs avec des plans d'entreprise. Entreprise

• Suivi des activités
• Environnements multiples
• Remplacer les valeurs par défaut du système pour les modes de réponse
• Envoi d'événements au segment

Le type de plan de l'instance de service que vous utilisez est affiché dans l'en-tête de page. Vous pouvez opter pour un type de plan plus complet. Pour plus d'informations, voir Mise à niveau.

Plans basés sur l'utilisateur : explication

Contrairement aux plans basés sur les API, qui mesurent l'utilisation en fonction du nombre d'appels API effectués au cours d'un mois, les plans Plus et Entreprise mesurent l'utilisation en fonction du nombre d'utilisateurs actifs mensuels.

Un utilisateur actif mensuel (MAU) est un utilisateur unique qui a au moins une interaction avec votre assistant ou votre application personnalisée au cours du mois de facturation calendaire.

Un utilisateur unique est reconnu à l'aide de l'ID utilisateur associé à la personne qui interagit avec votre assistant. La discussion Web et d'autres intégrations intégrées vous permettent de définir automatiquement cette propriété.

Vous pouvez calculer les MAU par vous-même, à la fois pour IBM Cloud et pour IBM Cloud Pak for Data. Pour calculer les unités MSU, utilisez le noeud final logs pour exporter les conversations. Pour un mois particulier, comptez le nombre d'ID utilisateur uniques trouvés dans les résultats. Les ID utilisateur comportant plus de 50 messages (appels API) par mois sont comptés plus d'une fois pour 50 messages. Dans un cas d'utilisation courant, où chaque ID utilisateur représente un client conversant avec un assistant, le nombre moyen de messages par utilisateur est généralement bien inférieur à 50 messages, il est donc inhabituel de compter un ID utilisateur plusieurs fois.

Spécification de l'ID utilisateur avec l'API REST

Si vous utilisez un client personnalisé avec l'API watsonx Assistant, vous devez définir la propriété user_id dans le contenu du message que votre client envoie à la méthode message. La propriété user_id est spécifiée à la racine du corps de la demande, comme dans cet exemple :

{
  "input": {
    "message_type": "text",
    "text": "I want to cancel my order"
  },
  "user_id": "my_user_id"
}

Dans certaines versions plus anciennes du kit de développement logiciel (SDK), la propriété user_id n'est pas prise en charge comme paramètre de méthode de niveau supérieur. Vous pouvez également spécifier user_id dans l'objet context.global.system imbriqué.

Pour plus d'informations sur la propriété user_id, voir la documentation de référence de l'API :

• v2 sans état /message
• v2 avec état /message

Si l'ID utilisateur n'est pas spécifié

Si vous utilisez une application client personnalisée et que vous ne définissez pas de valeur user_id, le service la définit automatiquement sur l'une des valeurs suivantes :

• Session_id (APIv2 uniquement): propriété définie dans l'API v2 qui identifie une conversation unique entre un utilisateur et l'assistant. Un ID session est fourni dans les appels d'API /message qui sont générés par les intégrations intégrées. La session se termine lorsqu'un utilisateur ferme la fenêtre de discussion ou lorsque le délai d'inactivité est atteint.

  Si vous utilisez l'API message v2 sans état, vous devez spécifier l'attribut session_id avec chaque message dans une conversation en cours (dans context.global.session_id).

• conversation_id (API v1 uniquement): Une propriété définie dans l'API v1 qui est stockée dans l'objet contextuel d'un appel à l'API /message. Cette propriété peut être utilisée pour identifier plusieurs appels d'API /message associés à un seul échange conversationnel avec un utilisateur. Toutefois, le même identifiant n'est utilisé que si vous le conservez explicitement et le renvoyez avec chaque demande formulée dans le cadre de la même conversation. Sinon, un nouvel ID est généré pour chaque nouvel appel d'API /message.

Si la même personne discute avec votre assistant à trois reprises au cours de la même période de facturation, la façon dont vous représentez cet utilisateur dans l'appel API a une incidence sur la manière dont les interactions sont facturées. Si vous identifiez l'interaction utilisateur avec la propriété user_id, elle compte pour une utilisation. Si vous identifiez l'interaction de l'utilisateur à l'aide d'une adresse session_id, elle compte pour trois utilisations car une session distincte est créée pour chaque interaction.

Les applications personnalisées doivent capturer une propriété user_id ou session_id unique et transmettre l'information à watsonx Assistant. Choisissez un ID ne permettant pas d'identifier une personne et qui ne changera pas au cours du cycle de vie du client. Par exemple, n'utilisez pas l'adresse électronique d'une personne comme ID utilisateur. En effet, la syntaxe de user_id doit répondre aux exigences des champs d'en-tête telles que définies dans le RFC 7230.

Les intégrations intégrées dérivent de l'ID utilisateur de l'une des manières suivantes :

• Pour les intégrations de Facebook, la propriété user_id prend la valeur de l'ID d'émetteur fourni par Facebook dans son contenu.
• Pour les intégrations de Slack, la propriété user_id est une concaténation de l'ID d'équipe, par exemple, T09LVDR7Y, et de l'ID de membre de l'utilisateur, par exemple, W4F8K9JNF. Par exemple, T09LVDR7YW4F8K9JNF.
• Pour l'intégration Web, vous pouvez définir la valeur de la propriété user_id.

La facturation est gérée par utilisateur actif mensuel par instance de service. Si un même utilisateur interagit avec des assistants qui sont hébergés par différentes instances de service appartenant au même plan, chaque interaction est considérée comme une utilisation distincte. Vous êtes facturé séparément pour l'interaction de l'utilisateur avec chaque instance de service.

Traitement des utilisateurs anonymes

Si votre application personnalisée ou votre assistant interagit avec des utilisateurs anonymes, vous pouvez générer un ID universel unique aléatoire pour représenter chacun de ces utilisateurs. Pour plus d'informations sur les UUID, voir la RFC 4122.

• Pour l'intégration Web, si vous ne transmettez pas l'identificateur de l'utilisateur au début de la session, la discussion Web en crée un pour vous. Elle crée un cookie interne avec un ID anonyme généré. Le cookie reste actif pendant 45 jours. Si le même utilisateur revient sur votre site plus tard dans le mois et s'entretient à nouveau avec votre assistant, l'intégration de discussion Web le reconnaît. En outre, vous n'êtes facturé qu'une seule fois lorsque le même utilisateur anonyme interagit avec votre assistant à plusieurs reprises au cours du même mois.

Si un utilisateur anonyme se connecte, et qu'il est par la suite identifié comme ayant fait une demande sous un ID connu, vous êtes facturé deux fois. Chaque message avec un ID utilisateur unique est facturé comme un utilisateur actif indépendant. Pour éviter cette situation, vous pouvez inviter les utilisateurs à se connecter avant de lancer une discussion. Vous pouvez également utiliser l'ID utilisateur anonyme pour représenter l'utilisateur de manière cohérente.

Centres de données

IBM Cloud dispose d'un réseau de centres de données mondiaux qui offrent des avantages en termes de performances à ses services de cloud. Voir IBM Cloud les centres de données mondiaux pour plus de détails.

Vous pouvez créer des instances de service watsonx Assistant hébergées dans les emplacements de centre de données suivants :