产品的数据沉淀

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

data

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

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

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

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

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

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

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

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

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

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

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

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

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

来源:简书

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. @有道云笔记收藏

    回复
加载中