快速验证业务决策玩转用户增长

背景闲鱼目前已经是国内最大的闲置物品交易平台,每天都有数以千万计的用户过来闲鱼,以C2C交易为主。在闲鱼里面,用户的C2C购物频率其实是很低的,而纯粹地逛商品feed流是一件挺无聊的事情。在业务上做加法,突破闲鱼用户增长缺少抓手的困境,将业务与玩法深度结合到一起,提升用户参与积极性和活跃度,同时让更多没来过闲鱼的用户对闲鱼产生兴趣。 思路玩法是什么? 玩法不是一种业务类型,它是作为一种能力去赋予具体的业务。 在我理解上来看,玩法像是游戏里面的打怪升级,产品(游戏规则制定者)制定了整个游戏生命周期的规则,用户(游戏参与者)通过完成一个个的任务来获得升级和即时奖励,游戏过程中不仅用户能玩得爽,而且对游戏本身来说,用户游戏等级越高,用户对游戏的粘性越强。 举例来说,在用户浏览feed商品流的时候,当浏览了5个宝贝时弹出宝箱,用户打开宝箱可获得现金红包;对挂出很久仍未卖出的宝贝,去引导用户降价,在宝贝售出后赠与用户一张“回血宝卡”即现金回血。也就是说,产品设置一套玩法规则(一系列的任务编排组合),用户行为触发任务上报,任务达成时发放奖励。 我们再来看看,设计一个这样的玩法体系需要哪些功能支撑? 1、支持不同人群投放不同的玩法策略。 2、支持分桶做ABtest。 3、支持不同人群编排设计不同的任务。 4、在用户达到任务触发条件时,能够上报任务并更新用户的任务列表进度。 5、支持积分兑换权益。 6、数据反馈。 系统设计玩法是由一系列的任务组合而成,在任务的设计上,它是自由的,可以是有序的组合,也可以是无序的。比如说,A人群当天登录闲鱼,先去到某个兴趣鱼塘签到,再发帖子且点赞数超过1个,就自动弹出宝箱,获取积分,并能拿积分换取免费送商品,这是有序的任务编排组合;假如说A人群发帖和签到的顺序不分先后,只要完成全部子任务就算达成目标任务,这就是无序的任务组合。 我们设计的玩法体系,产品可以对任务进行编排设计,运营可以针对性地进行各种玩法实验策略,对不同人群投放不同玩法,对玩法命中人群进行分桶AB测试,并获得即时反馈数据,辅助业务决策,组合成一整个快速优化迭代地玩法策略闭环。 赋能运营在玩法体系中,产品是玩法规则制定者,运营则是架起用户和玩法之间地桥梁,负责将玩法的效益最大化。对运营来说,我们构建了一条完整的实验通道: 1、人群圈选。每个玩法对应的受众是不一样的。打个比方,假如玩法目标在于提升留存率,对于高活人群来说活跃率已经足够高了,在这基础上投入现金红包激励,能够带来的活跃增量就很少,对应的ROI(投入产出比)就很低了,所以像浏览feed开宝箱的玩法,我们会投放给中低活人群。但针对引导发布商品的玩法策略“回血宝卡”,就适合投放给对应的发布高活人群。 2、分桶AB Test。针对同一个玩法,我们希望能快速地找到这个玩法地最佳策略组合。像浏览feed开宝箱的玩法,就有很多个因子的组合可能性(1个宝箱或n个宝箱、是否自动帮用户打开宝箱、feed个性化的方案等等),每个因子对于用户留存都存在影响,通过分桶测试,我们能快速验证哪种组合的效果是最优的。 3、及时地数据反馈。各个玩法下发到对应人群中的对应分桶实验结果,运营都能及时从回流的数据中得到反馈。 效果上述玩法体系已经在为闲鱼多个玩法场景提供能力支持,像边逛边赚钱、流量宝卡、回血宝卡、百币夺宝等,其中百币夺宝的参与率达到了70%多,用户活跃率相比提升了30%左右。 既丰富了闲鱼的娱乐性,让用户除了在闲鱼完成商品交易之外,还能做一些有趣的事情,增强了用户对闲鱼的粘性,又能够赋能运营,建立一条实验通道,验证运营各种业务决策,减少试错成本,并为闲鱼整体的业务决策方向提供非常大的辅助。 未来上述文章介绍了一个简易的玩法体系设计思路,其中很多能力依赖了团队内部其他同学努力的成果,比如:任务系统、积分系统和权益系统。 目前玩法体系依然存在两个局限性,还有较多可以优化的点: 1、固定的产品场景。未来我们希望玩法可以覆盖到整个闲鱼APP,甚至渗透到小程序、快应用等端外投放的场景。 2、实验方法论沉淀。经历了多个玩法开发之后,发觉运营在使用技术提供的实验能力时,缺乏明确的放量节奏和AB节奏,未来我们希望能沉淀出一套方法论,或者是一些工具,来辅助这条通道更加高效和合理化。 3、数据工具化和可视化。目前每开发一个玩法,都需要投入开发资源去做数据报表,未来我们希望在玩法数据这块做更多地抽奖和沉淀,以及提供可视化的能力。 闲鱼目前除了C2C交易,还有很多其他分支业务,比如说免费送、闲鱼币、回收、鱼塘、租赁租房等等,我们相信,玩法的多样性跟用户粘性是呈正相关的,在技术上满足一个优良的螺旋式上升的快速实验闭环,将会在未来给闲鱼、给用户创造更多的价值。 本文作者:闲鱼技术-云听阅读原文 本文为云栖社区原创内容,未经允许不得转载。

July 26, 2019 · 1 min · jiezi

揭秘闲鱼拉新投放系统如何设计

背景闲鱼目前已经是国内最大的闲置物品交易平台。随着闲鱼体量的增长和用户规模不断扩大,闲鱼App上的一个普通banner抑或是feeds中的一张普通的卡片,每天都可能被数以千万计的人看到。 为了更好地服务好广大的用户群体,更加个性化的内容推荐和更加精细化的素材投放就显得尤为必要了。今天我们来聊一聊如何设计一个可以精准触达用户、运营快速试错、解放开发生产力的投放系统。 思路分析投放是什么?举例来说,往城市广场的一块广告牌上在不同时段不同场景下更换广告画就是一种投放,当然互联网技术带来了人的维度,不同用户看到的广告画可能也是不一样的。我们来看下这样一个系统应该包含哪些功能。 1、我们把“城市广场上的那块广告牌”叫资源位,那么需要一个服务端接口来获取需要透出的素材。2、不同资源位需要透出的素材格式可能是不一样的,可能是banner,可能是feeds,可能是运营自定义的手填数据,可能是任何合理的数据结构。3、同一个资源位,不同时段,针对不同平台、不同人群,透出的素材可能是不一样的,那么就需要有一个服务来在一堆素材中筛选出适合资源位的内容。在资源位命中了多个素材的时候,还需要有一些机制来裁决出最终透出的那一个。 详细设计我们设计的投放系统扮演的是前端实体资源位和后端多种数据源之间的桥梁的角色。它负责从各个业务数据源中根据一定规则筛选出在特定资源位上需要透出的数据,基本的数据流如下图所示: 资源位所谓资源位,在我们这个体系内,是指前端页面上的实体坑位。是技术同学在产品开发中创建的。理所当然,资源位需要消费的数据结构是在开发阶段就确定了,比如banner、feeds或者结构非常灵活的手填数据等。 在我们这个体系里,我们用一个 schema 描述资源位需要消费的数据结构。 这个 schema 是用 json 描述的。技术同学在前端页面上开发实体资源位后,需要在我们的系统中创建对应的虚拟资源位,并通过一个图形化的 json schema 编辑器来定义这个资源位需要消费的数据结构 投放物料上述 schema 定义了一个资源位所需要消费的数据的格式。但是光有 schema 是不够的,因为资源位要消费的数据,而不是数据结构本身。在我们的系统中,我们用一个动态表单模块根据schema生成动态的表单,产品运营同学通过动态表单生产的数据,我们称之为投放物料。资源位消费的就是投放物料。 对于一些手填数据,表单直接产生的数据就是资源位可用的了。但是对于 Feeds 之类的,表单往往只能定义 Feeds 的一些诸如选品等特征字段。对于这类特殊类型的数据源,服务端就不能简单的直接返回数据了,需要根据这些特征字段,做一些数据查询和数据解析工作,再返回给前端一个完整规范的数据。 投放单元前述文章说到,同一个banner,可能对新用户投放的是红包,对年轻男孩子投放的是手机数码内容,对年轻女孩子投放的是美妆服饰。我们把这个连接了资源位、投放物料与多个投放因子的桥梁叫做投放单元。 那么投放单元需要有多少个投放因子呢?其实是视业务而定的,我们认为基础的投放因为应该包含 投放时段、投放人群、投放平台、投放AB配置等。 当资源位向投放系统发起请求拉取数据时,投放系统在这个资源位上挂载的所有投放单元中根据投放因子筛选出命中的投放单元,最后将命中的投放单元上挂载的投放物料返回给前端的投放资源位。当命中了多个投放单元时,需要有些方法来裁决出最终胜出的那一个。这个方法简单点做,可以在投放单元中配一个权重,筛选时最后选择权重高的那个,也可以引入算法决策,根据投放的 ctr 数据做排序。 投放计划投放计划是产品运营对多个资源位管理形式。简单来说,一个投放计划下,可以挂载多个关联的资源位。试想一下,一次大促活动可能涉及到几十个资源位的投放,将这些资源位组织到同一个投放计划中进行管理,可以更加方便操作以及查看投放效果。 端侧接入对于前端来说,我们希望通过提供一个封装的npm包,通过简单调用,传入resourceId(资源位ID) 即可获取数据。 这种调用方式对业务调用方来说是比较优雅的,但是对页面性能来说却是不省心的。因为一个页面往往由很多个资源位组成,每个资源位单独发起请求就会形成大量的并发请求,不仅页面性能会降低,还会对服务器产生比较大的qps压力。 针对这种情况,我们做了一个小优化。服务端提供一个批量查询的接口,前端SDK内部,每10ms 对模块的请求调用做一次聚合,将单个资源位的数据获取转化成批量的查询。负面影响是对部分资源位的数据加载造成最大10ms的延时,优点是提升了页面整体的性能,有效减小了服务端QPS压力。 效果上述投放系统在我们的拉新业务实践中run得非常好,已为闲鱼应用内的数百个资源位提供投放能力支持,每天服务数以千万记的闲鱼用户。既实现了资源位的精细化投放,提高了单个资源位的利用率,又赋能运营更自由地进行各种拉新投放实验,减小试错成本,还减少了技术同学频繁参与运营实验改造的开发工作量,解放了技术同学的生产力。 总结上述文章介绍了一个简易的投放系统的设计思路,本质上是一个连接前端实体资源位和服务端多种数据源的桥梁的设计。 其中有很多能力是依赖了团队内部其它同学努力的成果,比如:1、描述资源位数据结构的 json schema如何设计2、根据json schema动态生成的表单怎么实现3、人群校验的服务和能力4、AB测试的能力5、feeds 的选品服务4、个性化动态banner能力 还有很多可以优化的点,比如数据回流如何做得更好,怎样引入算法能力对策略筛选进行优化。。。持续优化、持续为业务创造价值是我们一直坚持努力的方向。 本文作者:闲鱼技术-长玖阅读原文 本文为云栖社区原创内容,未经允许不得转载。

June 5, 2019 · 1 min · jiezi