写点什么

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

2020 年 5 月 29 日

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

推荐系统


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 年 5 月 29 日 15:291124

评论

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

C++中glog源码剖析以及如何设计一个高效 log模块

helloworld

c c++ C#

MacOS高效使用指南-我的体系化方案以及软件清单

lmymirror

高效工作 效率工具 知识管理 Mac 操作系统

关于职能型团队管理一些总结

黄大路

项目管理 管理

游戏夜读 | 联网才能玩的单机

game1night

做程序员有未来吗

这小胖猫

程序员 个人成长 职业规划 技术人

Java并发编程--ReentrantLock

Java收录阁

并发编程

理解雾计算(Fog Computing)与边缘计算(Edge Computing)

老任物联网杂谈

雾计算 Fog Computing 边缘计算 Edge Computing

Java 环境配置与编辑器使用

旭霁

Java IDEA

数据挖掘|cross_val_score交叉验证使用

黄大路

Python 数据挖掘 学习 数据分析

产品经理中必会SQL技能,相关内容研发可不予支持

韩超

MySQL sql 产品经理

深入浅出虚拟内存

helloworld

c c++ C#

腊鸡与猴儿

黄大路

人生 小说

读 Go Scheduler 有感:给产品经理的建议

Ya

程序员 产品经理 操作系统 OS Scheduler

直播电商行业一些看法

黄大路

互联网 商业 商业模式 商业价值 行业资讯

如何快速对应用系统做一个360度画像诊断?

姜戈

Java 运维 多线程 网络 内存

Redis 命令执行过程(上)

程序员历小冰

redis 源码分析

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (三)单元测试在整个测试体系中的位置

编程道与术

软件测试 TDD 单元测试 集成测试 验收测试

拜托,别再问我Zookeeper如何实现分布式锁了!

不才陈某

zookeeper 分布式 后端 分布式锁

向上管理第一项:路径P背后的目标B

kimmking

管理

每日算法之leetcode 50 Power

田镇珲

递归 LeetCode 分治

作为自由职业者,我的近况

一尘观世界

程序员 自由职业 复盘

高仿瑞幸小程序 04 小程序的全局数据

曾伟@喵先森

小程序 微信小程序 前端

以不变应万变——复杂系统回归测试新思路

刘华Kenneth

DevOps 敏捷 测试 单体系统 复杂

来了来了,2020 首场 Meetup ,可!

Apache Flink

大数据 flink 流计算 实时计算 大数据处理

Netty 源码解析(八): 回到 Channel 的 register 操作

猿灯塔

数据湖引擎是什么鬼

数据社

大数据 数据仓库 数据湖 数据架构

时间足够爱你

rmrf

学习 思考 持之以恒

一个 UED 团队的自我修养

oldj

团队管理 UED

使用人工智能技术改进面试机器人

陆道峰

人工智能 学习 聊天机器人

Elasticsearch原理讲透了!

for

lucene elasticsearch 倒排索引 分布式搜索引擎 数据的分片和备份

关于查尔斯-斯特里克兰

黄大路

提升认知 小说 个人提升 认识自己

大数据技术升级脉络及认知陷阱

大数据技术升级脉络及认知陷阱

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