浅谈用户价值模型

  某天被某叫去谈了某些事情.
  大体是什么打算云云.
  然后又说到了某部门以后要做的计划之类的.
  其中一个是所谓用户价值模型.

  听到这个词其实不只一次了.
 
  早前也想过,但没定论以及具体的实践还不好着手.

  最简单的衡量标准莫过于ARPU了.
  
  ARPU的问题在于,对于social game或者类似的用户流失很常见的领域来说,这提取有效用户数.
  当然,DAU/DMU可以一定程度解决这个问题.
  但即便以这两个为基础,还是避免不了每个月可能N%的用户是属于"新陈代谢"的.

  当然,如果用户的付费行为跟游戏时间经历无关,上面这个问题意义不大.

  所以,对于要不要修正用户基数的计算方式以使ARPU更精确,这需要看下首次用户的首次付费时间跟注册时间的关系分布.

  ARPU的另一个问题是,revenue的取舍.
  取所有历史数据当然最简单,但也比较没意义.
  因为如果这样的话,对于如果实际revenue衰减的话,可能在ARPU上反映不出来.
  
  所以通常的做法都是采用一定周期内的revenue来计算.
  
  这样的话,周期长短选择就需要些考虑了.
  毕竟,这个个消费周期的长短有关.
  比如一件商品可能固定在一个时期内没有多少销售,那么将这段时期作为一个独立计算周期来考虑的话,意义就不是很明显了.

  所以,ARPU的计算周期也应该是跟消费方式有所联系的.

  但是,很多时候,消费行为是无固定模式的.
  如何解决呢?

  其实换个角度,借鉴下AMPU的某些思路也许就可以解决.

  ARPU的目的是衡量用户revenue的平均水平.
  换句话说,对于包含付费和非付费用户的系统来说,其实讲述的就是将付费用户的revenue"分配"到非付费用户身上.
  于是,通过对于ARPU的计算就归结到:
  对于任意时间段t,可以有total revenue Revenue(t).
  而根据付费记录历史和用户创建/活跃时间,可以得到一个比较准确的T时段内的paid比率P.
  即ARPU=Revenue(t) * Paid

  从这个指标等式的两个因素可以看出,
  如果能维持一个相对固定的付费比的话,提高单价是简单快捷的提高ARPU的方式.

  当然,提高单价也许可能会影响付费比.
 
  但如果用户对价格的sensitive是可以衡量的话.
  假设销售价格p跟数量Amount的关系为Amount=Trade(p),
  价格对付费比Paid的影响为Paid=Sensitive(p)

  于是ARPU就可以修正为:
  ARPU=(Amount*p)*Sensitive(p) = Trade(p)*p*Sensitive(p) 
  
  从这里,如果有数据表明付费行为跟商品定价有关的话.
  那么可以很直接地从上面等式可以有
  ARPU=Function(p)
  即ARPU跟价格直接相关.

  那么Function应该是大致是怎样一条曲线呢?
  考虑
  Amount=Trade(p),价格和数量关系.以及 
  Paid=Sensitive(p),价格对付费欲望的影响.

  假设,对于这两个等式的认识都是常识性的.即价格提高消费数量增多,消费欲望降低.
  于是曲线Function(p)的趋势就取决于,是Sensitive占主导呢还是Trade占主导.

  对于Sensitive的取样,也许可以对销售物品价格和付费人数的关系做个计算.
  对于Trade的取样,也许可以对销售品价格和付费次数的关系做个计算.

  但最终ARPU不能解决的问题是,它支持纯粹考虑直接的revenue.
  它没办法衡量非付费用户,甚至付费用户本身的价值.
  它只是一个平均观测.

  那么,如何建立一个比较全面的用户价值参考呢?
  对于付费用户,相对简单,可以直接对其群体套用ARPU.
  但是对于非付费用户也许就要花些时间.

  比如,一个用户也许不直接付费,但是通过它的渠道过来的可能付费用户占了相当一部分.
  但是因为它没有直接的付费计算,所以价值被低估了.
  
  再比如,有些用户也许不付费,渠道也不怎么样,但是可能扩散性很好,或者活跃度很高,对于这类用户又该如何评价呢?

  这个其实可以参考adsense或者之类的思路.
  付费用户的每一次付费行为其实就算是一次点击,于是,对于其他非付费用户来说,就是参考content provider,或者campaign什么的.

  但是问题还是在于,如何把付费用户的付费行为转换为非付费用户的"广告分成".

  换句话说,就是付费行为跟非付费用户的相关度有多大?
  这么衡量这个相关度?

  一个简单但未必有效的方案就是.
  加入某个付费用户有n个好友,一次付费m的话,那么可以简单的对每个好友增减n/m的rank.
  这样的话,理论上,每个用户都会得到相应的价值rank.
  
  这样的话,一个问题就是,对于有很多付费好友的用户来说,它的rank很高.
  但它未必是有价值的用户.
  比如,它可以是故意加很多付费用户.
  或者它是一个沉默/不活跃/流失用户.
  这时候,即便它没有任何行动,rank也可能很高.

  如何过滤掉和谐噪音呢?

  可以考虑加入活跃度和交互亲密性来过滤掉.
  即在上面的rank的基础上,乘以有活跃度和亲密性生成的weight.

  随着而来的一个问题是,活跃度和亲密性如何量化.
  还有就是,能否把两者合并一下,变成一个普适的参考量.

  这是一个问题.
  
  对于合并普适的问题比较容易解决,可以转化为对行为的rank.
  参考下诸如豆瓣等的recommended就有大概模式.
  即,每一个行为都会得到一个rank.

  但,
  但是,
  如何定量?

  回到那个问题,要过滤的是那些实际跟付费用户没关系的人的rank.
  那么,什么是有关系的人呢?
   
  1.有相互访问行为.
  2.共同好友有显著重叠.

  这样的话,就简单多了.
  一共同好友所占的比例为基数,然后通过对访问行为通过类似facebook的like算法可以得到一个应该比较合理的weight,于是,算rank和用户价值就很直接明了了.

  一个有趣的问题就是共同好友衍生出来的其他一些东西.
  诸如social graph,不同游戏里同一帮好友的付费情况,交互情况等.
  以及,到底这个整个用户的graph是"联通"的还是..."移动"的...
  即,所谓的"6度"具体到某个特定群体是怎样的展现..

  诸如此类,不一而述  

从开心农场谈起

  传腾讯买断开心农场.

  想想其实很符合腾讯既有的策略.

  毕竟,QQ之于腾讯已经发展到了windows之于微软的地步.
  而腾讯也很明显地,在发展的轨迹上跟微软是相似的.

  平台为王的战略.

  在陆续推出了几个好的软件和服务之后.
  或者说在抄了几个号的软件和服务之后,QQ的平台做得更大了.

  将现有的QQ用户导一部分到新的应用中,于是,这些应用从一开始就有了高的人气.
  而人的猎奇心理也会带领相当部分QQ之外的人参与到这个应用中来.
  而这个应用如果恰好又是跟QQ绑定的话,那么,腾讯的抄,其实是将其他类型的非QQ用户"抄"了过来.

  于是,只要腾讯能做出来,就能将任何类型的用户整合进来,成为腾讯如何服务的用户资源储备.

  这是一个良性的异常完美的循环.
  QQ用户为QQ新产品提供源源不断的用户群.
  
  某种程度上说,只要腾讯做一个产品,就不愁没人用,不愁没有用户.

  这便是平台的魅力.

  所以,基于这一点,腾讯买断5分钟的开心农场很正常.
  而且,有数据页显示开心农场的相当部分盈利来源于QQ农场.

  说白了QQ农场的火爆,一个方面是产品设计确实完美,一方面也是有QQ用户这个几乎取之不尽用之不竭的用户来源.
  因此,某个程度上来说,是QQ在养着农场,是QQ掀起全国的偷采风潮.
  
  这样,腾讯自然会打小算盘.
  毕竟,按照现在的趋势,只要运营农场就必然有源源不断的钱收,与其在这个由自己制造的风潮里让别人获益,不如自己独吞.
  所以,买断农场也是可以理解的.
  关键在于农场还能火多久.

  想想农场为什么能火.
  
  农场在游戏的玩法上给了人两条路走.
  要么偷采,要么做老实农民.
  从表现上看,这是似乎是个很简单的游戏,偷采种菜.
  但是仔细想想,其实这是一个"开放"的游戏世界.

  想想一些经典游戏,尤其是RPG游戏的共同之处.
  那便是开放性.自由度.

  让尽可能多的人投入到游戏所设定的情景里,这便是RPG的精髓,也是所有游戏应该追求达到的目的.
  参与性,投入感,是游戏的首要准则.

  而农场显然用了一个大巧若拙的形式,达到了这个目的.
  想想偷菜对应的是什么.
  人性里的阴暗面.
  而种菜呢.

  没错,是人性里积极的一面.
  "劳动最光荣"
  通过劳动,可以得到各种各样的东西.

  可以说,种菜和偷菜,就人性来说,已经囊括了所有类型的用户.
 
  有时候,最复杂的东西就是最简单的东西.
  
  因为其简单,所以不确定因素便多.
  也就意味着结果也随着变得多样.

  WOW之所以受人推崇便在一其高自由度.
  而这一切都是受益于wow的"松散"性.
  没有过多的限制各种各样的东西,包括肢体动作伤害环境等.
  一切都有着很好的扩张性,极力模仿着现实世界.
  在物件的粒度上,尽可能地让所有东西都能够演算出来,而不是靠诸多的条件限制它.
  不像一些游戏,到了悬崖边却发现其实是掉不下去的.

  忽然想,其实所谓软件架构的灵活性,其实来源于需求的设计.
  明确的需求是建立可扩展软件的基础.

  因为需求的改变其实是不受限制或少收限制的.
  而软件,或者说代码,毕竟是成文的.
  改起来不是说说就完了的.

  或许这也是设计模式存在的理由.
  为了尽可能应付不同的需求变更所总结出来的best practice吧.