做到可控

  1. 需要显示总数的活动,要注意总数显示多少,以一个什么样程度增长是符合预期的。
  2. 要有一个固定的曝光位置,这个是最基本的。
  3. 运营活动目标UV,目标获奖人数。可能多,也可能少。要防止完成用户过多,不可控,通过一些关键资源来控制,比如集卡活动中的稀有卡个数。用户过少,达不到预期。分为两部分:1. 没达到增长指标 2. 没达到奖励用户数预期 没达到增长指标,可能是活动入口曝光不够,也可能是活动不够有吸引力/可玩性。 没达到奖励用户预期数,可能是因为对用户数预期过高,或者是获取奖励的任务设置太难。
  4. 稀有卡控制和实际总数之间会有出入,不能预设所有用户都是参与度非常高的用户,可能有些用户获取到稀有卡,就不继续参与活动了,也有可能。
  5. 一般来说,即使达不到运营预算人数,也不会给每个用户更多的钱。因为ARPU不能过高,要算账的。所以,其实除了极少数活动,大多数活动,平均到每个人都上也就几块钱,要不然,获客成本过高了。
  6. 运营经费是固定的。一定要严格控制运营经费不能超,否则,没办法向老板交代的。
  7. 一般一个活动开始之后,只能通过调节曝光资源或者发push之类的来提升用户使用,需要改配置的地方,主要就是控制预算。

数据存在哪里

活动按照时间分,可以分为两种:短期活动和长期活动。

  • 短期活动:项目型活动。一般一周左右,最长不会超过两周。对于这种活动,数据一般使用redis之类的内存存储就好(当然也要注意数据持久化),速度快。
  • 长期活动:运营型活动。一般为几个月以上,甚至一年两年。需要用户长期参与的活动,需要将数据存档到mysql之类的数据库中。在过程中可能会有一些新增的历史数据分析需求,最重要的用户参与数据最好能够持久化存储。当然,一些短时间有效的数据,存放缓存即可。

重要参数配置化

活动过程中,一些关键参数很有可能会发生变化。
比如抽奖活动的抽奖概率,会根据活动数据进行变化,因此,最好做成可配置的。

流量预期

要根据运营或者产品提供的目标数据,结合自己的经验,预估QPS及对存储和第三方服务的要求。活动的流量具有波动大,峰值高的特点。尤其是一些关键时间点,要注意,必要情况下使用MQ进行削峰,或者使用熔断器拒绝部分请求。当然这些值,一般来说都是吃一堑长一智的,具体多少值会出问题,只有出了问题才能知道。所以,最好是有全链路压测。但是全链路压测,
对很多公司和团队来说,门槛太高,而且投入产比低。因此,可快速扩容缩容就显得尤为重要。

任何人想要转载我的文章,无需和我联系,请转载后把链接私信贴给我,谢谢!

白羊沈歌
15 声望0 粉丝