业务背景：平台A是传播裂变和传播数据监控工具，平台B是电商工具，双方是两个独立系统，两套人马。现在平台A开始发力做电商生意，所以使用平台B。
用户的体验流程路径：用户经由平台A的传播页，跳转到平台B的落地页，并在落地页完成浏览、加购、下单、支付等行为。
现在的需求是：用户（可细分）从传播页进入到落地页，转化效果如何？这也就是说，用户在进入落地页后，也能知道用户是传播页中的哪一个人。
针对这样的背景和需求，谈谈推进过程以及产品需求文档如何写。
Step1:确认业务数据需求
由于处于试验阶段，满足如下业务数据需求应该就已足够：
- 建立传播-转化行为数据漏斗，即：
a.访问传播页的人数；
b.访问了传播页的人中访问了落地页的人数/占比；
c.访问了落地页的人中加购的人数/占比；
d.加购的人中下单的人数/占比；
e.下单的人中支付的人数/占比。
需要注意的是后续需要考虑，是否需要刨除反向行为的用户，如加购后，又取消加购；下单后，又取消下单。
- 可以从更多维度分析数据（有平台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获得数据，需要考虑是否需要算出数据结果，甚至需要展示，还是只需要先结构化处理好数据即可。
总结
“麻雀虽小，五脏俱全”——通过一个小项目可以了解到数据从获取到展示的流转过程。
理解事件-属性-值的含义，对数据埋点，使用第三方数据统计和分析平台都很有帮助。
