开发任何功能，数据打点（或者叫埋点）都是必须的，是非常重要的。没加打点，就好比是服务上线了却没有监控，这就没有指标数据参考了呀。
打点主要跟客户端密切相关，一般都是在客户端打点，将数据采集上报到大数据那边。服务端的打点也有，但相对较少。不过，为了后续统计更方便，必要的服务端打点还是不能少的。
这一次，除了用户的行为，已经路径（点到哪一个页面了）等等这些数据外，其它绝大部分产品需要的统计都可以从数据库里查出来。比如，每天新增用户多少，会员转化率多少，每日时长，次日留存，微信过来的有多少，发了多少体验卡，AB哪个效果好一点等等。
8. 成长计划之弹窗
每个任务开始和结束的时候有弹窗，计划完成或过期有弹窗。最初设计的时候，弹窗是单独的，与某个计划没有关系，每次进首页该弹什么窗都是根据计划完成情况计算出来的。后来，随着业务越来越复杂，弹窗也有点乱了。比如，体验卡的弹窗和勋章的弹窗就不一样，翻倍任务的弹窗和常规任务的弹窗又不一样。以至于后来，什么时候弹什么窗这部分逻辑变得越来越复杂。
后来，我想了一下，如果最好还是把弹窗与任务绑定在一起比较好。当前是什么任务就弹什么窗，给什么奖励，多么清晰，多个简洁明了。
9. 结构优化
我后来想到的是，将弹窗和奖励都和任务进行绑定，而任务之间又是层层递进的关系。
就像，拦截器和过滤器。类似的还有，js中的事件冒泡，设计模式中的责任链模式
于是，主要的关联关系就变成了：计划之下是内容和任务，任务之下是奖励和弹窗，APP和微信消息提醒是独立的。
于是，按照我的设想，一个计划的生命周期应该是这样的：
任务有任务类型：一次性任务和周期性任务。所谓一次性任务就是指完成就进入下一个任务，比如常规任务；周期性任务指的是每天任务都从新开始，直到任务完成，比如翻倍任务就是这样的。
任务之间又内在的关联关系，就像一个链表一样，要知道它的上一个任务和下一个任务都是谁。
有了这种链表结构，那么想增加一个任务或者删除一个任务就变得轻而易举，如此巧妙灵活的设计，我可真是个小机灵鬼
再回到这次的翻倍任务上来，这种任务跟常规任务不一样，奖励什么的运行方式乃至弹窗都不一样，简直要疯了。如果我们的任务是这种链表结构，那么，请随便插入。
所有任务完成以后的奖励挂在最后一任务的奖励上。
10. 降本增效
为什么要用SSDB呢？最主要的原因是：降本增效
我就提几点吧：
成本比Redis低
完美支持Redis常用的数据类型及操作
容量大，久经考验
性能与Redis不相上下
从Redis迁移至SSDB也非常容易
文档在这里：
https://github.com/ideawu/ssdb
具体的，看文档吧，我就不多说了，这里直接引用了
11. 其它
曾经截了几张接口优化过程中的截图，一并放上来吧，留着也没用，以后也没有机会了