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

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 :

1. Les utilisateurs passent des commandes via l'application mobile. Dans le système ERP, les commandes sont créées et traitées.

2. 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.

3. 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

   Téléphone : nous utilisons le « téléphone » comme identifiant d'utilisateur.

   
   

   • 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

4. 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.
5. 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.
6. 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 :

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.

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:

1. Supposons qu'un utilisateur ait maintenant un panier avec 2 produits - A et B ;
2. 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) ;
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) ;
4. 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);
5. 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).
6. 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 :

1. La valeur moyenne des commandes (AOV) 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.

   
   

2. Pourcentage de marchandises ajoutées à partir de la section des ventes croisées dans le total des marchandises vendues . 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.

   
   

3. Pourcentage de commandes contenant des plats en vente croisée . 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.

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 :

1. https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html