Entwicklerleitfaden für Conversational Commerce-Agenten

In diesem Leitfaden wird beschrieben, wie Sie die Conversational API einbinden, um Ihren Kunden dynamische, KI-basierte Chatfunktionen zu bieten. Wenn Sie die verschiedenen Anfragetypen kennen und die Antworten der API nutzen, können Sie relevante Produktsuchen durchführen, Kundenanfragen beantworten und Endnutzer durch den Kaufprozess führen.

Die conversationalFilteringMode in der Conversational API verdeutlicht die Unterschiede zwischen einem Conversational Commerce-Agenten und der konversationellen Produktfilterung.

Einrichtung

Die Conversational API unterstützt die Funktion „Konversations-Agent für den Handel“:

Die Conversational API ermöglicht eine Chatfunktion, bei der Ihre Nutzer Anfragen senden und das System eine Textantwort, klassifizierte Anfragetypen und potenzielle verfeinerte Suchoptionen zurückgibt.

Diese API funktioniert als Streamingdienst und ermöglicht so die frühzeitige Erkennung der Suchanfrage. Für nachfolgende Interaktionen in der Unterhaltung muss eine conversation_id angehängt werden.

Um Suchergebnisse zurückzugeben, muss die alte Retail API parallel zur Conversational API aufgerufen werden.

Anfrage vom Endnutzer senden

In diesem Abschnitt wird beschrieben, wie Sie eine Conversational Commerce-Agent-Erfahrung starten. Ein Nutzer gibt beispielsweise Hilf mir, eine Party zu planen in das Suchfeld ein.

Anfrage an Vertex AI Search for Commerce senden

Es gibt zwei verschiedene API-Endpunkte:

  1. Die Conversational API muss verwendet werden, um die Konversationsfunktion abzurufen.
  2. Die Search API muss verwendet werden, um Suchergebnisse abzurufen.

Endpunkt 1: Conversational API-Anfrage

  • Sie sollten eine Anfrage für einen Conversational Commerce-Agenten erstellen, indem Sie die Eingabe des Nutzers als query festlegen.
  • Die Anfrage sollte als HTTP-POST-Anfrage an den projects/*/locations/*/catalogs/*/placements/*:conversationalSearch-Endpunkt gesendet werden.

HTTP-Methode und Endpunkt

  POST https://retail.googleapis.com/v2alpha/{placement=projects/*/locations/*/catalogs/*/placements/*}:conversationalSearch
  

Conversational API-Anfrage:

Ausgangsanfrage

{
  "query": "Help me plan a party",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "placement": "projects/799252947591/locations/global/catalogs/default_catalog/placements/default_search",
  "visitorId": "your_visitor_id",
  "conversationId": "", // Leave empty for the first query
  "searchParams": {
    // IMPORTANT: These search parameters should mirror the configuration
    // of your core Search API calls to ensure consistency between LLM answers and search results.
    "filter": "categories:(\"Party Supplies\" OR \"Decorations\" OR \"Food & Drink\")"
  },
  "userInfo": {
    // Optional: User information for enhanced personalization
    // Example: "userId": "user123", "userAgent": "Chrome/120.0"
  },
  "conversationalFilteringSpec": {
    // Optional: Controls conversational filtering behavior. Defaults to DISABLED if unset.
    // "conversational_filtering_mode": "DISABLED" - Otherwise you can also explicitly set to disabled.
}
  • placement: Der Ressourcenname der Platzierung, z. B. projects/your-project-id/locations/global/catalogs/default_catalog/placements/default_branch. Dies ist ein Pfadparameter und erforderlich.
  • query: Die unbearbeitete Suchanfrage des Nutzers. Dies ist ein Pflichtfeld.
  • branch: Der Ressourcenname des Zweigs, z. B. projects/P/locations/L/catalogs/C/branches/B. Wenn kein Wert angegeben ist, wird default_branch verwendet. Dies ist ein Pflichtfeld.
  • visitorId: Eine eindeutige Kennung für das Tracking von Besuchern. Dies ist ein Pflichtfeld.
  • conversationId: Eine eindeutige ID zum Nachverfolgen von Unterhaltungssitzungen. Bei der ersten Anfrage in einer neuen Unterhaltung sollte dieses Feld leer sein. Für nachfolgende Anfragen innerhalb derselben Unterhaltung muss es auf den conversation_id-Wert gesetzt werden, der in der vorherigen ConversationalSearchResponse empfangen wurde.
  • searchParams: (Optional) Standardparameter für die Hauptsuche, z. B. filter, canonicalFilter, sortBy und boostSpec. Es ist wichtig, dass diese Parameter der Konfiguration entsprechen, die in Ihren wichtigsten Search API-Aufrufen verwendet wird, um die Konsistenz zwischen LLM-Antworten und allen angezeigten Produktsuchergebnissen zu gewährleisten.
  • userInfo: (Optional) Nutzerinformationen für eine verbesserte Personalisierung. Kann userId, user_agent, direct_user_request (boolescher Wert) enthalten.
  • conversationalFilteringSpec: (Optional) Gibt den Konversationsfiltermodus an. Wenn nicht festgelegt, wird standardmäßig DISABLED verwendet.

    mode: Integrieren Sie die Conversational API in einem der drei Modi, um die Filterung von Conversational-Produkten zu steuern:

    • DISABLED: In diesem Modus implementiert der Client nur die Suche nach dem Konversations-Agent für den Handel. Dies ist der bevorzugte Modus für diese Implementierungsanleitung zur Suche nach Conversational Commerce-Agents.
    • Beispiel für eine API-Anfrage

              placement: "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search"
              branch: "projects/118220807021/locations/global/catalogs/default_catalog/branches/default_branch"
              query: "show me some monster energy drinks"
              visitor_id: "test"
              conversational_filtering_spec {
                conversational_filtering_mode: DISABLED
              }
            

      Beispiel für eine API-Antwort

              user_query_types: "SIMPLE_PRODUCT_SEARCH"
              conversation_id: "479fd093-c701-4899-bcc3-9e711233bdf9"
              refined_search {
                query: "monster energy drinks"
              }
            
    • ENABLED: In diesem Modus implementiert der Client alle Funktionen für die Konversationsführung, einschließlich der Suche nach Konversations-Agents für den Handel und der Filterung von Produkten über Konversationen.
    • Weitere Informationen zum Integrieren beider Konversationsprodukte

      Beispiel für eine API-Anfrage

              placement: "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search"
              branch: "projects/118220807021/locations/global/catalogs/default_catalog/branches/default_branch"
              query: "show me some monster energy drinks"
              visitor_id: "test"
              conversational_filtering_spec {
                conversational_filtering_mode: ENABLED
              }
            

      Beispiel für eine API-Antwort

              user_query_types: "SIMPLE_PRODUCT_SEARCH"
              conversation_id: "479fd093-c701-4899-bcc3-9e711233bdf9"
              refined_search {
                query: "monster energy drinks"
              }
              conversational_filtering_result: {
                  followup_question{
                    followup_question: "What is the size?"
                    suggested_answers {
                      product_attribute_value {
                        name: "size",
                        value: "12oz"
                      }
                    }
              }
              }
            
    • CONVERSATIONAL_FILTER_ONLY: Wenn diese Option ausgewählt ist, implementiert der Kunde nur die Konversationsfilterung für Produkte. Wenn dieser Modus ausgewählt ist, wird dem Nutzer nur ein dialogorientierter Produktfilter angezeigt, ohne dass eine LLM-Antwort, eine Anfrageklassifizierung oder vorgeschlagene Suchanfragen generiert werden.
    • Weitere Informationen finden Sie im Entwicklerhandbuch für konversationelle Produktfilter.

Endpunkt 2: Core Search API-Anfrage

Es gibt zwei primäre Ansätze zum Anzeigen von Suchergebnissen in Ihrer Weboberfläche.

Option 1: Suchergebnisse immer anzeigen

Wenn in Ihrem UX-Design festgelegt ist, dass Suchergebnisse immer angezeigt werden sollen, unabhängig von der Ausgabe des Konversationsmodells, z. B. in einem speziellen Bereich für Suchergebnisse neben dem Chat, senden Sie die ursprüngliche Anfrage des Nutzers mit Ihrem Aufruf der Conversational API an die Core Product Search API. So sind Produkteinträge sofort verfügbar.

Option 2: Suchergebnisse basierend auf der konversationellen Ausgabe anzeigen

Wenn Ihr UX-Design dynamischer ist und Sie Suchergebnisse nur in Abhängigkeit von der Antwort der Conversational API anzeigen möchten, z. B. nur für SIMPLE_PRODUCT_SEARCH-Anfragen oder wenn refined_search-Vorschläge bereitgestellt werden, warten Sie auf die Antwort der Conversational API, bevor Sie Anfragen an die Core Product Search API senden. Wenn eine Antwort vorhanden ist, verwenden Sie die bereitgestellte refined_search-Anfrage, um Produktergebnisse abzurufen.

Unabhängig davon, welche Benutzeroberflächenoption Sie auswählen, können Sie die Retail API aufrufen, wenn Sie tatsächliche Produktergebnisse abrufen möchten. Weitere Informationen finden Sie unter Suchanfragetypen und Händleraktionen.

HTTP-Methode und Endpunkt

    POST https://retail.googleapis.com/v2beta/{placement=projects/*/locations/*/catalogs/*/servingConfigs/*}:search
    

Kernprodukt-Suchanfrage über die API:

Ausgangsanfrage

    {
      "placement": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/servingConfigs/default_search",
        // Or if using legacy placements:
        // "placement": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/placements/default_search",
      "query": "Help me plan a party", // This is the original user query
      "visitorId": "your_visitor_id",
      "branch": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/branches/default_branch",
      "pageSize": 20, // Optional: Number of results to return per page
      "filter": "categories:(\"Party Supplies\" OR \"Decorations\" OR \"Food & Drink\")", // Mirroring the filter from the Conversational Commerce API
      "orderBy": "relevance DESC", // Optional
      "userInfo": {
        // Optional: User information for enhanced personalization, should mirror Conversational Commerce API
        // "userId": "user123", "userAgent": "Chrome/120.0"
      },
      "searchMode": "PRODUCT_SEARCH" // Typically for product searches
    }
    
  • placement (erforderlich): Der Ressourcenname der Serving-Konfiguration für die Einzelhandelssuche oder des alten Placements. Beispiel: projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/servingConfigs/default_search.
  • query: Erforderlich. Die Suchanfrage. Das kann die Roh-Eingabe des Nutzers sein, z. B. Hilf mir, eine Party zu planen, oder ein optimierter refinedSearch.query, z. B. Partyplanungszubehör, Dekorationen, der aus der Antwort der Conversational Commerce API stammt.
  • visitorId: Erforderlich. Eine eindeutige Kennung für das Tracking von Besuchern. Dieser Wert sollte mit dem visitorId übereinstimmen, der für denselben Endnutzer an die Conversational Commerce API gesendet wird.
  • branch (erforderlich): Der Ressourcenname des Zweigs, z. B. projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/branches/default_branch.
  • pageSize (Optional): Die maximale Anzahl der zurückzugebenden Produkte.
  • filter (Optional): Wird verwendet, um Suchergebnisse zu filtern. Hier wenden Sie alle Filter an, die den Parametern entsprechen, die Sie in `searchParams` an die Conversational Commerce API senden, um die Konsistenz zu wahren.
  • orderBy (Optional): Gibt die Reihenfolge an, in der Produkte zurückgegeben werden (z. B. nach Relevanz oder Preis).
  • userInfo (Optional): Nutzerinformationen zur Personalisierung, die mit dem Conversational Commerce API-Aufruf übereinstimmen sollten.
  • searchMode (Optional): Definiert das Suchverhalten. PRODUCT_SEARCH ist bei allgemeinen Produktanfragen üblich.

Antwort verstehen

Dieses Codebeispiel zeigt eine Antwort der Conversational Commerce API.

Die API-Antwort (ConversationalSearchResponse) enthält query_types, conversational_text_response (falls zutreffend), refined_search-Optionen und möglicherweise followup_question oder conversational_filtering_result. Die conversation_id ist für die Fortsetzung der Sitzung erforderlich.

Antwort von Vertex AI Search for Commerce

In diesem Codebeispiel wird eine Antwort der Conversational API veranschaulicht:

Erste Antwort

    {
      "userQueryTypes": ["INTENT_REFINEMENT"],
      "conversationalTextResponse": "To plan a party, you'll need decorations, snacks, party supplies, drinks, and a cake. You can find a wide variety of decorations, snacks, and drinks. For party supplies, you can find everything from plates and cups to balloons and streamers. And for cake, you can choose from a variety of flavors and sizes.",
      "followupQuestion": {
        "followupQuestion": "What kind of party are you planning?"
      },
      "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
      "refinedSearch": [
        { "query": "Decorations" },
        { "query": "Snacks" },
        { "query": "Party Supplies" },
        { "query": "Drinks" },
        { "query": "Cake" }
      ],
      "state": "SUCCEEDED"
    }
    

Was Einzelhändler mit der Antwort tun sollten (Allgemein)

Rendern Sie die folgenden Felder aus der Antwort:

  • user_query_types: Dieses Feld enthält die Klassifizierung(en) der Intention des Nutzers. Ausführliche Informationen zu Aktionen, die auf diesen Typen basieren, finden Sie unter Suchanfragetypen und Händleraktionen.
  • conversation_id: Sie können diese eindeutige ID im Browserspeicher oder in einem ähnlichen clientseitigen Speicher speichern, um die Unterhaltungssitzung mit dem Server aufrechtzuerhalten. Das ist wichtig, um zwischen mehreren laufenden Unterhaltungen für einen einzelnen Käufer zu unterscheiden. Ihr Modell behält den Kontext für ein bestimmtes conversation_id bei. Wenn Sie ein neues conversation_id senden, wird eine neue Sitzung gestartet. Es wird empfohlen, die Sitzungsdauer zu definieren, z. B. 30 Minuten Inaktivität.
  • refined_search: Dies ist eine Liste mit vorgeschlagenen verfeinerten Suchanfragen, die zum Abrufen der relevanten Suchergebnisse verwendet werden. Bei SIMPLE_PRODUCT_SEARCH handelt es sich immer um eine einzelne Anfrage. Bei anderen Anfragen, bei denen eine LLM-Antwort gesucht wird, ist es eine oder mehrere. Die refined_search-Anfragen können für Aufrufe der Core Search API (SearchService.Search) verwendet oder Ihren Nutzern als Vorschläge angezeigt werden.
  • conversational_text_response: Zeigen Sie diesen Text dem Nutzer als primäre KI-generierte Antwort auf seine Anfrage an.
  • followup_question: Optional. followup_question wird angezeigt.
  • state: Dieses Feld gibt den Status der Antwortgenerierung an ("STREAMING" oder "SUCCEEDED"). Sie können es für Feedback zur Nutzerfreundlichkeit verwenden, z. B. um eine Ladeanzeige bis "SUCCEEDED" einzublenden. Weitere Informationen dazu finden Sie im nächsten Abschnitt.

Streaming API verstehen

Die Conversational Commerce API funktioniert als Streaming-API. Das bedeutet, dass Ihr Nutzer Teile der Antwort in mehreren Chunks anstelle einer einzelnen, vollständigen Nutzlast erhält.

Der erste Teil der Antwort enthält die Abfragen query_types und refined_search. Der state-Wert ist STREAMING. Durch die frühzeitige Erkennung der Intention und die sofortige Verfügbarkeit von Suchverfeinerungen kann Ihr Modell schnell entscheiden, wie die Anfrage des Nutzers behandelt werden soll und wie die Latenz bei LLM-Antworten für den Nutzer gehandhabt werden soll:

  • Bei Anfragetypen, bei denen keine Antwort in Form von Konversations-Text erwartet wird, z. B. SIMPLE_PRODUCT_SEARCH, RETAIL_IRRELEVANT, BLOCKLISTED, QUERY_TYPE_UNSPECIFIED, ORDER_SUPPORT, DEALS_AND_COUPONS, STORE_RELEVANT:
    • Da sich query_types im ersten Chunk befinden, weiß Ihr System sofort, dass keine LLM-Antwort kommt. Sie können mit der vordefinierten Verarbeitung für diese Typen fortfahren, z. B. eine statische Meldung anzeigen oder an den Support weiterleiten, ohne auf weitere Conversational-Ausgabe zu warten.
    • Speziell für SIMPLE_PRODUCT_SEARCH kann Ihr System mit der im ersten Chunk empfangenen refined_search-Anfrage sofort einen direkten Aufruf der Core Search API ausführen. So können Suchergebnisse mit minimaler Verzögerung angezeigt werden, was den typischen SLAs für die Suche entspricht.
  • Für Anfragetypen, bei denen keine Antwort in Form von Konversationstext erwartet wird, z. B. INTENT_REFINEMENT, PRODUCT_DETAILS, PRODUCT_COMPARISON, BEST_PRODUCT:
    • Sie erhalten die query_types- und refined_search-Abfragen im ersten Chunk. Sie können mit diesen refined_search-Abfragen sofort einen parallelen Aufruf der Core Search API initiieren, um mit dem Laden von Produktergebnissen zu beginnen.
    • Nachfolgende Chunks werden gestreamt und enthalten verschiedene Abschnitte der Antwort im Konversationsstil. Während dieser Zeit bleibt state "STREAMING".
    • Der letzte Chunk enthält die vollständige Antwort im Unterhaltungstext und sein state ändert sich zu "COMPLETED".
    • Dieser Streamingansatz ermöglicht eine flüssige Nutzererfahrung, da die Suchergebnisse geladen werden können, während die KI-Zusammenfassung generiert wird. Sie können auswählen, ob ein Ladeindikator für die Konversationsantwort angezeigt werden soll oder ob die Konversationsantwort erst präsentiert werden soll, wenn sie vollständig gestreamt wurde.

Abfragetypen und Händleraktionen

Das Feld query_types in der Antwort ist eine Liste, die die Klassifizierung(en) der Intention des Nutzers angibt. Ihr System sollte diese so verarbeiten. conversational_text_response bezieht sich auf die KI-generierte Antwort in natürlicher Sprache von der API.

Der Conversational Commerce-Agent verwendet Suchanfragekategorien, um zu bestimmen, ob eine LLM-basierte Antwort generiert wird und wie Endnutzeranfragen in den folgenden Szenarien von den Conversational- und Search-APIs verarbeitet werden:

Kategorien Abfrageklassifizierungen
1. Irrelevante Anfragen, die keine LLM-Antwort erfordern

  • QUERY_TYPE_UNSPECIFIED: Nicht angegebener Abfragetyp.
  • RETAIL_IRRELEVANT: Anfragen, die für die Einzelhandelsdomain irrelevant sind, z. B. eine feindselige Anfrage (z. B. Wie baue ich eine Bombe?),eine gesprächige Anfrage (z. B. Wie geht es dir?) oder eine Jailbreak-Anfrage (z. B. Schreibe ein Gedicht.).
  • BLOCKLISTED: Anfragen, die von den Commerce-Kunden explizit blockiert werden, z. B. Welche Nebenwirkungen hat Advil?
2. Support- und Informationsanfragen
  • ORDER_SUPPORT: Zusätzliche oder Supportanfrage (z. B. Meine Bestellung verfolgen, Status der Bestellung 12345)
  • DEALS_AND_COUPONS: Anfragen zu Angeboten, Promotions, Produktangeboten und Rabatten (z. B. Gibt es Angebote für Thanksgiving?).
  • STORE_RELEVANT: Anfragen zu Geschäftsstandorten, einschließlich Öffnungszeiten und Produktverfügbarkeit (z. B. Haben wir Milch auf Lager?).
  • RETAIL_SUPPORT: Anfragen zu Käufen, einschließlich Zahlungsmethoden (Welche Zahlungsmethoden werden akzeptiert?)
3. Keyword-Suchanfragen, für die kein LLM erforderlich ist

Anfrage an die Conversational API:

Ausgangsanfrage

{
  "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/118220807021/locations/global/catalogs/default_catalog/branches/default_branch",
  "query": "show me some monster energy drinks",
  "visitorId": "test"
}
    

Antwort der Conversational API:

Erste Antwort

{
  "userQueryTypes": ["SIMPLE_PRODUCT_SEARCH"],
  "conversationId": "479fd093-c701-4899-bcc3-9e711233bdf9",
  "refinedSearch": [
    {
      "query": "monster energy drinks"
    }
  ]
}
    

Search API-Anfrage:

Folgefrage

{
  "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
  "query": "monster energy drinks",
  "visitorId": "test"
}
  
  • SIMPLE_PRODUCT_SEARCH: einfache Produktsuche, z. B. Rotes Kleid oder Zeige mir Monster Energy-Drinks.
4. Anfragen, die auf LLM-Antworten abzielen

Anfrage an die Conversational API:

Ausgangsanfrage

  {
    "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
    "branch": "projects/118220807021/locations/global/catalogs/default_catalog/branches/default_branch",
    "query": "Compare 1% milk with 2% milk",
    "visitorId": "test"
  }
    

Antwort der Conversational API:

Erste Antwort

{
  "userQueryTypes": ["PRODUCT_COMPARISON"],
  "conversationalTextResponse": "1% milk contains 110 calories, 1.5 g of saturated fat, and 140 mg of sodium per cup. 2% milk is reduced fat with 37% less fat than regular milk and contains vitamins A & D.",
  "conversationId": "0e1cfdac-802f-422d-906e-9fc9f9d733ba",
  "refinedSearch": [
    {
      "query": "1% milk"
    },
    {
      "query": "2% milk"
    }
  ]
}
  

Search API-Anfrage:

Folgefrage

{
  "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
  "query": "1% milk",
  "visitorId": "test"
}
  
  • PRODUCT_DETAILS: Der Nutzer sucht nach Produktdetails und ‑spezifikationen, z. B. Zeige mir die Spezifikationen von [Produktname]. Wie hoch ist der Proteingehalt von Milch mit 2% Fett?
  • PRODUCT_COMPARISON: Produktvergleich, z. B. Vergleiche [Produktname] und [Produktname], Vergleiche 1% ige Milch mit 2% iger Milch.
  • BEST_PRODUCT: Suchanfragen mit dem am besten passenden Muster, z. B. Was ist der gesündeste Keks? Welche Milchmarke ist die beste?
5. Zweck eingrenzen

Anfrage an die Conversational API:

Ausgangsanfrage

{
  "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/118220807021/locations/global/catalogs/default_catalog/branches/default_branch",
  "query": "Help me plan a party",
  "visitorId": "test"
}
  

Antwort der Conversational API:

Erste Antwort

{
  "userQueryTypes": ["INTENT_REFINEMENT"],
  "conversationalTextResponse": "To plan a party, you'll need decorations, snacks, party supplies, drinks, and a cake. You can find a wide variety of decorations, snacks, and drinks. For party supplies, you can find everything from plates and cups to balloons and streamers. And for cake, you can choose from a variety of flavors and sizes.",
  "followupQuestion": {
    "followupQuestion": "What kind of party are you planning?"
  },
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "refinedSearch": [
    { "query": "Decorations" },
    { "query": "Snacks" },
    { "query": "Party Supplies" },
    { "query": "Drinks" },
    { "query": "Cake" }
  ],
  "state": "SUCCEEDED"
}
  
  • INTENT_REFINEMENT: Der Typ ist unklar und es ist möglicherweise ein Folgegespräch oder eine Verfeinerung erforderlich, um den Typ zu klären, z. B. Hilf mir, eine Party zu planen. Dies ist oft die beliebteste Intention in Unterhaltungen.

Kategorie 1 Irrelevante Anfragen, für die keine LLM-Antwort erforderlich ist

  • QUERY_TYPE_UNSPECIFIED:
    • Es wurde kein conversational_text_response angegeben.
    • Aktion: Als Standard- oder Fehlerfall behandeln. Sie können den Nutzer um eine Klarstellung bitten oder ihn an eine Stelle verweisen, an der er allgemeine Hilfe erhalten kann.
  • RETAIL_IRRELEVANT:
    • Es wurde kein conversational_text_response angegeben.
    • Maßnahme: Reagieren Sie darauf mit einer geeigneten Meldung, z. B. Ich kann diese Frage nicht beantworten oder Ich bin ein Shopping-Assistent. Wie kann ich Ihnen helfen?, wie im Design Ihrer Anwendung festgelegt.
  • BLOCKLISTED:
    • Es wird keine conversational_text_response bereitgestellt.
    • Aktion: Gemäß Ihrer Blockierungsrichtlinie vorgehen, in der Regel durch Anzeigen einer allgemeinen Meldung Diese Anfrage kann nicht ausgeführt werden.

Kategorie 2 Support- und Informationsanfragen

Für diese Typen wird von der API standardmäßig kein direkter conversational_text_response bereitgestellt. Sie haben jedoch die Möglichkeit, auf die richtigen Links oder Ressourcen zu verweisen.

  • ORDER_SUPPORT:
    • Standardaktion: Es wird kein conversational_text_response bereitgestellt. Ihre Weboberfläche muss eine Standardmeldung, relevante Links oder eine Umleitung der Anfrage an Ihre eigene Support-API oder Ihren Kundenservicekanal anzeigen.
  • DEALS_AND_COUPONS:
    • Standardaktion: Es wird kein conversational_text_response bereitgestellt. Ihre Weboberfläche muss eine Standardmitteilung, relevante Links oder eine Umleitung der Anfrage an Ihr Angebots- oder Promotionsystem anzeigen.
  • STORE_RELEVANT:
    • Standardaktion: Es wird kein conversational_text_response bereitgestellt. Ihre Weboberfläche muss eine Standardmeldung, relevante Links oder eine Umleitung der Anfrage an Ihre eigene Standortsuche oder Ihr eigenes Informationssystem anzeigen.
  • RETAIL_SUPPORT:
    • Standardaktion: Es wird kein conversational_text_response bereitgestellt. Ihre Weboberfläche muss eine Standardmeldung, relevante Links oder eine Umleitung der Anfrage an Ihr eigenes System mit häufig gestellten Fragen und Informationen anzeigen.

Kategorie 3. Keyword-Suchanfragen, für die keine LLM-Antworten erforderlich sind

  • SIMPLE_PRODUCT_SEARCH:
    • Es wird keine Antwort in Form von Konversationstext generiert.
    • Aktion: Die API-Antwort gibt immer eine einzelne refined_search-Anfrage zurück. Diese verfeinerte Anfrage dient als vorgeschlagener Suchbegriff. Rufen Sie die Core Search API (SearchService.Search) direkt auf und rufen Sie relevante Produktergebnisse entweder mit der ursprünglichen Anfrage oder mit der refined_search-Anfrage ab. Die refined_search.query stammt möglicherweise nicht direkt aus der aktuellen Eingabe des Endnutzers, sondern kann auch aus dem Kontext des Chatverlaufs abgeleitet werden. Wenn ein Endnutzer beispielsweise zuvor Partykleid in rote geändert hat,kann die verfeinerte Anfrage rotes Partykleid lauten.
      • Für dialogorientierte Benutzeroberflächen (z. B. Chatbots): Es wird dringend empfohlen, die von der API bereitgestellte refined_search.query zu verwenden. In einem Konversationsablauf werden Anfragen in natürlicher Sprache wie „Kannst du mir helfen, Bananen zu finden?“ automatisch von der API in einen präzisen Produktsuchbegriff („Bananen“) optimiert, was zu relevanteren Produktergebnissen führt.
      • Für die wichtigsten Suchfunktionen (z. B. die Suchergebnisseite): Sie können entweder die refined_search.query aus der API oder die ursprüngliche Anfrage des Endnutzers verwenden, da die ursprüngliche Anfrage mit größerer Wahrscheinlichkeit bereits ein präziser Produktsuchbegriff ist. Wählen Sie die Option aus, die am besten zu Ihrer Weboberfläche und Ihrer Strategie für die Anzeige von Suchergebnissen passt.
    • Optionen für die Nutzerfreundlichkeit: Die Unterhaltung muss bei SIMPLE_PRODUCT_SEARCH-Anfragen nicht beendet werden. Ihr Nutzer kann die Unterhaltung fortsetzen, indem er die conversation_id in nachfolgenden Anfragen übergibt.
      • Option A: Konversationsbasierte Weboberfläche beenden: Viele Einzelhändler leiten den Nutzer nach Erkennung von SIMPLE_PRODUCT_SEARCH auf eine Standard-Suchergebnisseite weiter und schließen so das Chatfenster. Wenn der Endnutzer in diesem Szenario dann eine neue Anfrage in das Standard-Suchfeld eingibt, ohne das vorherige conversation_id, wird dies als neue, separate Konversation behandelt und ein neues conversation_id wird ausgegeben.
      • Option B: Konversationsoberfläche im Web fortsetzen: Einzelhändler können das Chatfenster geöffnet lassen. So kann der Nutzer wieder in den Unterhaltungsmodus wechseln. Die Entscheidung, ob Option A oder B implementiert werden soll, hängt ganz von der bevorzugten Nutzerfreundlichkeit des Einzelhändlers ab.

    Damit Suchanfragen Conversational-Interaktionen korrekt zugeordnet und alle Analysefunktionen in Vertex AI Search for Commerce genutzt werden können, ist eine korrekte Ereignis-Tagging-Implementierung unerlässlich:

    1. conversation_id abrufen: Wenn Sie einen conversationalSearch API-Aufruf ausführen, wird ConversationalSearchResponse.conversation_id zurückgegeben.
    2. Nutzerereignisse taggen Wenn die Antwort im Konversationsstil zu einer Suchanfrage führt, z. B. wenn Ihr System automatisch eine Suche basierend auf der verfeinerten Anfrage für SIMPLE_PRODUCT_SEARCH ausführt, müssen Sie dieses nachfolgende Nutzerereignis für die Suche (UserEvent) mit derselben conversation_id taggen, die in der ConversationalSearchResponse empfangen wurde.

Wenn Sie UserEvent.conversation_id richtig taggen, können Suchanfragen in Ihren Analysen den vorherigen dialogorientierten Interaktionen korrekt zugeordnet werden. So erhalten Sie wertvolle Einblicke in das Nutzerverhalten und die Conversion-Pfade.

Kategorie 4. LLM-Anfragen, die auf Antworten abzielen

Bei diesen Abfragetypen generiert die API eine conversational_text_response (LLM-Antwort) und stellt möglicherweise auch eine oder mehrere refined_search-Anfragen bereit. Die Unterhaltung wird nicht beendet und der Endnutzer kann sie fortsetzen.

  • PRODUCT_DETAILS:
    • Aktion: Der conversational_text_response liefert die angeforderten Produktdetails. Diese Informationen sollten dem Nutzer in Ihrem System deutlich angezeigt werden.
    • Die Antwort enthält auch refined_search (ein oder mehrere vorgeschlagene Suchanfragen, sortiert und gerankt), die verwendet werden sollten, um Suchergebnisse mit der Search API abzurufen.
  • PRODUCT_COMPARISON:
    • Aktion: Das conversational_text_response bietet einen Vergleich der angegebenen Produkte. Diese Informationen sollten dem Nutzer in Ihrem System deutlich angezeigt werden.
    • Die Antwort enthält refined_search (ein oder mehrere vorgeschlagene Suchanfragen, sortiert und gerankt), die verwendet werden sollten, um Suchergebnisse mit der Core Search API abzurufen.
  • BEST_PRODUCT:
    • Aktion: Der conversational_text_response gibt Empfehlungen oder Informationen zu Produkten, die am besten zur Anfrage passen. Diese Informationen sollten in Ihrem System angezeigt werden.
    • Die Antwort enthält refined_search (ein oder mehrere vorgeschlagene Suchanfragen, sortiert und gerankt), die verwendet werden sollten, um Suchergebnisse mit der Core Search API abzurufen.

Kategorie 5. Intent-Optimierung

  • INTENT_REFINEMENT:
    • Aktion: Die Antwort enthält conversational_text_response, ein followup_question und refined_search (eine oder mehrere vorgeschlagene Suchanfragen). Die empfohlene Reihenfolge ist:
      1. conversational_text_response
      2. refined_search-Vorschläge: Diese werden sortiert und gerankt. Es ist daher wichtig, sie in derselben Reihenfolge wie in der Antwort anzuzeigen.
      3. Followup_question
    • Die Antwort enthält refined_search (ein oder mehrere vorgeschlagene Suchanfragen, sortiert und gerankt), die verwendet werden sollten, um Suchergebnisse mit der Core Search API abzurufen.
    • Senden Sie bei nachfolgenden Interaktionen die Antwort des Nutzers zusammen mit dem conversation_id.

Vorgeschlagene Anfragen für Produkte anzeigen

So konfigurieren Sie die Google Suche, damit Fragen und Produktvorschläge im Conversational Commerce-Agent angezeigt werden.

Wenn die Conversational API refinedSearch-Anfragen zurückgibt, bieten diese Anfragen eine hervorragende Möglichkeit, den Endnutzer zu relevanten Produkten zu führen. Das ist besonders wertvoll für Kategorie 4 (LLM-Anfragen zur Suche nach Antworten) und Kategorie 5 (INTENT_REFINEMENT).

Empfehlung

  • Anzeigen: Präsentieren Sie dem Nutzer die N (1–3, je nach Tests zur Ermittlung der idealen Anzahl für Ihre Weboberfläche) refinedSearch häufigsten Suchanfragen.
  • Mechanismus: Diese vorgeschlagenen Suchanfragen sollten im Hintergrund oder bei Nutzerinteraktion über die Core Search API (SearchService.Search) ausgeführt werden.
  • Präsentation: Die Ergebnisse werden als interaktive Karussells oder anklickbare Karten angezeigt, sodass Nutzer verwandte Produktkategorien oder bestimmte Artikel durchsuchen können. Das bietet sofortigen Mehrwert und hilft, die Lücke zwischen Konversationsinteraktion und Produktentdeckung zu schließen.

Search API-Anfrage:

Folgefrage

{
  "placement": "projects/118220807021/locations/global/catalogs/default_catalog/placements/default_search",
  "query": "Decorations",
  "visitorId": "test"
}
  

Ereignisse, die an Vertex AI Search for Commerce gesendet werden

Es ist wichtig, Suchanfragen konversationellen Interaktionen korrekt zuzuordnen und die vollständigen Analysefunktionen in Vertex AI Search for Commerce mit dem richtigen Event-Tagging zu nutzen:

  1. conversation_id abrufen: Wenn Sie einen conversationalSearch API-Aufruf ausführen, wird ConversationalSearchResponse.conversation_id zurückgegeben.
  2. Nutzerereignisse taggen Wenn die Antwort im Chat zu einer Suchanfrage führt, z. B. durch die Anzeige eines refined_search-Vorschlags, auf den der Endnutzer klickt, oder wenn Ihr System automatisch eine Suche basierend auf der verfeinerten Anfrage ausführt, müssen Sie dieses nachfolgende Nutzerereignis für die Suche (UserEvent) mit demselben conversation_id taggen, das im ConversationalSearchResponse empfangen wurde.

Wenn Sie UserEvent.conversation_id richtig taggen, können Suchanfragen in Ihren Analysen den vorherigen dialogorientierten Interaktionen korrekt zugeordnet werden. So erhalten Sie wertvolle Einblicke in das Nutzerverhalten und die Conversion-Pfade.

Unterhaltung fortsetzen

In diesem Abschnitt wird beschrieben, wie Conversational Commerce-Agentsitzungen von der Conversational API verwaltet werden und in diesem letzten Schritt fortgesetzt werden.

Die Conversational API verwendet eine conversation_id, um laufende Unterhaltungen zu verwalten. Damit die Antworten des LLM und die Suchergebnisse übereinstimmen, müssen nachfolgende Conversational API-Anfragen SearchParams enthalten, die der Konfiguration der Core Search API-Aufrufe entsprechen.

Sitzungsverwaltung

  • So starten Sie eine neue Unterhaltung:
    • Beschreibung: Wenn der Client eine neue Unterhaltung beginnen möchte, lässt er das conversationId in der API-Anfrage weg.
    • Wann sollte eine neue Unterhaltung gestartet werden?: Ein Kunde möchte in mehreren gängigen UX-Szenarien eine neue Unterhaltung starten und so eine neue conversationId aus der API-Antwort erhalten:
      • Neuer Tab oder neue Sitzung: Wenn ein Kunde Ihre Website in einem neuen Browsertab öffnet oder eine völlig neue Sitzung startet.
      • Neue Originalanfrage: Wenn ein Kunde in einigen UX-Designs eine neue, nicht verwandte Anfrage eingibt, können Sie den Konversationsablauf neu starten, um den relevantesten Kontext zu gewährleisten.
      • Schaltfläche „Unterhaltung neu starten“: Wenn die Weboberfläche eine explizite Schaltfläche Neuen Chat starten oder Unterhaltung zurücksetzen bietet, wird durch Klicken darauf eine neue Unterhaltungssitzung gestartet.
    • Integration der Conversational API: Die API-Antwort enthält ein neues conversationId, das für nachfolgende Anfragen verwendet wird.
  • Unterhaltung fortsetzen:
    • Beschreibung: Die Conversational API gibt als Teil der API-Antwort ein conversation_id zurück. Diese ID muss in Folgeanfragen gesendet werden, um dieselbe Unterhaltung fortzusetzen. So wird sichergestellt, dass der Conversational Commerce-Agent auf die Anfragen Ihres Nutzers basierend auf dem Unterhaltungsverlauf innerhalb dieser Sitzung reagiert und dabei den Endnutzer query, das conversational_text_response und das followup_question berücksichtigt.
    • Integration der Conversational API: Der Client übergibt die conversation_id aus der vorherigen Antwort in der ConversationalSearchRequest.
  • Für konsistente Suchergebnisse sorgen:
    • Beschreibung: Damit die LLM-Antworten mit den Suchergebnissen übereinstimmen, die Ihrem Nutzer angezeigt werden, muss der Client searchParams in der Conversational API-Anfrage verwenden. Diese Suchparameter sollten dieselbe Konfiguration wie die Search API-Aufrufe zum Abrufen von Produktergebnissen haben, z. B. Filter und Sortierreihenfolge.
    • Integration der Conversational API: Das searchParams-Objekt innerhalb von ConversationalSearchRequest sollte identisch mit dem SearchRequest sein, das für die Suche nach Kernprodukten verwendet wird.

Anfrage an Vertex AI Search for Commerce senden

Sie können die conversation_id aus dem Sitzungsspeicher abrufen. Die Anfrage sollte die neue Kunden-query enthalten, die möglicherweise eine Antwort auf die Frage aus der vorherigen Antwort ist. Die Anfrage sollte auch die letzte refined_search.query aus der vorherigen Antwort enthalten, wenn der Endnutzer auf eine verfeinerte Anfrage reagiert. Andernfalls sollte sie eine völlig neue und unabhängige Anfrage sowie die conversationId enthalten. Denken Sie daran, immer einheitliche searchParams zu verwenden.

  • Szenario 1: Einzelne Suchleiste und fortlaufende Unterhaltung: Wenn Ihre Suchoberfläche nur eine Hauptsuchleiste oder ein fortlaufendes Unterhaltungsfenster hat, wird conversationId nicht zurückgesetzt, auch wenn der Endnutzer eine neue, scheinbar nicht zusammenhängende Anfrage eingibt. Das System verwendet den vorhandenen Unterhaltungsverlauf (der mit conversationId verknüpft ist), um kontextbezogene Antworten zu geben.
  • Szenario 2: Separates Unterhaltungsfenster und Abfragefenster: Wenn Ihre Suchoberfläche ein separates Unterhaltungsfenster und eine separate, standardmäßige Suchleiste (z. B. ein websiteweiter Suchbereich) bietet, kann die Eingabe einer neuen Anfrage in die standardmäßige Suchleiste implizit die Absicht signalisieren, eine neue, unabhängige Suche zu starten. Dies kann dazu führen, dass die conversationId für diese spezifische Suchaktion zurückgesetzt wird. Im entsprechenden Unterhaltungsfenster sollte die conversationId jedoch immer beibehalten werden, um die Kontinuität zu wahren.

Letztendlich ist die Entscheidung, wann der conversationId wiederverwendet oder zurückgesetzt wird, eine Designentscheidung, mit der Sie die Konversationserfahrung für Ihre Kunden optimieren können.

HTTP-Methode und Endpunkt (wie bei der ursprünglichen Anfrage)

POST https://retail.googleapis.com/v2alpha/{placement=projects/*/locations/*/catalogs/*/placements/*}:conversationalSearch
    

Conversational API-Anfrage:

Folgefrage

{
  "query": "A birthday party", // New query continuing the conversation from the previous turn
  "placement": "projects/799252947591/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "visitorId": "test", // Or your actual visitor_id
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb", // conversation_id from previous response
  "searchParams": {
    "filter": "categories:(\"Birthday Party Supplies\")"
  }
}
  

Antwort der Conversational API:

Folgeantwort

{
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "userQueryTypes": ["INTENT_REFINEMENT"],
  "conversationalTextResponse": "Great! For a birthday party, you might be interested in specific themes or age-group appropriate items.",
  "followupQuestion": {
    "followupQuestion": "What's the age group or theme?"
  },
  "refinedSearch": [
    { "query": "Birthday party decorations" },
    { "query": "Birthday party supplies" }
  ],
  "state": "SUCCEEDED"
}
  

Beispiele dafür, dass ein Endnutzer weiterhin Fragen erhält:

  • Nutzerfrage: Hilf mir, eine Party zu planen.
  • Antwort des Systems: Welche Art von Party planst du?
  • Antwort des Nutzers: Eine Geburtstagsfeier.

Was Einzelhändler mit der Antwort tun sollten

Die Felder werden ähnlich wie in der ursprünglichen Antwort gerendert. Beachten Sie jedoch die Änderungen, die sich aus der fortgesetzten Unterhaltung ergeben:

  • refined_search: Dieses Feld enthält aktualisierte Anfragen, in die die letzten Eingaben des Endnutzers einbezogen wurden. Sie sollten die Clientkonsole für die aktuelle Anfrage entsprechend aktualisieren, z. B. indem Sie die für Nutzer sichtbare Anfrage von „Dekorationen“ in „Dekorationen für Geburtstagsfeiern“ oder „Zubehör für Geburtstagsfeiern“ ändern. Die verfeinerten Suchanfragen können für Aufrufe der Core Search API (SearchService.Search) verwendet oder dem Endnutzer als Vorschläge angezeigt werden.
  • conversational_text_response: Hier wird die neue KI-generierte Textantwort angezeigt, die für den letzten Turn relevant ist.
  • followup_question: Wenn die Unterhaltung zur weiteren Optimierung fortgesetzt werden muss, wird ein neues followup_question bereitgestellt.

Ereignisse, die an Vertex AI Search for Commerce gesendet werden

Das Tagging von Ereignissen ist wichtig, um Suchanfragen konversationellen Interaktionen zuzuordnen und die Analysefunktionen in Vertex AI Search for Commerce zu nutzen.

Das Tagging von Ereignissen erfolgt in zwei Schritten:

  1. conversation_id abrufen: Wenn Sie einen conversationalSearch API-Aufruf ausführen, wird ConversationalSearchResponse.conversation_id zurückgegeben.
  2. Nutzerereignisse taggen Wenn die Antwort im Konversationsstil zu einer Suchanfrage führt, z. B. durch die Anzeige eines refined_search-Vorschlags, oder wenn Ihr System automatisch eine Suche basierend auf der verfeinerten Anfrage ausführt, müssen Sie dieses nachfolgende Nutzerereignis für die Suche (UserEvent) mit derselben conversation_id taggen, die in der ConversationalSearchResponse empfangen wurde.

Wenn Sie UserEvent.conversation_id richtig taggen, können Suchanfragen in Ihren Analysen den vorherigen dialogorientierten Interaktionen korrekt zugeordnet werden. So erhalten Sie wertvolle Einblicke in das Verhalten von Endnutzern und in Conversion-Pfade.

Agent in die konversationelle Produktfilterung einbinden

In dieser Anleitung wird beschrieben, wie Sie die Conversational API und die konversationelle Produktfilterung einbinden, um ein KI-gestütztes Shoppingerlebnis zu bieten. Wenn conversationalFilteringSpec.mode auf ENABLED festgelegt ist, kann Ihr System direkt zwischen offenen Konversationsinteraktionen und geführter Produktfilterung wechseln. So wird ein sehr optimierter Nutzerpfad geboten.

Zusammenspiel verstehen

Wenn sowohl der Conversational Commerce-Agent als auch die konversationelle Produktfilterung aktiviert sind, nutzt das System die Stärken beider. Der Conversational Commerce-Agent verarbeitet allgemeine Anfragen, liefert KI-generierte Antworten und verfeinert die ursprünglichen Intents. Die Conversational Commerce-Produktfilterung führt Nutzer durch die Auswahl bestimmter Produktattribute mithilfe eines vereinfachten chip- oder kachelbasierten Interaktionsmodells.

Der Interaktionspunkt und der potenzielle Übergang zwischen diesen beiden Modi treten auf, wenn die Klassifizierung der Conversational Commerce API zu einer produktorientierten Suche führt, insbesondere SIMPLE_PRODUCT_SEARCH. An diesem Punkt kann die API entweder eine direkte Suchanfrage bereitstellen oder, wenn die Absicht des Nutzers weiter verfeinert werden kann, einen geführten Filtervorgang durch dialogbasierte Produktfilterung auslösen.

Ein wichtiger Grundsatz dieser Integration ist, dass alle Freitext-Eingaben von der Conversational Commerce API verarbeitet werden, während Klicks auf Antwortvorschläge, die als Chips angezeigt werden, von der Konversationsproduktfilterung verarbeitet werden.

Nutzeranfrage senden

Beispiel für Nutzereingabe: Hilf mir, eine Party zu planen.

Damit sowohl der Konversations-Agent als auch die dialogbasierte Produktfilterung aktiviert werden, muss Ihre ConversationalSearchRequest diese Konfiguration enthalten:

Conversational Commerce API-Anfrage – Erste Anfrage

{
  "query": "Help me plan a party",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "placement": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/placements/default_search",
  "visitorId": "your_visitor_id",
  "conversationId": "", // Leave empty for the first query, or populate for ongoing conversation
  "searchParams": {
    // IMPORTANT: These search parameters should mirror the configuration
    // of your Commerce Search API calls to ensure consistency.
    "filter": "categories:(\"Party Supplies\" OR \"Decorations\" OR \"Food & Drink\")"
  },
  "userInfo": {
    // Optional: User information for enhanced personalization
  },
  "conversationalFilteringSpec": {
    "conversational_filtering_mode": "ENABLED" // Crucial for enabling product filtering
  }
}

Die wichtigsten Konfigurationen sind:

  • Conversational_filtering_mode: ENABLED: Wenn Sie dieses Feld in Ihrem conversationalFilteringSpec auf ENABLED setzen, wird der API mitgeteilt, dass Ihr System die Filterung von Produkten in Unterhaltungen verarbeiten kann. So kann die API relevante filterungsspezifische Antworten liefern.

Erste Antwort: Intention verfeinern

Das Feld userQueryTypes ist weiterhin von zentraler Bedeutung, um die Nutzerabsicht zu verstehen. Bei einer ersten allgemeinen Anfrage wie Hilf mir, eine Party zu planen wird die API sie wahrscheinlich als INTENT_REFINEMENT klassifizieren, wenn keine genauere Produktsuche sofort ersichtlich ist.

Antwort von Google

Antwort der Conversational Commerce API – Erste Anfrage

{
  "userQueryTypes": ["INTENT_REFINEMENT"],
  "conversationalTextResponse": "To plan a party, you'll need decorations, snacks, party supplies, drinks, and a cake. You can find a wide variety of decorations, snacks, and drinks. For party supplies, you can find everything from plates and cups to balloons and streamers. And for cake, you can choose from a variety of flavors and sizes.",
  "followupQuestion": {
    "followupQuestion": "What kind of party are you planning?"
  },
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "refinedSearch": [
    { "query": "Decorations" },
    { "query": "Snacks" },
    { "query": "Party Supplies" },
    { "query": "Drinks" },
    { "query": "Cake" }
  ],
  "state": "SUCCEEDED"
}

Aktion

  1. Zeigen Sie die conversationalTextResponse an.
  2. Präsentiere die refinedSearch-Vorschläge als anklickbare Chips für Dekorationen, Snacks. Alternativ können Sie die Commerce Search API parallel mit den refined_search-Anfragen aufrufen, um relevante Produktergebnisse wie Dekorationen, Snacks als Karussell neben dem Chat anzuzeigen.
  3. Zeige die followupQuestion an: Welche Art von Party planst du?
  4. Freie Nutzereingaben sind zulässig, um die Unterhaltung fortzusetzen.

Ereignis-Tagging und ‑Analyse

So sorgen Sie für genaue Analysen und Attributionen für die erste Konversationsinteraktion:

  • conversation_id abrufen: Erfassen Sie die conversation_id aus dem ConversationalSearchResponse. Diese ID ist wichtig, um alle nachfolgenden Aktionen mit dieser bestimmten Konversationssitzung zu verknüpfen.
  • Nutzerereignisse taggen Wenn die Antwort im Dialog zu einer Suchanfrage führt, z. B. wenn Ihr System automatisch eine Suche basierend auf einer refined_search-Anfrage ausführt oder wenn der Nutzer auf einen refined_search-Vorschlag klickt, müssen Sie dieses nachfolgende Nutzerereignis für die Suche (UserEvent) mit derselben conversation_id kennzeichnen.

Folgefrage

Wenn der Nutzer auf followupQuestion antwortet, wird die Unterhaltung verfeinert.

Beispiel für Nutzereingabe: Eine Geburtstagsfeier

Absichtsverfeinerung | Code-Snippets

Conversational Commerce API-Anfrage – Follow-up-Anfrage

{
  "query": "A birthday party", // New query continuing the conversation from the previous turn
  "placement": "projects/799252947591/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "visitorId": "test", // Or your actual visitor_id
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb", // conversation_id from previous response
  "searchParams": {},
  "conversationalFilteringSpec": {
    "conversational_filtering_mode": "ENABLED"
  }
}

Conversational Commerce API-Antwort – Follow-up-Anfrage

{
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "userQueryTypes": ["INTENT_REFINEMENT"],
  "conversationalTextResponse": "Great! For a birthday party, you might be interested in specific themes or age-group appropriate items.",
  "followupQuestion": {
    "followupQuestion": "What's the age group or theme?"
  },
  "refinedSearch": [
    { "query": "Birthday party decorations" },
    { "query": "Birthday party supplies" }
  ],
  "state": "SUCCEEDED"
}

Aktion

  1. Aktualisieren Sie die Weboberfläche mit den neuen Vorschlägen für conversationalTextResponse, refinedSearch und followupQuestion.
  2. Setzen Sie die Unterhaltung fort und fordern Sie weitere Details an.

Ereignis-Tagging und ‑Analyse

Wenn der Nutzer die Unterhaltung fortsetzt:

  • conversation_id abrufen: Achten Sie darauf, dass die conversation_id aus dem vorherigen ConversationalSearchResponse im aktuellen ConversationalSearchRequest übergeben wird.
  • Nutzerereignisse taggen Wenn die Antwort im Konversationsstil zu einer neuen Suchanfrage führt, z. B. weil ein Nutzer auf einen refined_search-Vorschlag klickt oder Ihr System einen parallelen Suchaufruf ausführt, taggen Sie das nachfolgende Nutzerereignis für die Suche (UserEvent) mit derselben conversation_id. So lässt sich der Verlauf von Multi-Turn-Unterhaltungen nachvollziehen.

Umstellung auf die dialogbasierte Produktfilterung

Wenn die Unterhaltung spezifischer wird, kann das System den Intent als SIMPLE_PRODUCT_SEARCH klassifizieren und gegebenenfalls die konversationelle Produktfilterung auslösen.

Beispiel für Nutzereingabe: Prinzessinnen-Thema

Conversational Commerce API-Anfrage – Follow-up-Anfrage

{
  "query": "Princess theme",
  "placement": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "visitorId": "your_visitor_id",
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "searchParams": {},
  "userInfo": {},
  "conversationalFilteringSpec": {
    "conversational_filtering_mode": "ENABLED"
  }
}

Wenn eine Anfrage als SIMPLE_PRODUCT_SEARCH klassifiziert wird, gibt es zwei mögliche API-Antworten, je nachdem, ob die Konversationsbasierte Produktfilterung ausgelöst wird. Der Hauptunterschied liegt im Vorhandensein und Inhalt des Felds conversationalFilteringResult.

Ergebnis 1: Filterung wird ausgelöst

Dies ist der Fall, wenn die Anfrage so allgemein ist, dass sie durch Produktattribute weiter verfeinert werden kann. Die Antwort enthält conversationalFilteringResult, die von Ihrer Weboberfläche priorisiert werden sollten.

Conversational Commerce API-Antwort – Umstellung auf Produktfilterung:

{
  "userQueryTypes": ["SIMPLE_PRODUCT_SEARCH"],
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "refinedSearch": [
    { "query": "princess birthday decorations" }
  ],
  "conversationalFilteringResult": {
    "followupQuestion": "What specific type of princess decoration are you looking for?",
    "suggestedAnswers": [
      { "answer": "Balloons", "query": "princess birthday balloons" },
      { "answer": "Streamers", "query": "princess birthday streamers" },
      { "answer": "Tablecloths", "query": "princess birthday tablecloths" }
    ]
  },
  "state": "SUCCEEDED"
}

Aktion

Die Anfrage wurde jetzt als SIMPLE_PRODUCT_SEARCH klassifiziert. In diesem Fall wird die dialogbasierte Produktfilterung ausgelöst. Es kann jedoch sein, dass die dialogbasierte Produktfilterung nicht ausgelöst wird.

  • Weboberfläche für die Konversations-Produktfilterung priorisieren:Wenn conversationalFilteringResult ausgefüllt ist, bedeutet das, dass Sie den Produktfiltermodus aufgerufen haben. Auf Ihrer Weboberfläche sollte der followupQuestion im Vordergrund stehen, der auf der Benutzeroberfläche etwa als Welche Art von Prinzessinnendekoration suchen Sie? angezeigt wird, sowie suggestedAnswers, z. B. klickbare Schaltflächen für Luftballons, Luftschlangen, Tischdecken.
  • Produktergebnisse anzeigen: Rufen Sie die Retail Search API sofort mit dem refined_search.query (princess birthday decorations) auf, um erste Produktergebnisse zusammen mit den Filteroptionen anzuzeigen.
  • Empfohlene Vorgehensweise für die Nutzerfreundlichkeit: Es sollte ein einzelnes, dauerhaft sichtbares Freitext-Eingabefeld für die gesamte Interaktion geben. Diese Leiste bleibt immer aktiv, auch während eines dialogbasierten Produktfilterungsvorgangs. Wenn conversationalFilteringResult aktiv ist und Sie Antwortvorschläge als anklickbare Chips anzeigen, haben Nutzer zwei klare Optionen:
    • Setzen Sie den Filtervorgang fort, indem Sie auf eine vorgeschlagene Antwort klicken.
    • Neuen Gesprächsbeitrag starten: Geben Sie eine neue Anfrage in die aktive Textleiste ein. Diese neue Eingabe löst immer einen neuen Aufruf der Conversational Commerce API aus, wodurch der aktuelle Filtervorgang beendet wird.

Ergebnis 2: Es wird kein Filter ausgelöst

Wenn die Anfrage bereits spezifisch genug ist oder sich nicht weiter filtern lässt, enthält die Antwort nicht das Feld conversationalFilteringResult. In diesem Fall sollten Sie mit einer Standardsuche fortfahren.

Aktion

  • Behandeln Sie die Interaktion als Ende des Konversationsablaufs und rufen Sie mit der refined_search-Abfrage die Retail Search API auf, um eine Standardseite mit Produktergebnissen anzuzeigen.

Ereignis-Tagging und ‑Analyse

Wenn die Unterhaltung zur Produktfilterung übergeht:

  • conversation_id abrufen: Verwenden Sie weiterhin dieselbe conversation_id.
  • Nutzerereignisse taggen Wenn der Übergang zu einer sofortigen Suche führt, taggen Sie UserEvent mit conversation_id. Wichtig: Wenn der Nutzer mit dem suggestedAnswers interagiert, z. B. wenn ein Endnutzer auf Luftballons klickt, sollte diese Aktion auch einen UserEvent auslösen, z. B. ein filter-Ereignis oder ein neues search-Ereignis, das mit demselben conversation_id getaggt ist. So können Filteraktionen im Konversationsablauf zugeordnet werden.

Mit der dialogbasierten Produktfilterung fortfahren

Wenn der Nutzer ein suggestedAnswer auswählt, senden Sie ein neues ConversationalSearchRequest.

Beispiel für Nutzereingabe (Klicken auf eine vorgeschlagene Antwort): Luftballons

Einfache Produktsuche | Code-Snippets

Conversational Commerce API-Anfrage – Weiter filtern

{
  "query": "Balloons", // The selected answer
  "placement": "projects/YOUR_PROJECT_ID/locations/global/catalogs/default_catalog/placements/default_search",
  "branch": "projects/{project_id}/locations/{location_id}/catalogs/{catalog_id}/branches/default_branch",
  "visitorId": "your_visitor_id",
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb", // Maintain conversation ID
  "searchParams": {},
  "userInfo": {},
  "conversationalFilteringSpec": {
    "conversational_filtering_mode": "ENABLED"
  }
}

Antwort der Conversational Commerce API – Filterung fortsetzen

{
  "userQueryTypes": ["SIMPLE_PRODUCT_SEARCH"],
  "conversationId": "1577511e-36ed-4054-8e07-48d1ca016bcb",
  "refinedSearch": [
    { "query": "princess birthday balloons" }
  ],
  "state": "SUCCEEDED"
}

Aktion

Die API antwortet mit einer SIMPLE_PRODUCT_SEARCH-Abfrage, aber ohne das Feld conversationalFilteringResult. Das bedeutet, dass der Ablauf für die geführte Filterung abgeschlossen ist.

  • Verwenden Sie die endgültige refinedSearch-Anfrage (princess birthday balloons), um die Retail Search API direkt aufzurufen.
  • Zeigen Sie dem Nutzer die Ergebnisse des Endprodukts an. An diesem Punkt kann die Unterhaltung entweder beendet werden oder der Nutzer kann eine neue Anfrage eingeben, um eine neue Runde zu starten.

Ereignis-Tagging und ‑Analyse

Für jeden Schritt im Produktfilterprozess:

  • conversation_id abrufen: Verwenden Sie für alle Anfragen innerhalb der Filtersitzung immer denselben conversation_id.
  • Nutzerereignisse taggen Jede Nutzerinteraktion mit einem suggestedAnswer, z. B. ein Klick, sollte ein relevantes UserEvent auslösen, z. B. ein filter-Ereignis oder ein neues search-Ereignis, wenn eine neue Anfrage erstellt wird. Diese UserEvent muss mit dem conversation_id getaggt werden, um den Filterprozess und seine Auswirkungen auf die Conversion genau zu erfassen.

Empfehlungen für die Benutzeroberfläche und Designentscheidungen

Die Interaktion zwischen dem Konversations-Agenten für den Handel und der dialogorientierten Produktfilterung bietet erhebliche Flexibilität. Hier sind einige wichtige UX-Aspekte, die Sie berücksichtigen sollten, um eine reibungslose und intuitive Nutzung zu ermöglichen:

  • Ein einzelnes Eingabefeld: Für die gesamte Funktion sollte nur ein Eingabefeld für Freitext vorhanden sein. Für die dialogbasierte Produktfilterung gibt es keine separate Eingabeleiste. Das vereinfacht die Benutzeroberfläche und sorgt für eine einheitliche Interaktion.
  • Nahtlose Übergänge: Gestalten Sie Ihre Weboberfläche so, dass sich Übergänge zwischen Antworten im Chat, vorgeschlagenen Anfragen und Filteroptionen natürlich und intuitiv anfühlen.
  • Klare Anleitung: Verwenden Sie visuelle Hinweise wie unterschiedliche Schaltflächenstile für vorgeschlagene Antworten anstelle von allgemeinen Eingaben und geben Sie klare Anweisungen, um den Nutzer in jeder Phase der Interaktion zu unterstützen.
  • Kontrolle ausbalancieren: Der Nutzer sollte immer das Gefühl haben, die Richtung des Gesprächs zu bestimmen.
    • Filtern im Vergleich zu Freiform: Die einzelne Freitext-Eingabeleiste bleibt jederzeit aktiv. So hat der Nutzer immer die Wahl: Er kann entweder auf eine vorgeschlagene Antwort klicken, um seine Suche weiter zu verfeinern, oder eine neue Anfrage in die Textleiste eingeben, um eine neue Unterhaltung zu starten. Dieses Design sorgt dafür, dass der Nutzer auch während eines Filtervorgangs zu einem anderen Thema wechseln kann, wenn sich seine Anforderungen ändern.
    • Option zum Zurücksetzen: Bieten Sie eine klare Option Neue Unterhaltung starten oder Filter zurücksetzen an, damit Nutzer ihre Suche oder ihren Filtervorgang neu starten können.

  • Visuelle Persistenz: Auch wenn Sie zu Produktfiltern wechseln, kann es hilfreich sein, den Unterhaltungsverlauf im Chatfenster beizubehalten, z. B. indem Sie frühere Fragen und Antworten anzeigen. So wird der Kontext verbessert und die Nutzerfreundlichkeit erhöht.

Zusätzliche Hinweise und Best Practices

Bei der Implementierung der Benutzeroberfläche Ihres Conversational Commerce-Agents sind zusätzliche Überlegungen und Best Practices zu berücksichtigen:

  • Konsistenz der Besucher-ID: Sorgen Sie dafür, dass für einen bestimmten Endnutzer bei jeder Anfrage eine eindeutige visitor_id gesendet wird. Das ist für eine genaue Personalisierung und das Modelltraining unerlässlich. Diese Kennung sollte idealerweise für einen Endnutzer über Sitzungen und An- oder Abmeldestatus hinweg konsistent bleiben.
  • Filialverwaltung: Obwohl default_branch üblich ist, sollten Sie die richtige Filial-ID verwenden, wenn Ihr Produktkatalog mehrere Filialen umfasst.
  • Search API-Interaktion: Denken Sie bei SIMPLE_PRODUCT_SEARCH und allen Fällen, in denen refined_search angegeben ist, daran, einen separaten Aufruf der Core Search API (SearchService.Search) mit dem query aus dem Feld refined_search oder der ursprünglichen Anfrage zu senden, um die tatsächlichen Produkteinträge zu erhalten. Bei der Conversational API geht es in erster Linie um die Konversationsfunktion und das Verständnis der Nutzerabsicht und nicht darum, direkt Produktergebnisse zurückzugeben.
  • Design der Benutzeroberfläche: Gestalten Sie Ihre Weboberfläche so, dass die Optionen conversational_text_response, followup_question und refined_search intuitiv präsentiert werden, um den Nutzer zu führen.

Nächste Schritte

Weitere Supportressourcen finden Sie in den FAQs zu konversationellen Funktionen.