笔者从平台数据对接出发,一步步梳理了产品推进的路线图:确认业务数据需求、确认关键技术方案、完善产品需求文档,展示了数据从获取到展示的流转过程。 业务背景:平台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获得数据,需要考虑是否需要算出数据结果,甚至需要展示,还是只需要先结构化处理好数据即可。 总结 "麻雀虽小,五脏俱全"——通过一个小项目可以了解到数据从获取到展示的流转过程。 理解事件-属性-值的含义,对数据埋点,使用第三方数据统计和分析平台都很有帮助。