Gebührenpflichtige Planoptionen

Die folgenden Funktionen stehen nur Benutzern eines Plus-Tarifs oder höher zur Verfügung. Plus

• Telefonintegration
• Private Endpunkte
• Search
• APIwatsonx Assistant v2
• Webhook protokollieren

Die v2-Protokoll-API ist mit einer kostenlosen Testversion des Plus-Plans verfügbar.

Die folgenden Funktionen sind nur für Benutzer von Enterprise-Plänen verfügbar. Enterprise

• Aktivitätsverfolgung
• Mehrere Umgebungen
• Systemstandardwerte für Antwortmodi überschreiben
• Ereignisse an Segment senden

Der Plantyp der Serviceinstanz, die Sie gerade verwenden, wird in der Seitenkopfzeile angezeigt. Sie können ein Upgrade von einem Plantyp auf einen anderen Typ durchführen. Weitere Informationen finden Sie unter Upgrade durchführen.

Erläuterungen zu benutzerbasierten Plänen

Im Gegensatz zu API-basierten Plänen, die die Nutzung anhand der Anzahl der API-Aufrufe während eines Monats messen, messen die Plus- und Enterprise-Pläne die Nutzung anhand der Anzahl der monatlich aktiven Benutzer.

Ein aktiver Benutzer pro Monat (MAU) ist jeder einzelne Benutzer, der im Abrechnungsmonat des Kalenders mindestens eine Interaktion mit Ihrem Assistenten oder Ihrer benutzerdefinierten Anwendung hat.

Ein eindeutiger Benutzer wird anhand der Benutzer-ID erkannt, die der mit Ihrem Assistenten interagierenden Person zugeordnet ist. Der Web-Chat und andere integrierte Integrationen legen diese Eigenschaft automatisch für Sie fest.

Sie können MAUs für IBM Cloud und IBM Cloud Pak for Dataselbst berechnen. Zur Berechnung von MAUs verwenden Sie den Endpunkt logs, um Dialoge zu exportieren. Zählen Sie für einen bestimmten Monat die Anzahl der eindeutigen Benutzer-IDs, die in den Ergebnissen gefunden wurden. Benutzer-IDs mit mehr als 50 Nachrichten (API-Aufrufe) in einem Monat werden mehr als einmal pro 50 Nachrichten gezählt. In einem allgemeinen Anwendungsfall, bei dem jede Benutzer-ID einen Kunden darstellt, der mit einem Assistenten im Gespräch ist, beträgt die durchschnittliche Anzahl der Nachrichten pro Benutzer in der Regel deutlich weniger als 50 Nachrichten, sodass es ungewöhnlich ist, eine Benutzer-ID mehrmals zu zählen.

Benutzer-ID mit der REST-API angeben

Wenn Sie einen angepassten Client mit der watsonx Assistant-API verwenden, müssen Sie die Eigenschaft user_id in den Nachrichtennutzdaten festlegen, die Ihr Client an die Methode message sendet. Die Eigenschaft user_id wird wie im folgenden Beispiel im Stammverzeichnis des Anforderungshauptteils angegeben:

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

In einigen älteren SDK-Versionen wird die Eigenschaft user_id nicht als Methodenparameter der höchsten Ebene unterstützt. Alternativ können Sie user_id im verschachtelten Objekt context.global.system angeben.

Weitere Informationen zur Eigenschaft user_id finden Sie in der API-Referenzdokumentation:

• v2 statusunabhängig /message
• v2 statusabhängig /message

Wenn die Benutzer-ID nicht angegeben ist

Wenn Sie eine angepasste Clientanwendung verwenden und keinen Wert für user_id festlegen, setzt der Service den Wert automatisch auf einen der folgenden Werte:

• Sitzungs-ID (nurv2-API): Eine in der v2-API definierte Eigenschaft, die einen einzelnen Dialog zwischen einem Benutzer und dem Assistenten identifiziert. In API-Aufrufen des Typs /message, die von den integrierten Integrationen generiert werden, wird eine Sitzungs-ID angegeben. Die Sitzung wird beendet, wenn ein Benutzer das Chatfenster schließt oder das Inaktivitätszeitlimit erreicht ist.

  Wenn Sie die statusunabhängige API 'message' der Version 2 verwenden, müssen Sie in einem laufenden Dialog mit jeder Nachricht die Sitzungs-ID (session_id) angeben (in context.global.session_id).

• conversation_id (nur v1 ): Eine in v1 definierte Eigenschaft, die im Kontextobjekt eines /message-API-Aufrufs gespeichert wird. Mithilfe dieser Eigenschaft können mehrere API-Aufrufe des Typs /message identifiziert werden, die einem einzelnen Dialog mit einem Benutzer zugeordnet sind. Es wird jedoch nur dieselbe ID verwendet, wenn die ID explizit aufbewahrt und mit jeder Anforderung zurückgegeben wird, die als Teil desselben Dialogs übergeben wird. Andernfalls wird für jeden Aufruf der API /message eine neue ID generiert.

Wenn dieselbe Person im selben Abrechnungszeitraum dreimal mit Ihrem Assistenten chattet, wirkt sich die Art und Weise, wie Sie diesen Benutzer im API-Aufruf darstellen, auf die Abrechnung der Interaktionen aus. Wenn Sie die Benutzerinteraktion mit einem Element user_id angeben, wird sie als 1 Nutzung gezählt. Wenn Sie die Benutzerinteraktion mit einer session_id identifizieren, zählt dies als drei Verwendungen, da für jede Interaktion eine separate Sitzung erstellt wird.

Entwerfen Sie alle angepassten Anwendungen so, dass ein eindeutiges Element user_id oder session_id erfasst wird und die Informationen an watsonx Assistant übergeben werden. Wählen Sie eine durch Personen nicht identifizierbare ID aus, die sich im Kundenlebenszyklus nicht ändert. Verwenden Sie zum Beispiel nicht die E-Mail-Adresse einer Person als Benutzer-ID. Tatsächlich muss die Syntax von user_id die in RFC 7230 definierten Anforderungen für Header-Felder erfüllen.

Es gibt folgende Möglichkeiten, wie die integrierten Integrationen die Benutzer-ID ableiten:

• Bei Facebook-Integrationen wird als Eigenschaft user_id die Absender-ID verwendet, die Facebook in den zugehörigen Nutzdaten angibt.
• Bei Slack-Integrationen ist die Eigenschaft user_id eine Verkettung der Team-ID, beispielsweise T09LVDR7Y, mit der Mitglieds-ID des Benutzers, beispielsweise W4F8K9JNF. Zum Beispiel T09LVDR7YW4F8K9JNF.
• Für Web-Chat können Sie den Wert der Eigenschaft user_id festlegen.

Die Abrechnung wird pro monatlich aktivem Benutzer je Serviceinstanz gesteuert. Falls ein einzelner Benutzer mit Assistenten interagiert, die von unterschiedlichen, aber zum gleichen Serviceplan gehörenden Serviceinstanzen gehostet werden, wird jede Interaktion als separate Nutzung behandelt. Die Interaktion des Benutzers mit jeder Serviceinstanz wird separat in Rechnung gestellt.

Behandlung von anonymen Benutzern

Falls Ihre angepasste Anwendung bzw. Ihr Assistent mit anonymen Benutzern interagiert, können Sie für jeden der anonymen Benutzer eine eigene randomisierte und universell eindeutige ID generieren. Weitere Informationen zu UUIDs finden Sie unter RFC 4122.

• Wenn Sie bei einem Web-Chat zu Beginn der Sitzung keine ID für den Benutzer übergeben, wird vom Web-Chat eine ID für Sie erstellt. Sie erstellt für die erste Partei ein Cookie mit einer generierten anonymen ID. Das Cookie ist für 45 Tage aktiv. Falls derselbe Benutzer zu einem späteren Zeitpunkt im Monat erneut mit Ihrem Assistenten chattet, erkennt die Web-Chat-Integration den Benutzer. Daher wird es für Sie nur ein einziges Mal berechnet, wenn derselbe anonyme Benutzer mehrmals in einem einzelnen Monat mit Ihrem Assistenten interagiert.

Falls sich ein anonymer Benutzer anmeldet und später als dieselbe Person erkannt wird, die eine Anforderung mit einer bekannten ID übergeben hat, fallen zwei Mal Gebühren an. Jede Nachricht mit einer eindeutigen Benutzer-ID wird als unabhängiger aktiver Benutzer abgerechnet. Um diese Situation zu vermeiden, können Sie Benutzer auffordern, sich anzumelden, bevor Sie einen Chat starten. Alternativ können Sie die anonyme Benutzer-ID verwenden, um den Benutzer konsistent darzustellen.

Rechenzentren

IBM Cloud verfügt über ein globales Netz von Rechenzentren, die Leistungsvorteile für zugehörige Cloud Services bieten. Weitere Informationen finden Sie in den globalen Rechenzentren IBM Cloud.

Sie können watsonx Assistant-Serviceinstanzen erstellen, die an den folgenden Standorten der Rechenzentren gehostet werden: