平台数据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获得数据,需要考虑是否需要算出数据结果,甚至需要展示,还是只需要先结构化处理好数据即可。
总结
“麻雀虽小,五脏俱全”——通过一个小项目可以了解到数据从获取到展示的流转过程。
理解事件-属性-值的含义,对数据埋点,使用第三方数据统计和分析平台都很有帮助。
本文由 @KASALEE 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
作者暂无likerid, 赞赏暂由本网站代持,当作者有likerid后会全部转账给作者(我们会尽力而为)。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: