本地服务场景下的流量分发算法实践

导读： 58 本地服务由数百个细分品类、多个创新业务和国际业务组成，如何构建智能化的流量分发体系是一项挑战，我们通过整合搜索和推荐场景构建了一套统一的流量分发系统，本次分享将主要介绍系统中的算法实践，包括基于信息结构化和用户意图识别的用户表征、召回和排序算法等。

本次分享的主要内容包括：

• 58 同城本地服务生态介绍

• 本地服务主站流量分发问题与特点

• 本地服务主站流量分发解法

• 总结和展望

01 58 同城本地服务生态介绍

1. 业务背景

58 本地服务事业群，旧称"大黄页"、“黄老大”，在集团内是即古老又年轻的业务线，古老是因为自从 58 成立以来，就是以提供本地信息服务的分类信息网站，年轻是因为近期来在业务上也做了很多创新，面貌焕然一新了。58 本地服务的业务生态涉及面非常广并且杂，其中业务上主要战场有 20 多个，涉及行业有 200 多个，如丽人、餐饮美食、家政、教育培训等，能看出行业间关联也比较少。

目前本地服务主要分三大块：主站、到家、到店 &电商，业务形态多变，依托于商家中台和合伙人流量分发网络 ( 一种流量组织形式，通过对社会各个锚点的重新组织，形成与之前流量投放及变现完全不同的流量分发渠道 )。

2. 产品流量形态

主站：58 通用的业务形式，由 APP\PC\M 等端侧入口进来到本地服务落地页，以流量生意为主 ( 开环业务，目前产品形态正在从开环向半闭环演进 )。

• 推荐场景：列表页、详情页、落地页等

• 推荐内容：帖子、商家、店铺、商品、标签等

• 推荐关注指标：CTR、CVR、Call/UV 等

到家：提供到家精选服务品牌 ( 完全闭环业务 )。推荐关注指标：GMV、订单转化率、复购率等。

到店 &电商：创新业务 ( 完全闭环业务 )。推荐关注指标：GMV、订单转化率、复购率等。

城市合伙人：通过线上和线下方式招募或者主动注册为 58 合伙人后，可以转发对应合伙人任务，该任务可以是以上多种业务形态，通过社交分发并且任务形成转化后，可以拿到一定的分佣。推荐关注指标：效果转化率、ROI、DAU。

由于此次分享时间关系，本文只讲对主站的流量分发探索。

02 本地服务主站流量分发问题与特点

主站场景下，核心目标是将主站上的信息资产，通过算法场景化和搜索推荐等分发系统，达到对用户的精准触达。

1. 主站用户交互流程

用户核心行为路径：用户可以直接带着需求或者不带需求 ( 搜索词 )，进入到主要的服务场景-主站的列表页。在列表页上，用户可以浏览帖子标题、价格等内容，并点击进行帖子详情页，查看详细信息、评论等，发起线上电话沟通，或者通过 58 提供的微聊，从而促进线下成交。

中间产生的数据信息：列表页详情页曝光、点击、电话、微聊、评论等

2. 主站流量分发特点和问题

信息同质化严重，体现在一是帖子信息堆叠严重，二是可区分度差，部分帖子只有一句话，很多是无意义内容，比如线上出现过有发布保姆月嫂的帖子，只有一张正常女性照片，帖子内容只有三个字，你懂的。

人群结构复杂，存在未登录用户、新用户、低活用户等，需要制定差异化的推荐策略，针对性优化推荐模型。

决策周期问题，长短周期不一、轻重决策共存，同时也存在短期低频、需求周期短的情况，比如说单价高的家装、租车等长周期服务，用户会相对谨慎，花更多的时间来挑选决策；而管道疏通、空调维修等需求，用户则会在浏览几个店家后就进行决策，此类需求往往要求短时间内快速解决。

多行业多场景多种类多目标，本地服务类目繁多，涉及 200+不相关行业、10+个推荐场景位，推荐内容包括帖子、商家、店铺等，结合业务特点有不同的优化目标 ( CVR、CTR、Call/UV 等 )。

03 主站流量分发解法

上面提到的问题比较多，我们首先从信息供给侧解决，重点通过内容结构化来提高内容描述能力，增加信息区分度。

1. 信息结构化

① 发布结构化

原来的帖子内容雷同，能看出大量拷贝的痕迹，这个问题理应先想到在发布的时候解决。从内容发布端定义了针对不同服务的内容模板，商家直接选择对应模板，填写个性化参数即可完成发布。除了多种模板可选，同时也针对不同服务类型在产品侧进行了优化，主要有 3 部分：

一是服务标准化。以搬家为例，按照用户个性化需求选择不同需求项，快速完成服务预订，同时也能得到相应的价格预估，更方便辅助用户决策：

• 如车辆信息，可选择具体车辆型号、尺寸、可载量等

• 如详细服务，可选择是否有电梯、小件搬运、支持长途、小件搬运等

• 如收费单项，可选择不同里程对应的价格、超里程计算、无电梯楼层加价、随车人员数量等

二是服务智能定价，根据已选项由算法计算输出合理的价格区间，为了剔除市场出现过高过低的报价，用以规范 58 的运营和列表页结果展现

三是相册自动分类，即让用户上传的图片可以自动分类到不同相册，方便回溯

② 标签设计及应用

左图是未做优化前的列表页展示页面，从图上来看，各搜索结果的展现信息都是雷同的，信息罗列程度单一，看不出来各自的区分度，很难契合用户关注，体验较差；因此针对这个问题，我们重点做了信息标签设计，并体现在产品展示层中，标签化是结构化的重要方法。用户通过需求搜索词进入列表页后，通过搜索词匹配对应服务的标签，展示出标准化的服务特点，能够更好地细化用户需求，契合用户关注，如体现家电维修的快速上门、家政服务包括老人看护等 ( 右图 )。

③ 标签挖掘流程

整个标签挖掘流程是，通过帖子等数据源挖掘备选词，再在备选词库中融合成标签词，这批标签词再通过同义词库和归一规则形成基础标签，用算法进行行业词消歧，形成行业标签，最终在不同场景应用。

2. 知识结构化

① 知识化标签体系

上面提到的标签化，是相对扁平的信息，无法体现出标签间的关联关系。因此我们希望能够挖掘出标签间的关系。初期通过标题、评论、搜索词等数据源，找到每个行业中的关注维度，再根据维度定义出种子词，经过数据挖掘，通过短文本相似把对应其他标签词归类到同一个维度下，并不断地滚动迭代。具体方式就是各标签词与维度词和维度下的种子词进行向量计算距离，取距离最近的标签词放入到维度中继续作为种子词，这样种子词越来越多，后续标签词分维度会越来越准，然后根据阈值，有一部分不能归类的标签词可能是需要继续添加维度，然后在进行下一次滚动一直到所有词归类完毕。

② 场景化标签体系

根据以上挖掘的标签之间的关系，以及类目和标签之间的关系，维度和标签之间的关系最终形成了完整的场景化标签体系，标签体系是信息的表达媒介，结构化的基础。目前，我们的场景化标签体系规模如下：

• 行业标签 ( 40w+ )：根据各行业服务维度设计，如租车、家装，其分类维度及对应不同标签

• 通用标签 ( 10w+ )：包括用户体验相关 ( 态度好、价格满意 )、商家服务承诺、平台评估标签等

• 应用场景：包括标签筛选、热词推荐、找相似、猜你喜欢、智能摘要等

用户场景构建：

利用场景化标签体系，我们进行了用户场景构建，原因如下：

在老版无场景提示条件下，我们发现 58 本地服务的登录用户在一进入列表页后的跳出率非常高。这个问题分析得到的最后结论是，用户确实是带着明确需求和目的性进入列表页，如果用户在默认结果页中没有找到想要的服务，这时候就会跳出。既然是有目的的，我们何不事先猜好，找到契合高频场景的词，至少能让用户在默认页产生一次点击，然后利用这次点击逐步引导用户。

通过挖掘用户的服务需求，我们发现其和 58 本身的 CMCS 类目体系是交叉、网状的关系 ( 如用户想找水电改造服务，在标签中对应是装修建材->局部维修->水电改造 )。可以看到右图，一开始我们是用弹窗形式让用户选择，但这种阻断式提醒非常影响用户体验。因此我们采用了在顶部横滑的方式展示。

上图可以看到的是用户需求的细化和标签的对应关系，用户在横滑模块中选择的功能服务或者说是一种使用场景 ( 也是一类标签，这类标签代表用户的在特定场景下的需求，具有很强的用户属性，用户看到后很容易产生共鸣，下文将提到这类标签如何挖掘 )，可以对应到结构化标签中，并通过标签可以进行特定召回。

③ 类目标签体系

这些有用户属性的标签可以认为是类目标签，因为描述比较宽泛所以具备跨类目属性，因此我们采用了合并、拆分原有类目的方法来建立类目标签体系。

合并：

从需求侧来看：

• 可以根据搜索词进行类目预测，计算类目预测 PMI ( 类目词的贡献值 )。

从内容侧来看：

• 根据帖子标题检查类目词的相似度，通过 Tagging 计算词频。

从用户行为数据应用来看：

• 采用转化行为前 24 小时点击过的 Top3 类目和个数，增加阈值筛选等方式计算类目词频繁项

• 采用用户随机游走计算类目相似度的算法。获取用户点击商品、电话的点击序列，按照点击类目是否相同分别打分，再根据构造出来的类目图关系，通过随机游走算法产生行为序列，通过 SkipGram 计算词向量，最后计算类目词之间的相似度。

拆分：

通过拆分挖掘类目词主要有两种做法：

• 采用通用的知识图谱。比如家电维修，家电在通用图谱中是有下位词的，如电视、冰箱、洗衣机等，根据下位词和模板可以挖掘出来是电视维修，还是冰箱维修。

• 采用帖子图聚类算法。根据用户行为获取两个帖子之间的点击、电话序列，同时赋予不同的权重并构造 I2I 关系图，根据图进行聚类得到帖子聚类表。每个帖子对应到一个集合里，再对图进行 DeepWalk 的训练生成帖子向量，再对集合的 Embedding 进行表征，再利用表征关系计算集合间的相似度。

通过合并和拆分类目再结合高频搜索词挖掘，可以找到需求词，构建出场景标签以及标签和类目之间的关系，标签和标签之间的关系。

3. 用户意图感知

现在我们完成了用户场景化分发体系的构建，如上图所示，从用户的需求侧到供给侧编织了一张大网，一端是用户，其中长期偏好通过用户画像获取，实时意图通过意图系统获取 ( 下文介绍 )，另一端是已经经过结构化的帖子店铺和商品 SKU，中间通过类目标签 ( 需求侧标签 ) 和内容标签 ( 结构化标签 ) 串起来，整个过程是通过获取用户画像和点击对应类目行为，再选择类目对应的结构化标签，召回对应的商家帖子和店铺。即通过信息的结构化快速找到对应服务的 SKU。如搬家->公司搬家->拆装服务->展示出有拆装服务的优质公司搬家店铺。在用户端，我们有对应的用户画像，在用户点击对应类目时，可以关联到对应的结构化标签中，从而召回对应的商家帖子和店铺。

上图就是整个用户使用流程。用户通过点击横滑模块的标签，展示已形成结构化的标签列表，最终用户可以挑选并快速找到对应的帖子和关心的服务 SKU。

4. 分层优化

刚才说的是场景化构建过程，目的是在默认页能让有明确需求的用户能够在短时间内找到想要的服务，减少用户跳出，只要用户有了点击，我们就有希望明确用户的意图，除此之外还有很大一部分用户他们还使用了搜索或者推荐等功能，在此我们主要介绍一下在分发系统上的分层优化的方案。如前所述，快速捕捉用户意图十分关键，用户意图是树型或者是网状的关系。下面我们讲一下，怎么感知和表征这个关系，怎么在算法分层上进行优化。

① 召回优化

不管用户是否带着 Query 词进入列表页，此时用户总会有上下文信息，如用户画像、所在场景、点击标签、点击行为等。我们有一套用户意图系统，可以通过系统改写 Query，串出用户意图树，再根据意图树在引擎中召回帖子、店铺列表等。这种改造 Query 词的方式其实是一种布尔召回，召回深度偏低。因此希望通过建立用户意图表征，优化成以向量召回，提高泛化能力，从而提高召回深度。

用户意图表征：

那怎么做用户意图表征？首先对近期的帖子文本内容进行清洗、分词、标签化，通过 SkipGram 形成最终词向量。这种方式仍然存在问题：整体帖子内容多而杂，表意性稍差。

因此引入了业界通用的腾讯 AI Lab 中文词向量，虽然在本地服务场景下无法直接使用，但我们通过在 SkipGram 之前对词向量做了初始化，利用了词向量的预训练结果。完成这步后，在人工评测时效果有大幅提升，相似召回率提升超过 2 倍；在线上验证应用时，标签推荐 CTR 效果有 4%提升 ( 标签推荐不涉及帖子标题、企业等其他信息，因此可以用来验证词向量是否准确 )。

在预训练的基础上进一步优化，我们将使用用户的最近使用序列进行清洗，最终也放到模型中去训练。在模型增加行为序列时，也有一些应用技巧。一个是标签的点击行为数据稀疏，需要做一些前期处理，如拆分 Session，把长 Session 根据时间切分，根据长度取 topN 做数据增广、通过 Dropout 做泛化。经过前期处理后，整体数据训练样本量基本达到预期。另一个是根据 Session 生成用户向量，同时会对用户前一段的向量进行初始化，持续保持用户的原有信息不流失。在增加用户使用序列后，线上标签推荐的 CTR 转化效果提升 15%，涨幅还是非常明显的。

用户意图多目标表征：

刚刚也提到本地服务的优化目标多样，有 CTR、CVR 等，这些目标在实际推荐效果中要求都要有一定程度的满足，也就是要求模型能够平衡多目标，即需要模型对用户把握更全面。那怎么来训练最终用户的表征向量呢？我们使用了多任务学习模型，通过共享部分网络结构，来学习基础通用的表征。而相对多个单任务模型，多任务模型有以下优点：网络结构更小、在线 CPU 使用率更低、支撑更高 QPS、性能稳定性高、存储资源更少。

同时，学习用户的通用表征向量，也可以更方便迁移到其他任务模型中。根据前期的数据准备，对用户行为序列做 Embedding，再接入双向 LSTM，即可根据 Embedding 对用户行为序列本身进行表征。在完成表征后，考虑到用户行为千变万化，还需要再加一个 Attention 网络，即当用户搜索或者用户本身有这样的标签时，可以及时捕捉到对应行为序列中的变化点，并反应到网络中，最后形成 128 维的用户表征。因此，可以实现根据不同优化目标，可以选择不同网络进行学习。以 CTR 目标为例，将生成的用户通用表征和 Item 通用表征，一起放在网络中对 CTR 进行优化。

多目标表征几点启示：

• 相关任务，多目标学习的各任务间需要有一定的相关性，否则会起反作用。至于具体是什么样的相关性，在实际应用中需要多多考量。

• 增量学习，前面也说到在多目标学习模型中增加了 Attention 网络，而随着时间和用户兴趣的变化，Embedding 表征也需要随之变化，比如固定时间间隔自动增量更新，每天级更新等，让模型更贴近用户的近期数据。

• 数据稀疏问题，多目标表征可以解决一部分样本稀疏问题。如帖子 CTR 点击数据多，电话、微聊 CVR 转化数据少，因此可以通过 CTR 数据解决一部分 CVR 数据问题 ( Share )。

• 模型泛化特征更有效，加了多个任务目标后，其他任务对当前任务有正向作用。从模型 AUC 来看，多目标学习在线上测试集是优于单目标学习的。在训练集中相反，单目标更优，但这个影响不大。实际上我们认为多目标学习的作用是在单目标基础上增加了正则项 ( 原本网络训练时也需要加入正则 )，有一定促进作用。

• 模型效率问题， 比如说 CTR 训练任务中，有 1w 个物品，需要计算 1w 次，每次调用耗费资源很高。如果最终是需要生成一个 User 表征，其实可以只计算一次。

• 样本偏差问题，需要注意离线均值和方差和在线保持一致。

上图是在加上多目标表征做召回的实验效果，可以看到 PV CTR、UV CTR 都有 1%多的提升，尽管样本没有发生太大的改变。

② 排序优化

实时意图：

排序上优化重点在如何挖掘用户点击的实时意图。我们通过收集用户各种行为数据，做数据清洗、存储和权重计算，最终存储在用户意向表中，包括一些行为更新、过期管理、分值衰减等。这里最终存储的就是用户的行为和对应行为的分值、标签和对应标签的分值。在统计标签分值时，需要考虑帖子标签的权重是否有区分度：

• 不重要无区分度的标签权重相对较小

• 根据用户对帖子行为距离当前的时间设置权重，时间越近影响越大

• 不同行为类型权重不同，如搜索、筛选、电话等需要设置不同权重

上下文感知：

刚才得到的是对用户行为特征的意图挖掘，可添加到线上网络中应用。而网络中还涉及到大量的其他特征，如人群、商家、场景特征等。由于用户点击序列不会特别长，点击特征可能存在冷启动问题，所以更多可以通过场景、商家特征作为补充。这些特征维度特别高，需要通过几层网络来做降维，最终形成有上下文关系的用户意图感知。

上图是实时意图特征应用的实验效果，通过帖子提取大量的内容标签，根据用户行为进行标签匹配，最后产生用户所感知的信息。可以看到在对应场景下，转化效果都有一定提升。

③ 展示优化

由于用户意图实时变化，而帖子信息特别繁杂，在列表页展示信息时，其展示的信息不一定契合用户当前需求。因此我们做了智能展示策略，核心是基于用户服务标签和行为数据，根据用户实时意图，对帖子本身进行展示区分，同时改变其结构化信息。标签、标题、图片、摘要等展示内容都会随着用户的实时意图随时发生改变，极大提高了对用户需求的关注粒度，有效提升用户体验。

5. 系统整合优化

在流量分发过程中，涉及的系统繁多，如搜索、推荐、智能摘要等。因此我们需要对各系统进行整合。

好处很明显，不同系统沉淀的用户数据不需要存多份，减少重复数据存储；通用算法共享；相似场景模块复用，减少开发成本。

• 数据资产，我们能够提供的数据资产丰富 ( 用户画像、行为数据 )，还包括帖子、服务、SKU、商品、任务都可以作为分发的内容。

• 算法注册表，包括召回、排序等各种模型，封装在组件服务中。

• 组件注册表，提供满足用户在不同场景、不同上下文意图中的功能组件。如需要处理 Query 时，有纠错、改写、Tagging 等组件，需要处理用户意图，有意图识别、偏好预估等组件。

• 场景任务配置，提供方便组件间自由组合的配置功能，如智能摘要中，只需要配置召回、排序组件；在用户搜索场景中，在召回、排序基础上，还需要配置 Query 相应的处理、用户搜索意图识别等。

04 总结与展望

1. 重排序

后续会继续研究重排序模块，我们尝试在详情页、猜你喜欢页面上做了交互式推荐，如在 Feed 流无限下拉，点击回退后希望会对之前结果进行重排序，目前还在实验中。

2. 品类交叉推荐

刚刚提到 58 的服务品类是多而杂的，虽然品类间关联少，仍然也可以挖掘出一定的交叉能力，如通常用户在搬完家后会找保洁服务，那搬家和保洁就是有一定关联的。

3. 拼单推荐

我们也在探索拼单推荐的模式。如果发现当前小区有多个服务需求，而附近保洁阿姨正在工作，为了减少跑腿，可以有第二单减免的优惠等，对平台、用户、商家都是有利的。

4. 周期推荐

像做饭、保洁这类服务都是有一定周期性的，比如每月一次、每日三餐等。

5. 闭环反哺开环

本地服务大多依赖于线下成交，用户在线上寻找服务后的电话、微聊转化情况，线下是否成交等，我们是很难知道的。而目前的到家精选业务是有完整的闭环数据，可以辅助我们决策。

6. 社交关系分发

合伙人网络这块，实际是社交关系的分发，比如合伙人会分享任务在微信群或者其他群里，这里是存在社交中的信任关系的。

7. 利益驱动分发

另外，由于合伙人涉及分佣，其中的提成比例、分佣金额等，涉及到与业务投入产出比的指标，也需要考虑。

8. 流量分发与生态建设：规则？算法？

58 本地服务涉及到 200+基础行业的方方面面，中小商家、务工人员等，都是依托整个平台流量来生存。因此我们需要思考怎么更好地匹配商家和用户，根据生态更好的演化，做到更好的优胜劣汰；需要思考如何把产品规则和算法目标更好地融合。目前初步的想法是把产品规则前置，减少规则性对算法输出结果的破坏和干扰。

作者介绍：

陈琳：58 同城，算法架构师

58 本地服务事业群算法策略部负责人，负责本地服务业务中用户/商家画像、标签挖掘、搜索推荐、知识图谱等系统的建设，支持 58 站内本地服务、城市合伙人体系、到家到店及电商体系的流量分发和营销。

本文来自 DataFunTalk

原文链接：

本地服务场景下的流量分发算法实践