LikeShop单商户Java版个性化推荐体系建设：用户行为驱动的智能商品排序架构落地实践

一、业务背景：私域商城的流量效率瓶颈

在独立站与私域电商场景中，商品列表与首页推荐位的排序策略，直接决定了流量利用率与整体转化效率。
LikeShop单商户Java版原生提供了销量、新品、价格、综合等基础排序能力，能够满足业务初期的运营需求。但随着商品SKU规模扩大、用户体量增长，千人一面的固定权重排序会逐渐触达增长天花板：用户进入商城后需要花费大量时间筛选感兴趣的商品，点击率、加购率与转化率难以持续提升，平台流量价值无法充分释放。

传统运营方式依赖人工置顶、精选推荐位与活动专区，不仅维护成本高，也无法做到千人千面的精准匹配。而重型推荐系统需要大数据组件与算法团队支撑，对绝大多数单商户商家而言投入产出比过低。

基于此，我们以LikeShop单商户Java版为底座，采用离线预计算 + 在线轻排序的工程思路二开落地了一套轻量化个性化推荐体系：基于用户浏览、收藏、加购、下单等行为构建用户偏好画像，通过多路召回 + 加权融合两阶段算法实现智能排序，在不引入重型大数据组件的前提下，显著提升推荐精准度。落地后商品列表点击率提升22%，加购转化率提升16%，整体下单转化率提升11%。

二、方案选型与设计原则

2.1 主流方案对比

在方案选型阶段，我们对四类排序方案做了系统性评估：

最终选择轻量化个性化方案，核心原因在于：在可接受的二开成本下，能够获得显著的转化提升，同时保持系统的稳定性与可维护性，与LikeShop单商户的产品定位高度匹配。

2.2 核心设计原则

作为商城系统的二开扩展能力，方案设计严格遵循五项原则：

1. 低侵入原则
   新增独立推荐服务层与数据表，复用原生商品、订单、用户核心能力，不修改交易核心逻辑，不影响官方版本升级路径。
2. 离线+在线分离原则
   画像计算、相似度计算等重计算逻辑全部离线定时执行，线上仅做轻量排序与结果融合，保证接口性能与原生排序持平。
3. 可灰度可降级原则
   全链路配置化开关，支持按用户比例灰度放量；异常时可一键降级为原生排序，保障业务连续性。
4. 数据驱动原则
   内置AB测试框架，用量化指标评估效果，持续迭代算法策略，不靠感觉调优。
5. 隐私合规原则
   仅采集必要的业务行为数据，不采集敏感信息；支持用户关闭个性化推荐，满足合规要求。

三、整体架构设计

3.1 四层架构模型

系统自下而上分为四层，全部基于Spring Boot + Redis + MySQL技术栈实现，无需额外引入大数据组件。

业务接入层：首页推荐、商品列表、搜索结果、猜你喜欢
    ↓
排序服务层：多路召回、得分融合、多样性打散、结果缓存
    ↓
特征画像层：用户偏好画像、商品基础分、相似度矩阵
    ↓
数据采集层：行为埋点、日志存储、离线计算
    ↓
原生底座层：商品服务、用户服务、订单服务

3.2 核心执行流程

完整的个性化排序链路分为五步：

1. 行为采集：用户浏览、收藏、加购、下单等动作通过切面异步记录；
2. 画像更新：每日凌晨离线计算，更新用户偏好画像与商品基础分；
3. 多路召回：请求到达时，从热度、偏好、相似、新品四个通道召回候选商品；
4. 融合排序：按权重融合多路结果，计算最终排序分，做多样性打散；
5. 结果输出：返回重排后的商品列表，同时支持缓存热门用户结果。

四、核心算法设计

推荐排序采用多路召回 + 融合排序的两阶段架构，既保证召回的丰富度，又保证排序的精准度。

4.1 第一阶段：多路召回策略

召回阶段的目标是用较低的成本，从全量商品中筛选出百级候选集，兼顾相关性、热度与多样性。我们设计了四路召回通道：

（1）热度召回

• 作用：保底基础转化，保证热门高转化商品有足够曝光；
• 计算逻辑：综合销量、加购量、浏览量、好评率计算商品基础热度分；
• 占比：约占候选集的30%，作为基础盘保障。

（2）偏好召回

• 作用：匹配用户明确兴趣，提升点击率；
• 计算逻辑：基于用户类目、品牌、价格区间的历史行为权重，召回对应分类下的高分商品；
• 占比：约占候选集的35%，是个性化的核心来源。

（3）相似召回

• 作用：基于ItemCF协同过滤，拓展用户兴趣边界；
• 计算逻辑：根据用户历史交互商品，召回相似度最高的TopN商品；
• 占比：约占候选集的20%，提升发现感。

（4）新品召回

• 作用：扶持新品，补充流量多样性；
• 计算逻辑：上架7天内的新品给予流量扶持分，按类目比例插入；
• 占比：约占候选集的15%，保障新品曝光。

4.2 第二阶段：融合排序模型

召回得到候选集后，通过统一的排序分公式计算最终得分，完成精排。

排序总分公式

最终得分 = 商品基础分 × (1 + 偏好加权系数) × 多样性调节因子 × 时效因子

各因子说明

1. 商品基础分
   由销量、好评率、上架时间、价格竞争力等维度加权计算得出，所有用户一致，是排序的底座。
2. 偏好加权系数
   核心个性化因子，基于用户画像计算得出：

• 类目偏好权重：用户在该商品所属三级类目上的累计行为权重（带时间衰减）；
• 品牌偏好权重：对应品牌的历史行为权重；
• 价格偏好匹配度：商品价格与用户历史消费价格区间的匹配程度。

1. 时间衰减机制
   用户行为不是永久有效的，距离当前越近的行为权重越高。采用指数衰减函数：

有效权重 = 基础权重 × e^(-λ × 间隔天数)

默认7天半衰期，即一周前的行为权重衰减为原来的50%。衰减系数可后台配置，适配不同行业的用户兴趣变化周期。

1. 多样性调节因子
   防止同类目商品过度集中，连续出现相同细分类目时，逐次降低后续商品得分，强制打散。

4.3 冷启动策略

个性化推荐必须处理好冷启动问题，不能因为数据不足而降低用户体验。

用户冷启动

• 无任何行为的新用户，完全走热度排序，不强行个性化；
• 累计3次以上有效行为后，逐步引入偏好权重；
• 行为达到10次以上，再启用全量个性化排序。

商品冷启动

• 新品给予基础热度补偿分，保障初始曝光；
• 放入探索流量池，通过小流量测试用户反馈；
• 表现好的商品逐步提升基础分，进入主流排序池。

五、数据模型设计

全部采用新增表方式扩展，原生商品表仅扩展少量冗余分数字段，最小化侵入性。

5.1 用户行为日志表

记录用户全量核心行为，是画像计算的数据源。

CREATE TABLE ls_user_behavior_log (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  behavior_type TINYINT NOT NULL COMMENT '1浏览 2搜索点击 3收藏 4加购 5下单',
  goods_id BIGINT NOT NULL,
  category_id BIGINT COMMENT '冗余类目ID，便于统计',
  behavior_weight DECIMAL(5,2) NOT NULL COMMENT '行为基础权重',
  stay_seconds INT DEFAULT 0 COMMENT '停留时长',
  create_time DATETIME NOT NULL,
  INDEX idx_user_id(user_id),
  INDEX idx_goods_id(goods_id),
  INDEX idx_create_time(create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户行为日志表';

5.2 用户偏好画像表

离线计算结果表，线上排序直接读取，避免实时计算。

CREATE TABLE ls_user_preference_profile (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL UNIQUE,
  category_preference TEXT COMMENT '类目偏好JSON：key=类目ID value=权重',
  price_preference VARCHAR(64) COMMENT '价格偏好区间',
  brand_preference TEXT COMMENT '品牌偏好JSON',
  activity_level TINYINT COMMENT '活跃度等级',
  last_calc_time DATETIME COMMENT '上次计算时间',
  update_time DATETIME NOT NULL,
  INDEX idx_user_id(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户偏好画像表';

5.3 商品相似度表

ItemCF离线计算结果，每个商品保留Top20相似商品。

CREATE TABLE ls_goods_similarity (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  goods_id BIGINT NOT NULL,
  similar_goods_json TEXT COMMENT '相似商品列表JSON：包含ID与相似度',
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_goods_id(goods_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品相似度表';

5.4 推荐配置表

后台可动态调整的参数配置，无需发版即可调优策略。

CREATE TABLE ls_recommend_config (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  config_key VARCHAR(64) NOT NULL UNIQUE,
  config_value VARCHAR(255),
  description VARCHAR(255),
  update_time DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='推荐配置表';

六、工程化落地实现

6.1 行为采集：AOP无侵入埋点

采用Spring AOP切面埋点，对业务代码零侵入，异步记录不影响主接口性能。

@Aspect
@Component
public class GoodsBehaviorAspect {

    @Autowired
    private UserBehaviorService behaviorService;

    private final ThreadPoolExecutor asyncPool = new ThreadPoolExecutor(
            2, 8, 60L, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(500),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );

    @Pointcut("execution(* com.likeshop.controller.GoodsController.detail(..))")
    public void goodsDetailPointcut() {}

    @AfterReturning("goodsDetailPointcut()")
    public void afterViewGoods(JoinPoint joinPoint) {
        Long userId = UserContext.getUserId();
        if (userId == null) return;

        Long goodsId = (Long) joinPoint.getArgs()[0];
        // 异步写入行为日志
        asyncPool.execute(() ->
            behaviorService.recordBehavior(userId, goodsId, BehaviorType.VIEW)
        );
    }
}

6.2 离线画像计算：定时任务批量更新

使用XXL-Job定时任务，每日凌晨全量更新用户画像，高活用户支持增量更新。

@Service
public class UserProfileCalcService {

    @Autowired
    private UserBehaviorMapper behaviorMapper;
    @Autowired
    private UserPreferenceMapper profileMapper;

    /**
     * 全量计算用户画像（每日凌晨执行）
     */
    @XxlJob("calcUserProfileJob")
    public void calcAllUserProfile() {
        // 分批处理，避免大内存
        long maxId = 0;
        int batchSize = 500;

        while (true) {
            List<Long> userIds = behaviorMapper.listUserIdGtId(maxId, batchSize);
            if (CollectionUtils.isEmpty(userIds)) break;

            for (Long userId : userIds) {
                calcSingleUserProfile(userId);
                maxId = Math.max(maxId, userId);
            }
        }
    }

    private void calcSingleUserProfile(Long userId) {
        // 查询近30天行为
        List<UserBehaviorLog> behaviors = behaviorMapper.listRecent30Days(userId);

        // 计算类目偏好（带时间衰减）
        Map<Long, BigDecimal> categoryWeight = calcCategoryWeight(behaviors);
        // 计算价格偏好区间
        String priceRange = calcPricePreference(behaviors);

        // 写入或更新画像
        profileMapper.insertOrUpdate(userId, 
                JSON.toJSONString(categoryWeight), priceRange);
    }

    private Map<Long, BigDecimal> calcCategoryWeight(List<UserBehaviorLog> behaviors) {
        Map<Long, BigDecimal> weightMap = new HashMap<>();
        long now = System.currentTimeMillis();
        double lambda = 0.1; // 衰减系数

        for (UserBehaviorLog behavior : behaviors) {
            long days = (now - behavior.getCreateTime().getTime()) 
                    / (1000 * 60 * 60 * 24);
            double decay = Math.exp(-lambda * days);
            BigDecimal effectiveWeight = behavior.getBehaviorWeight()
                    .multiply(BigDecimal.valueOf(decay));

            weightMap.merge(behavior.getCategoryId(), 
                    effectiveWeight, BigDecimal::add);
        }
        return weightMap;
    }
}

6.3 在线排序服务：多路召回融合

线上排序服务负责多路召回与融合重排，全部基于内存计算，毫秒级返回。

@Service
public class RecommendSortService {

    @Autowired
    private UserProfileService profileService;
    @Autowired
    private GoodsScoreService goodsScoreService;
    @Autowired
    private GoodsSimilarityService similarityService;

    /**
     * 个性化重排序
     */
    public List<GoodsVO> personalSort(List<GoodsVO> originList, Long userId) {
        if (userId == null || CollectionUtils.isEmpty(originList)) {
            return originList;
        }

        // 获取用户画像
        UserPreferenceProfile profile = profileService.getUserProfile(userId);
        if (profile == null) {
            return originList; // 无画像返回原顺序
        }
        Map<Long, BigDecimal> categoryWeight = profile.getCategoryWeightMap();

        // 计算每个商品最终得分
        for (GoodsVO goods : originList) {
            // 1. 基础分
            BigDecimal baseScore = goodsScoreService.getBaseScore(goods.getId());

            // 2. 偏好加权
            BigDecimal weight = categoryWeight.getOrDefault(
                    goods.getCategoryId(), BigDecimal.ZERO);
            BigDecimal boost = BigDecimal.ONE.add(weight.multiply(new BigDecimal("0.06")));

            // 3. 最终得分
            BigDecimal finalScore = baseScore.multiply(boost);
            goods.setSortScore(finalScore);
        }

        // 按得分降序
        originList.sort((a, b) -> b.getSortScore().compareTo(a.getSortScore()));

        // 多样性打散处理
        diversityReshuffle(originList);

        return originList;
    }

    /**
     * 多样性打散：连续3个同类目则后移
     */
    private void diversityReshuffle(List<GoodsVO> list) {
        // 实现类目打散逻辑，避免连续相同细分类目
    }
}

6.4 业务接口接入

在原有商品列表查询中，通过配置开关控制是否启用个性化，可灰度、可回退。

public List<GoodsVO> queryGoodsList(GoodsQueryDTO dto) {
    // 原生查询逻辑
    List<GoodsVO> list = goodsMapper.queryList(dto);

    // 个性化排序（配置开关 + 用户登录判断）
    if (recommendConfig.isPersonalSortEnable() && UserContext.getUserId() != null) {
        list = recommendSortService.personalSort(list, UserContext.getUserId());
    }

    return list;
}

七、性能保障与工程机制

7.1 性能保障手段

1. 离线预计算：画像、相似度全部离线计算，线上只做简单加权排序；
2. 多级缓存：热门用户画像、商品基础分存入Redis，减少DB查询；
3. 分页优化：仅对当前页商品做重排，不处理全量数据，保证分页性能；
4. 降级开关：系统负载过高时自动关闭个性化，降级为原生排序。

7.2 AB测试框架

内置轻量AB测试能力，量化推荐效果：

• A组（对照组）：原生综合排序；
• B组（实验组）：个性化排序；
• 自动统计两组的点击率、加购率、转化率；
• 支持按用户比例灰度放量，逐步扩大实验组。

7.3 监控与可观测

• 推荐接口耗时、命中率、缓存命中率监控；
• 画像覆盖率、行为数据量统计；
• 核心业务指标日报，自动输出效果趋势。

八、效果评估与落地数据

8.1 三层评估体系

从三个维度全面评估推荐效果：

8.2 落地效果数据

在某服饰类单商户商城落地两个月后，通过AB测试得出核心数据：

8.3 持续迭代机制

效果优化不是一次性工作，而是持续迭代的过程：

1. 每周分析badcase，优化权重与衰减系数；
2. 每月复盘业务指标，调整召回通道占比；
3. 每季度迭代算法模型，逐步引入更精细的特征。

九、实践踩坑与经验总结

9.1 冷启动阶段效果不明显

新用户、新商品初期数据不足，个性化优势体现不出来，容易被认为效果差。
经验：明确冷启动分层策略，不要强行对无行为用户个性化；通过热度排序保底体验，数据积累后逐步加强个性化权重。

9.2 信息茧房与转化的平衡

个性化越强，用户越容易只看自己熟悉的类目，发现感下降，长期不利于拓展消费边界。
经验：必须加入多样性打散与新品探索流量，控制同类目连续出现数量；每屏插入一定比例的探索性商品，平衡精准度与丰富度。

9.3 性能与效果的权衡

越精细的算法通常意味着更高的计算开销，容易拖慢接口。
经验：坚持离线重计算、在线轻排序的原则；线上只做简单加权与排序，复杂计算全部前置到离线任务中。

9.4 不要为了技术而技术

单商户场景不需要追求算法复杂度，简单的行为加权 + 协同过滤就可以获得绝大多数收益。盲目引入复杂模型，只会徒增维护成本，收益边际递减。

结语

个性化推荐不是只有大平台才能做的事情。
对于LikeShop单商户Java版这类成熟商城系统，不需要从零搭建重型推荐引擎。基于已有的用户、商品、订单数据，通过行为埋点、画像预计算、多路召回融合的轻量方案，就可以用较低的二开成本，获得非常可观的转化提升。

电商运营的本质，是流量的精细化运营。个性化排序让每个用户看到更符合自己兴趣的商品，既提升了用户体验，也提高了流量利用率与转化效率。随着数据积累与策略迭代，推荐效果还会持续优化，是一项投入一次、长期收益的二开能力。