写点什么

老司机谈电商系统之推荐系统

  • 2020-05-29
  • 本文字数:5944 字

    阅读完需:约 20 分钟

老司机谈电商系统之推荐系统

推荐系统

01 概述

推荐一直是电商平台的重要流量入口。以往在电商平台上,推荐的场景更多的覆盖在交易的各个环节,比如详情页、购物车、订单及支付等。近年来推荐发展逐渐的多样化,场景上逐渐覆盖到各流量入口,推荐的实体也扩展到活动、类目、运营位等。


在电商网站里进行商品推荐,可以提高整个网站商品销售的有效转化率,增加商品销量。通过用户已经浏览、收藏、购买的记录,更精准的理解用户需求,对用户进行聚类、打标签,推荐用户感兴趣的商品,帮助用户快速找到需要的商品,适时放大需求,售卖更加多样化的商品。甚至在站外推广时,能够做个性化营销。


02 推荐系统

商品推荐分为常规推荐、个性化推荐。常规推荐是指商家选择一些固定商品放在推荐位,或者基于商品之间的关联性,进行相关的商品推荐。例如:在用户买了奶瓶之后推荐奶粉。个性化推荐指基于用户购物习惯,根据商品特性来进行推荐。例如"看过此商品后的顾客还购买的其他商品"推荐项。


电商系统中的商品推荐位一般有:首页运营 Banner 最底部的位置(猜你喜欢/为你推荐)、购物车最底部的位置(猜你喜欢为你推荐)、商品详情页中部(看了又看、买了又买、为你推荐等)、用户签到等位置。还有这两年兴起的内容电商,通过社区做内容来提高转化率。

常规推荐

常规推荐的商品不会因为用户不同产生差异,主要是运营配置的活动或固定商品(商品精选)。除了在固定推荐位选定某些商品进行配置,例如选取 N 件固定商品放在签到页进行推荐。还有一些固定规则的动态配置商品,例如图中商品销量排行榜、商品收藏排行榜、某品类的销量排行榜(例如图书会有许多排行榜),这类根据浏览、收藏、销售数据做的商品统计在常规推荐时会经常用到,对用户的消费决策影响也比较大。



在 APP 的盛行的前提下,用户的浏览减少,更倾向于浏览和推荐,但简单的商品列表和标语描述的冲击力已然不够,内容电商将商品嵌入到文案或者视频中,通过详细的描述消费感受和商品特点,激起用户的同理心,这样的购物消费更容易产生冲动性消费,而非计划性消费。在内容电商中,除了平台商家自己产生内容,还应允许用户产生内容(UGC),并且对 UGC 内容进行激励。内容形式有长图文、视频推荐、直播推荐等多种形式,在内容中嵌入商品购买入口,在浏览时可以直达商品,增加购买转化率。对内容进行分类打标,可以缩短用户查找的路径。建立内容社区,提供评论、关注、种草(收藏)、赞赏等多种互动方式,增加用户粘性,提供分享到其他社交平台(微信、微博等)的功能。在内容中尽量推荐统一风格或同一场景的商品,增加商品之间的关联性。

个性推荐

个性化智能推荐最终的目标就是让一个普通访问电商平台的用户,在进入平台页面时,系统能够根据用户日常的行为偏好和习惯,用户心理想要购买的商品,在还没有发生点击行为时,系统能自动推荐到用户访问的页面,提升平台用户下单转化率。即使在用户没有访问平台时,企业通过与用户日常浏览互联网行为轨迹的平台进行联盟合作,在联盟平台推送用户希望购买的商品广告和链接,刺激和引导用户点击购买。即使在用户没有打开电脑时,能够通过信息和邮件的方式,根据用户平常的购买频次和周期,在特定的时间推送到用户手机和其他终端。


个性化智能推荐系统设计建设由三步构成:第一建立平台用户行为的召回模型,维度基于用户历史行为数据召回、用户偏好召回和用户地域召回来实现,用户历史行为数据召回基于用户历史浏览、点击、购买、评论、分享、收藏、关注等触点,分类推荐在线相关、在线相似、离线相关、离线相似行为;基于用户偏好召回是基于用户归类画像与平台多屏互通融合;基于用户地域召回是基于用户地域的网格化来实现地域行为推荐算法;第二是召回模型匹配算法,利用算法来得出与用户召回行为的匹配商品及广告信息;第三是平台针对匹配模型推荐结果的排序算法,基于用户交互日志通过模型训练特征权重,采用排序算法来实现自动匹配个性化推荐。


个性化推荐的难点


平台前端实现用户千人千面,而后台需要建立复杂的用户行为数据采集、数据存储、数据建模和用户画像过程,单纯采集某一纬度的数据,仅能达到个性化推荐的部分效果,如果要提升个性化推荐的效果,就必须覆盖用户多领域足够全面的行为轨迹,甚至用户线下行为,这就形成了以互联网电商平台为核心的生态系统,要想建立全面的个性化推荐,数据采集的涉及领域需要足够广,足够深。下面从用户画像、数据采集、数据存储、数据建模讲解个性化推荐的难度。

1 用户画像

用户画像是通过用户兴趣、行为、自身属性建立的一个模型。通过对用户的调研、对用户行为的分析,结合业务的需求,将用户分为不同的群体;然后在群体中抽象出一些典型的特征,用结构化的信息记录下来,概括出用户的特征。根据用户画像标签体系,对访问平台的用户计算行为特征值,用户特征提取并不是针对所有的标签维度,对于优先关键标签,如果从用户数据库查询不到特征值,就需要调用 R 函数对其进行计算,最终得出每个标签维度的特征值,依据特征属性值,就可以对用户进行画像处理。


用户画像有其自身的特性和局限性,例如无法 100%地描述一个人,且具有时效性,因此,需要根据用户画像的基础数据持续更新和修正,同时要善于从已知数据中具象化出新的标签使用户画像越来越鲜活立体,发挥其参考指引价值。


用户画像的作用


  1. 精准营销,分析产品潜在用户,针对特定群体利用短信邮件等方式进行营销;

  2. 用户统计,比如热销商品 top100 品牌;

  3. 数据挖掘,构建智能推荐系统,利用关联规则计算,喜欢 X 运动品牌的人通常还喜欢什么,利用聚类算法分析,关注 x 品类人的性别、年龄分布情况

  4. 效果评估,完善产品运营,提升服务质量,其实这也就相当于市场调研、用户调研,迅速下定位服务群体,提供高水平的服务;

  5. 私人定制,即个性化的服务某类群体甚至每一位用户(个人认为这是目前的发展趋势,未来的消费主流)。

  6. 行业分析,业务经营分析以及竞争分析,影响企业发展战略。

2 数据采集

首先需要在网站和移动 App 中进行埋点,在页面埋入『隐形』探针,采集用户行为数据和业务系统操作日志、从数据库中提取业务数据,采集回来存储在数据服务,采集服务器组负责将采集到的日志信息生成文件,落地到存储设备,用户行为数据采集基本上采用 SDK 方式;ETL 服务器负责将日志文件和结构化数据导入数据存储分析集群,并将分析结果导出到数据库;数据解析服务器负责连接数据分析服务器,完成数据分析各项计算;存储服务和分析服务提供数据分布式存储和计算的基础框架。



用户行为数据的处理和分析具有较高的技术门槛:


1、SDK 会采集到大量的"脏数据",包含一些空白区域和特殊符号,甚至根本没有见过的数据类型,这些脏数据的处理和分析具有较大的技术挑战,特别是数据的实时采集和处理。通常技术人员只有经历了海量数据采集和处理,填平了大量"技术坑"之后,才能形成成熟的技术架构。


2、采集的数据都是以渠道、日期、地区统计,无法定位到具体每个用户,计算统计出的数据都是规模数据,针对规模数据进行挖掘分析,无法支持,数据无法支撑系统做用户获客、留存、营销推送使用。


所以,要使系统采集的数据指标能够支持平台前端的个性化行为分析,必须围绕用户为主线来进行画像设计,在初期可视化报表成果基础上,将统计出来的不同规模数据,细分定位到每个用户,使每个数据都有一个用户归属。将分散无序的统计数据,在依据用户来衔接起来,在现有产品界面上,每个统计数据都增加一个标签,点击标签,可以展示对应每个用户的行为数据,同时可以链接到其他统计数据页面。

3 数据存储

用户行为数据采集后,需要存储在数据仓库,对采集的原始数据进行 ETL 加工处理,首先需要处理掉存储的无效重复数据,对于用户行为没有影响或重复数据,对非结构化数据和半结构化数据进行结构化处理,并对数据进行补缺、替换、数据合并、数据拆分、数据加载和异常处理。

4 数据建模

用户模型的表示方法有 4 类: 协同过滤模型、行为规则的模型、基于概念的用户兴趣模型与向量空间模型。向量空间模型(VSM)是最为常用的用户模型表示方法之一, 通常使用一组向量值描述用户特征, 向量的每一个维度代表用户感兴趣的一个主题。




维度的提取往往与网站系统的数据特征有关: 在标签系统中, 特征维度往往由用户提供的标签表示; 在检索系统中, 特征语词来自分析系统页面后所得到的关键词; 在协同过滤系统中, 可以把项目认为是描述用户特征的维度。使用 VSM 构建用户行为模型的困难是, 数据中并没有明确表示信息行为的词语, 所以在构建描述信息行为的维度时, 需要从数据中抽象出描述信息行为的维度。



浏览路径能够在一定程度上反映用户浏览行为特征。根据用户的浏览路径(包括页面停留时间)计算用户之间的相似性。但此方法仅适用于网站页面类型较少的情况, 如果页面较多或者包含较多的动态页面, 会使构造矩阵过于稀疏, 导致用户聚类不准确。有研究依据用户访问路径创建页面序列, 使用关联规则挖掘页面跳转规律; 或将用户访问的页面分类, 计算用户在这些页面之间跳转的概率以描述用户信息行为。由于访问日志中只记录用户访问的页面, 没有标识出用户信息行为, 使得用户的行为序列信息没有被充分挖掘。

03 推荐流程

个性化推荐系统一般有三大环节:预处理 -> 召回 -> 排序 。


注:也可以认为是两层(召回 -> 排序)


预处理


第一个环节是预处理,预处理指的是对各种数据源的数据进行特征提取和特征构建,例如:内容特征提取,用户行为画像构建。


召回


第二个环节是召回,召回就是把预处理产生的特征作为输入参数,训练出推荐模型,然后使用推荐模型得出候选集合的过程。常用的召回方式有:基于内容推荐、基于协同过滤推荐等。


排序


第三个环节是排序,简单来说就是将候选集合根据一定的规则,例如:点击预估、匹配关联度、人为权重等进行调整,从而影响最后的推荐顺序。


推荐数据流



以上是一个简单的推荐猜你喜欢实现,首先算法离线训练好与该商品的相似商品集,当在线用户请求过来的时候,有一个用户实时点击过的相似商品召回策略,该策略先获取用户实时点击过的商品列表,再取每个商品的相似商品。从而得到一个候选集。再通过在线排序进行点击率预估。取其中 top 商品从而得到一个推荐结果集。实际的场景中,将在离线训练、召回策略、排序策略等环节不断优化。召回策略中,除了支持实时个性化外,还可以不断发掘新的策略,进行策略,引入强化学习进行意图识别等。在线排序中支持 LR、GBDT 等模型外,还需要平衡性能与特征维度,支持模型的在线学习等。


概念


LR:逻辑回归模型(Logistic Regression, LR)


GBDT:梯度提升决策树(Gradient Boosting Decision Tree,GBDT)

04 系统架构

推荐系统的整体工程架构如下图,从下至上包括离线计算层、实时计算层、在线服务层,另外是后台配置管理系统和数据调度服务。


  • 在线服务:排序系统、推荐引擎、ABTEST 实验、推荐投放等;

  • 实时计算层:根据用户实时行为,提取用户实时特征、在线模型训练。

  • 离线计算层:根据用户历史行为,进行相关性训练、商品初排分、离线特征提取等



在线服务


系统分成推荐投放系统、排序系统、推荐引擎、abtest、字段补全服务等。


  1. 推荐投放:推荐统一接口,负责召回规则、abtest、埋点、字段补全。

  2. 排序系统:点击率预估,各打散置顶等业务层排序。

  3. 推荐引擎:离线算法训练的结果集存储。

  4. 字段补全:商品等正排信息补全,比如价格、标题等。


推荐投放


投放框架的功能如下:


  1. 提供统一的推荐接口。

  2. 各个场景的召回策略规则,可热部署。

  3. 提供通用数据源接口、工具类,方便算法推荐规则编写。

  4. 算法实验以及埋点统计。

  5. 推荐辅助工具。


推荐投放架构图



服务 API 调用统一投放接口获取推荐数据,投放接口解析请求参数,组装成下游推荐策略参数,对返回的推荐结果,拼装打点参数。为了实现推荐算法的在线对比,接口实现中接入了 AB 实验系统,它根据指定策略将上游请求按指定比例进行分流,通过实验配置,灵活控制不同流量的实验策略,算法工程师在线试验多个算法效果,极大的提升了推荐算法的迭代速度,优化推荐效果。


推荐策略模板是整个推荐投放服务实施的核心,监听动态配置服务,通过配置参数变更来驱动各类模板更新,迭代业务。推荐策略流程:入参补全 -> 数据召回 -> 精排 -> 格式化 -> 推荐数据补全。入参扩展模板,对入参做补充、修改,简化业务逻辑实现;业务模板,实现推荐策略主逻辑,由各类召回组件模板和精排调用组成(可选),一个业务模板中可以包含多个召回组件模板,组成数据召回链(实时点击偏好 -> 离线偏好 -> 店铺偏好 -> 类目偏好 -> …);数据组件模板,通过配置从不同的数据源召回和过滤数据;数据补全模板,按业务模板召回的推荐数据项 ID 补全详细的字段值;格式化模板,根据展现层样式需求,将推荐结果封装成展现层可加载渲染的数据格式。对于已实现的推荐策略和能够使用现有模板组装的推荐策略,都可以在动态配置服务平台上通过配置发布快速实现业务迭代和新增,一定程度上实现了代码简化,提高业务开发迭代效率。


推荐策略


推荐策略是整个推荐逻辑的核心,比如猜你喜欢场景,有用户实时特征做相关性的召回策略,也有用户离线特征的相关性召回策略。并且按照一定的配比 merge 出结果集,再调用排序系统的 lr 模型做点击率预估,这些都是需要写在策略脚本里。


推荐存储


主要承载了用户特征以及离线推荐结果集,存储系统对读写性能要求非常高。


  1. 整条推荐链路希望在 50ms-100ms 内完成。一次复杂的推荐请求会请求上百次(以存储中的 key 为单位)存储数据,存储需要在 1ms 内返回。

  2. 对时延要求比较高,比如需要收集用户的曝光行为数据做降权,同时曝光数据的量非常大,对内存有挑战。


排序系统


排序系统的职责是对候选集进行排序,其中核心点在于模型和特征,理想情况下系统尽可能支持多的模型和特征,但是在线计算需要较小的时延,这就要求系统要平衡效果和性能,前期推荐系统可以支持 LR 和 GBDT 两种排序模型。


线性模型公式



x 是特征,θ是权重,一个模型通常有几十维特征,这些特征的计算和存储就成为系统最大的挑战。


  1. 控制候选集数量在千级别,候选集增长整体计算就比较慢,rt 也会上升。

  2. 实体(商品)特征本地存储,每次需要排序特定数量商品,本地存储可以极大缓解网络压。

  3. 针对内存瓶颈,将用户相关特征迁移到远程,考虑每次查询只会查几次用户特征数据,开销不大。

  4. 并行计算,复杂模型下,组装特征和计算还是比较费时,为了提升 rt 系统进行并行计算,充分利用 cpu 的资源,在系统容量不变的情况下提升 rt。


总结


个性化推荐所取得的成就是一个“意料之外却情理之中”的结果。个性化用户体验将是大势所趋,从搜索走向发现(推荐),通过搜索满足用户主动表达的需求,通过推荐挖掘满足用户的潜在需求。市场营销的核心是用户体验,而用户体验的极致是个性化,满足每一位用户的不同需求,以人为本的电子商务才能够真正获得用户的青睐。


2020-05-29 15:295099

评论

发布
暂无评论
发现更多内容

聊聊Flink框架中的状态管理机制

百思不得小赵

大数据 flink 状态 7月月更

OpenHarmony应用开发之ETS开发方式中的Image组件

坚果

HarmonyOS Open Harmony OpenHarmony 3.1 Release 7月月更 harmony

疫情常态化大背景下,关于远程办公的思考|社区征文

如浴春风

初夏征文

【LeetCode】在每个树行中找最大值Java题解

Albert

LeetCode 7月月更

x86汇编语言-从实模式到保护模式 笔记

贾献华

7月月更

远程办公之大家一同实现合作编辑资料和开发文档 | 社区征文

Tech技术攻关

远程办公 协同办公 7月日更 初夏征文

毕业总结

大眼喵

「架构实战营」

NFT新的契机,多媒体NFT聚合平台OKALEIDO即将上线

小哈区块

ORACLE进阶(一) 通过EXPDP IMPDP命令实现导dmp

No Silver Bullet

oracle DMP 7月月更

Python|函数和模块

AXYZdong

7月月更

cgroup简介

总想做点什么

Cgroups

「Docker 那些事儿」还不会安装Docker?建议看这篇就够了

Albert Edison

7月月更

远程办公工具分享|社区征文

如浴春风

初夏征文

一入“远程”终不悔,几人欢喜几人愁。| 社区征文

法医

初夏征文

rxjs Observable filter Operator 的实现原理介绍

汪子熙

typescript 响应式编程 angular RXJS 7月月更

项目协作的进度如何推进| 社区征文

卢卡多多

初夏征文

TCP拥塞控制详解 | 3. 设计空间

俞凡

算法 网络 TCP拥塞控制

设计电商秒杀系统

大眼喵

「架构实战营」

聊聊支付流程的设计与实现逻辑

Java 架构

毕业总结

天琪实刚亮

TOGAF认证自学宝典V2.0

涛哥 数字产品和业务架构

企业架构 TOGAF

深入理解 SQL 中的 Grouping Sets 语句

元闰子

sql spark spark SQL

远程办公之如何推进跨部门项目协作 | 社区征文

Tech技术攻关

远程办公 7月日更 项目协调 初夏征文 工作协调

SpingCloud集成zookeeper实现服务注册并访问

AI乔治

Jenkins抛弃Java 8拥抱Java 11

FunTester

Vuex(二)

小恺

7月月更

Python 入门指南之开胃菜

海拥(haiyong.site)

7月月更

模块九作业

天琪实刚亮

NFT新的契机,多媒体NFT聚合平台OKALEIDO即将上线

西柚子

架构实战营 - 第 6 期 毕业总结

乐邦

「架构实战营」

自动渗透测试工具核心功能简述

穿过生命散发芬芳

渗透测试 7月月更

老司机谈电商系统之推荐系统_文化 & 方法_技术琐话_InfoQ精选文章