一、按照生产源头不同，数据可以分为四类：

1、最常见的、也是使用最广泛的是mysql库表的【业务交互数据】：比如业务过程中的商品、用户、支付、订单数据；再比如采购员在进行车辆采购入库过程中录入的车辆车型车系、颜色、行驶里程等数据；

这些结构化数据产生后会直接存到mysql库表中，后续大数据会使用Sqoop组件同步至HDFS，然后同步至Hive的ods层；Mysql—Sqoop—HDFS—HIVE是常用【离线业务数据】抽取方案；

2、其次，使用最广泛的是【埋点数据】：即C端用户从打开APP/小程序/PC网站开始到离开结束，在整个过程中产生的用户行为数据，例如，用户A打开APP，浏览了商品1又浏览了商品2，又点赞商品3，又收藏了商品4，最后关闭了APP，用户A的一系列动作行为都会通过埋点上报—Nginx—logfile—Flume—Kafka—HDFS—HIVE上报到数仓；

3、第三类，是【爬虫数据】，比如城市的天气数据需要从天气网站上爬取；

4、第四类，是【导入数据】，比如通过预测和多方沟通制定的每个城市月度GMV目标，一般采取导入系统的方式产生。

二、好的埋点方案什么样

1、【通用性强，覆盖面广】两个体现：一套埋点方案能覆盖公司各类产品，一个事件能覆盖一类类似的业务场景，这样做的目的是：

• 对于前端，开发成本、维护成本极低；
• 对于数仓，数据上报到数仓后的建模逻辑可以使用一套，开发成本和维护成本极低；在数仓的建模过程中，每多上报一种事件就意味着数仓需要新建一套模型。

2、【基本不需要迭代】，不需要随着产品上线新功能、优化老功能进行埋点上报参数的迭代，频繁的迭代意味着数仓要兼容新老事件模型，增加开发和维护成本；

3、【可理解性强】，面向业务侧、开发侧都具有较好的可解释性沟通成本低，可以高效拿结果，见过很多埋点方案，非常复杂、晦涩难懂；

总结起来就是：大道至简

三、如何设计出好的埋点方案？

1、埋点上报模板设计，就是前端人员上报到nginx的json模型，亮点包括：

1）全局参数+公共参数+参数的组成形式：

• 全局参数：记录数据从哪类项目上报，一般分为：APP、PC、wxapp；
• 公共参数，每个事件都需要上报的参数，一般包括：设备唯一标示、用户唯一标识、上报产品唯一标识、上报产品版本号、上报时间；
• 私有参数，不同的事件对应着不同的参数，这些参数是在数仓加工指标依赖的核心数据；

2）一套模板就能覆盖公司各类产品（TOC产品线、CRM、ERP、财务系统、EEP系统等），比如toc电商平台等商品列表 与 ERP系统等库存商品列表 都可以用一套埋点模型，只是上报的产品唯一标识不同，这样做的价值是更低的开发成本、维护成本、理解成本、沟通成本，这就是【通用性强，覆盖面广】【基本不需要迭代】。

2、埋点事件与参数设计，亮点包括：

1）一个埋点事件，通常由以下6部分组成：

• 事件主题，比如登陆注册类、入口点击类、豆腐块类、详情浏览类、互动类、页面类；
• 事件中文名
• 事件英文名
• 事件上报参数，非常重要，每个事件都对应着1个或者多个参数；
• 时间上报参数解释
• 事件上报时机

2）事件模型具有极强的通用性

• 比如，豆腐块点击ListCubeClick这一个事件，可以覆盖的场景包括：在商品列表点击某商品、在店铺列表点击某店铺、在文章列表点击某文章等，都可以使用ListCubeClick事件模型进行上报，只需要在ListCubeClick事件上报等参数中区分商品、店铺、文章；
• 同样的理念，也适用于点击入口事件EnterClick、进入详情页DetailPageEnter等更多事件；
• 通用性强，意味着更低的开发成本、维护成本、沟通成本，这就是【通用性强，覆盖面广】【基本不需要迭代】。

3、公参维度表与私参维度表设计，亮点包括：

1）公参维度表，比如产品唯一标识、页面唯一标识、产品端类型唯一标识等；公参维度和上报的事件没有关系，和上报的设备、产品、页面有关系；

2）私参维度表，比如主题唯一标识、菜单唯一标识、入口唯一标识、表单唯一标识等；私参维度表和上报的事件有关，是为每一个事件私自定制的参数集；

3）私参维度配置化，不需要为了新增的业务板块去改变事件原有的参数模型，比如产品侧新增加了 文章列表功能，只需要为主题them增加一个文章主题，而不需要修改事件原有的上报参数模型，如此设计下游的数仓建模也不需要改变，只是多接受了一种枚举值而已；这就是【通用性强，覆盖面广】【基本不需要迭代】。

三、埋点方案如何从0-1-100落地？

1、分工

1）整体埋点方案的设计，是由数产主导、业务配合完成；

2）埋点开发，是由前端同事完成；

3）数仓建模、数据流转方案，是由数仓主导、数产配合完成；

4）测试工作，是由数据口的测试人员主导、数产验收完成；

2、节奏

1）埋点上线优先级，是根据业务侧建议，数产梳理确定；

四、容易踩的坑

1、不是埋点事件越多越好，冗余的埋点事件意味着繁重的开发和维护成本，意味着业务侧更难找到想要的数据增加数据的使用成本，应该重视两个原则，第一个就是按照业务需要去加埋点，第二个就是重视埋点方案的通用性；

2、不要害怕推翻重来，遇见过很多公司埋点方案设计得非常不合理导致不能满足数据应用分析或者数据不准确，这个时候有的公司为了不增加额外的开发成本选择在原有体系上修修补补，这其实是不可取的，因为大量的修补意味着更加繁重维护工作，而且并不一定能解决数据不准确的问题。所以，要勇敢地去推翻重来；