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

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

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

自有平台可以接的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协议。

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页