筆者從平臺數據對接出發(fā)，一步步梳理了產品推進的路線圖：確認業(yè)務數據需求、確認關鍵技術方案、完善產品需求文檔，展示了數據從獲取到展示的流轉過程。

業(yè)務背景：平臺A是傳播裂變和傳播數據監(jiān)控工具，平臺B是電商工具，雙方是兩個獨立系統(tǒng)，兩套人馬。現(xiàn)在平臺A開始發(fā)力做電商生意，所以使用平臺B。

用戶的體驗流程路徑：用戶經由平臺A的傳播頁，跳轉到平臺B的落地頁，并在落地頁完成瀏覽、加購、下單、支付等行為。

現(xiàn)在的需求是：用戶（可細分）從傳播頁進入到落地頁，轉化效果如何？這也就是說，用戶在進入落地頁后，也能知道用戶是傳播頁中的哪一個人。

針對這樣的背景和需求，談談推進過程以及產品需求文檔如何寫。

Step1：確認業(yè)務數據需求

由于處于試驗階段，滿足如下業(yè)務數據需求應該就已足夠：

建立傳播-轉化行為數據漏斗，即：

1. 訪問傳播頁的人數；
2. 訪問了傳播頁的人中訪問了落地頁的人數/占比；
3. 訪問了落地頁的人中加購的人數/占比；
4. 加購的人中下單的人數/占比；
5. 下單的人中支付的人數/占比。

需要注意的是后續(xù)需要考慮，是否需要刨除反向行為的用戶，如加購后，又取消加購；下單后，又取消下單。

可以從更多維度分析數據（有平臺A維度，也有平臺B維度），包括：渠道維度、商品維度、歸屬地維度等。例如：某渠道用戶，支付購買某商品SKU的有多少？某渠道、某商品SKU都是維度。

Step2：確認關鍵技術方案

早期就要和技術討論，在這個項目中，關鍵是雙方平臺用戶如何匹配的問題。

最后確定的方案是：用戶從平臺A跳轉到平臺B時，平臺A傳給平臺B該用戶的關鍵參數，如帶有參數的用戶在平臺B進行了目標行為，就由平臺B調用接口，將數據回傳給平臺A。

需要或者說可以采用該方案是兩個因素決定的：

1. 平臺A和平臺B是獨立系統(tǒng)；
2. 平臺A和平臺B可為對方提供能力（說明開發(fā)團隊是可交流的）。

在這個項目中，還需要提前向平臺B獲取頁面路徑及行為數據字段等信息，以確認是否可以滿足業(yè)務數據需求。

Step3：完善產品需求文檔

到這一步，開發(fā)通常需要一個數據需求文檔，以此為依據，進行接口開發(fā)。

數據類的產品需求文檔最重要的是寫清楚事件-屬性-值。

什么是事件-屬性-值？

各類第三方數據統(tǒng)計和分析平臺的產品文檔都有比較清晰的說明，引自某平臺的解釋：

• 事件：用戶在產品上的行為
• 屬性：描述事件的維度
• 值：屬性的內容

可以再回想業(yè)務數據需求，比如：某渠道用戶，支付購買某商品SKU的有多少？

• 事件：支付
• 屬性：用戶ID、渠道ID、商品SKU
• 值：某

每次事件發(fā)生時，都將事件本身、事件屬性和值記錄下來（在這個項目場景里，是平臺B上報給平臺A），就能知道某個或多個屬性“有多少”。

按著上述思路，整理出來的表格如下：

數據需求文檔，使用表格展現(xiàn)是最好的。

Step4：后續(xù)

• 在接口開發(fā)環(huán)節(jié)，還要和開發(fā)商討數據同步頻次和異常等問題。
• 在數據測試環(huán)節(jié)，關鍵是要看每個事件，不同屬性是否都能有值返回，且是否正確。
• 在數據獲取環(huán)節(jié)，開發(fā)需要根據數據需求，結構化處理通過API獲得數據，需要考慮是否需要算出數據結果，甚至需要展示，還是只需要先結構化處理好數據即可。

總結

“麻雀雖小，五臟俱全”——通過一個小項目可以了解到數據從獲取到展示的流轉過程。

理解事件-屬性-值的含義，對數據埋點，使用第三方數據統(tǒng)計和分析平臺都很有幫助。

本文由 @KASALEE 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。