Kundenkontext an KI-Chatbot für E-Commerce übergeben

Lege den Connector auf einem eigenen TEST-Assistenten an. Nutze GET und `https://dummyjson.com/http/200/Order_{order_id}_is_in_transit_eta_August_8`. Erstelle genau ein Text-Pflichtfeld `order_id`; Platzhalter und Feldname müssen Zeichen für Zeichen übereinstimmen.

Der Tool-Prompt beschränkt den Aufruf auf die fiktive Statusfrage, übernimmt die aktuelle `order_id` aus dem Besucherkontext und gibt nur ID, Status und ETA aus. Der Endpunkt ist ein öffentlicher Mock, keine Shop-Integration. Produktive Tokens oder Kundendaten gehören nie in den Prompt.

Binde das Widget ohne `context-data` ein, starte ein frisches Gespräch und frage exakt: „Where is my order?“ Obwohl das Portal A-1023 zeigt, liest das Widget nicht beliebigen Seitentext und muss nach der Bestell-ID fragen.

Stoppe, wenn bereits A-1023, „in transit“ oder August 8 erscheint. Das spricht für alten Gesprächszustand, Prompt-Daten oder unsicheres Raten. Lösche Gespräch und Browser-Kontext vor dem nächsten Versuch.

Ergänze auf einer serverseitig gerenderten Seite `context-data="Customer=Jane Doe;order_id=A-1023;locale=en-US"` am Element `<web-chat-agent>`. Unterstützt werden Semikolon-Paare oder ein flaches JSON-Objekt.

Der normalisierte Datensatz erlaubt maximal 20 Schlüssel, 64 Zeichen je Schlüssel, 500 je Wert und insgesamt 4.000 serialisierte Zeichen. Nutze stabile Maschinenschlüssel wie `order_id`, keine Secrets und nur nötige Anzeigewerte.

Starte ein neues Gespräch mit Kontext und wiederhole „Where is my order?“. Der Assistent übernimmt A-1023 als Pflichtargument `order_id`, ruft den GET-Endpunkt auf und nennt für die fiktive Bestellung „in transit“ sowie ETA August 8.

Der Nachweis kombiniert Embed mit A-1023, Connector-URL mit `{order_id}` und die echte Mock-Response mit A-1023 plus Status. Der Kontext wählt den Datensatz; die Response liefert den Status.

Beim Wechsel zu A-2048 sendest du `new CustomEvent('webchatagent:context', { detail: { Customer: 'Jane Doe', order_id: 'A-2048', locale: 'en-US' } })`. Die Seite und die autorisierte Sitzung müssen bereits denselben neuen Datensatz meinen.

Das Event ersetzt bewusst: nicht enthaltene Schlüssel verschwinden. Beim Logout sendest du ein leeres Objekt oder `null`. Vermische alte Kunden- und Bestellwerte nur, wenn dieses Verhalten ausdrücklich gefordert und getestet ist.

Lass das Widget geöffnet und frage: „What is the status of the order now shown on this page?“ Die nächste Antwort muss A-2048 und den Mock-Status enthalten und darf A-1023 nicht nennen.

Speichere den Dreischritt als Regressionstest: fehlender Kontext, erster Kontext und Laufzeitersetzung. Wiederhole ihn nach Änderungen an Connector, System Prompt, Modell, Widget oder Host-Anwendung und dokumentiere Frage, Kontext, Toolargument, Response und Zeit.

Nutze das HTML-Attribut für serverseitige Werte, `window.webchatagentContext` vor dem asynchronen Widget-Skript für JavaScript-Initialisierung und `webchatagent:context` für Login-, Konto-, Warenkorb-, Produkt- oder Routenwechsel nach dem Laden.

In WordPress nutzt du den Filter `webchatagent_context_data` für zentral erzeugte Werte oder `[webchatagent_inline context-data="order_id=A-1023"]` für Inline-Platzierung. White-Label-Kunden verwenden `window.chatWidgetContext` und `chat-widget:context` mit derselben Ersetzungslogik.

Begrenze `allowedDomains` auf exakte Produktions- und Staging-Hosts. Eine Kundenbezeichnung, E-Mail oder Bestellnummer im Kontext darf keinen Abruf autorisieren, denn Besucher können jeden Browserwert in DevTools ändern.

Lass dein Backend einen kurzlebigen opaque Token für die angemeldete Sitzung erstellen, übergib nur diesen als Kontext und rufe einen minimal berechtigten Lese-Endpunkt auf. Dieser prüft Token, Kundenzuordnung, Ablauf und Umfang serverseitig und liefert nur ID, Status und ETA. Beim Logout wird der Token ungültig.