业界之中，类似于形而上的思考方式，加上KPI的压力，使得工作的目标被迷失，如同刻舟求剑的生搬硬套指标，最终成为数据的奴隶。显然，这是一种错误、并不可取的方法论。
比如留存率，这一反应用户转化效果的指标，被剥离出业务的范畴而被滥用，形成了知道数据是什么样，却不明白数据说明了什么意义，最终沦为汇报工具。
对比下面两种情况，可见一斑：
1.周留存率定义：以某一天为统计基期，在一周内，有任意一天存在使用记录，定义为周留存率；
2.7天留存率定义：同样的，以某一天为统计基期，在第七天有使用记录，定义为7天留存率。
两者的名称比较接近，但含义却相距玄远。在日常的应用中，更是大相径庭。然而，对于某些产品线丰富的公司而言，应用统一的SDK进行统计，用一套BI体系去测度所有产品的情况并不少见。因此，将两种本来各有应用场景的指标，人为的标准化成了一套内容。于是乎，有了对某类周期性使用的产品（比如财经股票类）7天留存率的考察，而忽视了周留存率。甚至用统计基期活跃用户来进行7天留存率的统计，要知道，某一天的活跃用户包含着新增与既往的留存用户，在无视既往留存用户生命周期的时刻，特别是在大力推广一阵子之后，活跃用户沉积了大量新晋的留存和质量尚不明晰的新增，如此考察活跃用户的7天留存率，除了能让汇报更好看些之外，实在想不出更有用的场景。
好吧，跳出这个逻辑，我们来探讨一下基于业务逻辑的数据模型。
首先，第一个问题是何谓模型？答案耳熟能详，即按照模型，我们能让这东西运转起来。那么产品的模型，自然就是产品价值假设实现的运转。
紧接着，第二个问题应运而生——价值假设如何运转，产品是给用户使用，那么实现用户转化为产品的用户，以及进一步转化为创造价值的用户（可以是付费，可以是创造内容），便是价值的运转。
继续，第三个问题是产品的运行状态，我们聊了价值如何运转，但运转速度的快慢也需要测度。于是这里有了复合增长（新增-流失），有了用户生命周期（延长的话，能够在给定的新增下，增加留存，进一步增加日活跃）等等；
最后，却是非常重要的是产品在价值实现的运行中，用户与对象是否的关系、结构是否良性，中心化是否明显。合理的产品结构，特别是web2.0之后的互联网产品，往往是去中心化的。然而，有些时候在KPI的压迫下，驱动运营的力量，让用户或者是对象强烈的中心化。

待续