标签:报表 tor tag 渠道 其他 监控 服务端 class target
Android平台做灰度再合适不过了。
找单一渠道投放特别版本出去是一个思路。另一个是做升级平台的改造,允许针对部分用户推送升级通知甚至版本强制升级。
无论哪种方法都需要做好版本管理工作,分配特别的版本号以示区别。
当然,既然是做灰度,数据监控(常规数据、新特性数据、主要业务数据)还是要做到位,该打的数据桩要打。
还有,灰度版最好有收回的能力,一般就是强制升级下一个正式版。自己做产品时也有类似的需求,下边是我的方案:)
基本的逻辑是两个版本的代码都打到app包里,然后在app端植入测试框架,用来控制显示哪个版本。
测试框架负责与服务器端api通信,由服务器端控制app上A/B版本的分布,可以实现指定的一组用户看到A版本,其它用户看到B版本。
服务端会有相应的报表来显示A/B版本的数量和效果对比。
最后可以由服务端的后台来控制,全部用户在线切换到A或者B版本~
所以这个也可以用来做灰度发布 :)
另外由于打进去两个版本的代码,app的包体积会大一点(这和功能变化多少有关)
iOS:官方的测试平台有Testflight,已经被苹果收购,但是整个内测用户邀请的方法流程还是没有打通,邀请用户成本比较高,是通过添加用户邮箱的方式,收到邀请邮件后还需要用户按步骤下载tf,下载应用等,没有一套教学视频普通用户还是难以接受。但非常适合在新产品发布前使用一些运营手段去建立这个用户群。用户一旦完成第一次操作,以后更新就像appstore一样简单。对开发者来说,操作也是和appstore一样的。比较方便。
且一个公司有多款产品的话,使用这个成本也会稍低一些,不过最大的问题还是灰度的用户量,和后期用户的消亡管理和扩充
还有一个是如果有打不同的iOS渠道包(除了appstore还有其他越狱渠道)或者其他tag的话,也可以通过升级配置来指定灰度发布。
标签:报表 tor tag 渠道 其他 监控 服务端 class target
原文地址:http://www.cnblogs.com/strinkbug/p/7078851.html