数据驱动在链家网搜索优化与推荐策略中的实践

2017 年 4 月 05 日

大家好,我叫严言,来自于链家网商业搜索部,现主要负责链家网推荐系统,用户画像,以及线上商机获取等相关工作,很高兴本次能有这样一个机会与大家一起沟通交流,今天的分享主要介绍下数据驱动策略,以及我在链家网工作中的一些实践。

Part I 背景与概念

1. 数据的重要性与房产领域特殊性

2014 年是互联网掀起新一轮 O2O 产业变革的一年,移动互联的思维结合着 0-1 世界便捷的数据处理与分发,快速并深刻地改造着人们生活中的方方面面。也正是在 2014 年链家网正式成立,并立刻积极投身于重塑自身与其所处的行业的浪潮之中。

当前移动互联网的高速发展,伴随着业务的迭代,用户的增长以及内容的积累,几乎所有的公司都能够深切意识到数据对其自身发展的重要性。其实这点相对好理解,而且也是绝大部分从业者的共识。其原因正是由于互联网化后产业和场景的频繁变化,用户累计的行为与反馈快速沉淀,突破了原有依靠规则,流程,甚至核心人才固化行业经验的传统做法。

数据,这种新兴的公司级财富地位不断上升,最终以当前我们都熟知的“大数据”面貌影响各个专业领域与传统行业。从这里我们也就能明白,这个“大”字的定语,远不止是数据量规模的代指,更涵盖了数据的广度、深度、价值与重要性。

链家网所处的房产领域可以说与众多 O2O 场景有很多相似性,但也有其特殊性存在:

1)属于大宗商品交易,从而导致成交周期长,线上线下场景交叠反复切换等情况;

2)商品性质特殊,不但不可重复消费(中短期),众多特征很难定量描述(如户型好坏,采光通风情况,周边交通等),还极易受到外部环境的干扰;

3)业务与交易环节繁复,房产交易中所需要的专业知识与经验要求相对较高,一般买卖双方很难独自完成交易,且不同用户的关注点也不同,下图只是一个简单例子;

4)用户心理复杂,房产属于家庭与个人财富的重要组成部分,同时还担负了子女上学,父母医疗等众多附加社会属性,用户选择时经常需要进行多方资源与代价的权衡。

正是由于房产领域的特殊性,也带来了诸如数据来源众多,清洗与分析难度较高,反馈周期较长等问题,反过来讲,也正是因为存在以上原因,数据驱动在房产领域的重要性也更加凸显。

2. 为什么是数据驱动策略

这里主要需要回答两个问题:

a)为什么要驱动策略迭代?

这个问题相对好回答,往大了说,公司为了能够脱颖而出,赶上风口,解决痛点,开创新领域,改造旧场景;往小了讲,即便是为了在竞争中维持下去,开源节流,维持用户,都需要其提供的服务或产品能够紧跟时代需求,不断迭代策略,提高效率。

b)为什么是数据来驱动策略?

以链家网为例,房产领域天然融合了,房、客、经纪人三方的数据,其相互之间的匹配关系与资源调度也都需要策略进行调优,我们期望通过科学的数据处理与分析,以及合理的实验论证,不断提高线上与线下的策略效果,也给用户带来更好的产品体验。

上图为抽象与简化了的链家网线上漏斗分析,其中的 2 类关键路径即 1)完成用户与商品或内容的连接;2)完成用户与服务者的连接。也正是基于此,链家网正在重构房产交易中的各个业务场景,并通过分析、研究数据,优化关键转化路径的效率。

实际具体的优化中,需要提前选定核心指标,以带看转化率为例,即总的带看转化率等于各个带看转换路径上不同房源转化能力的叠加,以此量化全网在此项指标上的可比性:

所以说数据之所以能够驱动策略,就是因为策略的迭代需要由数据出发,通过对关键路径现状地分析,发现当前不足,以此驱动下一次迭代,而其效果又必须反过来通过数据进行验证。可以说不断更新的数据既是果,又是因,链家网也正是通过线上真实信息无差别的分享,积累数据,驱动策略优化,进而提高整体作业效率。

Part II 链家网的数据驱动实践

1. 链家网数据仓库及其上层应用示意

明确了数据的重要性,当然也要有一套合适的数据方案,下面简单给出链家网数据仓库的架构及其应用示意图。

如上图所示,其基本思想是通过收集尽可能多且准确的业务与用户数据,包含如楼盘基础信息,二手房房源、客源、成交、业主、带看,用户线上线下行为等,进行数据抽取、清洗、转换后逐层处理,形成业务方更易获取的数据形式,以供诸如推荐系统,用户画像,个性化排序等应用方使用。也正是依赖底层这套高效可靠的数据平台,业务策略才能够不断有效迭代。

2. 数据分析与实验平台的搭建

如上图,在明确了数据驱动策略迭代的方法,并拥有了底层数据支持后,就需要确立完整的闭环优化流程。我们首先依据优化指标的不同将其分为 3 类。

1)系统级指标优化,关注服务本身,如时延,并发,稳定性等,如搜索服务(Base Search),画像服务(User Profiling);

2)产品级指标优化,侧重功能覆盖与准确性,用户体验与粘性等,如搜索提示服务(Suggestion),标签挖掘(Tag Mining);

3)转化指标优化,更专注于转化效果与路径优化,如推荐系统(Recommendation),排序服务(Ranking)。

在前期的实验与探索中,我们也遇到了诸如优化周期推进较慢,重复工作,数据统计口径不一致等问题,为了一劳永逸地解决这些问题,我们开发并落地了数据分析平台——北极星平台(Polaris)以及流量实验平台——TSM(Traffic Sampling Management)。

数据分析平台通过汇总并处理数据,周期性自动化地产出业务核心指标,不但统一数据输出口径,更为策略迭代提供了可信赖的指标支持,还能支持核心指标监控。现以覆盖搜索、推荐、挖掘、爬虫与反爬以及商业化 5 个方向,近百项核心指标。平台截图如下:

流量实验平台则是完成用户分组与实验流量分流,配合策略升级进行 A/B Test 或者灰度发布,验证线上实际收益与提高,配置页面与架构图如下:

通过 TSM 平台,提供了全网各平台与频道进行分组实验的统一解决方案,而且能够与数据分析平台紧密结合,方便随时查看对应分组的关注指标,分析实验数据。当然除了一般的按照地域、频道、产品进行实验,很多时候还需要更精细化的用户群体实验,比如按照用户年龄,平台,活跃度以及其他标签属性等进行实验,这类功能的实现就需要结合下面要介绍的用户画像。

3. 用户画像

用户画像数据的建立可以说是业务发展的必然结果,其核心目的就是为了精准营销。一般可以从以下几个方面进行衡量。

1)全面的数据回流与处理:只有尽可能收集并分析用户线上线下的各类行为数据,才能够更准确全面地刻画每一个用户;

2)客观的分析与输出:画像作为众多业务方的底层数据支持,需要能够客观完成多维度用户识别、聚类等输出,保证数据质量;

3)标签的覆盖与准确性:画像数据不能是简单的数据堆积,用户关联性与标签、特征的深度挖掘才是画像价值的重要体现;

4)时效性:个性化推送与推荐都需要对用户群体快速反馈,因此时效性也是一项重要指标。下图为当前链家网用户画像的一些现状:

有了完善的画像数据之后,不但可以与搜索或推荐结合,针对单一用户或特定群体进行精细化地策略迭代,也可以开放数据给渠道、运营与市场相关人员,帮助他们制定计划,预估收益,降低单位成本。下面给出用户画像的架构示意图:

画像的核心模块也可以按功能分为:行为转化,用户身份标识,标签挖掘 3 个部分。

行为转化主要完成业务数据以及经纪人录入的非结构化数据的清洗与处理工作;

用户身份标识则是为了对应线上(PC/M 站 /App)与线下同一个用户的完整路径,从自然人的角度区分用户,保证同一个用户切换入口或设备时,画像数据能够持续积累,现在我们也正在进行关于自然人之上再聚合家庭购房需求的相关探索;

标签挖掘主要完成对用户基础属性,兴趣偏好,商机渠道,活跃等级,行为特征等不同类别的特征挖掘与预测,并给出相应的置信度以供业务方参考。

下面分别给出群体用户和个体用户的一些基础特征示例图:

上图为近期随机选择链家网一个用户真实的轨迹分析示例,每一个波峰都可以看做是用户的典型行为聚合,例如委托,搜索,浏览,关注,拨打电话,带看等购房过程中可能出现的所有行为,不同的组合与频度也能够挖掘出这个用户所处的购房阶段,意向需求,看房意愿和习惯,并借此评估用户当前的购买意愿,实现经纪人服务与用户需求的精确匹配。

当然随着画像数据的建立,拥有不同特征的用户群体之间也可以进行集合运算,筛选出符合业务需求的特异化用户,从而快速支持产品、运营以及市场部门的分析需求。

4. 数据驱动策略部分实例

前面分别从数据与策略的关系,数据仓库架构,实验与分析平台搭建,用户画像与标签等几个方面介绍了链家网数据驱动策略闭环优化的大部分组件,下面就以实际业务的策略迭代为例串联介绍一下完整流程。

CASE1:搜索无结果流量的挽回

二手房的库存量与电商商品不同,以北京为例,近几个月来基本稳定在 30000 套左右。这个数量是远小于有潜在购买意向用户的数量的。同时由于房源的特征众多,用户需求又不尽相同,这就导致实际用户在进行房源搜索 + 筛选的过程中,容易造成召回无结果或少结果(返回个数不足一页)。我们正是通过北极星数据分析平台,发现并定位一层漏斗中搜索流量流失情况,并结合搜索和推荐各自的优势对房源无召回时的场景进行流量挽回。

具体的做法是搜索通过实现切面统计功能(Facet),实时反馈用户不同特征下的房源套数,引导用户减少或避免其进入无效的召回页面,提升用户体验。使其每次完成搜索后都能清楚地了解当前房源依据特征的数量分布情况。经过线上实验,分组算法改进,当前线上搜索无结果流量比该功能上线前下降了 96.3%。

同时针对用户直接进行字面搜索而触达无结果页面的行为,补充相应的推荐策略,提高房源列表页点击率,挽回这部分流量。下图显示了引入用户画像与搜索小区词分析(命中小区的搜索量大约占比为 66%)后对推荐点击率的提高,从数据可以发现,这类提高不是仅在实验期内存在,是能够持续获得的增益。

CASE2:个性化排序

下面再介绍一个实验正在进行的个性化排序迭代。用户找房的需求千人千面,传统的统一默认排序虽然能在一定程度上担负曝光热门房源的功能,但是对于整体转化的贡献度很低。以北京搜索数据为例,默认排序的平均点击转化率大约只是字面搜索与筛选转化效果的 10%,只能达到搜索提示转化效果的 6%,这种情况在用户使用移动端时更为突出。

正是基于很多同类数据分析,我们希望能够在这个转化路径上将推荐系统与搜索引擎相结合,基于用户自身画像帮助其发掘新的兴趣点,或者更快发现适合需求的房源或经纪人,打通页面之间转化路径,从而提高整体列表页的点击转化率。从目前收集到实验数据上看,实验组相比对照组大约可以获得一倍以上的点击率提升。

可以发现,不同于在用户意图明确时搜索引擎解决信息过载的场景,当用户未明确表达意图之前或者需求本身很难用清晰的语义表达时(房产领域很常见),借助于用户画像和推荐系统,为其推送个性化的结果,便成为一种更好的选择。

从系统架构角度,链家网当前推荐系统主要可以分为数据存储层、计算层、策略层与融合层。数据存储层包括数据生成和数据存储,主要是利用各种数据处理工具对原始日志进行清洗,处理成格式化的数据,落地到不同类型的存储系统中,以供策略模型的读取和使用;计算层包括策略的预计算和实时计算,主要是利用分布式计算框架(Spark/Hadoop)进行策略运算,提供计算资源与能力;

策略层包括了多种推荐算法的实现。房源是大宗商品,具有极强的实效性,需要针对房源特点定制推荐策略。但由于房源不同于传统意义上的商品,每一套在售房源都具有唯一性,所以在推荐方法上主要以混合推荐为主,当前表现效果较好的是 FeatureCF 方法,其本身基于经典的 ItemCF 算法,利用物品之间的相似度,构造特征矩阵。在协同过滤算法的基础上,我们将抽取的众多房源特征与小区特征量化,分类,进而将所有房源切分为数十万类别,最终结合用户线上线下行为,推荐出符合用户兴趣的在售房源。融合层则是根据不同业务场景,动态调整各个策略候选集的综合方式,平衡新颖,准确,时效等推荐指标,确定最终的推荐结果。

5. 小结

随着搜索、画像、推荐等产品线的不断开展与迭代,其天然的业务属性、及其在转化路径中所处的位置,共同决定了我们不仅仅需要通过平台化的服务支撑业务与策略,更重要的是从数据本身出发驱动、优化策略。从上面两个 case 也能看出,数据驱动策略是建立在分析 - 预测 - 实验 - 评估这套科学方法之上的。可信赖的数据产出,多元定量的实验平台,合理的预测与有效的实践都是为了保障优化闭环能够自洽运行下去。

当然,在我们实践这一套方法论时,不可避免的也走了一些弯路,在此也想一并分享给大家:

1)正确的结论永远建立在正确的数据之上,我们组作为数据出口部门更需要有相匹配的责任和冷静,时刻保证产出的客观与准确;

2)并不是所有的迭代或改动都需要进行线上实验,实验前合理的预期分析不但能保证团队对实验结果的接受度,还能提前避免很多耗费人力时间的无效工作;

3)谨慎对待优化效果提高,数据解释不单是针对未符合预期的实验,超过预期的实验更是需要,只有明确了每次迭代的影响面与实际收效,才能真正带来持久收益;

4)互联网公司都处于快速迭代中,要能够抓大放小,把有限的人力投入到更能对全局或关键路径提升的优化之中,而不是一味追求相对比例的数字提升。数据分析的能力要求要远高于报表的制作。

以上简单几点分享都是我在链家网负责相关产品线迭代过程中切身体会到的,搜索与推荐的大部分产品本身对于用户就是选择信息的入口,同时又影响着用户之后的转化路径关联。不论是从横向的各个业务方之间的用户跳转,还是纵向多路径触达到最终页面的转化效果,我们不但需要汇总、处理、并提供大量的相关数据,更重要的是在这个过程中能够积累到用户在链家网的行为与反馈数据,从而直接作用并优化转化漏斗的效果。

所以今天着重介绍了链家网内数据驱动策略的实践方法,对涉及到的数据仓库,画像与推荐等产品本身没有做过多的展开。当然,由于我本人能力所限,肯定也有很多地方没有说明白或者有纰漏,也希望大家不吝赐教,共同进步。

最后感谢大家的时间,也感谢部门内同学们的大力支持。

答疑环节

Q1:请问如何构建数据分析系统?

答:数据分析系统包含如数据收集、清洗、处理,以及业务方指标计算,核定,分析与展示等众多模块,

所以构建完整的数据分析系统,首先还是需要从需求本身出发,要明确数据的来源与用途,厘清系统的边界,否则既有可能未达到自己预期,也有可能出现因旁支业务不断积累,而拖垮团队的情况。

以我们的北极星数据分析系统为例,它主要面向市场、运营和产品团队,实现关键转化路径效率监控和产品效果迭代评估使用,而诸如线下门店报表,网站流量监控则不属于其业务范畴。

Q2:如何构建用户画像,是否经过分类,从多少特征中分类出来多少个特征

答:画像数据本身也是分层的,首先肯定是业务数据的积累与融合,再往上是行为分类与用户聚类,再之后为统计类标签和挖掘类标签,以及其他扩展应用数据。一般我们所说的画像多指用户画像标签,其前提要建立特征库,特征库来源于日志 /DB/ 外部资源等,现在链家网用户端的画像特征大约已投入使用的大约在 100 个以上。

Q3:都使用什么工具采集数据、分析数据?

答:采集数据工具主要有 Flume/Storm/ 自建爬虫 /kafka 等,分析工具有 Spark/R/Python 等

其实选择工具上主要还是场景决定,并没有明确的优劣之分。

讲师介绍

严言 北京邮电大学,之前就职于 BI 公司 MicroStrategy(微策略),于 2015 年 1 月加入链家网,先后负责链家网线上房源排序,展位策略,推荐与用户画像等业务线。现负责链家网线上商机获取策略与数据分析。


感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017 年 4 月 05 日 17:062372

评论

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

大数据课程笔记

superman

第12周作业

Jaye

如何判断程序员的代码是否优美?

Garfield

代码质量 代码 代码优化 代码重构

第 0 期架构师训练营第 7 周作业 1

傅晶

Go云原生应用实战系列(一)

田晓亮

go 云计算 微服务 云原生

架构师训练营 week 12 作业

Frank Zeng

架构师训练营作业

qihuajun

极客时间训练营-12周作业2

潜默闻雨

逛过这个商城,摄像机竟然学会了独立思考

脑极体

大数据

GalaxyCreater

大数据

架构师课程第十二周总结

dongge

第 0 期架构师训练营第 7 周作业 2 ----总结

傅晶

架构师训练营第十二周总结

0x12FD16B

week12 总结

雪涛公子

mapReduce

深度解析OAuth 2.0授权!!

架构师修行之路

架构 高并发系统设计 OAuth 2.0

架构师训练营第十二周作业

吴吴

架构师训练营Week12学习总结

Frank Zeng

大数据简介&架构(一)

dony.zhang

大数据 hdfs hive YARN MAPRED

极客大学架构师训练营 0 期 week 12 作业

chun1123

大数据 hive

w-12

麻辣

极客大学架构师训练营

第 12 周作业

Mr.Monkey

week12

强哥

极客大学架构师训练营

极客大学架构师训练营 0 期 week 12 学习笔记

chun1123

大数据 学习

极客时间训练营-12周作业

潜默闻雨

JWT认证看这一篇就够了

架构师修行之路

程序员 架构

架构师训练营学习总结(大数据)

qihuajun

大数据总结

周冬辉

大数据技术

第十二周总结

Linuxer

week12 作业

雪涛公子

Flink从一致性检查点中恢复-14

小知识点

scala 大数据 flink

数据驱动在链家网搜索优化与推荐策略中的实践-InfoQ