闲鱼玩法平台系列文章——双11实操篇-阿里云开发者社区

开发者社区> 闲鱼技术> 正文
登录阅读全文

闲鱼玩法平台系列文章——双11实操篇

简介: 你的就是我的,我的还是我的~

背景

  营销玩法是电商行业进行商品促销和用户增长的重要手段,上一篇中介绍了闲鱼的玩法平台——多啦A梦,本篇将介绍在该系统上承接的玩法。闲鱼作为闲置循环工厂也参与了大促,为了让更多闲置在闲鱼游起来,在商品侧设计了《转卖抽奖》活动玩法;为了能让更多用户在闲鱼玩起来,在用户侧设计了《摇钱树》活动玩法。下面详细介绍《转卖抽奖》和《摇钱树》的活动玩法以及技术实现上注意的细节。

转卖抽奖

  商品是闲鱼的必要组成部分,为了让用户可以在大促期间买买买,所以闲鱼在节前设计了转卖抽奖的活动帮助用户舍断离,具体详细玩法如下:

玩法介绍

  用户发布商品后,将会获取一次抽奖机会,抽奖机会每天最多可以获取50次,活动期间抽奖机会可以累积,活动结束后抽奖机会清零;当用户拥有抽奖机会后即可抽奖,每次抽奖将会消耗抽奖机会,当抽奖机会为零时则不可以抽奖;每次抽奖用户将有概率获得支付宝现金红包和双十一店铺优惠券。
  用户可以通过在闲鱼内发布商品或是在淘宝的闲鱼小程序中一键转卖商品参与活动,商品发布后如果用户获取到了抽奖机会,则在闲鱼端内弹出POP提醒用户获取到一次抽奖机会,并引导用户跳转到活动落地页,在落地页用户可以参与抽奖。
|center

技术方案

  转卖抽奖活动从实现上分为两个活动,一个是完成发布获取抽奖机会,另外是消耗抽奖机会进行概率抽奖。进一步抽象两个活动可以发现他们对应一个共同的业务模型:前置条件->抽奖->奖励。对于发布获取抽奖机会来说,前置条件是发布,抽奖是领取抽奖机会,奖励就是抽奖机会;对于消耗抽奖机会进行概率抽奖来说,前置条件是抽奖机会,抽奖是进行概率抽奖,奖励是红包或是优惠券。所以这个活动的底层实现方案使用的是闲鱼的业务玩法平台哆啦A梦,下面详细介绍着两个活动的技术实现。
  发布后获取抽奖机会,首先需要感知到用户的发布行为,在实现上可以通过硬编码的方式,侵入到商品发布过程中但是这种方案显然过耦合,本文采用的是OMEGA事件采集能力,该方案可以无侵入的感知用户的发布行为,同时可以在采集过程中定制逻辑例如对特定类目、标题进行筛选。用户发布后需要累计抽奖机会,在本方案中抽奖机会累计使用的是积分系统实现,但是要注意在业务上要做好幂等防止一次发布多次累计,同时每个用户每天最多获取50次机会,所以在给单用户发放机会过程中要进行单用户的全局锁,防止发放超出50次。
|center
  消耗抽奖机会进行概率抽奖,用户在进行抽奖前防止并发操作造成抽奖次数过多消耗,所以用户进行抽奖操作时首先进行并发控制,然后消耗抽奖机会再进行最终的抽奖,奖品发放是按照概率进行发放,在概率设计中价值越高的奖品中奖的概率越低,同时考虑活动效果和保证用户参与感,需要保证活动期间都有可抽取的奖品,这就要考虑奖品的发放排期,按照小时级别和天级别对奖品进行排期,保证奖品在活动中均匀分布。在活动期间对于按照价值对奖品进行分组,在高价值组中限制用户的中奖次数,保证高价值奖励能让更多的用户获取。
|center
关键技术点:
1.用户公平性,活动初期活动中的现金红包按照每小时生效进行排期,通过活动监控发现整点参与量都会有一个峰值,分析发现这些用户掌握了红包生效的规律,整点来参与活动刷红包导致红包快速耗光,这对于大多数用户来说是不公平的,所以技术侧做了一个小时内随机多次生效红包,保证用户参与的公平性。
2.疲劳度,控制用户单位时间内可领取的次数,疲劳度的设计利用的是Tair分布式缓存的Incr自增能力,通过设计业务和key的映射实现对用户领取疲劳度的控制,但是在分业务进行疲劳度控制之上建议设计一个基于用户维度的总疲劳度,这样保证在业务疲劳度控制失效时,由用户疲劳度做兜底的控制。

摇钱树

  经过双十一疯狂的剁手后闲鱼帮你来回血,在用户侧闲鱼设计了摇钱树活动,通过用户裂变的玩法对闲鱼用户进行拉新拉活,具体详细玩法如下:

玩法介绍

  用户首先进入活动页面,可以领取一颗摇钱树,在领取摇钱树时会为每个用户分配一个随机的初始现金金额。领取摇钱树后可以通过分享按钮把自己的摇钱树分享给好友,好友通过分享口令进入闲鱼后,会帮助用户进行摇树,摇树成功后双方都可获取现金奖励。但一个用户每天最多只能成功邀请4个好友为自己摇树,超出后不计数,同时每天每人只能帮别人摇树一次。具体如下所示:
|center
用户可以在闲鱼端内和手淘投放的Banner进入到活动页面,开启自己的摇钱树后可以通过淘口令、微信、当面扫一扫等方式把自己的摇钱树分享给好友,累计到一元即可提现。

技术方案

  摇钱树活动是一种典型的用户裂变玩法,从技术上看可以分为三个部分,第一部分是领取自己的摇钱树获取奖励,第二部分是自己帮助好友摇树获取奖励,第三部分邀请好友为自己摇树获取奖励。进一步抽象三个部分其实对应一个业务模型:关系系统->领取奖励->获取奖励。在第一部分中关系系统中存储的是自己和自己的映射关系,在第二部分中关系系统存储的是自己和好友的映射关系,在第三部分中存储的是好友和自己的映射关系,同时在第二部分和第三部分两个的关系是同时存在的。所以整个实现方案如下所示:
|center
本方案中领取奖励的部分是基于多啦A梦和拉菲已有的能力实现的,在设计关系系统时存储采用的是基lindorm(HBase)设计,主态和客态关系存在一个表中,通过对Key的设计满足查询的功能和性能要求。当然也可以基于mysql的数据模型设计,对于主态和客态关系建立两个表,分别以主态和客态的用户ID作为分库分表设计;之所以没有采用mysql的数据模型是因为需要维护两个表的事务性和一致性成本过高。
  在整个方案设计上主要关注的点有两个,第一个是资损,在活动中一个用户只能领取1次摇钱树,每天只能帮好友摇树1次,每个用户每天最多可以成功邀请4个用户,这些规则即是玩法规则也是资损易发点,在本文中采用了实时对账和领取限制实现对资损现象的监控和兜底保证,保障无资损是技术侧底线在方案设计上要优先考虑。第二个是并发控制,在活动中用户邀请多个好友为自己摇树,但是一天只能成功邀请4位,所以要做好邀请人侧的并发控制防止出现超过4人的邀请。
关键技术点:
1.幂等性,幂等能力是每个营销活动必要的能力,常用的方法有利用数据库乐观锁、Tair(redis)分布式缓存、zookeeper等方案实现分布式全局锁,本文中采用的是Tair缓存分布式锁方案。
2.对账校验,对账是营销的一个必要环节,可以通过数据库层面的对账实现数据校验,也可通过业务上的对账进行校验领奖资格,本文采用的是业务上的对账,通过接受领奖后的消息,反查领取用户的资格实现实时的对账能力。

总结

  限于篇幅的限制本文主要介绍了相关的玩法以及在设计玩法过程中需要注意的技术点,后面会对每个技术点的实现单独进行介绍。目前多啦A梦已经在功能上实现了组件化,例如疲劳度校验、并发控制、人群校验的常用能力,这些能力会极大的方便新玩法的开发,未来除了在实现功能组件化以外会逐步实现玩法的组件化,这样运营同学可以直接利用玩法组件拼装自己的业务玩法。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里巴巴集团-闲鱼技术团队官方账号 简历投递:guicai.gxy@alibaba-inc.com

官方博客
开源工具
English