自有平台可以接的api接口項目?筆者從平台數據對接出發，一步步梳理了産品推進的路線圖：确認業務數據需求、确認關鍵技術方案、完善産品需求文檔，展示了數據從獲取到展示的流轉過程，今天小編就來聊一聊關于自有平台可以接的api接口項目?接下來我們就一起去研究一下吧!

自有平台可以接的api接口項目

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

業務背景：平台A是傳播裂變和傳播數據監控工具，平台B是電商工具，雙方是兩個獨立系統，兩套人馬。現在平台A開始發力做電商生意，所以使用平台B。

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

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

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

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

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

訪問傳播頁的人數；

訪問了傳播頁的人中訪問了落地頁的人數/占比；

訪問了落地頁的人中加購的人數/占比；

加購的人中下單的人數/占比；

下單的人中支付的人數/占比。

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

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

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

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

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

平台A和平台B是獨立系統；

平台A和平台B可為對方提供能力（說明開發團隊是可交流的）。

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

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

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

什麼是事件-屬性-值？

各類第三方數據統計和分析平台的産品文檔都有比較清晰的說明，引自某平台的解釋：

事件：用戶在産品上的行為

屬性：描述事件的維度

值：屬性的内容

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

事件：支付

屬性：用戶ID、渠道ID、商品SKU

值：某

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

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

數據需求文檔，使用表格展現是最好的。

在接口開發環節，還要和開發商讨數據同步頻次和異常等問題。

在數據測試環節，關鍵是要看每個事件，不同屬性是否都能有值返回，且是否正确。

在數據獲取環節，開發需要根據數據需求，結構化處理通過API獲得數據，需要考慮是否需要算出數據結果，甚至需要展示，還是隻需要先結構化處理好數據即可。

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

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

本文由 @KASALEE 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。