Personnaliser la recherche e-commerce : intégrer l’historique d’achat et les cohortes d’utilisateurs

Les parties 1 à 5 de cette série décrivent un plan de contrôle gouverné qui classe l’intention, applique les contraintes, résout les conflits de politiques et oriente vers la stratégie de récupération appropriée, le tout avant même l’interrogation du catalogue produit. Tous les mécanismes décrits jusqu’à présent traitent les clients de manière identique. Une recherche sur « chocolat » produit le même ensemble de résultats gouverné, que le client soit vegan, un parent préparant l’anniversaire de son enfant ou un consommateur respectant les règles halal.

Cet article présente deux mécanismes de personnalisation qui étendent le plan de contrôle gouverné sans en modifier l’architecture. Les deux mécanismes s’ajoutent de manière cumulative à la couche de gouvernance présentée dans les parties 1 à 5 : les politiques continuent de s’appliquer, les contraintes restent respectées, les conflits sont toujours résolus, et les signaux de personnalisation sont intégrés à la même requête gouvernée, garantissant ainsi que les résultats renvoyés par Elasticsearch sont déjà personnalisés.

Le premier mécanisme met en avant les produits déjà achetés par le client concerné. Le second active des politiques spécifiques à certaines cohortes selon le profil du client. Ensemble, ils montrent que la personnalisation n’est pas un système distinct ajouté à la recherche ni un traitement appliqué après récupération des résultats ; elle constitue une extension naturelle du plan de contrôle piloté par des politiques.

Pour une analyse approfondie des techniques mathématiques de personnalisation utilisées dans cet article, consultez les articles Personnaliser la recherche dans Elasticsearch avec un post-traitement ML et Classement basé sur les cohortes dans Elasticsearch.

Pour voir une démonstration en direct montrant comment l’historique d’achat peut être utilisé pour booster les résultats de recherche des clients fidèles, regardez la vidéo Personnalisation explicable : booster la recherche grâce à l’historique d’achat.

Amélioration de l'historique des achats individuels

La forme la plus simple de personnalisation est aussi l’une des plus efficaces : lorsqu’un client a déjà acheté un produit, mettez-le en avant lorsqu’il effectue une recherche associée. Un client qui achète régulièrement une marque précise de cookies aux pépites de chocolat devrait voir ces produits apparaître plus haut dans les résultats lorsqu’il recherche « cookies », non pas parce qu’un modèle a prédit une préférence, mais parce qu’il existe des preuves comportementales directes.

Fonctionnement

Lorsqu’une requête de recherche inclut un identifiant utilisateur, comme c’est le cas pour un utilisateur disposant d’une session ouverte, le plan de contrôle exécute deux requêtes Elasticsearch en parallèle à l’aide d’un pool de threads :

1. La requête percolator exécutée sur l’index des politiques (la même recherche de gouvernance décrite dans les parties 3 et 4).
2. Une requête sur l'historique des achats dans un index user_purchases, filtrée sur l'utilisateur spécifique par term(user_id), puis faisant correspondre la chaîne de recherche actuelle avec les titres des produits de cet utilisateur.

Ces requêtes s’exécutent simultanément (aucune n’attend l’autre), de sorte que la recherche de personnalisation n’ajoute aucune latence significative au pipeline de gouvernance.

La requête sur l’historique d’achat utilise l’analyse de texte d’Elasticsearch (racinisation, tokenisation) pour faire correspondre la chaîne de recherche actuelle aux titres de produits enregistrés. Cela signifie qu’une recherche sur « cookies » correspondra à un achat passé de « brownie cookies » grâce à l’analyse de texte standard, sans nécessiter de correspondance exacte de chaîne.

Calcul des pondérations de boost

Tous les achats passés ne méritent pas le même niveau de boost. La pondération prend en compte deux facteurs intuitifs : la fréquence d’achat du produit par le client et la date récente de cet achat. Un produit acheté 15 fois la semaine dernière constitue un signal bien plus fort qu’un produit acheté une seule fois il y a six mois. La pondération utilise une échelle logarithmique pour la fréquence (afin qu’un seul produit acheté en grande quantité ne domine pas tous les autres) et une décroissance exponentielle pour la récence (afin que les achats plus anciens perdent naturellement en importance au fil du temps).

Pour les détails mathématiques de la formule de boost, consultez l’article Personnaliser la recherche dans Elasticsearch sans post-traitement ML.

Transformation en requête

Les boosts liés à l’historique d’achat sont intégrés à la requête comme couche de scoring la plus externe, englobant les filtres et boosts des politiques de gouvernance décrits dans les parties 3 et 4, ainsi que tous les boosts liés aux signaux métier, tels que la marge et la popularité (que nous explorerons dans la partie 7). Cela signifie qu’un produit supprimé par une politique de gouvernance ne réapparaîtra pas à cause d’un boost lié à l’historique d’achat. La gouvernance contrôle l’ensemble de résultats ; la personnalisation ajuste l’ordre des résultats au sein de celui-ci. Les produits sans historique d’achat ne sont pas pénalisés. Leur classement gouverné est préservé, même si les produits disposant d’un historique d’achat pertinent apparaîtront avant eux, toutes choses étant égales par ailleurs.

Pourquoi interroger Elasticsearch à chaque recherche ?

L’historique d’achat est interrogé dans Elasticsearch à chaque recherche plutôt que mis en cache dans la couche applicative. Il s’agit d’un choix de conception délibéré. Comme la requête compare la chaîne de recherche actuelle aux titres des produits à l’aide du pipeline d’analyse de texte d’Elasticsearch, le système bénéficie des mêmes mécanismes de racinisation, de tokenisation et de gestion linguistique que ceux utilisés par la recherche produit elle-même. Une recherche en mémoire mise en cache nécessiterait de réimplémenter cette analyse ou d’accepter une correspondance moins précise.

Pour comprendre pourquoi cet ordre est important, prenons l’exemple d’un client qui a déjà acheté du jus d’orange et recherche maintenant « oranges ». La requête sur l’historique d’achat associe « jus d’orange » au terme de recherche « oranges » grâce à l’analyse de texte et calcule un boost pour ce produit. Mais la couche de gouvernance a déjà limité « oranges » à la catégorie des produits frais, excluant ainsi totalement le jus d’orange. Le boost lié à l’historique d’achat pour le jus d’orange est bien présent dans la requête, mais il n’a aucun effet, car aucun document correspondant n’existe dans l’ensemble de résultats gouverné sur lequel il pourrait s’appliquer. Le client voit des oranges fraîches classées selon leur pertinence et les critères de personnalisation. Les garde-fous de gouvernance restent en place.

Le coût en performances reste minimal : l’index de l’historique d’achat est de petite taille (l’historique d’un utilisateur contient généralement quelques dizaines à quelques centaines de documents, et non des millions), et la requête s’exécute en parallèle de la recherche percolator ; elle n’allonge donc pas le chemin critique.

Exemple de requête pour « eau de source » sans historique utilisateur

Si un utilisateur non connecté, ou un utilisateur n’ayant jamais acheté d’« eau de source », effectue une recherche, il pourra voir des résultats similaires à ceux-ci :

Exemple d’historique d’achat utilisateur

À l’inverse, une utilisatrice nommée Carol dispose d’un historique d’achat contenant les produits suivants :

Exemple de recherche pour « eau de source » avec l’historique d’achat ci-dessus

Si Carol recherche « eau de source », elle verra des résultats personnalisés qui reflètent ses achats passés. D’après l’historique d’achat ci-dessus, elle a acheté « Carbonated Spring Water » (la bouteille verte) environ 40 fois, le plus récemment il y a deux jours. Si elle recherche « eau de source », ce produit bénéficie alors d’un boost, puisque nous savons qu’elle l’apprécie. Notez que dans les résultats non personnalisés, l’eau de source Rubicon apparaissait en première position.

Activation des politiques basées sur les cohortes

L’historique d’achat individuel fonctionne bien pour les clients fidèles dont les habitudes sont déjà établies. Mais de nombreux clients sont nouveaux, anonymes ou naviguent en dehors de leurs habitudes habituelles. Pour ces clients, l’appartenance à une cohorte offre une autre forme de personnalisation, fondée sur le profil du client plutôt que sur ses actions passées.

Un client vegan recherchant « chocolat » devrait voir les chocolats vegans apparaître plus haut dans les résultats. Un client respectant les règles halal et recherchant « snacks » devrait voir les options certifiées halal mises en avant. Un client soucieux de sa santé recherchant « yaourt » devrait voir les options probiotiques bénéficier d’un boost.

Les cohortes comme politiques, et non comme étiquettes produit

Les produits possèdent déjà leurs attributs habituels, y compris des champs tels que dietary_restrictions: ["vegan"] ou dietary_restrictions: ["halal"]. La question est de savoir où réside la logique qui relie la cohorte d'un acheteur à ces attributs de produit.

L’approche naïve serait de coder cette mapping en dur dans la couche application ou dans le modèle de recherche : si l’utilisateur est vegan, ajoutez un bonus à dietary_restrictions: "vegan". Mais c’est le même spaghetti de couche application décrit dans la Partie 1, et cela crée la même friction opérationnelle : ajouter une nouvelle cohorte ou modifier la signification d’une cohorte nécessite un changement de code.

Le plan de contrôle gouverné conserve la logique de cohorte dans le moteur de politiques. Une politique de cohorte fait le lien entre deux éléments : l'appartenance d'un client à une cohorte (par exemple, « végétalien ») et un attribut de produit (par exemple, dietary_restrictions: “vegan”). La politique définit le lien : lorsqu’un client de la cohorte végane recherche, privilégiez les produits où dietary_restrictions inclut « végan ».

Comme la logique des cohortes réside dans le moteur des politiques plutôt que dans le code de l'application, cela signifie :

• L’ajout d’une nouvelle cohorte peut se faire en créant une nouvelle politique ; aucune réindexation des produits n’est nécessaire.
• Les politiques de cohorte utilisent l’intégralité du moteur de règles : elles peuvent ajouter des filtres, appliquer des boosts souples, étendre les synonymes, modifier la stratégie de récupération ou effectuer toute autre action prise en charge par une politique.
• Le comportement des cohortes est géré via la même interface utilisateur d'administration que toutes les autres politiques : un marchand peut créer, tester et promouvoir des politiques de cohorte via le workflow Auteur → Test → Promouvoir décrit dans la deuxième partie.

Exemple de politique de cohorte vegan

Un responsable merchandising crée une politique de cohorte présentant les caractéristiques suivantes :

• Cohortes : ["vegan"].
• Critères de correspondance : correspond à n'importe quelle requête (ou à une catégorie de produit spécifique).

Action : Accélération douce sur dietary_restrictions: "vegan" avec un poids d'accélération de 2.

Comment fonctionne l'activation des cohortes

Chaque document de politique comporte un champ cohorts. Les politiques universelles qui s'appliquent à tous les acheteurs, quelle que soit leur cohorte, peuvent laisser ce champ vide, et une valeur de "_all" leur sera attribuée en interne par le plan de contrôle. Les politiques spécifiques à chaque cohorte stockent les noms de leurs cohortes cibles, comme ["vegan", "kosher", “sweet_tooth”].

Lorsqu’une requête de recherche inclut un profil utilisateur, le plan de contrôle construit un filtre terms simple pour la requête du percolateur :

Ce filtre unique inclut toutes les politiques universelles ainsi que les politiques spécifiques à chaque cohorte de l’utilisateur. La sentinelle _all en fait un filtre d'inclusion propre : Aucune requête must_not ou exists n'est nécessaire pour traiter le cas où une politique n'a pas de restriction de cohorte.

Le percolator évalue ensuite les correspondances de politiques comme d’habitude. La seule différence est que l’ensemble des politiques candidates a été restreint à celles pertinentes pour les cohortes de ce client. Tous les traitements en aval (transformations en cascade, résolution des conflits champ par champ, suivi des expressions consommées) fonctionnent exactement comme dans le flux non personnalisé décrit dans les parties 3 et 4.

Résultats d’un utilisateur non vegan (standard) lors d’une recherche sur « chocolat »

Lorsqu’un utilisateur non vegan recherche du chocolat, aucun boost lié à une cohorte vegan n’est appliqué à ses résultats. Ils verront souvent des chocolats non vegans parmi les premiers résultats, comme ci-dessous :

Résultats de la politique de cohorte vegan lors d’une recherche sur « chocolat »

Lorsqu'un client végétalien recherche « chocolat », cette politique est incluse dans l'ensemble des candidats au percolateur. Il correspond, et le plan de contrôle applique un boost doux aux chocolats certifiés végétaliens. Le boost est multiplicatif : les chocolats végétaliens sont mieux classés, mais les chocolats non végétaliens ne sont pas totalement exclus, car le filtre ci-dessus est défini comme un soft boost, comme nous l'avons décrit en détail dans la troisième partie de cette série.

Cependant, si le client recherche explicitement « Hershey milk chocolate », le boost vegan s’applique toujours, mais peut être compensé par la pertinence textuelle plus forte des produits Hershey au chocolat au lait.

Un client n’appartenant pas à la cohorte vegan et effectuant la même recherche ne voit jamais la politique « cohorte vegan » ; elle ne fait pas partie de son ensemble de politiques candidates. La couche de gouvernance reste identique ; seul l’ensemble des politiques actives diffère.

Cohortes avec historique d’achat

Un client vegan disposant d’un historique d’achat important bénéficie à la fois de l’activation des politiques spécifiques à la cohorte vegan et des boosts liés à son historique d’achat. Pour les nouveaux clients ou les utilisateurs anonymes, l’appartenance implicite à une cohorte suffit à offrir une personnalisation pertinente sans nécessiter de données comportementales (par exemple, un utilisateur anonyme n’a peut-être recherché que des produits vegans, et nous le classons donc comme membre de la cohorte vegan). Un client qui indique respecter les règles halal lors de la création de son compte reçoit immédiatement des résultats adaptés au halal dès sa première recherche.

Composition des couches de personnalisation

L'ordre d'imbrication des couches function_score est important. De l'intérieur vers l'extérieur :

1. Requête de base : la correspondance par mots-clés ou sémantique avec les requêtes nommées (fulltext_match, title_phrase_match).
2. Couche de politique de gouvernance : Filtres durs sous forme de clauses bool.filter, coups de pouce doux sous forme de fonctions function_score (parties 3 et 4).
3. Stimulation des signaux d'affaires : L'augmentation des marges et de la popularité (que nous étudierons dans la partie 7).
4. L'historique des achats stimule : La couche externe function_score.

Cet ordre garantit que la gouvernance contrôle l’ensemble de résultats (ce qui apparaît), que les signaux métier ajustent le classement au sein de cet ensemble (ce qui apparaît en premier du point de vue du distributeur) et que l’historique d’achat affine encore davantage le classement selon le comportement individuel (ce qui apparaît en premier du point de vue du client). Chaque couche s’ajoute à la précédente de manière multiplicative, de sorte que les effets se cumulent plutôt qu’ils n’entrent en conflit.

Ce que cela signifie sur le plan opérationnel

La personnalisation via le plan de contrôle gouverné préserve toutes les propriétés opérationnelles décrites dans les parties 1 et 2 :

• Modifications sans déploiement. Les politiques de cohorte sont créées, testées et promues via l'interface utilisateur. L'ajout d'une nouvelle cohorte alimentaire ou l'ajustement d'un poids d'appoint ne nécessite aucune modification du code et aucune intervention technique.
• Auditabilité. Chaque politique de cohorte est un document distinct et versionné. Lorsqu’un responsable merchandising demande : « Pourquoi les produits vegans sont-ils mieux classés pour cet utilisateur ? », la réponse réside dans une politique précise dotée d’une priorité spécifique, visible dans le panneau de débogage aux côtés de toutes les autres politiques déclenchées pour cette requête.
• Résolution de conflits. Les politiques de cohorte participent au même mécanisme de résolution des conflits champ par champ décrit dans la partie 3. Si le boost de catégorie d’une politique de cohorte entre en conflit avec la surcharge de catégorie d’une politique de campagne, le conflit est résolu de manière déterministe à l’aide du même cadre de priorités et de stratégies, sans traitement spécifique supplémentaire.
• Mesurabilité. Comme les politiques de cohorte sont distinctes et activables individuellement, leur impact sur les taux de conversion, de clic et d’ajout au panier peut être mesuré indépendamment, comme pour toute autre politique du système.

À suivre dans cette série

Le prochain article explore une autre dimension du plan de contrôle gouverné : la manière dont les boosts liés à la marge et à la popularité peuvent être ajustés requête par requête via des politiques, transformant ainsi l’optimisation économique en décision de gouvernance plutôt qu’en configuration statique.

Voir la partie 7 : Optimisation économique gouvernée par les requêtes : boosts de marge et de popularité par requête

Mettre en pratique la recherche e-commerce réglementée

Les mécanismes de personnalisation décrits dans cet article (boost basé sur l’historique d’achat individuel et activation de politiques adaptées aux cohortes) ont été conçus et développés par Elastic Services Engineering dans le cadre de notre accélérateur reproductible de recherche e-commerce. Les deux mécanismes s’intègrent à l’architecture de plan de contrôle gouverné décrite tout au long de cette série. Contactez Elastic Professional Services.

Rejoignez la discussion

Avez-vous des questions sur la gouvernance de la recherche, les stratégies de récupération ou l'architecture de recherche e-commerce ? Participez à la discussion élargie de la communauté Elastic.