Améliorer Vertex AI Search pour le commerce avec la personnalisation CRM

Ce guide d'implémentation de l'API Vertex AI Search for Commerce explique comment utiliser vos données de gestion de la relation client (CRM) pour personnaliser les expériences de recherche dans Vertex AI Search for Commerce. En intégrant les attributs utilisateur de votre CRM, vous pouvez fournir des résultats de recherche plus pertinents, ce qui améliore l'engagement client et les conversions. Ce document décrit en détail le processus d'intégration de ces attributs utilisateur, y compris les considérations relatives aux données et les spécifications techniques.

Sélectionner les données pour la personnalisation

L'efficacité de la personnalisation dépend de la qualité, de la couverture et de la pertinence des données CRM que vous fournissez. Réfléchissez aux informations sur un client qui pourraient réellement influencer les résultats de recherche qu'un vendeur compétent pourrait proposer.

Conseil : Posez-vous la question suivante : Si un vendeur en magasin connaissait ces données sur le client, lui proposerait-il un autre produit ?

Une fois les tests pilotes terminés, vous disposerez de recommandations plus pertinentes sur les données qui ont un impact (ou non).

Catégories de données recommandées pour l'impact

Ces catégories de données constituent les informations les plus révélatrices du comportement des utilisateurs sur votre site e-commerce.

• Informations géographiques : emplacement du client (État ou pays, par exemple). Les informations sur le code postal sont trop précises. Pour en savoir plus, consultez la section Granularité excessive.
• Données démographiques : caractéristiques clés des clients, comme l'âge et le genre.
  • Connaître la tranche d'âge d'un client (18-24 ans plutôt que 55-64 ans) permettrait probablement d'adapter les stratégies d'affichage des produits pour des articles tels que les vêtements ou les appareils électroniques. Il s'agit de données très importantes.
• Personas client : par exemple, un client soucieux de son budget ou économe, par opposition à un client dépensier.

Catégories de données moins susceptibles d'avoir un impact

Ces catégories de données ont un impact marginal sur la collecte de vos données commerciales.

• Attributs dérivés de l'historique des achats :
  • Notre système intègre déjà l'historique des achats pour la personnalisation.
  • L'envoi d'attributs tels que user bought a green dress yesterday est redondant, car ces informations sont capturées et utilisées de manière native.
  • Concentrez-vous sur les insights inédits de votre CRM.
• Données spécifiques sur les réponses marketing, telles que Clicked email #7 :
  • Bien qu'il soit pertinent pour l'analyse des campagnes marketing, il n'indique pas à l'IA quel résultat de recherche afficher.

Exhaustivité des données

Au-delà de la pertinence, l'exhaustivité de vos données pour l'ensemble de votre base d'utilisateurs a un impact significatif sur leur utilité pour la personnalisation. Un attribut est plus utile lorsqu'il est disponible pour une partie importante de vos utilisateurs, ce qui permet au système d'identifier des tendances plus larges et d'appliquer la personnalisation plus largement.

• Très utile :
  • Attributs dont vous disposez pour une grande majorité de vos utilisateurs, comme shipping_state:MA s'il est disponible pour 70 % de votre base d'utilisateurs.
  • Cela permet une reconnaissance robuste des schémas et une application généralisée de la personnalisation.
• Moins utile :
  • Attributs disponibles pour une petite fraction de vos utilisateurs uniquement, comme hair_color:blonde s'il n'est disponible que pour 0,1 % de votre base d'utilisateurs.

Bien que ces données soient intéressantes, elles sont trop rares pour que le système puisse en déduire des signaux de personnalisation pertinents en raison du manque d'exemples suffisants. Privilégiez plutôt les attributs qui offrent une couverture plus large de vos profils de clients.

Consignes concernant la précision des données

Le niveau de précision des données est essentiel pour une personnalisation efficace. Des données trop générales ou trop spécifiques peuvent réduire la capacité du système à identifier des schémas significatifs. Essayez de choisir des attributs qui segmentent votre base de clients en groupes exploitables.

Conseil : Pour une granularité optimale, essayez d'utiliser des attributs qui génèrent entre 2 et 50 catégories distinctes.

Précision appropriée

Voici des exemples de précision appropriée :

• Sexe
• État
• Ville
• Tranche d'âge (par exemple, 30 à 39 ans)

Ce niveau de précision permet de différencier la personnalisation sans créer un nombre ingérable de catégories.

Précision insuffisante

Par exemple, country:US est un exemple de précision insuffisante si la grande majorité de votre clientèle réside aux États-Unis. En effet, un attribut qui présente peu de variance dans votre base de clients offre une valeur minimale pour la personnalisation.

Précision excessive

Voici des exemples de granularité excessive :

• Codes postaux exacts (zipcode:12345) : il existe des dizaines de milliers de codes postaux potentiels, mais la plupart d'entre eux ne sont associés qu'à très peu de clients. Cette atomisation dilue le signal. Si vous utilisez des codes postaux, tronquez-les aux deux premiers chiffres pour obtenir un niveau de précision plus approprié. Les deux premiers chiffres des codes postaux sont approximativement associés à des zones de la taille d'un État.
• Âges exacts (age:37) : cela crée un nombre excessif de catégories d'âge. Pour réduire ce nombre, regroupez les données numériques comme l'âge dans environ 10 bins ou buckets prédéfinis (par exemple, age:30-39).

Consignes supplémentaires pour les données

Cette section traite des formats de données catégorielles et autres.

Format des données catégorielles

Ce système est optimisé pour les données catégorielles, c'est-à-dire les valeurs distinctes et nommées, telles que :

• state:MA
• gender:male

Données numériques

Point clé : Le système traite toutes les valeurs (y compris les nombres) comme des catégories plutôt que de comprendre intrinsèquement la proximité ou l'ordre numériques. Par exemple, age:37, age:37.1 et age:37.0 seront traitées comme trois catégories distinctes et sans rapport. Le système n'inférera pas que age:37 et age:38 sont proches, ni qu'il comprendra que age:37 et age:82 sont éloignés.

Pour cette raison, tous les attributs numériques tels que l'âge, le revenu ou la fréquence doivent être regroupés dans des buckets pertinents avant la transmission des données.

Voici des exemples incorrects et corrects, respectivement :

• age:37
• age:30-39

Contraintes supplémentaires concernant les données

• Limite d'attributs : chaque requête accepte jusqu'à 100 paires clé-valeur. D'autres paires pourront être ajoutées dans les prochaines versions.
• Clés en double : les clés en double ne sont pas autorisées dans une même requête. Toutefois, plusieurs valeurs par clé sont acceptées.
• Informations permettant d'identifier personnellement l'utilisateur interdites : vous ne devez en aucun cas envoyer d'informations permettant d'identifier personnellement l'utilisateur spécifiques, telles que les adresses e-mail des clients, les numéros de sécurité sociale, les noms complets ou les données financières, comme les numéros de carte de crédit, sous quelque forme que ce soit.

Intégration d'API et transmission de données

Les données client doivent être transmises dans le champ query de vos requêtes de recherche, et non dans les événements.

Structure du tampon de protocole (pour les développeurs)

Les attributs utilisateur sont définis dans le message SearchRequest sous forme de mappage de chaînes vers un message StringList.

Afficher l'exemple de fichier .proto

// 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;
}

Exemple de requête JSON

Cet exemple montre comment structurer user_attributes dans une requête de recherche JSON.

Afficher un exemple JSON

{
...

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"
         }
       }
      ]
}

Réponse de l'API

Aucune modification n'est apportée à l'API SearchResponse lorsque vous utilisez cette fonctionnalité. La personnalisation a lieu en interne en fonction des attributs utilisateur fournis.

Exigences concernant le hachage des données

Pour assurer la confidentialité et la sécurité des données, les valeurs des attributs doivent être hachées. Les clés peuvent être envoyées hachées ou non hachées.

Clés de hachage

Les clés d'attribut, telles que pet_owner et state, peuvent être envoyées sous leur forme de chaîne d'origine ou hachées. Les deux sont acceptables.

Exemple :

• Acceptable : pet_owner
• Acceptable : hash(pet_owner)

Hachage des valeurs

Les valeurs des attributs, telles que dog et CA, doivent être hachées. L'envoi de valeurs en texte brut n'est pas autorisé.

Exemple :

• Acceptable : hash(dog)
• Non acceptable : "Dog"

Hachage combiné des paires clé-valeur

Si la clé et la valeur doivent être hachées, elles doivent l'être indépendamment. Ne hachez pas la chaîne clé-valeur combinée.

Exemple :

• Acceptable : pet_owner:hash("dog")
• Acceptable : hash(pet_owner):hash("dog")
• Non acceptable : hash("Pet_owner:dog")

Bonnes pratiques pour la transmission de données

Cette section présente plusieurs bonnes pratiques pour la transmission de données, y compris la gestion des valeurs répétées, la cohérence des données, la flexibilité de la dénomination des clés d'attributs et la gestion des profils utilisateur variés.

Gérer les valeurs répétées

Si un utilisateur possède plusieurs valeurs pour un même attribut (par exemple, un chien et un chat), indiquez toutes les valeurs sous un seul key dans StringList.

Ces exemples de code illustrent respectivement des exemples d'utilisation incorrecte et correcte :

Voir l'exemple

// 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"
  }
}

Voir l'exemple

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

Cohérence des données

Veillez à ce que l'orthographe, l'espacement et la casse de toutes les clés et valeurs soient strictement cohérents. Le système interprète même les variations mineures comme des catégories distinctes.

Par exemple, State:MA, state:MA, state:ma, STATE:MA et residence_state:MA seront tous traités comme des attributs distincts et sans rapport.

Attention : La même clé doit toujours être utilisée pour un attribut donné.

Exemple :

• Ne pas inverser pets: et pets_owned:.
• Une fois qu'un attribut de clé ou de valeur est établi, ne modifiez pas l'espacement, la ponctuation ni la mise en majuscules.

Flexibilité dans la dénomination des clés d'attributs

Bien que cohérente, la convention de dénomination spécifique de vos clés d'attribut (par exemple, pet_owner, pets, codeabc) n'a pas d'incidence intrinsèque sur la capacité du système à utiliser les données. L'aspect crucial est la cohérence des données que vous transmettez.

Gérer différents profils utilisateur

Il est acceptable que différents utilisateurs disposent de différents ensembles d'attributs.

• Exemple : L'utilisateur A peut avoir age:30-39 et pet:dog, tandis que l'utilisateur B a gender:male, mais aucune donnée sur son animal de compagnie ni son âge. Le système gère les profils partiels de manière fluide.

Mises à jour dynamiques des données

Les attributs utilisateur peuvent évoluer au fil du temps. Vous pouvez mettre à jour le profil d'un utilisateur avec de nouvelles informations dès qu'elles sont disponibles.

• Exemple : Un utilisateur initialement identifié avec age:30-39 et pet:dog peut ensuite se voir ajouter state:MA si sa position est acquise.

Cohérence multiplate-forme

Essayez de transmettre les attributs de manière cohérente pour un utilisateur donné sur tous les points de contact, tels que l'application mobile ou le site Web. Cela garantit une expérience de personnalisation unifiée.

• Optimal : l'utilisateur A est systématiquement age:30-39 dans l'application mobile et sur le site Web.
• Sous-optimal : l'utilisateur A est age:30-39 sur l'application mobile, mais seulement pet:dog sur le site Web.

Gérer les données manquantes

Si une information spécifique sur un utilisateur n'est pas disponible, n'envoyez pas d'espace réservé ni de valeur vide. Il vous suffit d'omettre cette paire clé-valeur dans la requête.

• Exemple : Évitez pet:unknown ou pet:

Accès au SDK et à la bibliothèque

Vous pouvez accéder à ces bibliothèques dans les versions suivantes et ultérieures :

• Java
• Python
• Node.js
• Go
• PHP
• Ruby
• C# .NET