Vertex AI Search for Commerce mit CRM-Personalisierung optimieren

In diesem API-Implementierungsleitfaden für Vertex AI Search for Commerce wird beschrieben, wie Sie Ihre CRM-Daten (Customer Relationship Management) verwenden, um die Suchergebnisse in Vertex AI Search for Commerce zu personalisieren. Durch die Integration von Nutzerattributen aus Ihrem CRM können Sie relevantere Suchergebnisse liefern und so letztendlich die Kundeninteraktion und die Conversion verbessern. In diesem Dokument wird der Prozess der Einbindung dieser Nutzerattribute beschrieben, einschließlich Datenüberlegungen und technischer Spezifikationen.

Daten für die Personalisierung auswählen

Die Effektivität der Personalisierung hängt von der Qualität, Abdeckung und Relevanz der von Ihnen bereitgestellten CRM-Daten ab. Überlegen Sie, welche Informationen über einen Kunden die Suchergebnisse beeinflussen würden, die ein sachkundiger Verkäufer anbieten könnte.

Nach Abschluss der Pilotversuche erhalten Sie fundiertere Empfehlungen dazu, welche Daten sich positiv auswirken und welche nicht.

Diese Datenkategorien enthalten die aussagekräftigsten Informationen zum Nutzerverhalten auf Ihrer E-Commerce-Website.

  • Geografische Informationen: Kundenstandort, z. B. Bundesland oder Land. Die Postleitzahlinformationen sind zu detailliert. Weitere Informationen finden Sie im Abschnitt Zu hoher Detaillierungsgrad.
  • Demografische Daten: Wichtige Kundenmerkmale wie Alter und Geschlecht.
    • Wenn Sie die Altersgruppe eines Kunden kennen (z. B. 18–24 Jahre im Gegensatz zu 55–64 Jahren), können Sie wahrscheinlich unterschiedliche Strategien für die Produktanzeige für Artikel wie Bekleidung oder Elektronik verwenden. Diese Daten sind sehr wirkungsvoll.
  • Kunden-Personas: Zum Beispiel ein preisbewusster oder sparsamer Käufer im Gegensatz zu einem Käufer, der viel ausgibt.

Datenkategorien, die wahrscheinlich weniger Auswirkungen haben

Diese Datenkategorien haben nur geringe Auswirkungen auf die Erfassung Ihrer Commerce-Daten.

  • Attribute, die aus dem Kaufverlauf abgeleitet werden:
    • In unserem System wird das bisherige Kaufverhalten bereits für die Personalisierung berücksichtigt.
    • Das Senden von Attributen wie user bought a green dress yesterday ist redundant, da diese Informationen nativ erfasst und verwendet werden.
    • Konzentrieren Sie sich auf neue Erkenntnisse aus Ihrem CRM.
  • Spezifische Daten zur Marketingreaktion, z. B. Clicked email #7:
    • Dieser Parameter ist zwar für die Analyse von Marketingkampagnen relevant, gibt der KI aber nicht vor, welches Suchergebnis angezeigt werden soll.

Vollständigkeit der Daten

Neben der Relevanz hat auch die Vollständigkeit Ihrer Daten für alle Nutzer einen erheblichen Einfluss auf die Nützlichkeit der Daten für die Personalisierung. Ein Attribut ist am wertvollsten, wenn es für einen erheblichen Teil Ihrer Nutzer verfügbar ist. So kann das System umfassendere Muster erkennen und die Personalisierung breiter anwenden.

  • Sehr nützlich:
    • Attribute, die Sie für einen Großteil Ihrer Nutzer haben, z. B. shipping_state:MA, wenn es für 70% Ihrer Nutzer verfügbar ist.
    • Das ermöglicht eine robuste Mustererkennung und eine breite Anwendung der Personalisierung.
  • Weniger nützlich:
    • Attribute, die nur für einen kleinen Teil Ihrer Nutzer verfügbar sind, z. B. hair_color:blonde, wenn sie nur für 0,1% Ihrer Nutzerbasis verfügbar sind.

Solche spärlichen Daten sind zwar interessant, erschweren es dem System jedoch, aufgrund fehlender Beispiele sinnvolle Personalisierungssignale abzuleiten. Konzentrieren Sie sich stattdessen auf Attribute, die eine breitere Abdeckung Ihrer Kundenprofile bieten.

Richtlinien für den Detaillierungsgrad von Daten

Der richtige Detaillierungsgrad der Daten ist entscheidend für eine effektive Personalisierung. Zu allgemeine oder zu spezifische Daten können die Fähigkeit des Systems, aussagekräftige Muster zu erkennen, beeinträchtigen. Verwenden Sie Attribute, mit denen Sie Ihre Kundenbasis in umsetzbare Gruppen unterteilen können.

Angemessener Detaillierungsgrad

Beispiele für einen angemessenen Detaillierungsgrad sind Felder für:

  • Geschlecht
  • Bundesland
  • Ort
  • Altersgruppe (z. B. 30–39 Jahre)

Auf dieser Granularitätsebene ist eine Personalisierung möglich, ohne dass eine unüberschaubare Anzahl von Kategorien entsteht.

Unzureichende Granularität

Ein Beispiel für eine unzureichende Granularität ist country:US, wenn sich der Großteil Ihres Kundenstamms in den USA befindet. Das liegt daran, dass ein Attribut, das nur geringe Unterschiede zwischen den Kunden aufweist, nur wenig Wert für die Personalisierung bietet.

Übermäßige Granularität

Beispiele für übermäßigen Detaillierungsgrad:

  • Genaue Postleitzahlen (zipcode:12345): Da es Zehntausende von möglichen Postleitzahlen gibt, sind die meisten mit nur sehr wenigen Kunden verknüpft. Durch diese Atomisierung wird das Signal verwässert. Wenn Sie Postleitzahlen verwenden, kürzen Sie sie auf die ersten beiden Ziffern, um eine angemessenere Granularität zu erzielen. Die ersten beiden Ziffern von Postleitzahlen werden ungefähr Bundesstaaten zugeordnet.
  • Genaue Altersangaben (age:37): Dadurch wird eine übermäßige Anzahl von Alterskategorien erstellt. Um die Anzahl zu reduzieren, können Sie numerische Daten wie das Alter in etwa 10 vordefinierte Klassen oder Gruppen (z. B. age:30-39) einteilen.

Weitere Datenrichtlinien

In diesem Abschnitt werden kategoriale und andere Datenformate behandelt.

Format kategorischer Daten

Dieses System ist für kategorische Daten optimiert, d. h. für eindeutige, benannte Werte wie:

  • state:MA
  • gender:male

Numerische Daten

Aus diesem Grund sollten alle numerischen Attribute wie Alter, Einkommen oder Häufigkeit vor der Datenübertragung in sinnvolle Gruppen eingeteilt werden.

Hier sind Beispiele für falsche und richtige Werte:

  • age:37
  • age:30-39

Zusätzliche Dateneinschränkungen

  • Attributlimit: Jede Anfrage unterstützt bis zu 100 Schlüssel/Wert-Paare. In zukünftigen Versionen werden möglicherweise weitere Paare unterstützt.
  • Doppelte Schlüssel: Doppelte Schlüssel sind in einer einzelnen Anfrage nicht zulässig. Mehrere Werte pro Schlüssel werden jedoch unterstützt.
  • Verbotene personenidentifizierbare Informationen: Sie dürfen unter keinen Umständen bestimmte personenidentifizierbare Informationen wie E‑Mail-Adressen von Kunden, Sozialversicherungsnummern, vollständige Namen oder Finanzdaten wie Kreditkartennummern in irgendeiner Form senden.

API-Integration und Datenübertragung

Kundendaten sollten im Feld query Ihrer Suchanfragen und nicht in den Ereignissen übertragen werden.

Protokollpufferstruktur (für Entwickler)

Die Nutzerattribute werden in der SearchRequest-Nachricht als Zuordnung von Strings zu einer StringList-Nachricht definiert.

Protobuf-Beispiel ansehen

// A list of string values.
message StringList {
// String values.
repeated string values;
}

// Request message for [SearchService.Search][] method.
message SearchRequest {
...
// The user attributes that could be used for personalization of search.
maptring, StringList> user_attributes;
}

Beispiel für JSON-Anfrage

In diesem Beispiel wird veranschaulicht, wie user_attributes in einer JSON-Suchanfrage strukturiert wird.

JSON-Beispiel ansehen

{
...

user_attributes: [
       { key: "pets" # note keys can be hashed or unhashed
         value {
           values: "dog" # Note: these values MUST be hashed
           values: "cat"
         }
       },
       { key: "state"
         value {
           values: "CA"
         }
       }
      ]
}

API-Antwort

Bei Verwendung dieses Features gibt es keine Änderungen an der SearchResponse API. Die Personalisierung erfolgt intern auf Grundlage der bereitgestellten Nutzerattribute.

Anforderungen an das Hashing von Daten

Zum Schutz von Daten und zur Gewährleistung der Datensicherheit müssen Attributwerte gehasht werden. Schlüssel können gehasht oder nicht gehasht gesendet werden.

Hashing-Schlüssel

Attributschlüssel wie pet_owner und state können in ihrer ursprünglichen Stringform oder gehasht gesendet werden. Beide sind zulässig.

Beispiel:

  • Akzeptabel – pet_owner
  • Akzeptabel – hash(pet_owner)

Werte hashen

Attributwerte wie dog und CA müssen gehasht werden. Das Senden von Klartextwerten ist nicht zulässig.

Beispiel:

  • Akzeptabel – hash(dog)
  • Nicht akzeptabel – "Dog"

Kombiniertes Hashing von Schlüssel/Wert-Paaren

Wenn sowohl der Schlüssel als auch der Wert gehasht werden sollen, müssen sie unabhängig voneinander gehasht werden. Die kombinierte Schlüssel/Wert-Zeichenfolge darf nicht gehasht werden.

Beispiel:

  • Akzeptabel – pet_owner:hash("dog")
  • Akzeptabel – hash(pet_owner):hash("dog")
  • Nicht akzeptabel – hash("Pet_owner:dog")

Best Practices für die Datenübertragung

In diesem Abschnitt werden einige Best Practices für die Datenübertragung beschrieben, darunter der Umgang mit wiederholten Werten, Datenkonsistenz, Flexibilität bei der Benennung von Attributschlüsseln und der Umgang mit unterschiedlichen Nutzerprofilen.

Umgang mit wiederholten Werten

Wenn ein Nutzer mehrere Werte für ein einzelnes Attribut hat, z. B. sowohl einen Hund als auch eine Katze, geben Sie alle Werte unter einem einzelnen key innerhalb des StringList an.

Die folgenden Codebeispiele zeigen Beispiele für die falsche bzw. richtige Verwendung:

Beispiel ansehen

// This is incorrect because it sends the same key multiple times for different
// values, causing only one of the two values for pets to be used, choosing one
// value or the other in an inconsistent manner.
{
  key: "pets",
  value {
    values: "dog"
  }
},
{
  key: "pets",
  value {
    values: "cat"
  }
}

Beispiel ansehen

{
  key: "pets",
  value {
    values: "dog",
    values: "cat"
  }
}

Datenkonsistenz

Achten Sie auf eine einheitliche Rechtschreibung, Leerzeichen und Groß-/Kleinschreibung aller Schlüssel und Werte. Das System interpretiert selbst geringfügige Abweichungen als separate Kategorien.

Beispielsweise werden State:MA, state:MA, state:ma, STATE:MA und residence_state:MA als separate und unabhängige Attribute behandelt.

Flexibilität bei der Benennung von Attributschlüsseln

Die spezifische Namenskonvention für Ihre Attributschlüssel (z. B. pet_owner, pets, codeabc) hat zwar keinen direkten Einfluss auf die Fähigkeit des Systems, die Daten zu verwenden, sie sollte aber einheitlich sein. Entscheidend ist die Konsistenz der von Ihnen übertragenen Daten.

Umgang mit unterschiedlichen Nutzerprofilen

Es ist in Ordnung, wenn verschiedene Nutzer unterschiedliche Attributsätze haben.

  • Beispiel: Nutzer A hat möglicherweise age:30-39 und pet:dog, während Nutzer B gender:male, aber keine Daten zu Haustieren oder zum Alter hat. Das System verarbeitet unvollständige Profile problemlos.

Dynamische Datenaktualisierungen

Nutzerattribute können sich im Laufe der Zeit ändern. Sie können das Profil eines Nutzers mit neuen Informationen aktualisieren, sobald diese verfügbar sind.

  • Beispiel: Ein Nutzer, der anfangs mit age:30-39 und pet:dog identifiziert wurde, kann später state:MA hinzugefügt bekommen, wenn sein Standort ermittelt wird.

Plattformübergreifende Konsistenz

Achten Sie darauf, dass Attribute für einen bestimmten Nutzer über alle Touchpoints hinweg, z. B. mobile App oder Website, einheitlich übertragen werden. So wird eine einheitliche Personalisierung gewährleistet.

  • Optimal: Nutzer A ist sowohl in der mobilen App als auch auf der Website durchgehend age:30-39.
  • Suboptimal: Nutzer A ist in der mobilen App age:30-39, auf der Website jedoch nur pet:dog.

Umgang mit fehlenden Daten

Wenn bestimmte Informationen zu einem Nutzer nicht verfügbar sind, senden Sie keinen Platzhalter oder leeren Wert. Lassen Sie das Schlüssel/Wert-Paar einfach aus der Anfrage weg.

  • Beispiel: Vermeiden Sie pet:unknown oder pet:.

SDK- und Bibliothekszugriff

Der Zugriff auf diese Bibliotheken ist ab den folgenden Versionen möglich: