平臺(tái)數(shù)據(jù)API對(duì)接:產(chǎn)品推進(jìn)4步走

Kx4
1 評(píng)論 8920 瀏覽 66 收藏 6 分鐘

筆者從平臺(tái)數(shù)據(jù)對(duì)接出發(fā),一步步梳理了產(chǎn)品推進(jìn)的路線(xiàn)圖:確認(rèn)業(yè)務(wù)數(shù)據(jù)需求、確認(rèn)關(guān)鍵技術(shù)方案、完善產(chǎn)品需求文檔,展示了數(shù)據(jù)從獲取到展示的流轉(zhuǎn)過(guò)程。

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

用戶(hù)的體驗(yàn)流程路徑:用戶(hù)經(jīng)由平臺(tái)A的傳播頁(yè),跳轉(zhuǎn)到平臺(tái)B的落地頁(yè),并在落地頁(yè)完成瀏覽、加購(gòu)、下單、支付等行為。

現(xiàn)在的需求是:用戶(hù)(可細(xì)分)從傳播頁(yè)進(jìn)入到落地頁(yè),轉(zhuǎn)化效果如何?這也就是說(shuō),用戶(hù)在進(jìn)入落地頁(yè)后,也能知道用戶(hù)是傳播頁(yè)中的哪一個(gè)人。

針對(duì)這樣的背景和需求,談?wù)勍七M(jìn)過(guò)程以及產(chǎn)品需求文檔如何寫(xiě)。

Step1:確認(rèn)業(yè)務(wù)數(shù)據(jù)需求

由于處于試驗(yàn)階段,滿(mǎn)足如下業(yè)務(wù)數(shù)據(jù)需求應(yīng)該就已足夠:

建立傳播-轉(zhuǎn)化行為數(shù)據(jù)漏斗,即:

  1. 訪(fǎng)問(wèn)傳播頁(yè)的人數(shù);
  2. 訪(fǎng)問(wèn)了傳播頁(yè)的人中訪(fǎng)問(wèn)了落地頁(yè)的人數(shù)/占比;
  3. 訪(fǎng)問(wèn)了落地頁(yè)的人中加購(gòu)的人數(shù)/占比;
  4. 加購(gòu)的人中下單的人數(shù)/占比;
  5. 下單的人中支付的人數(shù)/占比。

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

可以從更多維度分析數(shù)據(jù)(有平臺(tái)A維度,也有平臺(tái)B維度),包括:渠道維度、商品維度、歸屬地維度等。例如:某渠道用戶(hù),支付購(gòu)買(mǎi)某商品SKU的有多少?某渠道、某商品SKU都是維度。

Step2:確認(rèn)關(guān)鍵技術(shù)方案

早期就要和技術(shù)討論,在這個(gè)項(xiàng)目中,關(guān)鍵是雙方平臺(tái)用戶(hù)如何匹配的問(wèn)題。

最后確定的方案是:用戶(hù)從平臺(tái)A跳轉(zhuǎn)到平臺(tái)B時(shí),平臺(tái)A傳給平臺(tái)B該用戶(hù)的關(guān)鍵參數(shù),如帶有參數(shù)的用戶(hù)在平臺(tái)B進(jìn)行了目標(biāo)行為,就由平臺(tái)B調(diào)用接口,將數(shù)據(jù)回傳給平臺(tái)A。

需要或者說(shuō)可以采用該方案是兩個(gè)因素決定的:

  1. 平臺(tái)A和平臺(tái)B是獨(dú)立系統(tǒng);
  2. 平臺(tái)A和平臺(tái)B可為對(duì)方提供能力(說(shuō)明開(kāi)發(fā)團(tuán)隊(duì)是可交流的)。

在這個(gè)項(xiàng)目中,還需要提前向平臺(tái)B獲取頁(yè)面路徑及行為數(shù)據(jù)字段等信息,以確認(rèn)是否可以滿(mǎn)足業(yè)務(wù)數(shù)據(jù)需求。

Step3:完善產(chǎn)品需求文檔

到這一步,開(kāi)發(fā)通常需要一個(gè)數(shù)據(jù)需求文檔,以此為依據(jù),進(jìn)行接口開(kāi)發(fā)。

數(shù)據(jù)類(lèi)的產(chǎn)品需求文檔最重要的是寫(xiě)清楚事件-屬性-值。

什么是事件-屬性-值?

各類(lèi)第三方數(shù)據(jù)統(tǒng)計(jì)和分析平臺(tái)的產(chǎn)品文檔都有比較清晰的說(shuō)明,引自某平臺(tái)的解釋?zhuān)?/p>

  • 事件:用戶(hù)在產(chǎn)品上的行為
  • 屬性:描述事件的維度
  • 值:屬性的內(nèi)容

可以再回想業(yè)務(wù)數(shù)據(jù)需求,比如:某渠道用戶(hù),支付購(gòu)買(mǎi)某商品SKU的有多少?

  • 事件:支付
  • 屬性:用戶(hù)ID、渠道ID、商品SKU
  • 值:某

每次事件發(fā)生時(shí),都將事件本身、事件屬性和值記錄下來(lái)(在這個(gè)項(xiàng)目場(chǎng)景里,是平臺(tái)B上報(bào)給平臺(tái)A),就能知道某個(gè)或多個(gè)屬性“有多少”。

按著上述思路,整理出來(lái)的表格如下:

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

Step4:后續(xù)

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

總結(jié)

“麻雀雖小,五臟俱全”——通過(guò)一個(gè)小項(xiàng)目可以了解到數(shù)據(jù)從獲取到展示的流轉(zhuǎn)過(guò)程。

理解事件-屬性-值的含義,對(duì)數(shù)據(jù)埋點(diǎn),使用第三方數(shù)據(jù)統(tǒng)計(jì)和分析平臺(tái)都很有幫助。

 

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

題圖來(lái)自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 這樣的產(chǎn)品具體的prd形式與普通行業(yè)的prd文檔的區(qū)別很大嗎?或者說(shuō)上面的表格應(yīng)該放在文檔中的哪一部分呢?

    回復(fù)