闲鱼如何0到1搭建一套发布引导链路

简介: 闲鱼是如何搭建一个运营可长期干预的促发布链路?

作者:闲鱼技术——觅渡

背景

随着闲鱼持续不断的需求迭代和业务迅速的发展,如何进一步提升用户的使用、留存和活跃的转化,进而带动整体二手交易市场的增长是核心命题。经闲鱼内部数据分析我们发现,用户的商品发布数与成交量呈现明显正相关,宝贝数量越多的卖家,更活跃且留存高,所以发布对于成交和用户留存活跃有着至关重要的作用。那么我们如何引导卖家发布更多的商品,从而帮助交易创新业务快速迭代,促进供给与交易增长,是闲鱼目前重点思考方向之一。

现状与目标

闲鱼目前的MAU中66%非卖家,而在线卖家中有接近一半的用户只有2件以内的宝贝,卖家不发布的主要原因可以分为以下三类:

  1. 动力不足
  2. 发布成本高
  3. 没有触发卖家转卖意识

以往闲鱼通过在双十等大促活动中尝试发布闲置领红包、权益等相关营销活动提高卖家发布动力;智能发布(模糊、相似度检测、主题识别)、轻发布(同款预测、输入联想、键盘标签)的建设致力于降低用户的发布成本;而在发布链路上的促发布营销策略基本都是临时活动为主,需要研发每次提前case by case的单独开发,排期耗时严重,一直以来缺乏固定场景的定向干预能力,触发用户的转卖意识。
结合闲置二手市场货品的孤品特性,不同商品品类的商品效率和成交效率相去甚远,我们希望基于闲置市场供需现状分析,挖掘机会市场,在固定引导页建立导卖主阵地,搭建一条人工可定向干预+算法推荐的促发布导卖推荐链路,实现千人千面的精细化运营,引导卖家发布,调整发布商品的品类结构,从而更好的给闲鱼提供优质供给,提高商品效率,促进交易增长,实现卖家促发布闭环。
image.png

思路

围绕闭环链路中的问题,具体该如何搭建一个运营可长期干预的促发布平台?我们需要从以下角度着手:

  1. 结合二手闲置商品算法的供需分析,实现不同卖家的不同策略推荐
  2. 基于卖家淘宝订单融合多算法推荐策略,展示同类商品匹配求购和卖出详情
  3. 通过工程手段赋能业务方,提供实时干预能力,加速新业务的快速上线、快速调整投放策略

基于以上考虑,我们和算法和搜索团队合作,打通算法基于一键转卖列表的个性化推荐链路,同时支持运营干预能力,联动搜索实时匹配卖出的关联商品,为促发布导卖长期定向干预搭建一条基础链路,实现导卖策略的千人千面,给予业务方快速试错机会。

主要实现方法

围绕前面提到的核心思路,我们可以将促发布引导链路可拆分为两类场景,一类是运营配置的活动和策略,另一类是算法根据卖家淘宝订单列表的个性化SPU推荐。基于移动端的UT日志采集,我们分别设计了运营活动配置、算法推荐、条件搜索三大模块,实现不同的功能

  1. 运营活动配置支持对多种导卖活动类型的灵活配置
  2. 算法推荐用于获取促发布算法的不同策略
  3. 条件搜索用于解决承接页关联商品的数据源

在实现过程中我们遵循以下两个原则:

  1. 模块之间互相解耦,实现过程中依赖的多个外部系统,明确批次的边界,做到最小耦合
  2. 模块内接入服务具有可扩展性,运营策略和算法策略可能会不断迭代,在代码实现上我们需要做到可快速接入,易扩展

总体分层架构如下:
image.png
运营活动配置建设

为给运营提供长期干预能力,实现千人千面的导卖策略。如果像以往老的开发模式中,需要通过服务端推开关甚至修改代码才实现,不仅成本高且效率低。因此促发布活动配置基于闲鱼技术团队打造的鲲鹏系统(面向业务开发和运营同学的平台)进行二次开发,通过鲲鹏积木化特性提供的两个主要扩展点(DataFetcher和MatFilter)开发框架实现业务特殊需求,使得开发模式从原来的单人串行开发升级为多人并行,将开发与运营的角色分工隔离,并实现活动周期管理、灰度控制、多种条件过滤(版本、疲劳度、平台等)等功能。

  1. DataFetcher子系统,通过实现该父类,运营活动后续在首页feeds、搜索结果页、猜你喜欢页面等投放时此DataFetcher类可快速复用,通过控制台注册到对应场景即可,有效节省开发资源,也提升了业务上线效率。
  2. MatFilter过滤器子系统,它沉淀了多种基础组件供业务使用,例如分版本、灰度流量比例、搜索词严格匹配、页码过滤、uv疲劳度过滤等前置过滤器等。活动配置可根据相关的运营定投需求,在控制台上选择对应的过滤器使用,同时通过继承MatFilter基类实现具体业务逻辑。

促发布链路基于以上两个子系统的能力,在投放出来的扩展点上拓展业务需求,实现场景的可扩展和素材过滤器的复用,开发出促发布独有的配置模板和素材,提供运营基础组件来达到不同配置的投放效果。
image.png

  • 运营配置设计如下

image.png
运营在配置平台上,可灵活配置活动的生命周期、投放人群、活动疲劳度、投放策略的优先级以及活动的具体主题参数等,然后根据不同活动选择不同的素材,配置完成后经样式预览,进行审批,产生实验数据,实现活动链路闭环。
开发同学实现完设计的几种配置模板后,后续所有运营类的变更都可以由运营和产品自助在控制台操作完成,如果投放不符合预期,也可自动修改、自助下线,整体流程和开发同学解耦。

算法分析推荐
算法测主要通过供需分析为运营导卖策略提供重要依据以及提供个性化SPU商品推荐

  1. 商品供需分析。利用细分市场与大盘流量效率及商品效率的对比,结合动销情况,根据发布到成交的时间长短,挖掘出紧俏供给类目,供运营圈选人群的策略提供重要依据;
  1. 针对个性化SPU商品推荐。基于用户淘宝订单,从扩展可转卖订单、优化排序模型、优化促发布利益点:如求购人数、价格指导、售卖时间预估 三个方面进行优化;重构离线数据源与在线方案,透出真实求购商品和匹配人数,促进发布;

考虑到算法的多来源接入及后续接入的扩展性,针对集团统一的TPP服务(集团内通用的JVM代码开发和托管平台,目前承载主要的推荐业务),促发布链路根据不同算法源(获取spu商品、对应的匹配商品数)进行结果DO定义,继承基础DO(resultBaseDO),使用统一封装的模板请求和解析TPP服务的结果,大幅降低接入成本,提升代码扩展性。
模板定义结构类图如下:
image.png
客户端每次只需要自定义具体场景id对应的tpp返回结果结构体,然后统一调用getResultAndParse函数即可,由模板统一完成数据结构转换、日志打印、异常保护等,极大提升了接入效率。
代码示例如下:

    function <T extends TppResultBaseDO> TppResultDO<T> getResultAndParse(sceneId, userId, params, cls) {
        TppResultDO<T> tppResultDO = new TppResultDO<>();  
                // 请求获取tpp结果
        String response = retrieveTppData(sceneId, userId, params);
        try {
            if (condition) {
                    // 根据继承模板类解析成基础DO
                tppResultDO = JSONObject.parseObject(response, new TypeReference<TppResultDO<T>>(cls) {
                });
            } else {
                ...
            }
        } catch (Throwable throwable) {
            ...
        }   
        return tppResultDO;
 }

条件搜索

为给用户展示与推荐策略同类型商品详情,我们联动搜索,分别在运营活动配置和策略、算法SPU推荐商品的不同活动承接页中支持了不同条件下关联商品的搜索(关键词、多类目、多状态排序),解决承接页同类商品的实时数据源问题。

效果

image.png
目前,促发布导卖已在线上分桶实验中,卖家进入页面后点击率和承接页转化效率较高,但整体入口转化率表现不明显,对发布和交易的大盘提升有限,后续会根据卖家发布行为特征,尝试在更多新场景下进一步探索适用场景,触发卖家转卖心智。

总结与展望

本文主要介绍发布引导促发布链路的整体架构及几个关键点的解决思路,希望能给读者带来的一些思考和启发。促发布链路天然支持奥格人群圈选、鲲鹏多场景过滤,运营活动、策略和算法推荐相结合,不光是在发布引导页,首页feeds、猜你喜欢等多场景也可快速接入,后续我们也会尝试探索更多的促发布新场景(闲鱼集市,新手村,拍照扫码发布等),持续挖掘卖家行为数据和特征,提升卖家用户标的精度和转化效率,同时结合品牌力、价格力、供需关系来提升商品优质供给和卖家活跃度,实现交易增长。

相关文章
|
4月前
|
Kubernetes 监控 API
微服务从代码到k8s部署应有尽有系列(十二、链路追踪)
微服务从代码到k8s部署应有尽有系列(十二、链路追踪)
|
4月前
|
存储 容灾 Cloud Native
钉钉发展与优化迭代问题之钉钉单元化1.0的建设主要是出于什么驱动,两个站点的用户划分如何实现
钉钉发展与优化迭代问题之钉钉单元化1.0的建设主要是出于什么驱动,两个站点的用户划分如何实现
|
5月前
业务系统架构实践问题之实现平台集中复用和业务自主灵动的方式问题如何解决
业务系统架构实践问题之实现平台集中复用和业务自主灵动的方式问题如何解决
|
7月前
|
设计模式 小程序 安全
【社区每周】商家分账接入指南更新;基础库新增抽象节点功能及上周问题反馈(2月第二期)
【社区每周】商家分账接入指南更新;基础库新增抽象节点功能及上周问题反馈(2月第二期)
190 11
|
7月前
|
小程序 开发者
【社区每周】小程序商品能力两项接口变动(11月第三期)
【社区每周】小程序商品能力两项接口变动(11月第三期)
77 10
|
存储 网络协议 调度
淘宝移动端统一网络库的架构演进和弱网优化技术实践
本文将介绍淘宝 APP 统一网络库演进的过程,讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构,通过构建 NPM 弱网诊断感知能力,落地原生多通道技术/多协议择优调度手段,贴合厂商附能网络请求加速,实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡,为用户提供弱网更好、好网更优的 APP 加载浏览体验,支撑业务创造更多的可能性。
374 0
|
缓存 运维 负载均衡
如何构建流量无损的在线应用架构 | 专题开篇
本篇是整个《如何构建流量无损的在线应用架构》系列的第一篇,这一系列共三篇,旨在使用最为朴素的语言将影响在线应用流量稳定性的技术问题做一个归类,这些问题的解决方案有的只是一些代码层面的细节,有的需要工具进行配合,有的则需要昂贵的解决方案,如果您的应用想在云上有一个【流量无损】的一站式体验,可以关注阿里云的《企业级分布式应用服务(EDAS)》这个云产品,EDAS 也将会持续向默认接入流量无损的方向演进。
1109 11
如何构建流量无损的在线应用架构 | 专题开篇
|
弹性计算 缓存 Kubernetes
【音频】微服务线上发布稳定性解决方案|学习笔记
快速学习【音频】微服务线上发布稳定性解决方案
|
缓存 Kubernetes 负载均衡
如何构建一个流量无损的在线应用架构 | 专题中篇
本篇是整个《如何流量无损的在线应用架构》系列的第二篇,这一系列共三篇,旨在使用最为朴素的语言将影响在线应用流量稳定性的技术问题做一个归类,这些问题的解决方案有的只是一些代码层面的细节,有的需要工具进行配合,有的则需要昂贵的解决方案,如果您的应用想在云上有一个【流量无损】的一站式体验,可以关注阿里云的《企业级分布式应用服务(EDAS)》这个云产品,EDAS 也将会持续向默认接入流量无损的方向演进.下一篇,我们将从数据服务交换的角度进行讲解,更重要的是下一章还会点出重点预防的两把钥匙。
729 2
 如何构建一个流量无损的在线应用架构 | 专题中篇
|
小程序 前端开发 物联网
微应用平台方案设想
微应用平台方案设想
295 0