产品的数据沉淀

一个产品从出生到消亡的整个生命周期中会有几个关键的角色出现。产品经理、产品运营、产品实施、产品运维，用户；前四种角色所做的事情都是为用户服务的。

对于用户来说好的产品是用户体验或者有新颖的立题等；对于产品的生产方来说数据的沉淀才是最重要的目的。有了可以成规模的数据，就可以用来建模，分析用户行为，发掘目标客户并进行靶向营销，实在不济，还可以将数据出售。

产品经理是产品出生时最重要的角色，从原型设计到产品上线时，他起到的作用是关键性的。产品从原型到落地则是产品实施的主责。上线前期和上线之后的产品推广是产品运营的主责。产品运维主要是系统层面上的运维，类似于仓库管理员，只有他可以登录生产环境，查看日志，做产品更新之类的。

一个产品能不能吸引用户看产品经理，一个产品能不能生存看产品运营，一个产品能不能有很强的后坐力看产品实施。产品实施是数据积累的重要一环，因为此时涉及到系统架构的搭建以及数据库表结构的设计，系统架构使用的是否优秀会影响产品更新的便捷性；而数据库表结构的设计，则会影响到数据积累。

数据库所存储的数据应该包含，业务生成到终结整个流程中所产生的所有数据，以及关键状态迁移的时间点。同时应该全流程可追溯，并且可以不用他复杂的嵌套就可以查询到自己想要的信息。

以网购下单为例做一下简单说明，订单状态包括（未支付，已取消，已支付，已退款【只退款】，已发货，已收货，已退货，已退款【退货退款】）。不同的模式会有不同的订单状态，这里只讨论单一订单的情况，不涉及组合订单等情况。

订单的状态的变化涉及到相关数据的变更。以唯品会的模式为例：
1、在商品为“未支付”状态时，就虚占库存，20分钟内如果没有变成“已支付”，系统会恢复库存，此时此订单变为“已取消”；这段时间产生的数据并未形成真实订单。
2、真实订单的生成是“已支付”状态为切点的。已支付时扣减库存，已支付但未发货时，可以发起退款行为，退款完结时会变成已退款【只退款】。支付完成后，卖家发货此时变成已发货。货物到达买家手中时变成已收货。已收货在可发生退货时间范围内可以发起退货行为，退货完结时会变成已退款【退货退款】。

第一点中的数据都是流水数据，此时并未发生真实的商品交易。但这样的流水数据对平台来说依然是有用的。可以根据这些流水中所涉及到的产品对客户做喜好分析。

第二点中的数据都是真实交易的数据。从付了钱那刻起就是真正的交易行为。“已支付”时，买方账户会流出资金，卖方账户会流入资金，此时会产生资金交易流水；“已发货”时，卖方的商品会出库，会产生出入库流水，物流公司会产生物流信息；“已退款”时，买卖双方的资金账户会流入和流出资金，会产生资金交易流水；“已退货”时，会产生物流信息数据。

“资金交易流水”，“商品出入库流水”，“物流信息数据”都是伴随着订单产生的。可以从侧面佐证交易的真实性。唯品会的模式中，是自建仓库。加上巡核库基本可以保证交易的真实性。淘宝的仓库不在自己手上，没有真实的商品出入库流水数据，所以会存在造假的情况。淘宝收集到的数据，在某些领域并不存在分析的价值。如果跨领域的平台间合作时，唯品会的数据更有价值。

一个真实的订单数据，是可以根据订单编号追溯到“资金交易流水”，“商品出入库流水”，“物流信息数据”的。这些数据的数据源头都是订单，所以应该可以根据订单编号直接查询出这些数据。譬如说我要查商品出入库流水数据，先根据订单号查出商品编号，和仓库编号，发货时间，载根据库存编号，商品编号，和发货时间查询出出库流水。这样的设计就是失败的，而且无法避免并发的情况。还有一个关键点就是状态迁移时需要盖时间戳。这些时间对于一些指标分析是很关键的尤其是效率类的指标。

数据的产生一定会存在源头数据、过程数据、结果数据。这三种数据之间一定是需要一线串起来的。给这串数据打个标签，可以根据这个标签查询出所有的相关数据。

最近在跟某个电商平台做数据共享，其数据结构混乱，想要的数据没有同时还有有些设计反人类思维，如数量*单价！=总金额。有感而发。