Dans cet article, je vais décrire une méthode relativement simple pour lancer une fonctionnalité de vente croisée (produits proposés à un client en plus de ceux du panier) dans le commerce électronique, comme l'épicerie ou les services de livraison de nourriture, que nous avons mis en œuvre avec succès dans l'application mobile "Mnogo Lososya". Il s'agit d'un système de recommandation de filtrage collaboratif de base qui combine des approches basées sur l'utilisateur et sur les articles et peut être utilisé dans une variété de projets de commerce électronique, en particulier ceux avec un grand nombre de SKU, pour fournir un large éventail de recommandations.  Mnogo Lososya, fondée en 2018, est une chaîne de plus de 50 cuisines fantômes et de plus de 250 cuisines à emporter ainsi qu'une marque ombrelle pour plusieurs concepts de plats. Notre argument de vente unique est la livraison en 30 minutes de repas fraîchement cuisinés. Nous avons connu une expansion rapide et avons récemment dépassé les 100 000 applications MAU avec plus de 100 millions de roubles de revenus mensuels bruts.  La majorité de nos commandes sont passées en ligne, un tiers provenant de notre propre application mobile et les deux autres tiers provenant des services de livraison. L'application est un élément important de notre produit car c'est l'un des premiers points de contact qui, avec notre service et la nourriture elle-même, contribue à une meilleure expérience client.   Architecture  Cette solution a été entièrement construite sur les services Yandex Cloud, mais elle pourrait également être construite sur AWS car elle dispose également de tous les services nécessaires. Je désigne les services en termes de notation AWS pour la commodité des utilisateurs d'AWS, ce qui devrait également être clair pour de nombreux utilisateurs de YC.  MongoDB géré  Fonction lambda  Passerelle API  DNS en nuage  Backend mobile (cloud de calcul)  L'architecture simplifiée ressemble à ceci :   Les utilisateurs passent des commandes via l'application mobile. Dans le système ERP, les commandes sont créées et traitées.  Les commandes sont ensuite copiées dans l'entrepôt de données au cours d'un processus ETL une fois par jour pendant la nuit. Chaque commande comporte des informations sur les produits commandés ainsi que l'identifiant du client.  Les procédures SQL calculent les préférences de l'utilisateur et la similarité des produits. Une description plus détaillée du calcul est fournie ci-dessous. Le calcul donne deux collections dans MongoDB avec la structure suivante :   collection userPref    nous utilisons le « téléphone » comme identifiant d'utilisateur. Téléphone :  liésPlats  id : ID d'un plat associé  rang  datedernièremiseàjour. Date et heure du dernier recalcul     Exemple de document :   productSimilarity collection  ID plat  liésPlats  id : ID d'un plat associé  rang  lastUpdateDate : date et heure du dernier recalcul     Exemple de document  Lorsqu'un utilisateur met à jour le panier, l'application envoie une demande à la fonction Lambda. La demande comprend l'identifiant de l'utilisateur (téléphone) et une liste d'identifiants de produits qui sont actuellement dans le panier.  Lambda extrait les plats associés de la collection productSimilarity pour chaque repas du panier et les plats associés par le téléphone donné de la collection userPref.  L'algorithme lambda combine ensuite ces listes de plats associés en une seule et la renvoie à l'application mobile sous forme de liste de recommandations. Dans le panier, l'application affiche les fiches produits.   Algorithme   Préférences de l'utilisateur  Nous avons implémenté les préférences des utilisateurs en fonction de l'historique des ventes pondérées, les ventes récentes étant prioritaires. Considérez l'historique des ventes de l'utilisateur arbitraire suivant :   Produit   Ventes   Quand   Coef temps (1/mois)   Ventes pondérées   UN   1   ce mois-ci   1   1   B   1   ce mois-ci   1   1   C   4   Il ya 1 mois   0,5   2   UN   4   Il ya 1 mois   0,5   2   B   3   Il ya 4 mois   0,25   0,75  L'utilisateur a acheté le produit B et le produit C quatre fois. Cependant, comme la majorité des ventes du produit B ont eu lieu il y a quatre mois, nous accordons la priorité aux ventes plus récentes du produit C. Les produits sont triés par ventes pondérées totales, qui sont la somme des ventes pondérées pour chaque produit.   Produit   Ventes pondérées totales   Rang   UN   3   1   B   1,75   3   C   2   2  L'exemple ci-dessus implique que l'utilisateur préfère le produit A au produit C et le produit C au produit B.   Similitude du produit  Le nombre de commandes dans lesquelles des paires de produits étaient présentes est utilisé pour calculer la similarité des produits. Le résultat est calculé séparément pour chaque mois, les mois les plus récents étant prioritaires. En conséquence, nous classons les produits similaires pour chaque produit et les stockons dans MongoDB, où l'ID de produit est un index pour la collection.   Recommandation  La liste de recommandations de produits qui en résulte combine les préférences de l'utilisateur et des produits similaires et les trie selon une stratégie, qui consiste à trier par ordre croissant. En conséquence, nous combinons simplement toutes les listes de produits connexes et les trions. Nous calculons le classement moyen des produits récurrents. Voici un exemple:  Supposons qu'un utilisateur ait maintenant un panier avec 2 produits - A et B ;  Lambda sélectionne un document dans la collection productSimilarity pour le produit A. Les plats associés sont C (rang 1), D (rang 2) et E (rang 3) ;  Lambda sélectionne un document dans la collection productSimilarity pour le produit B. Les plats associés sont F (rang 1), G (rang 2) et H (rang 3) ;  Lambda sélectionne un document dans la collection userPref pour le téléphone donné. Les plats apparentés sont D (rang 1) et H (rang 2);  Tous les plats associés sont combinés et pour les plats en double, le classement moyen est calculé. La liste résultante est C (rang 1), D (rang 1,5), E (rang 3), F (rang 1), G (rang 2) et H (rang 2,5).  Après avoir trié la liste est C, F, D, G, H et E, et retourné à l'application.   Résultat   Métriques ou comment mesurer le résultat  Nous avons choisi les métriques suivantes pour mesurer l'efficacité des ventes croisées :    des commandes qui comprenaient des plats de vente croisée était supérieure à l'AOV des commandes qui n'en avaient pas. La somme totale de tous les produits de la commande est la valeur de la commande, c'est-à-dire le montant que le client paie pour la commande. Par conséquent, cette mesure indique si les clients paient plus pour les commandes comprenant des plats vendus de manière croisée. Il s'agit de la mesure clé, car l'augmentation de l'AOV correspond exactement à ce que nous attendons de la vente croisée. La valeur moyenne des commandes (AOV)    . Il s'agit d'une mesure secondaire fortement influencée par la nature des biens vendus ainsi que par la stratégie de vente croisée. Considérez un magasin de commerce électronique d'électronique qui vend des suppléments à faible coût comme des valises et des câbles de charge à des articles plus chers dans le panier comme les smartphones et les ordinateurs portables. Dans ce cas, de nombreux suppléments peuvent être vendus à un seul article principal, et la métrique peut dépasser 50 %. Bien que notre exemple n'inclue pas une grande variété de suppléments, cette métrique montre comment la vente croisée affecte la structure finale du panier. Pourcentage de marchandises ajoutées à partir de la section des ventes croisées dans le total des marchandises vendues    . Il s'agit d'une autre mesure secondaire qui affiche la "popularité" de la vente croisée, ou la fréquence à laquelle les clients achètent des produits recommandés pour la vente croisée. Pourcentage de commandes contenant des plats en vente croisée   Résultats actuels  L'ensemble de données ci-dessous contient des données de commande impersonnelles collectées de décembre 2022 à janvier 2023 dans l'une des villes d'exploitation de MnogoLososya.   https://github.com/alexchrn/cross-sell/blob/main/orders.csv  L'ensemble de données est compilé à partir de diverses sources, y compris AppMetrica (événements d'ajout au panier) et le système ERP (états de commande et de paiement, remise et montants de paiement).   Structure du jeu de données :  numéro de commande. Un identifiant unique d'une commande  number_of_cross_sell_dishes. Le nombre de plats qui ont été ajoutés à partir de la section de vente croisée.  statut. Le dernier statut de commande connu.  statut de paiement. Le dernier statut de paiement connu  nombre_points. Le nombre de points bonus qui ont été retirés dans une commande. 1 point équivaut à 1 rouble.  discount_sum. La réduction en roubles, sans compter les points bonus.  paiement_somm. Combien un client a payé pour une commande  créé à. Date et heure de création d'une commande  appmetrica_device_id. Identifiant unique de l'appareil  app_version_name. Version de l'application  nombre_total_de_plats. Le nombre total de plats dans une commande  a_cross_sell_dish. Si une commande contient des plats ajoutés à partir de la vente croisée. Ce champ est calculé à partir de number_of_cross_sell_dishes.  Voici donc les valeurs des métriques (dérivées de l'ensemble de données ci-dessus en utilisant python).  Le pourcentage de plats ajoutés à partir de la section de vente croisée dans le total des plats achetés -    3,97 %  Le pourcentage de commandes contenant des plats de vente croisée -    10,46%  AOV des commandes qui incluaient des plats de vente croisée par rapport à l'AOV des commandes qui n'en avaient pas :   Comme on peut le voir, les commandes avec des plats de vente croisée ont un AOV plus élevé avec une différence de 565 RUB. Le nombre moyen de plats dans ces commandes est également plus élevé, ce qui est raisonnable étant donné que le seul objectif de la vente croisée est d'inciter un client à ajouter plus de plats à son panier.  La différence de 565 est-elle significative ? Nous pouvons utiliser un test t pour voir si cette différence est due au hasard. La bibliothèque Python scripy a une méthode pour cela. Il s'agit d'un test pour l'hypothèse nulle selon laquelle 2 échantillons indépendants ont des valeurs moyennes (attendues) identiques (1).   Ainsi, la valeur p, ou la probabilité que l'hypothèse nulle soit vraie, est extrêmement faible et nous rejetons l'hypothèse nulle même au niveau de signification de 99 %. En d'autres termes, il est presque certain que la différence notable dans la valeur moyenne des commandes n'est pas une coïncidence, et les commandes avec des repas de vente croisée génèrent plus de revenus.   Conclusion  La vente croisée peut être un outil efficace pour augmenter la valeur moyenne des commandes, même avec de simples techniques de filtrage collaboratif. Il peut également être mis en œuvre relativement facilement d'un point de vue technique, grâce aux services sans serveur d'AWS et d'autres fournisseurs de cloud, comme indiqué dans cet article.  Matériaux associés :   https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

CTA: Download the FREE AI Productivity Shift report

La vente croisée en matière de commerce électronique : un guide technique pour la vente incitative en ligne

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Appuyez pour gagner : Telegram pourrait intégrer les 10 prochains milliards d'utilisateurs de crypto avant Solana

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps