KI-basierte Commerce-Suche mit CRM-Personalisierung optimieren

In dieser Implementierungsanleitung für die KI-basierte Suche im Einzelhandel wird beschrieben, wie Sie Ihre CRM-Daten (Customer Relationship Management) verwenden können, um die Suchergebnisse in der KI-basierten Suche im Einzelhandel zu personalisieren. Durch die Integration von Nutzerattributen aus Ihrem CRM können Sie relevantere Suchergebnisse liefern und so die Kundeninteraktion und Conversion verbessern. In diesem Dokument wird der Prozess der Integration 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 Pilottests haben Sie fundiertere Empfehlungen dazu, welche Daten sich auswirken und welche nicht.

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

  • Geografische Informationen: Standort des Kunden, z. B. Bundesland oder Land. Informationen zur Postleitzahl sind zu detailliert. Weitere Informationen finden Sie im Abschnitt Übermäßige Detaillierung.
  • 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 unterschiedliche Strategien für die Produktpräsentation für Artikel wie Kleidung oder Elektronik anwenden. Diese Daten sind sehr wirkungsvoll.
  • Kunden-Personas: Zum Beispiel ein preisbewusster oder sparsamer Käufer im Gegensatz zu einem Großverdiener.

Datenkategorien, die weniger wahrscheinlich wirkungsvoll sind

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

  • Attribute, die aus den bisherigen Käufen abgeleitet wurden:
    • Unser System berücksichtigt bereits das bisherige Kaufverhalten für die Personalisierung.
    • Das Senden von Attributen wie user bought a green dress yesterday ist überflüssig, 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:
    • Diese Daten sind zwar für die Analyse von Marketingkampagnen relevant, sagen der KI aber nicht, welches Suchergebnis angezeigt werden soll.

Vollständigkeit der Daten

Neben der Relevanz wirkt sich auch die Vollständigkeit Ihrer Daten für Ihre Nutzerbasis erheblich auf ihren Nutzen für die Personalisierung aus. 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 für einen Großteil Ihrer Nutzer vorhanden sind, z. B. shipping_state:MA, wenn sie für 70% Ihrer Nutzerbasis verfügbar sind.
    • Dies 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, machen es dem System aber schwer, aussagekräftige Personalisierungssignale abzuleiten, da nicht genügend Beispiele vorhanden sind. Priorisieren Sie stattdessen Attribute, die eine breitere Abdeckung Ihrer Kundenprofile bieten.

Richtlinien für die Datendetaillierung

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 beeinträchtigen, aussagekräftige Muster zu erkennen. Verwenden Sie Attribute, mit denen Sie Ihre Kundenbasis in umsetzbare Gruppen segmentieren können.

Angemessener Detaillierungsgrad

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

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

Dieser Detaillierungsgrad ermöglicht eine Personalisierung, ohne eine unüberschaubare Anzahl von Kategorien zu erstellen.

Unzureichende Detaillierung

Ein Beispiel für eine unzureichende Detaillierung ist country:US, wenn der Großteil Ihrer Kundenbasis in den USA ansässig ist. Ein Attribut, das nur wenig Varianz in Ihrer Kundenbasis aufweist, bietet nur einen minimalen Wert für die Personalisierung.

Übermäßige Detaillierung

Beispiele für eine übermäßige Detaillierung:

  • Genaue Postleitzahlen (zipcode:12345): Bei Zehntausenden potenziellen Postleitzahlen haben die meisten nur sehr wenige zugeordnete Kunden. Diese Atomisierung verwässert das Signal. Wenn Sie Postleitzahlen verwenden, kürzen Sie sie auf die ersten beiden Ziffern, um einen angemesseneren Detaillierungsgrad zu erreichen. Die ersten beiden Ziffern der Postleitzahlen sind ungefähr Gebieten in der Größe von Bundesländern zugeordnet.
  • Genaue Altersangaben (age:37): Dadurch wird eine übermäßige Anzahl von Alterskategorien erstellt. Um die Anzahl zu reduzieren, gruppieren Sie numerische Daten wie das Alter in ungefähr 10 vordefinierte Bins oder Buckets (z. B. age:30-39).

Weitere Datenrichtlinien

In diesem Abschnitt werden kategoriale und andere Datenformate behandelt.

Kategoriales Datenformat

Dieses System ist für kategoriale Daten optimiert: 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 aussagekräftige Buckets gruppiert werden.

Hier sind Beispiele für falsche und richtige Werte:

  • age:37
  • age:30-39

Zusätzliche Dateneinschränkungen

  • Attributlimit: Jede Abfrage unterstützt bis zu 100 Schlüssel/Wert-Paare. Unterstützung für weitere Paare wird möglicherweise in zukünftigen Versionen hinzugefügt.
  • Schlüsselduplikate: Schlüsselduplikate sind in einer einzelnen Abfrage nicht zulässig. Mehrere Werte pro Schlüssel werden jedoch unterstützt.
  • Verbotene personenbezogene Daten: Unter keinen Umständen dürfen Sie bestimmte personenbezogene Daten (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 Nachricht SearchRequest 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;
}

JSON-Beispielanfrage

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

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 dieser Funktion gibt es keine Änderungen an der SearchResponse-API. Die Personalisierung erfolgt intern basierend auf den bereitgestellten Nutzerattributen.

Anforderungen an das Daten-Hashing

Um den Datenschutz und die Datensicherheit zu gewährleisten, müssen Attributwerte gehasht werden. Schlüssel können gehasht oder nicht gehasht gesendet werden.

Schlüssel hashen

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

Beispiel:

  • Zulässig: pet_owner
  • Zulässig: hash(pet_owner)

Werte hashen

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

Beispiel:

  • Zulässig: hash(dog)
  • Nicht zulässig: "Dog"

Kombiniertes Schlüssel/Wert-Hashing

Wenn sowohl der Schlüssel als auch der Wert gehasht werden sollen, müssen sie unabhängig voneinander gehasht werden. Hashen Sie nicht den kombinierten Schlüssel/Wert-String.

Beispiel:

  • Zulässig: pet_owner:hash("dog")
  • Zulässig: hash(pet_owner):hash("dog")
  • Nicht zulässig: hash("Pet_owner:dog")

Best Practices für die Datenübertragung

In diesem Abschnitt werden mehrere 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 besitzt, geben Sie alle Werte unter einem einzigen key in der StringList an.

Diese Codebeispiele zeigen Beispiele für die falsche und 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 strikte Konsistenz bei der Schreibweise, den Abständen und der Groß- und Kleinschreibung aller Schlüssel und Werte. Das System interpretiert selbst geringfügige Abweichungen als unterschiedliche Kategorien.

Beispielsweise werden State:MA, state:MA, state:ma, STATE:MA und residence_state:MA alle als separate und nicht verwandte 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 keine direkten Auswirkungen auf die Fähigkeit des Systems, die Daten zu verwenden, sie sollte aber konsistent sein. Entscheidend ist die Konsistenz der von Ihnen übertragenen Daten.

Umgang mit unterschiedlichen Nutzerprofilen

Es ist zulässig, dass verschiedene Nutzer unterschiedliche Attributsätze haben.

  • Beispiel: Nutzer A hat möglicherweise age:30-39 und pet:dog, während Nutzer B gender:male hat, aber keine Daten zu Haustieren oder zum Alter. 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 ursprünglich mit age:30-39 und pet:dog identifiziert wurde, kann später state:MA hinzugefügt werden, wenn sein Standort erfasst wird.

Plattformübergreifende Konsistenz

Achten Sie auf eine konsistente Attributübertragung für einen bestimmten Nutzer über alle Touchpoints hinweg, z. B. mobile App oder Website. So wird eine einheitliche Personalisierung gewährleistet.

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

Umgang mit fehlenden Daten

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

  • Beispiel: Vermeiden Sie pet:unknown oder pet:

Zugriff auf SDK und Bibliotheken

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