筆者從平臺數據對接出發,一步步梳理了產品推進的路線圖:確認業務數據需求、確認關鍵技術方案、完善產品需求文檔,展示了數據從獲取到展示的流轉過程 。
文章插圖
業務背景:平臺A是傳播裂變和傳播數據監控工具 , 平臺B是電商工具,雙方是兩個獨立系統,兩套人馬 ?,F在平臺A開始發力做電商生意,所以使用平臺B 。
用戶的體驗流程路徑:用戶經由平臺A的傳播頁,跳轉到平臺B的落地頁 , 并在落地頁完成瀏覽、加購、下單、支付等行為 。
【平臺數據API對接 api是什么意思】現在的需求是:用戶(可細分)從傳播頁進入到落地頁,轉化效果如何?這也就是說,用戶在進入落地頁后,也能知道用戶是傳播頁中的哪一個人 。
針對這樣的背景和需求,談談推進過程以及產品需求文檔如何寫 。
Step1:確認業務數據需求由于處于試驗階段 , 滿足如下業務數據需求應該就已足夠:
建立傳播-轉化行為數據漏斗,即:
- 訪問傳播頁的人數;
- 訪問了傳播頁的人中訪問了落地頁的人數/占比;
- 訪問了落地頁的人中加購的人數/占比;
- 加購的人中下單的人數/占比;
- 下單的人中支付的人數/占比 。
可以從更多維度分析數據(有平臺A維度,也有平臺B維度),包括:渠道維度、商品維度、歸屬地維度等 。例如:某渠道用戶,支付購買某商品SKU的有多少?某渠道、某商品SKU都是維度 。
Step2:確認關鍵技術方案早期就要和技術討論,在這個項目中,關鍵是雙方平臺用戶如何匹配的問題 。
最后確定的方案是:用戶從平臺A跳轉到平臺B時,平臺A傳給平臺B該用戶的關鍵參數,如帶有參數的用戶在平臺B進行了目標行為,就由平臺B調用接口,將數據回傳給平臺A 。
需要或者說可以采用該方案是兩個因素決定的:
- 平臺A和平臺B是獨立系統;
- 平臺A和平臺B可為對方提供能力(說明開發團隊是可交流的) 。
Step3:完善產品需求文檔到這一步,開發通常需要一個數據需求文檔,以此為依據,進行接口開發 。
數據類的產品需求文檔最重要的是寫清楚事件-屬性-值 。
什么是事件-屬性-值?
各類第三方數據統計和分析平臺的產品文檔都有比較清晰的說明,引自某平臺的解釋:
- 事件:用戶在產品上的行為
- 屬性:描述事件的維度
- 值:屬性的內容
- 事件:支付
- 屬性:用戶ID、渠道ID、商品SKU
- 值:某
按著上述思路,整理出來的表格如下:
文章插圖
數據需求文檔 , 使用表格展現是最好的 。
Step4:后續
- 在接口開發環節 , 還要和開發商討數據同步頻次和異常等問題 。
- 在數據測試環節,關鍵是要看每個事件,不同屬性是否都能有值返回,且是否正確 。
- 在數據獲取環節,開發需要根據數據需求,結構化處理通過API獲得數據,需要考慮是否需要算出數據結果 , 甚至需要展示,還是只需要先結構化處理好數據即可 。
總結“麻雀雖?。?五臟俱全”——通過一個小項目可以了解到數據從獲取到展示的流轉過程 。
理解事件-屬性-值的含義,對數據埋點 , 使用第三方數據統計和分析平臺都很有幫助 。
本文由 @KASALEE 原創發布于人人都是產品經理,未經作者許可,禁止轉載 。
題圖來自Unsplash,基于CC0協議 。
- 118平臺是什么軟件
- 如何通俗理解API api是什么意思
- 智慧生活是干什么用的
- 10694是什么短信平臺
- flic是什么平臺
- 啟用wapl是什么意思
- 萬物心選是什么平臺
- 醫保收費系統_醫保通醫保結算收費平臺安裝需要多少位系統
- 蜂享店是什么平臺
- 不能與打印機通訊什么原因
