为了帮助卖家成交，闲鱼工程师做了些什么？

引言

闲鱼是一个C2C平台，提高卖家活跃度不仅有利于成交的提升，对于用户增长也有积极意义。而其中的关键点就在于其成交的效率。而个人卖家由于其专业程度不如专业卖家，成交效率往往并不高。我们希望可以实现两个提升：
能帮助卖家提高其成交效率。

可以快速的接入新的场景。

通过对线上数据进行分析，我们发现一些有趣的现象，比如：使用真人头像的卖家，会有更多的用户访问其主页或商品(潜在的流量来源)；回复积极的卖家更易成交；距离越近/信息越丰富的商品也更易售出。

卖家行为闭环

卖家活跃度最大的核心点在于是否能成交，所以我们以成交为抓手来提高卖家的在线活跃度。根据前面的观察，卖家行为可以影响其成交，这些影响有的显而易见，有的则没那么明显，基于这个我们做了一些尝试。

基于卖家行为的尝试

卖家的目的一定是成交，所以我们以成交转化为目的，基于线上的算法模型做了一轮模拟，模拟基于两个关键指标

• 在线状态。当前用户在线状态以及距离上一次在线时长。
• 询单回复统计。用户在过去半小时的询单回复情况。

算法模型在这里不做涉及，因为有更专业的算法同学来完成，在这里我们只解决工程侧的问题。首先我们定义了用户在闲鱼上的行为4要素：1）when。2）where。3）what。4）who。when和where定义卖家的时间和空间纬度，what刻画了行为本身，who则是对于行为主体人的表达。

另一方面卖家行为描述起来很简单，但是要正确识别却并不简单。比如一个完整的卖家回复行为需要做如下拆解

1. 买家基于商品和卖家创建对话。
2. 买家基于对话给卖家发送消息。
3. 卖家基于对话回复买家消息。

上面三个行为必须满足约束：1）时间有序。2）行为2可以重复发生。3）行为1，2，3之间可能存在干扰(自动回复，安全提醒等)。基于此我们选择用CEP来做复杂事件模型匹配，选型上对比轻量/灵活性/使用成本上综合对比了Siddhi以及flink cep，最终选择Siddhi来作为前期的cep计算引擎。

以上是算法基于两个指标的模拟结果，数据因为安全原因进行了脱敏。纵轴越大表示成交越多。横轴表示基于用户在线状态&回复行为的多维特征。从模拟结果上可以看到在线状态&回复积极的卖家更容易促成成交，这从一个方面说明卖家的行为确实会潜在的影响其成交效率。

构造完整闭环

前面的分析结果说明我们的收益是正向的，但是这远远不够。首先面临的就是卖家如何知道哪些行为可以有助成交？卖家如何去感知这些行为带来的正向收益？

前面说到我们的核心抓手是促成交，所以核心思想是构造上面这样一个完整的闭环来培养稳定的卖家心智，帮助其快速成交。

我们最核心的路径是卖家引导->卖家行为->产生收益->感知收益。围绕着这个核心路径，分别设计了活动，任务，数据采集三大模块。

• 活动关联若干任务，对卖家进行引导。
• 任务用于规范卖家行为。
• 数据用于卖家行为识别。

在整个实现过程中我们遵循两个原则

• 模块间互相解耦。实现过程中依赖了很多外部系统，明确彼此的边界，做到最小耦合。
• 模块内单一职责。整个系统的核心是数据流。越简单越稳定，3我们希望降低维护成本，减少风险。

我们希望可以达到两个目的：1）能帮助卖家提高其成交效率。2）可以快速的接入新的场景。总体实现架构如下

活动

活动引导卖家去进行对应的操作，并给出相应的利益点，负责

• 活动元数据管理。
• 对上层提供查询服务。
• 从底层数据同步通道同步活动信息。
• 容灾计算。虽然同步通道会将任务同步至活动，但是当底层通道出现异常时需要有机制保证可以同步从任务粒度实时计算出活动数据，容灾计算启动时系统整体性能降低。

任务

任务用来定义我们鼓励的卖家行为，解决以下问题

• 元数据管理。包括任务定义及其任务完成之后的回调。

  • 任务定义。定义任务基本要素。
  • 回调。任务完成之后执行，任务执行结果同步在这里完成。
• 任务初始化。数据均产自若干三方系统，主要来源于三部分：1）算法模型产出。2）数据分析。3）买家反馈。
• 三方系统。用一套标准的交互协议实现解耦。

• 数据一致性。任务模块涉及到多方的读写，需要保证数据的最终一致性。

  • 任务初始化/更新/任务查询分别组合成单向数据流，数据流彼此之间使用条件更新来保证数据的一致性。效果类似于乐观锁，但是整个系统不会因为并发写问题而导致性能瓶颈。

数据同步通道

同步通道根据活动元数据将任务粒度的数据同步至活动粒度，支持全量/增量两种同步模式。

• 增量：实时同步任务数据。任务初始化/卖家完成任务。

• 全量：全量一般在新增活动/活动规则变更时触发。需要解决

  • 分布式任务分发。分布式完成全量任务。
  • 操作幂等。操作可以重复，但不影响最终结果。
  • 全量增量彼此隔离，不影响在线服务。

数据层

数据层需要收敛卖家的行为数据。业务复杂度的差异导致其数据来源多样化：1）标准化的数据来源于闲鱼自研的Omega体系。2）差异化的数据来源多样化，包括日志采集/MQ消息/持久化存储设施。

前面提到闲鱼卖家行为的4要素，数据收敛之后首先要做的就是将这些数据归一化，映射成标准行为数据。由于数据量级和复杂度的差异，最终我们根据行为数据复杂度的不同，采用不同的方式完成识别

• 实时流计算。简单事件(聚合/关联等统计数据)匹配使用实时流计算来完成。资源消耗低，但缺乏灵活性，一些复杂事件虽然也能完成，但是代码复杂度高，不利于维护。
• CEP引擎。复杂事件采用CEP引擎做跨事件的模式匹配。功能灵活，可读性强，但是资源消耗高。
• 持久化。带状态的数据需要持久化，用于接下来的匹配计算。

其他

除去前面提到的三大模块之外，我们还补充了

• 收益感知。为了加强卖家利益点的感知，在外围添加了收益感知模块，从三方在线系统回流数据作为活动效果的展示，刺激卖家行为，我们认为这有助于卖家心智的培养与增强。
• 人群圈选。用于活动信息触达卖家。
• 服务层。规范和端上的协议，提供渲染模版，活动查询，action配置等功能。

匹配计算。

效果

当前已经落地了关联同款，基于卖家行为(在线状态指标&回复数据统计)的流量分配模型,真人头像等场景。
基于卖家行为的流量分配分桶测试数据显示，成交转化有3个百分点的提升；目前新场景接入不需要开发介入，只需要运营挖掘出了关键行为数据，就能快速地在系统中落地上线。
匹配计算。

未来规划

用户行为引导闭环归根结底是一个不断反馈，背后的逻辑是我们需要去更好的理解用户，用户是谁，怎么去刻画用户的行为还有很多有待深挖的点。
卖家理解离不开行为数据的支撑。我们需要更完善的用户行为数据及特征向量作为底层的基础设施。

有了完善的用户行为特征库，如何挖掘出对卖家更有价值的行为点加以引导，这些价值往往充满了差异性，需要结合个性化。

目前的收益反馈机制还较为简单，增加卖家对行为利益点的感知，有助于培养成熟稳定的卖家心智。

理解卖家只是第一步，电商领域无论是C2C还是C2B，都在讲导购，个性化。这种个性化可以将流量的价值最大化，但是其中也充满了不确定性，这时候确定性的卖家理解就可以更好的帮助到我们，去做流量匹配，做卖家运营。

---

本文作者：闲鱼技术-吴白

阅读原文

本文为云栖社区原创内容，未经允许不得转载。