数据上报-上报设计

数据上报是数据分析第一的环节，相当于是数据生产。

在具备相对靠谱的sdk后，需要开始设计如何上报。

不知道其他公司是由产品还是数据人员规划上报，我的经验是，数据产品可以不亲自参与，但必须审核（不亲自设计的前提是业务足够成熟）。

这里提两个反面教材：

1、umeng上报，简单也是灾难

umeng是业内使用最多的第三方数据机构。

某产品，在运营的2年内共累积了300-400个eventid.但真正推敲起来需要数据分析时，却发现处处有坑。不是数据上报点设置的不对导致数据上报不全。就是具体参数含糊不清。上报文档更新也不及时。ios和android两端虽产品形态类似，但同一个上报点参数又不同。

2、产品自定义，撑爆服务器

导师曾设计了自助上报体系。某分数据由产品控制，产品却吧用户id上报到维度字段。结果可想而知。

------------------------------------------------------

上报的

1、业务梳理

体验产品，或者阅读产品文档中的交互图。

有流程的地方梳理好流程图。流程的每个环节出 实体-对象 属性 。

2、需求明确

和产品明确需要细节关注的点在哪。（并不是每个细节都需要上报，在sdk不是很智能的情况下开发会累死。）

3、先框架后细节

先将产品整体的路径梳理清楚，如有a,b,c三个功能点，现在发出的版本着重更改a.则上报需覆盖a的细节以及b,c的大体总量。

4、开发|产品核对

上报设计完成后需要找开发check上报可行性。这一点非常重要，数据人员和产品对产品的代码认识较浅。

上报设计更多的是数据对产品业务理解的过程以及沟通的过程。浅薄之谈，希望对您有点帮助。