思考题三：我会优先考虑Lambda架构，理由是更稳健。我的考虑点有三点：服务稳定性，成本和后续拓展性。由于个人所在的团队内部对于实时处理并不擅长，所以需要一个兜底方案来增大容错性；而成本而言，Lambda相较于Kappa成本更多的是在存储层面，而这部分多出来的存储（两份数据）是可接受的；最后，用户行为事件我已经采用了实时化链路，那么潜在的诉求便是用户信息/累计行为统计这块的内容，而这些内容的迭代速率并不高，所以在维护好开发文档的基础上去维护两套代码我认为是完全可行的。综上，在成熟对外的CDP服务上，我倾向于先采用保守方案Lambda架构然后再评估看是否演进为全实时链路。

思考题二：这里我遇到过类似的场景，当想使用RFM分层时发现用户的复购率是比较低的，原因是大部分用户购买的年卡或者半年卡；而另一方面在购买频次评估中，订阅6个月会员的人与年卡用户相比显然会得到更优秀的指标值但是运营和数据都认为这具有很强的欺骗性。所以，基于以上考虑我并没有购买频次纳入考量，而是取用了站点停留指标作为了Frequency的补充，即将用户粘性（站点停留）+用户付费情况相结合来做。在具体实现层面取用的是近30/90/180天的停留时长，之所以不选用天数或者启动次数则是这两个虽然一定程度能反映用户活跃特性但是不如时长直观。总结下来，算是奥卡姆剃刀的应用，即找寻核心指标先探索，后续再进行枝枝蔓蔓的迭代。

思考题一：用户的基础信息与身份判断，比如是否添加企业微信和是否是新用户适合实时标签，理由是这些涉及到营销测对用户的基本判断从而触发不同策略，当一个用户进入站点超过一小时或者更久才想起来触达在任何角度都是不可接受的；用户近期行为也适合实时标签，这表示营销运营对于用户近期行为更感兴趣那么对于实时性要求也会很高；对于用户累计行为统计适合离线标签，因为对于绝大部分用户来说缺1小时或者1天的数据不是那么致命。运营有时候会比较贪婪，会提出万一对于新用户或者处于新手保护期（这一部分用户在游戏或者其他任意平台中都是流失最快的那一批，需要悉心呵护）的用户累计数据离线算就不准了，那么这时候我会去引导运营销售一是将新老用户拆开来圈选，而对于新用户使用近期行为数据即可，正所谓鱼与熊掌不可兼得。