產品的數據沉淀

1 評論 14635 瀏覽 7 收藏 7 分鐘

一個產品從出生到消亡的整個生命周期中會有幾個關鍵的角色出現。產品經理、產品運營、產品實施、產品運維,用戶;前四種角色所做的事情都是為用戶服務的。

對于用戶來說好的產品是用戶體驗或者有新穎的立題等;對于產品的生產方來說數據的沉淀才是最重要的目的。有了可以成規模的數據,就可以用來建模,分析用戶行為,發掘目標客戶并進行靶向營銷,實在不濟,還可以將數據出售。

產品經理是產品出生時最重要的角色,從原型設計到產品上線時,他起到的作用是關鍵性的。產品從原型到落地則是產品實施的主責。上線前期和上線之后的 產品推廣是產品運營的主責。產品運維主要是系統層面上的運維,類似于倉庫管理員,只有他可以登錄生產環境,查看日志,做產品更新之類的。

一個產品能不能吸引用戶看產品經理,一個產品能不能生存看產品運營,一個產品能不能有很強的后坐力看產品實施。產品實施是數據積累的重要一環,因為 此時涉及到系統架構的搭建以及數據庫表結構的設計,系統架構使用的是否優秀會影響產品更新的便捷性;而數據庫表結構的設計,則會影響到數據積累。

數據庫所存儲的數據應該包含,業務生成到終結整個流程中所產生的所有數據,以及關鍵狀態遷移的時間點。同時應該全流程可追溯,并且可以不用他復雜的嵌套就可以查詢到自己想要的信息。

以網購下單為例做一下簡單說明,訂單狀態包括(未支付,已取消,已支付,已退款【只退款】,已發貨,已收貨,已退貨,已退款【退貨退款】)。不同的模式會有不同的訂單狀態,這里只討論單一訂單的情況,不涉及組合訂單等情況。

訂單的狀態的變化涉及到相關數據的變更。以唯品會的模式為例:
1、在商品為“未支付”狀態時,就虛占庫存,20分鐘內如果沒有變成“已支付”,系統會恢復庫存,此時此訂單變為“已取消”;這段時間產生的數據并未形成真實訂單。
2、 真實訂單的生成是“已支付”狀態為切點的。已支付時扣減庫存,已支付但未發貨時,可以發起退款行為,退款完結時會變成已退款【只退款】。支付完成后,賣家 發貨此時變成已發貨。貨物到達買家手中時變成已收貨。已收貨在可發生退貨時間范圍內可以發起退貨行為,退貨完結時會變成已退款【退貨退款】。

第一點中的數據都是流水數據,此時并未發生真實的商品交易。但這樣的流水數據對平臺來說依然是有用的??梢愿鶕@些流水中所涉及到的產品對客戶做喜好分析。

第二點中的數據都是真實交易的數據。從付了錢那刻起就是真正的交易行為?!耙阎Ц丁睍r,買方賬戶會流出資金,賣方賬戶會流入資金,此時會產生資金交 易流水;“已發貨”時,賣方的商品會出庫,會產生出入庫流水,物流公司會產生物流信息;“已退款”時,買賣雙方的資金賬戶會流入和流出資金,會產生資金交 易流水;“已退貨”時,會產生物流信息數據。

“資金交易流水”,“商品出入庫流水”,“物流信息數據”都是伴隨著訂單產生的。可以從側面佐證交易的真實性。唯品會的模式中,是自建倉庫。加上巡 核庫基本可以保證交易的真實性。淘寶的倉庫不在自己手上,沒有真實的商品出入庫流水數據,所以會存在造假的情況。淘寶收集到的數據,在某些領域并不存在分 析的價值。如果跨領域的平臺間合作時,唯品會的數據更有價值。

一個真實的訂單數據,是可以根據訂單編號追溯到“資金交易流水”,“商品出入庫流水”,“物流信息數據”的。這些數據的數據源頭都是訂單,所以應該 可以根據訂單編號直接查詢出這些數據。譬如說我要查商品出入庫流水數據,先根據訂單號查出商品編號,和倉庫編號,發貨時間,載根據庫存編號,商品編號,和 發貨時間查詢出出庫流水。這樣的設計就是失敗的,而且無法避免并發的情況。還有一個關鍵點就是狀態遷移時需要蓋時間戳。這些時間對于一些指標分析是很關鍵 的尤其是效率類的指標。

數據的產生一定會存在源頭數據、過程數據、結果數據。這三種數據之間一定是需要一線串起來的。給這串數據打個標簽,可以根據這個標簽查詢出所有的相關數據。

最近在跟某個電商平臺做數據共享,其數據結構混亂,想要的數據沒有同時還有有些設計反人類思維,如數量*單價!=總金額。有感而發。

來源:簡書

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!