平台数据API对接：产品推进4步走

　　笔者从平台数据对接出发，一步步梳理了产品推进的路线图：确认业务数据需求、确认关键技术方案、完善产品需求文档，展示了数据从获取到展示的流转过程。
　　业务背景：平台A是传播裂变和传播数据监控工具，平台B是电商工具，双方是两个独立系统，两套人马。现在平台A开始发力做电商生意，所以使用平台B。
　　用户的体验流程路径：用户经由平台A的传播页，跳转到平台B的落地页，并在落地页完成浏览、加购、下单、支付等行为。
　　现在的需求是：用户（可细分）从传播页进入到落地页，转化效果如何？这也就是说，用户在进入落地页后，也能知道用户是传播页中的哪一个人。
　　针对这样的背景和需求，谈谈推进过程以及产品需求文档如何写。
　　Step1：确认业务数据需求
　　由于处于试验阶段，满足如下业务数据需求应该就已足够：
　　建立传播转化行为数据漏斗，即：
　　访问传播页的人数；
　　访问了传播页的人中访问了落地页的人数占比；
　　访问了落地页的人中加购的人数占比；
　　加购的人中下单的人数占比；
　　下单的人中支付的人数占比。
　　需要注意的是后续需要考虑，是否需要刨除反向行为的用户，如加购后，又取消加购；下单后，又取消下单。
　　可以从更多维度分析数据（有平台A维度，也有平台B维度），包括：渠道维度、商品维度、归属地维度等。例如：某渠道用户，支付购买某商品SKU的有多少？某渠道、某商品SKU都是维度。
　　Step2：确认关键技术方案
　　早期就要和技术讨论，在这个项目中，关键是双方平台用户如何匹配的问题。
　　最后确定的方案是：用户从平台A跳转到平台B时，平台A传给平台B该用户的关键参数，如带有参数的用户在平台B进行了目标行为，就由平台B调用接口，将数据回传给平台A。
　　需要或者说可以采用该方案是两个因素决定的：
　　平台A和平台B是独立系统；
　　平台A和平台B可为对方提供能力（说明开发团队是可交流的）。
　　在这个项目中，还需要提前向平台B获取页面路径及行为数据字段等信息，以确认是否可以满足业务数据需求。
　　Step3：完善产品需求文档
　　到这一步，开发通常需要一个数据需求文档，以此为依据，进行接口开发。
　　数据类的产品需求文档最重要的是写清楚事件属性值。
　　什么是事件属性值？
　　各类第三方数据统计和分析平台的产品文档都有比较清晰的说明，引自某平台的解释：
　　事件：用户在产品上的行为
　　属性：描述事件的维度
　　值：属性的内容
　　可以再回想业务数据需求，比如：某渠道用户，支付购买某商品SKU的有多少？
　　事件：支付
　　属性：用户ID、渠道ID、商品SKU
　　值：某
　　每次事件发生时，都将事件本身、事件属性和值记录下来（在这个项目场景里，是平台B上报给平台A），就能知道某个或多个属性“有多少”。
　　按着上述思路，整理出来的表格如下：
　　数据需求文档，使用表格展现是最好的。
　　Step4：后续
　　在接口开发环节，还要和开发商讨数据同步频次和异常等问题。
　　在数据测试环节，关键是要看每个事件，不同属性是否都能有值返回，且是否正确。
　　在数据获取环节，开发需要根据数据需求，结构化处理通过API获得数据，需要考虑是否需要算出数据结果，甚至需要展示，还是只需要先结构化处理好数据即可。
　　总结
　　“麻雀虽小，五脏俱全”通过一个小项目可以了解到数据从获取到展示的流转过程。
　　理解事件属性值的含义，对数据埋点，使用第三方数据统计和分析平台都很有帮助。