La barre de recherche moderne pour le commerce électronique est bien plus qu'un simple champ de saisie. Il s'agit d'un assistant interactif et dynamique qui guide vos utilisateurs vers les bons produits avant même qu'ils aient fini de saisir du texte. Cette expérience de saisie semi-automatique, qui affiche des suggestions de requêtes, des marques populaires, des catégories pertinentes et même les meilleurs résultats de produits en temps réel, favorise l'engagement des utilisateurs et augmente la probabilité de conversion.
Bien que Vertex AI Search pour le commerce fournisse des API distinctes pour la saisie semi-automatique des requêtes et la recherche de produits, il laisse intentionnellement l'implémentation finale d'une expérience utilisateur SAYT ouverte.
Ce guide de création avec Vertex AI Search pour le commerce explore deux principaux modèles de conception pour implémenter un widget SAYT robuste à l'aide des API Vertex AI Search pour le commerce, en détaillant les compromis de chaque approche.
Comprendre les composants principaux
Pour créer une fonctionnalité SAYT complète, vous devez comprendre les deux API fondamentales fournies par Vertex AI Search pour le commerce :
API
CompleteQuery: c'est le cerveau derrière vos suggestions de saisie semi-automatique.- Fonction : pour une chaîne d'entrée donnée, telle que rouge à lèvre, elle renvoie une liste de suggestions de saisie de requêtes, y compris rouge à lèvres et brillant à lèvres, les marques populaires associées et les catégories pertinentes.
- Coût : cette API est incluse dans les tarifs du package Vertex AI Search pour le commerce.
- Performances : il s'agit d'une API à haut débit conçue pour les réponses rapides et à faible latence requises pour une expérience de frappe par frappe. Elle s'appuie sur des fonctionnalités d'apprentissage automatique, y compris la correction orthographique et les suggestions conçues pour générer des résultats, toutes entraînées sur les événements de recherche quotidiens de votre magasin.
API
Search: il s'agit de votre moteur principal de découverte de produits.- Fonction : pour une requête donnée, elle renvoie une liste classée des résultats de produits pertinents.
- Coût : il s'agit d'une API payante dont l'utilisation a un impact direct sur vos coûts opérationnels.
- Événements : pour l'entraînement et l'analyse des modèles, chaque appel d'API
Searchdoit idéalement être associé à un événement de recherche afin de suivre le comportement des utilisateurs et d'améliorer la pertinence des modèles au fil du temps.
Pour créer l'expérience SAYT, vous devez écrire une API wrapper ou une logique frontend qui appelle ces deux API et combine leurs résultats dans une interface utilisateur unique et cohérente.
Modèle d'implémentation 1 : approche directe, mais plus coûteuse
Il s'agit de la méthode la plus simple à implémenter. La logique consiste à effectuer des appels parallèles aux API CompleteQuery et Search pour chaque frappe.
Flow
Le flux suit le chemin séquentiel suivant :
- Un utilisateur saisit un caractère, tel que l.
- Votre application envoie l à l'API
CompleteQuery. - Simultanément, votre application envoie l à l'API
Search. - Les résultats sont combinés et affichés.
- L'utilisateur saisit un autre caractère (l), ce qui donne la requête li.
- Le processus se répète pour la nouvelle requête li.
Avantages
Les avantages incluent une implémentation rapide, qui vous permet d'écrire et de déployer rapidement le journal.
Inconvénients
- Volume élevé d'appels d'API
Search: cette approche augmente considérablement le nombre d'appels d'APISearch. Une requête telle que rouge à lèvres déclencherait huit demandes de recherche distinctes, ce qui entraînerait une augmentation significative du volume. - Augmentation des coûts : l'API
Searchétant un service payant, ce volume élevé se traduit directement par des coûts opérationnels plus importants, ce qui rend difficile l'obtention d'un retour sur investissement (ROI) positif. - Complexité de la gestion des événements : chaque appel d'API
Searchdoit être consigné avec un événement de recherche correspondant pour un entraînement et une mesure précis du modèle. Le volume élevé d'appels rend difficile la capture de chaque événement, ce qui peut entraîner une perte de données et des analyses faussées. - Résultats potentiellement de qualité inférieure : les recherches d'un ou deux caractères, comme l, li, peuvent renvoyer des résultats bruyants ou trop larges, ce qui nuit à la pertinence de l'expérience initiale.
Schéma d'implémentation 2 : approche optimisée et recommandée
Ce modèle optimise les coûts, les performances et la pertinence en utilisant l'API CompleteQuery pour décider de manière intelligente quand appeler l'API Search.
Flow
Le flux suit le chemin séquentiel suivant :
- Un utilisateur saisit une requête textuelle partielle, telle que lèvres.
- Votre application envoie lip à l'API
CompleteQuery. - L'API renvoie une liste de suggestions, rouge à lèvres étant probablement le premier résultat.
- Votre application sélectionne la première suggestion (rouge à lèvres) et effectue un seul appel à l'API
Searchavec ce terme. - Les suggestions de saisie automatique et les résultats de produits pour rouge à lèvres s'affichent.
- À mesure que l'utilisateur continue de saisir lèvres, lèvres t, ..., vous pouvez ajouter une logique pour n'effectuer un nouvel appel de recherche que si la première suggestion de saisie semi-automatique change.
Avantages
- Réduction significative des coûts : en réduisant considérablement le nombre d'appels d'API
Search, cette méthode permet de maîtriser les coûts. - Volume d'API et d'événements contrôlé : les volumes d'API et d'événements sont gérables et prévisibles, ce qui garantit des données plus fiables pour l'entraînement et l'analyse des modèles.
- Pertinence accrue : vous recherchez des termes plus complets et plus probables, ce qui permet d'obtenir des résultats de produits de meilleure qualité dans le widget Saisie à l'avance.
- Meilleur ROI : des coûts plus faibles et une meilleure expérience utilisateur contribuent à un retour sur investissement plus élevé.
Gérer les cas particuliers
Cette approche est supérieure, mais nécessite de gérer quelques cas particuliers :
- Aucune suggestion : si l'API
CompleteQueryne renvoie aucune suggestion, votre logique doit revenir à l'appel de l'APISearchavec l'entrée brute de l'utilisateur. - Requête partielle ou suggérée : dans de rares cas, un utilisateur peut souhaiter voir les résultats pour un terme partiel, comme yeux plutôt que pour la suggestion principale, ombre à paupières. Bien qu'il s'agisse d'un compromis mineur, l'approche optimisée donne la priorité à l'intention de l'utilisateur la plus probable.
Mesurer le succès avec les ID de test
Quelle que soit l'implémentation choisie, il est important de mesurer les performances de votre widget SAYT indépendamment de la page principale des résultats de recherche. Si vous utilisez le même suivi pour les deux, vous ne pourrez pas déterminer si la fonctionnalité SAYT améliore réellement les taux de clics et les conversions.
Pour mesurer les taux de clics et de conversion du widget SAYT, vous devez utiliser des experimentIds distincts dans vos événements de recherche. Cela vous permettra de différencier ces métriques de celles des événements de recherche principaux.
- Événements SAYT : attribuez un ID spécifique, tel que
"experimentId": "sayt-widget", à tous les événements de recherche provenant de la fonctionnalité de saisie semi-automatique. - Événements de recherche principale : utilisez un ID différent (ou aucun ID) pour les recherches lancées lorsqu'un utilisateur appuie sur Entrée ou clique sur Rechercher pour accéder à la page principale des résultats de recherche.
En segmentant vos événements de cette manière, vous pouvez utiliser les tableaux de bord Analytics de la console Vertex AI pour filtrer et comparer les performances de votre widget SAYT par rapport à l'expérience de recherche standard. Vous obtenez ainsi des insights clairs et exploitables.
Conclusion
Vertex AI Search pour le commerce fournit les composants permettant de créer une expérience de saisie semi-automatique. En agissant en tant qu'architecte qui conçoit l'interaction entre les API CompleteQuery et Search, vous pouvez créer une fonctionnalité de recherche qui fait le lien entre l'expérience utilisateur et les performances. Dans la plupart des cas d'utilisation, l'approche optimisée offre une expérience pertinente pour l'utilisateur tout en évitant les opérations gourmandes en ressources de calcul.