自有平台可以接的api接口项目（平台数据API对接产品推进4步走）

笔者从平台数据对接出发，一步步梳理了产品推进的路线图：确认业务数据需求、确认关键技术方案、完善产品需求文档，展示了数据从获取到展示的流转过程，今天小编就来聊一聊关于自有平台可以接的api接口项目?接下来我们就一起去研究一下吧!

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

笔者从平台数据对接出发，一步步梳理了产品推进的路线图：确认业务数据需求、确认关键技术方案、完善产品需求文档，展示了数据从获取到展示的流转过程。

业务背景：平台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获得数据，需要考虑是否需要算出数据结果，甚至需要展示，还是只需要先结构化处理好数据即可。

总结

“麻雀虽小，五脏俱全”——通过一个小项目可以了解到数据从获取到展示的流转过程。

理解事件-属性-值的含义，对数据埋点，使用第三方数据统计和分析平台都很有帮助。

本文由 @KASALEE 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。