电子商务中的交叉销售：在线追加销售技术指南

在本文中，我将介绍一种相对简单的方法，用于在电子商务中启动交叉销售（向客户提供的产品以及购物车中的产品）功能，例如杂货或送餐服务，我们在“Mnogo Lososya”移动应用程序。这是一个基本的协同过滤推荐系统，结合了基于用户和基于项目的方法，可用于各种电子商务项目，特别是那些具有大量 SKU 的项目，以提供广泛的推荐。

Mnogo Lososya 成立于 2018 年，是一家拥有 50 多家幽灵厨房和 250 多家外卖厨房的连锁店，也是一个涵盖多种菜品概念的伞式品牌。我们的独特卖点是 30 分钟送达新鲜烹制的饭菜。我们一直在快速扩张，最近月活跃用户超过 10 万，月总收入超过 1 亿卢布。

我们的大部分订单都是在线完成的，其中三分之一来自我们自己的移动应用程序，另外三分之二来自送货服务。该应用程序是我们产品的重要组成部分，因为它是第一接触点之一，与我们的服务和食品本身一起，有助于提供更好的客户体验。

建筑学

该解决方案完全基于 Yandex Cloud 服务构建，但也可以基于 AWS 构建，因为它也具有所有必要的服务。为了方便 AWS 用户，我用 AWS 表示法来指定服务，许多 YC 用户也应该清楚这一点。

• 托管 MongoDB
• 拉姆达函数
• API网关
• 云域名解析
• 移动后端（计算云）

简化的架构如下所示：

1. 用户通过移动应用程序下订单。在 ERP 系统中，订单被创建和处理。

2. 然后，在每天晚上一次的 ETL 过程中，将订单复制到数据仓库。每个订单都包含有关订购产品的信息以及客户标识符。

3. SQL 程序计算用户偏好和产品相似性。下面提供了计算的更详细描述。计算在 MongoDB 中产生两个具有以下结构的集合：

   
   

   用户偏好集合

   电话：我们使用“电话”作为用户标识符。

   
   

   • 相关菜品

     • id：相关菜品的ID
     • 秩

   • 最后更新日期。上次重新计算的日期和时间

     
     

     文档示例：

产品相似度收集

• 碟号

• 相关菜品

  • id：相关菜品的ID
  • 秩

• lastUpdateDate：上次重新计算的日期和时间

  
  

文档示例

4. 当用户更新购物车时，应用程序会向 Lambda 函数发送请求。该请求包括用户标识符（电话）和当前购物车中的产品标识符列表。
5. Lambda 从 productSimilarity 集合中为购物车中的每顿饭提取相关菜肴，并通过 userPref 集合中的给定电话提取相关菜肴。
6. 然后，lambda 算法将这些相关菜肴列表组合成一个，并将其作为推荐列表发送回移动应用程序。在购物车中，应用程序呈现产品卡片。

算法

用户偏好

我们根据加权销售历史实施用户偏好，近期销售优先。考虑以下任意用户的销售历史：

用户购买了产品 B 和产品 C 四次。但是，由于 B 产品的大部分销售发生在四个月前，因此我们优先考虑最近的 C 产品销售。产品按总加权销售额排序，总加权销售额是每个产品的加权销售额之和。

上面的示例暗示用户更喜欢产品 A 而不是产品 C，更喜欢产品 C 而不是产品 B。

产品相似度

存在产品对的订单数量用于计算产品相似性。每个月单独计算结果，最近几个月优先。因此，我们对每个产品的相似产品进行排名，并将它们存储在 MongoDB 中，其中产品 ID 是集合的索引。

推荐

得到的商品推荐列表结合了用户的喜好和相似的商品，按照某种策略进行排序，即按排名升序排序。因此，我们只是简单地合并所有相关的产品列表并对其进行排序。我们计算重复产品的平均排名。这是一个例子：

1. 假设用户现在有一个包含 2 种产品的购物车——A 和 B；
2. Lambda 从产品 A 的 productSimilarity 集合中选择一个文档。相关菜肴是 C（排名 1）、D（排名 2）和 E（排名 3）；
3. Lambda 从产品 B 的 productSimilarity 集合中选择一个文档。相关菜肴是 F（等级 1）、G（等级 2）和 H（等级 3）；
4. Lambda 从给定电话的 userPref 集合中选择一个文档。相关菜式是D（等级1）和H（等级2）；
5. 所有相关的菜品合并，对于重复的菜品，计算平均排名。结果列表是 C（等级 1）、D（等级 1.5）、E（等级 3）、F（等级 1）、G（等级 2）和 H（等级 2.5）。
6. 列表排序后为C、F、D、G、H、E，返回给app。

结果

指标或如何衡量结果

我们选择了以下指标来衡量交叉销售效率：

1. 包含交叉销售菜肴的订单的平均订单价值 (AOV)高于不包含交叉销售菜肴的订单的 AOV。订单中所有产品的总和就是订单价值，也就是客户为订单支付的金额。因此，该指标表明客户是否为包含交叉销售菜肴的订单支付了更多费用。这是关键指标，因为 AOV 的增加正是我们对交叉销售的期望。

   
   

2. 从交叉销售部分添加的商品占总销售商品的百分比。这是一个次要指标，在很大程度上受所售商品的性质以及交叉销售策略的影响。考虑一家电子产品电子商务商店，它交叉销售低成本补充品（如手提箱和充电线）和购物车中更昂贵的商品（如智能手机和笔记本电脑）。在这种情况下，许多补充品可以交叉销售给一个主要项目，并且该指标可以超过 50%。尽管我们的示例不包括种类繁多的补充品，但该指标展示了交叉销售如何影响最终的购物车结构。

   
   

3. 包含交叉销售菜肴的订单百分比。这是另一个次要指标，显示交叉销售的“受欢迎程度”，或者客户购买交叉销售推荐产品的频率。

实际结果

下面的数据集包含从 2022 年 12 月到 2023 年 1 月在 MnogoLososya 的一个运营城市收集的非个人订单数据。

https://github.com/alexchrn/cross-sell/blob/main/orders.csv

该数据集是从各种来源编译而来的，包括 AppMetrica（添加到购物车事件）和 ERP 系统（订单和付款状态、折扣和付款金额）。

数据集结构：

• 订单号。订单的唯一标识符
• number_of_cross_sell_dishes。从交叉销售部分添加的菜肴数量。
• 地位。最后已知的订单状态。
• 支付状态。最后已知的付款状态
• 点数。订单中已提取的奖励积分数。 1 分等于 1 卢布。
• discount_sum.以卢布为单位的折扣，不包括奖励积分。
• payment_summ。客户为订单支付了多少
• 创建时间订单创建的日期时间
• appmetrica_device_id。唯一设备标识符
• 应用程序版本名称。应用版本
• total_number_of_dishes。一个订单的菜品总数
• has_cross_sell_dish。订单是否包含交叉销售添加的菜肴。该字段是根据 number_of_cross_sell_dishes 计算得出的。

所以这里是指标值（使用 python 从上述数据集派生）。

从交叉销售部分添加的菜品占总购买菜品的百分比——3.97%

包含交叉销售菜肴的订单百分比 – 10.46%

包含交叉销售菜肴的订单的 AOV 与不包含交叉销售菜肴的订单的 AOV 相比：

可以看出，交叉销售菜肴的订单具有更高的 AOV，相差 565 卢布。此类订单中的平均菜肴数量也更高，考虑到交叉销售的唯一目标是激励顾客将更多菜肴添加到他们的购物车，这是合理的。

565 的差异显着吗？我们可以使用 t 检验来查看这种差异是否是偶然造成的。 Python scripy 库有一个方法可以做到这一点。这是对零假设的检验，即 2 个独立样本具有相同的平均值（预期）值 (1)。

因此，p 值或原假设为真的概率极低，即使在 99% 的显着性水平下我们也拒绝原假设。换句话说，几乎可以肯定，平均订单价值的显着差异并非巧合，交叉销售餐点的订单产生了更多收入。

结论

即使使用简单的协同过滤技术，交叉销售也可以成为提高平均订单价值的有效工具。得益于 AWS 和其他云提供商的无服务器服务，从技术角度来看，它也可以相对容易地实现，如本文所示。

相关资料：

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