贝壳找房流量分发数据回收与治理演进之路

你好，我是来自贝壳找房商机中台的张昭，我想和你分享一下数据回收与治理相关的业务逻辑和技术实现。主要会分为五个部分：

• 场景应用与痛点分析
• 商机回收架构演进
• 商机溯源架构演进
• 商机治理能力演进
• 总结与展望

通过上面的目录相信你也看到了，我们的数据回收对象是商机。那么第一个问题就来了，什么是商机呢？借助一些截图，我先带大家了解一下贝壳 App。

首先我们找到贝壳 App，然后点开它进入到贝壳 App 的首页，可以看到在贝壳 App 里边有很多的入口，下边我们默认展示的是“为你推荐”的“房源”。用户可以点击一个房源卡片，然后进入到该房源的详情页当中。在该详情页里边，我们展示了该房源相关的各种属性，还有各种功能按键。用户点击“在线问”就会进入到与经纪人的聊天对话当中；点击“打电话”，就可以通过拨打 400 电话的方式与经纪人进行电话沟通。还有 VR 带看，点开之后我们会进入到该房源的 VR 视角，与经纪人进行一个线上带看，除此之外，贝壳 App 上还有很多类似的功能。像这样的一些基本的操作，都是我们允许的用户的基本常规操作。

回到我们刚才的问题，什么是商机呢？用一个简短的概念来讲，商机就是 C 端用户通过展位与经纪人产生的有意向（买房、租房、装修等意向）的交互行为数据。

可以看上面这个图，一条商机有几个基本的要素，首先有用户，有用户感兴趣的一个房源，然后通过房源上的广告位联系到一位经纪人。这里要注意一下，这里的广告位不是张贴房源的广告位，而是在房源的详情页里有很多展示经纪人信息这样的位置，我们称作广告位。

关于商机还有一些其他的属性，包括类型、业务线、终端、网站、品牌、媒体、版本等等。商机是贝壳经纪人作业的一个基础，也是贝壳公司衡量市场水平的一个重要的指标。

了解完商机的一些基本概念之后，再来看看贝壳对于商机数据需求演化的三个阶段：

阶段 1：商机数据的管控

这一阶段我们要做的事情首先是回收商机行为、判定商机、丰富属性、统一管控。可以注意一下用蓝色标记出来的两个概念，商机行为和商机。商机行为是用户最基础的这种行为数据，比如在 IM 对话聊天框中用户发出的每一句话都是一条商机行为。商机实际上是依据于商机行为的一些核心属性，经过按天级的这种去重得到的数据。

丰富属性是代表要将 C 端回传回来的商机数据进行属性填充，意味着如果 C 端回传一个用户信息只传了用户 ID，我们可能要根据用户 ID 填充用户名、用户手机号；如果回传展位 ID，我们要去关联展位的业务线、展位名称等信息。

统一管控意味着我们在全公司统一这种商机的判定口径之后，要在公司以及经纪人门店拉通标准，然后统一数据输出。

阶段二：商机溯源分析

在这一阶段，有很多团队对于商机归因有相应的诉求。这一阶段我们主要做的事情是要还原商机的产生链路。

阶段三：商机的质量治理

在这一阶段，我们主要是识别出来每一天商机中的无效商机，然后处置低质量的用户。

下面就依次来看三个阶段分别对应的几个事项。

首先是商机回收，我们看一下整个商机回收服务的架构图。



商机回收有几个核心的模块，上面红框框住的内容是商机行为回收模块。这个模块是整个商机回收服务最基础的模块，也是最早的模块，它要做的事情是基于 C 端用户的行为数据，经过处理输出商机数据。商机数据可能分为不同的维度，我们后边会提到。

在进行商机数据回收的过程中，我们要做数据校验、数据预处理、多维度属性填充、特征判定等。在这个过程中，我们会依赖大量的第三方的数据接口。这些数据存在于不同的业务线当中，存在的形式也有很多，比如有接口形式的，提供的是 Dubbo 或者 Http 接口；也有第三方的存储，比如最典型的像 Kafka、HBase、MySQL 还有 Hive 等等。因为要保证整个商机回收过程中对第三方数据依赖的稳定性，因此所有的异构数据存储我们都是统一存到了我们商机中台内部一个主要的 ES（Elasticsearch）索引当中。

第二个核心模块是商机前台感知模块。商机前台感知是我们基于商机行为回收模块做的一个环节， 它要做的事情是我们接收到特定的商机行为数据的时候，会给经纪人推送相应的一些卡片信息，比如推送用户的信息卡片或者恶意用户提醒等等。

第三个核心模块是商机质量治理模块。商机质量治理模块同样也是依附于商机回收模块的，它是整个商机回收过程中的一个同步处理逻辑。在这个过程当中，我们是要将行为数据进行各种质量分析，然后同时输出对应的质量结果。

第四个核心模块是商机状态感知模块。这个模块主要是将上游 B 端经纪人的一些行为，比如录客、 带看等数据，将这些状态数据、动作数据反映到整个商机的状态字段上，同时输出我们商机最新的数据。整个服务的输出包括了右边的行为流数据、索引数据，以及下边的产出日志监控 、消费生产监控还有一些看板类的数据。

接下来聊一下整个商机回收过程中，我们面临过的一些挑战与解决措施。

挑战一：实时性

措施 1：基于事件总线通知机制，实现多线程的并行处理（EventBus+ 自定义注解）

这个过程是这样，比如一条消息，我们要经过回收处理的过程中需要有大量的处理节点，每一个节点可能需要填充一定信息或者判定一定的信息。

看上面这张图，一条 Message 可能要经过很多这样黄色的节点，这样的黄色节点可能有几十个 ，然后不同的节点之间还有各种的依赖。随着我们业务的发展，比如不同的业务线，像新房和二手，它们对于这种逻辑上可能有特定的需求，也就意味着将来这种逻辑上下游依赖会变得越来越复杂。

对于这种复杂的关系，我们采用了这种自定义注解的方式。研发同学就可以自定义地往里面添加上游的依赖即可，也不用担心整个数据链路会出现死循环，只需要在启动过程中做一个循环依赖的检测即可。然后整个节点的执行过程中要保证实时性的话，我们是将所有的这种处理节点都当做异步线程去提交，这就意味着我们一次性会提交几十个这种线程。

怎么样保证线程之间的依赖按照我们的预期去执行的呢？所有的节点都会监听到一个事件总线之上，当一个节点完成之后会向事件总线发布完成的通知，如果有前序节点依赖的这种线程会持续地监听这条总线，当自己的前序依赖都已经完成之后，那自身就能进入到一种执行状态。这种设计理念比较适合多个任务同时执行，同时任务之间又有依赖的情况。

措施 2：高效率失败 Retry 机制（基于 DB 的 DelayQueue 实现 + 不重复填充属性）

看到上面这张图，当一条消息的某一个节点处理失败的时候，我们会要求当前消息全部都经过 Retry 处理。

整个流程可以看到，三个消费实例消费原始的数据，当出现异常的情况下，我们会将整个消息处理的上下文以持久化的方式写到 DB 里面去。因为处理的是商机数据，需要确保每一条数据的不丢失。我们写到 DB 里边去的时候，同时会设定该条数据什么时候会被第二次执行 也就是我们会设定一定的执行间隔。写到 DB 之后，我们会有第三个 Task 实例，以一定的 Schedule 的方式从里边捞取达到执行时间要求的数据，然后重新又会写入到 一个 RetryTopic 里面去。然后所有的消费实例同时也会及时地去消费 Retry 里面的数据去执行。整个处理的过程中要保证高效率的话，我们需要保证已经处理过的节点是不会再被执行一遍的。

措施 3：突破上游数据流 partition 数量限制（基于 CDSS 平台利用 KafkaMirrorMaker 扩容 partition）

在贝壳内部商机回收服务上游提供的数据大多都是 Kafka 的流，相信你可能在自己的公司也会遇到这种情况。比如上游提供的 topic 数据量比较大，但是由于一些历史原因，partition 数量不是那么多，这就意味着当下游遇到一些消费瓶颈时，无法通过增加实例的数量来提高并发度。我们推动上游去改变、动态调整 partition 数量可能会导致有一些不可控的风险存在，比如数据量的增发之类的。

我们采用了一个成本比较小的方式，基于部门内部实现的异构数据流式同步平台。在这个平台里，我们采用了 Kafka 的 MirrorMaker 的插件，然后实现从一个 topic 读取所有的数据，映射到另一个 topic 上。这样的话，新的 topic 可以设置足够多的 partition 供我们所有的 consumer 去消费，然后来提高并发性。

挑战二：准确性

措施 1：全年商机数据去重（基于 ES+Redis 实现全年数亿级数据下发幂等性）

因为我们要下发商机数据，需要确保下发的商机数据不重复。一般在这种场景下，我们都会考虑用 Redis 去做缓存，然后判断 Redis 里边如果存在这条数据，我们就不去下发。但是因为我们基本上以年的这种跨度来做去重，这就意味着全年的商机存到 Redis 里面，可能要消费大量的存储，这样的话经济性会比较差。

前面也提到了，我们整个商机回收服务依赖的主要存储都是 ES。但是 ES 写入数据会有段合并和 Refresh 的过程，这样导致我们不能直接用 ES 来做这种缓存。因此，我们基于 ES 加 Redis 组合的方式，实现了全年数亿级的数据下发的幂等性。

措施 2：同步相关业务方实时数据、离线数仓数据（基于 CDSS 平台完成诸多第三方数据接入）

我们原先整个商机产生很多都是在离线的环节，比如说在数仓环节的话，它依赖了很多的数仓表。我们要做实时的数据回收，需要确保实时的数据和离线的数据是一致的，因此我们要把很多很多的异构数据、数仓数据还有一些其他第三方团队的数据都同步到 ES 中。这么大的数据同步量，我们依然是基于自研的 CDSS 平台，异构数据流式处理平台，然后完成了诸多第三方的这种数据接入。

挑战三：服务的稳定性

措施 1：可动态扩缩容（增减节点对数据处理无影响）

前面提到了，如果上游给的 topic 的 partition 数量不够，下游即便是提高并发的实例数也不能保证整个消费性能是提高的。因此这一点是基于我们前面提到的增加了 partition 数量的机制下完成的。

措施 2：开机预热（基于 RateLimiter 的自定义 WarmUp 限流机制）

在整个流处理过程中，我们服务刚启动的时候会有大量的连接池需要去初始化，比如 ES 的连接池，Redis 等等。我们基于 RateLimiter 自定义了 WarmUp 的限流机制。RateLimiter 本身虽然有 WarmUp 的限流机制，但是实际使用下来它的效果一般。

措施 3：优雅停机（监听 ContextClosedEvent 事件预留 KafkaConsumer 停止间隔）

整个服务停机的过程不像一般的 Web 请求，Web 服务有摘流的过程。因此，我们与贝壳公司的发布平台进行了配合，当服务停止的时候，服务会监听上下文关闭事件，预留 KafkaConsumer 的停止间隔，以确保所有的数据在内存当中处理完了整个服务才停。

措施 4：预上线环境完整灰度方案（核心逻辑变更发布前具备灰度数据对比能力，验证数据量、属性完整度同比等）

这是比较重要的一点。整个数据的回收服务，我们有时会做一些业务的变更。然后业务变更很可能会带来的一些异常，我们并没有办法短时间内知道，比如在运行了一天之后，才能发现某些维度的数据量变少了，有一些属性没有打上。因为这些业务它只是业务逻辑里边的一些分支，然后并没有体现在我们上线过程中的一些异常之上。这种情况下我们采取的方式是，在线上环境基本上部署了两套类似的这种环境。当我们有核心逻辑发布变更的时候，我们先提前在预上线环境去完整地运行一个时间周期，比如运行 24 小时，验证两套环境生产的这种数据量、属性完整度是否都符合预期。

措施 5：监控报警（精确到商机类型、业务线、广告位等细粒度的消费、生产数据曲线监控以及异常报警）

这个是比较重要的，我们要精确到商机类型、业务线、广告位等细粒度的消费，生产数据曲线监控以及异常报警。

下面来看一下商机回收的产出成果。产出成果方面我们主要是输出了四条数据流：

这里解释一下商机对，商机对是基于商机的进一步清洗的结果。比如一个用户和一个经纪人在三十天之内只能产生一个商机对。商机状态流是商机核心属性，发生变更的时候我们去输出商机最新的数据。

这是我们产出的各种数据看板，有 PC 端的，还有这种经纪人手机上商机的列表看板。

商机回收就介绍到这里，接下来我们聊一下商机溯源的需求。

贝壳商机溯源方案产生有一个背景，主要来自于我们其他团队对于商机归因的诉求。比如最典型的就是市场投放团队，他们想知道自己投放出去的页面是否真正地产生了商机；或者推荐的团队他们也想知道推荐卡片是否真的有用户去点并且还产生了商机。

第二个背景是埋点方案的准确性不够。当我们接到这种商机归因的诉求的时候，首先想到的肯定是前端埋点方案。埋点方案主要是根据用户的设备 ID 去串联用户在不同的页面上留下来的这种行为轨迹。

我们在尝试了一段时间后发现了几点问题：

第一，用户的设备 ID 我们不一定能百分之百拿到，这会造成一定的数据量的折损。

第二，埋点方案，它会存在用户的设备的时间戳和我们服务端的时间戳不一致的情况，导致用户的时间线在我们服务端收集完之后出现这种乱序的情况，导致数据不可用。

第三，最重要的一点，我们做商机归因实际上是想知道一条商机产生的完整的链路，比如用户点开的页面它是一个别人分享出来的页面，这种情况下我们就没有办法知道最源头的页面在哪里了。

在这种情况下，我们通过调研，最终去参考 Google Dapper 分布式跟踪系统设计方案，尝试在前端页面中实现这种请求链路的串联。我们知道基于 Google Dapper 诞生了很多后端服务追踪的优秀的产品，我们也是把用户在贝壳 App、H5、小程序中的这种跳转类比于我们后端服务一个请求，在不同节点中的这种跳转。

看上图中整个溯源的服务架构，当用户在不同的页面上进行跳转的时候，我们每一个页面在加载的过程中，都会有页面上对应的 SDK 去异步地与溯源服务进行交互，主要是为了生成当前页面的 sid。同时上一个页面往下一个页面跳转，会带上上一个页面 parent 溯源 ID，我们就叫做 sid。

比如我们看到页面 1 上会有一些元素级别的 ID，有一些业务团队可能需要我们溯源到元素起点上。这种情况下，我们一般会要求生成这些元素的业务团队，在后端与溯源服务进行批量的 ID 交互，提前获取一批 sid 分配到元素之上。然后我们在页面跳转的时候，页面 2 就不光有上一个页面的 sid，还有上一个页面的元素 ID。

核心模块主要是三个，第一个是 ID 生成模块；第二个是日志收集模块，我们要将每一个页面往后跳的这种前后关系收集起来；第三个是日志处理模块，这个模块主要是要将所有的前后对应的关系串联成一整条链路。最终我们要输出的数据因为数据量会比较大，主要都是以离线数仓的方式去输出。

下面来实际模拟一下场景溯源的方案。

贝壳的场景溯源方案可能会涉及到三个主要服务：

第一，商机溯源服务

第二，是流量分发服务

第三，商机回收服务

首先用户打开 App，然后首页在加载的过程中会异步地请求商机溯源服务，这个时候它的参数会带上 schema，代表是当前页面的一个别名，比如首页就叫 homepage。然后 parent sid 是负 1，这里的负 1 是我们和各个业务方约定好的，比如链路到负 1 就截止。首页还有一些我们投放出去的广告页，我们都约定好要传负 1，这样我们在服务端会记录下来一组日志，生成一个 sid，同时返回给页面。

我们以细粒度的这种元素级别串联为例，用户点击房源卡片进入到房源详情页。详情页在加载过程中，同样也会异步地请求商机溯源服务，这时它的请求参数会带上上一个页面的 sid，比如 parent sid 以及元素 sid。然后 schema 是二手详情页，二手 detail 其他的参数我们就暂时忽略掉， 同时后面也会记录下来前后的对应关系。

然后同时这个页面在渲染的过程中，因为有一些广告位也需要去渲染，所以广告位实际上会请求到流量分发服务中来。可以看到页面最下面的广告位会展示一个经纪人，这个请求就是我们请求流量分发服务得到的。请求流量分发服务的时候，我们要求业务方会把 parent sid 还有元素级别 sid 一并传到流量分发服务中去，这样在流量分发服务我们也能拿到一组日志，然后页面中会拿到所有的数据。

第三步，用户点击在线问，进入到与经纪人的聊天对话当中，然后用户发出了一张房源卡片，这时商机回收服务就会收取到这条房源卡片对应的商机行为，内容是 from to，就代表从用户发给经纪人，以及一些其他的信息。我们会约束业务方在上报这种商机数据时，带上 adid 和 rid。到这里我们就可以从商机回收服务往前去回溯了。商机回收服务根据 adid 和 rid 就能串联到流量分发服务这边的日志，拿到 parent sid 和元素 sid。根据 parent sid 和元素 sid，我们去商机溯源那边就能一直串联到最终的负 1，这就是整个商机溯源的过程。

下面聊一下商机溯源面临的问题与挑战。

挑战一：溯源链路涉及 App、小程序、H5 间任意跳转，需要确保溯源信息不丢失

在这一点上，我们分别推出了统一的 App SDK、XCX SDK 还有 H5 SDK，这样前端同学在开发页面的时候，会以极低的成本去完成溯源信息的这种交互；第二，制定不同介质之间跳转的参数传递规则，包括我们从一般的页面去往外分享的时候的传参规则；第三，制定商机串联溯源电路的关键点传参规范，我们要求前端在回传商机行为数据的时候要带上相应的溯源信息。

挑战二：业务接入方溯源覆盖率指标随版本迭代波动

上面提到了，我们制定了很多规范但无法确保各个业务方的前端同学在开发的过程中一定能遵循规范，有一些可能是无意间的。因此，在这种情况下，我们中台构建了溯源覆盖率指标、大盘的看板以及健康度的感知报警。如果某个业务方的溯源覆盖率降低比较明显，他们会及时收到报警，然后去修复自己的一些业务逻辑。

挑战三：溯源服务的请求量大、响应时间要求苛刻

我们知道溯源服务最核心的是 ID 生成算法，我们内部实现也是基于雪花算法去实现的。雪花算法它实际上有一个同步块的逻辑，因此我们也提供了一些自定义的批量 ID 的生成方式，减少整个逻辑在同步代码块停留的时间。

挑战四：离线数据处理数据量大，对机器内存要求高

这里我们主要做的事情是数据分组平滑扩容，前面提到了，我们整个离线数据处理的一个比较重要的环节，就是要将任何页面前后的这种父子的关系串联成一整条链路。即便在我们业务低峰期的时候，每一天的数据量级大概也是几十亿，如果说要串联所有的链路，需要一个非常大的存储，这样的成本非常高，在我们集群中可能就比较难实现。因此，我们设计的是将所有的溯源 ID 进行分组处理，就是在 ID 的格式中设定固定的某一段代表这个数据的分组，父 ID 的分组和子 ID 的分组一定是相同的，这样我们就可以在处理数据的时候，每次加载一个分组进行处理。

最开始我们设定了 128 个分组，后来发现 128 个分组仍然不够用，因此我们又对 ID 的格式进行了优化，做到了数据分组的平滑扩容。既然 sid 有多个分组，我们在生成 ID 的时候就可以进行分组加锁机制，然后同时减少这种并发，在同步代码块的那种停留逻辑。

接下来看一下商机溯源的成果。比较简单的描述就是，我们基于 Dapper 的设计思路，成功实践了在前端页面中的溯源方案，实现了海量溯源数据的精准串联，提供了实时的商机溯源链路查询，实现了商机归因。

这是一些我们的看板，业务线、分业务线具体的溯源看板，还有我们基于整体的流量做的这种流量分布图以及我们可以查询某一条商机具体的产生链路。

下面我们来看一下商机治理能力的演进。

首先了解一下商机治理的背景。整个商机规则统一上线之后，随着自然流量的增长，还有比如市场团队投放等的作用，我们的商机量经过了一个爆发式增长的过程。在这个商机量爆发增长的过程中，我们收到了一些经纪人的负反馈分析。通过线下沟通、满意度调研、分析客服工单的方式，我们了解到每一天的商机里确实有很大量的商机属于低质量的商机，比如黑产类、微商类的等等。这是我们要整体开始治理商机的一个背景。

开始治理的时候，我们首先是讨论了很多的思路，这里分享一些比较可以挖掘的思路：

首先是基于多维度指标的一个判定。这个思路是说我们一个用户每天能够产生的商机量，或者是它产生的商机所关联的城市数、门店数、经纪人数都是有限的，应该也是符合正态分布的。比如，我们可以设定每一个属性它对应的正态分布就是百分之 4 个 9 或者 5 个 9 的极值，如果一个用户在多个维度方面都能超过极值，那么这个用户大概率会产生很多的低质量商机，这是我们的一个探索的思路。

第二是基于 IM 聊天内容中是否包含微信号、手机号来判定。我们知道，微商要做的事情就是要发送自己的联系方式，最典型的就是微信号、手机号。当收到一条 IM 消息时，我们实时地去从里边提取微信号、手机号，然后判定这个微信号、手机号本身是不是一些恶意的微信号、手机号。

第三，基于语义的微商识别。我们认为一个正常的用户与经纪人的沟通，整个聊天内容和微商用户或者是黑产用户与经纪人的聊天内容相比，它的语义特征应该会有很大的区别，所以这个也是我们目前正在实验中的一些思路。

第四，基于黑名单的低质量的商机识别。我们会设定很多非常苛刻的条件，如果用户还能违反这些条件，代表用户大概率就是一个低质量的用户或者是恶意的用户，它所关联的商机或者后续产生的商机都会是一种低质量的商机。

第五，基于公司风控、反黑团队提供的风险账号信息判定策略。公司内部的风控团队、反黑团队会提供一些风险账号信息，我们在整个商机回收过程中直接利用这些信息即可。

下面看一下整个治理的方案与架构。

前面也提到了，我们整个商机质量治理是在当商机回收过程中的一个模块。在这个模块中，拿到 C 端用户的行为数据之后，我们会进行多维度的指标收集，然后基于各种指标进行的实时策略的判定。因为有一些策略还涉及到这些模型存在，所以我们也有训练文本的采样，分类模型的训练等等。在整个过程中也会生产出来一些恶意的账号或者手机号的黑名单列表。

最终我们定下来治理商机的步骤。首先要做的是识别，然后是标记，把我们最终判定的结果要标记到商机上，然后是输出。输出有三种形式，第一输出商机数据，但是这些商机数据是带上了商机质量标签的；第二是处置 C 端，对于一些恶意用户我们直接会采用比封禁或弹出人机验证等方式，提高他们去产生低质量商机的成本；第三是感知 B 端，给经纪人去推送信息，提示经纪人 可以忽略掉这些低质量的商机。

再来看治理的目标与措施。

我们分析低质量商机发现了有很多类型，这里主要列举几个非常典型的类型：

第一类是黑产类的商机。这种商机一般都会说拉着经纪人去做一些流量类型的活动。

上图是以经纪人视角截下的用户发出来的信息，这种情况直接可以基于我们内部的风控、反黑实验室提供的风险用户信息进行匹配识别。

第二类是同业类的商机。有很多其他经纪公司的经纪人，他们会伪装成用户来贝壳上向经纪人去询问，比如某一套房源具体的位置在哪里或者具体的楼层在哪里，实际上都是为了套取房源， 然后录入到他们相应的系统里面。针对这种类型，我们也有相应的团队，首先他们会分析出很多疑似经纪人的这种手机列表，然后采用智能外呼的方式，判定对方是不是经纪。 

第三类是微商类的商机。微商类的商机主要就是发广告，比如上图这几种情况就是发出他的手机号、变种表情的以及二维码，形式特别多。

治理微商类的商机，我们采取的第一种措施是基于微信号、手机号的滑动窗口频次异常统计。我们在采集到一些微信号、手机号时，会记录下来这个微信号出现了多少次，关联了多少用户，那么当我们接收到一条新的消息，就会判定这消息里边包含的微信号、手机机号在某一个时间窗口内的频次是否异常。

第二种方式是基于变种表情符号的占比异常统计。比如中间那张图，一般的正常用户不会发出这种比较少见的表情，然后整体的思路和我们第一条类似。

第三我们基于完整的会话内容的语义识别策略。也就是前面说的，我们会做整体的会话的语义分析，以此来辨别是正常的用户还是恶意的用户。

第四，基于图片 OCR 转微信、手机号的识别。



接下来聊一下我们跟微商的对抗的过程。每次上线一个新的策略之后，我们都能感受到对应的微商提供者他们的反应和变化。比如最开始微商发送广告的时候，他可能会发的广告量特别大，一个用户一天可能发了几万条数据，例如第一条这样比较典型的内容。这种情况下，我们很容易就能通过用户商机量的排行识别出来。

后来他们就感受到了后端的检测压力，开始分散账户去发，会用大量的账户，每一条账户可能就发几十条甚至十条以内。这种情况下，我们会对每一条 IM 内容做全站的频次统计。如果在整个全站频次统计的，就是 Top 排行榜里边发现了对应的这种内容的话，我们依然也能找到相应的关联账户。所以这种策略并没有起到太大的作用。

后来他们就开始做随机字符的变化，每一条消息里边都会发出包含一个随机的字母，比如说 F、J 之类的，以此来让我们的这种排行榜失效。针对这种情况，我们加大了这种排行榜 Top 的检查深度就可以搞定了。

后面还有各种各样的微信号的混淆，他们在发送微信号的时候会加入空格、标点或者一些特殊符号，甚至有插入中文的，人去看是很容易发现微信是什么，但会增加解析微信的难。还有类似于数字表情符号、特殊表情的，以及把微信号通过两条消息发出来的方式。对于这种情况，我们也构建了每一个用户他所发出的内容的完整的会话索引，因此只需要拼在一起就能达到是检测单条消息的这种目的。还有是前面提到的发送图片、二维码、语音的。

应用场景之一是人机验证和 IM 封禁。前面提到了，如果我们检测到一个用户产生低质量商机，那么我们会根据情况采用提示让他去人机验证 或者是直接采用 IM 封禁的方式。

第二种是消息折叠、恶意用户卡片提醒、商业化产品自动退费、客服工单自动处理。消息折叠，类似于垃圾邮件箱，当一个商机用户联系到一个经纪人，我们会要求经纪人在很短的时间内与用户进行沟通，这也是贝壳优质服务的基础要求。消息折叠就是当进线的是一个低质量用户的时候，我们会直接把这个消息放到一个折叠区不提示经纪人，这样也可以节约一点经纪人的精力。

恶意用户卡片提醒是当我们以后置的方式识别出来某一个用户是恶意用户的时候，我们也会在用户与经纪人的对话框中给经纪人发送卡片，提醒该经纪人该用户不需要你再跟进。当然这也是经纪人自己的一个自由，可以去选择跟进也可以不选择跟进。商业化产品的自动退费。如果说产生的商机是恶意用户，我们就自动把已经扣费的内容回补回来。还有类似于客服工单自动处理等等。

最后是经纪人考核指标的剔除方式。我们只需要以 T+1 的方式，将所有的低质量商机汇总，将这些低质量商机从经纪人考核里边剔除，这样就解决了经纪人的最大头的一个诉求。

然后怎样评估我们的整个的治理效果呢？

首先要确定我们要治理的目标到底有多少，要摸底大盘。我们采用的随机采样的方式，在线上的商机数据中用一个比较长的时间跨度，随机采用了很多的商机，然后以人工评估的方式判定商机是低质量还是正常的商机，以最终我们采样样本里边的低质量的占比来类比整个大盘的情况，这也是我们做低质量商机治理的一个上限。

第二个是策略准招的评估。我们新上任何低质量商机的识别策略时，都会有一个准确率和召回率的这种准入标准。

第三是整体效果的评估。我们会定期给经纪人发送满意度调研或者问卷，通过经纪人的反馈来确定我们整体的低质量商机治理这个项目的效果。

最后整个商机治理的价值，就是净化经纪人的作业环境，提升商机的获取体验。

最后总结一下，我们主要提到了四个方面的内容

1. 贝壳的商机概念，不同阶段的诉求
2. 商机回收服务的架构，面临的挑战与采取的措施
3. 商机溯源的背景、方案、成果
4. 商机治理的背景，无效商机的分类与概念，治理方案与处置措施

后续我们还有很多的探索规划：

展望一：探索在流量分发场景中的应用。在做商机数据回收、商机治理过程中我们也积累了比较多的数据，我们可以基于无效商机关联的用户、用户历史溯源等数据，对低质量的用户采取特殊的流量分发策略，从源头上阻止这些用户产生低质量商机。

展望二：基于商机数据能力打造健康的广告位生态。目前贝壳生产环境的，广告位的数量已经达到了一个比较大的数量级，我们可以基于低质量的商机占比推进低效广告位的优化与下线回收。

展望三：商机价值的挖掘。我们在做商机治理的过程中，所有的重心都瞄准了少部分的低质量的商机，我们的目标是要将低质量的商机消灭掉以还给经纪人的一个比较好的作业体验，但是我们似乎也不能忽略掉绝大部分的优质的商机，要最大化的利用这部分商机。比如，对优质用户的行为轨迹、聊天内容等进行规律地探索与应用，最大化地转化优质的潜在客户，为这些用户带去更优质的服务，为公司带来更好的经济收益。

最后和你分享的一句话：数据回收与治理永远只是起点，在保障用户隐私和数据安全的前提下，从数据中挖掘业务价值才是业务持续发展的关键。

嘉宾介绍

张昭 贝壳找房商机中台资深研发工程师。目前主要负责贝壳商机数据回收、治理、流量溯源等方面工作。曾毕业并就职于华北计算技术研究所，参与过某军工信息系统建设；后加入阿里集团，工作相关代表产品包括 UC 浏览器、学习强国等。