天天看数据的你，知道数据是怎么来的么？

报表大家看的应该比较多了，可报表里面的数据是从哪里来的，整个数据报表的支撑系统又是怎样的呢，大多数人可能并不清楚…

正是因为不清楚整个流程，自己又比较好奇，所以就去补了一些相关的知识，简单的记录一下。

本文会先简单的说明数据展示的整个流程，后续文章的重点会放在数据埋点上，因为这个是第一步，也是非常重要的一步，而且其他的流程也触及到我知识的盲区了，没办法详细展开…

本小结会按照数据从生产到加工再到消费的流程展开，主要是为了说明数据报表中的数据是从哪里来的，整个流程是怎样的，具体流程可参考下图。

天上也许会掉下来个林妹妹，但是不太可能会自己生成一堆我们想要的数据，这些数据都需要提前做一些处理，不要等功能上线了才说怎么没有数据啊，我要的数据呢。

注：本小结的部分内容参考了果果公众号中的一篇文章。

数据埋点是整个数据分析的源头，很多数据分析的发起点就是它，没有了它很多东西都无从谈起。

有的数据是需要单独埋点才能获得的，比如曝光、点击等，有些数据是不需要埋点的，比如记录在服务端的一些日志，后文会有详细的说明，在此就不赘述了。

并不是每次采集到的数据都会立刻上报，一般情况下，客户端会把采集到的数据暂时存储在内存或者磁盘里，在下次启动或者退出应用程序时才会将数据进行上报。

这样也就意味着很有可能会出现数据丢失的情况，而且丢了可能就找不回来了。

之所以是攒着一次性上传，而不是每次一采集到数据就上传，主要是出于性能方面的考虑。

在TCP协议中有着三次握手和四次挥手的校验机制，每次连接和断开连接都会损耗性能，而且也会使用更多的流量。

一般来说，非实时性的数据上报之后是不会立即参与计算的，比如日活、周活、月活等数据，这些数据对实时性的要求没那么高，只会定期计算并更新一次，更新任务一般都是在服务器负载较低的时间段进行的。

在计算之前需要将这部分原始数据存储起来，一般会将客户端上报的数据先存储在服务端的磁盘中。

在数据量比较大或者数据跨了多张表时，数据的读写效率就会降低，这个时候一般会先通过数据仓库的小伙伴建立一张新的表。

在数据计算完成之后，会将这部分结果存入到数据库的新表中，供前端展示的数据报表进行调用。

整个数据流程的最后才是我们比较熟悉的数据可视化，可能是比较高大上的图表，也可能是从数据库里刚跑出来的原始数据。

整个流程中，我只稍微接触过一点点的数据埋点和数据展示，其他部分基本没接触过，所以就不再展开了，下面是本文最主要的部分——埋点。

没有在网上找到关于数据埋点比较权威的定义，忘记在哪里看到下面这个定义的了，可以先帮大家简单的了解下什么是埋点。

根据不同产品以及需求在不同位置嵌入相对应代码来收集数据的行为，俗称埋点。

下面我们分别说明下埋点的方式和主要类型。

按照埋点的位置来分的话，埋点主要分为两种，分别是前端埋点和后端埋点。

前端埋点指的是利用客户端或者前端（H5）收集用户的行为数据，这种形式的优点是可以比较灵活的获取用户行为上下文的数据，缺点是数据存在丢失的风险。

后端埋点主要指的是通过服务端记录收集用户的行为数据，优点是比客户端埋点可靠，缺点是有些属性没有，而且后续可能需要连接多张表获取业务属性，在数据结构发生变化的时候会比较麻烦。

其中前端的埋点方式按照市面上的实现技术又能分为代码埋点、可视化埋点和无埋点三种。

代码埋点

代码埋点一般会嵌入SDK，由开发人员定义事件并添加事件代码，在某个事件发生时，会调用SDK里面相应的接口发送数据。比如在某个按钮被点击时，就会调用SDK提供的数据发送接口来发送数据。

代码埋点的优点是可以按照业务需要进行采集，业务数据比较全面，更利于后续的分析，缺点是需要开发人员配合，具有一定的工作量。

可视化埋点

可视化埋点主要是通过嵌入 SDK圈选自定义事件的形式，产品和运营同学可以直接在页面上进行简单的圈选，然后来追踪用户的行为和点击操作。

可视化埋点的优点是无需单独开发，配置之后即可生效，无需App发版，缺点是支持的自定义样式比较有限，而且在页面发生界面变化时，需要重新配置。

市面上有一些第三方公司提供了可视化埋点的服务，只需要接入SDK即可。

无埋点

无埋点并不是真正意义上的“无”，更接近于“全”埋点， 无埋点指的是通过SDK，自动收集页面所有可点击元素的操作数据…

无埋点的优势是简单便捷，需要的开发工作量较小，缺点是数据上传需要耗费较多的流量，而且脏数据会相对较多，毕竟上传了所有的操作数据。

以上，就是埋点的主要方式，没有哪一种方式是十全十美的，各自都有自己的优点和缺点，所以很多公司也会采用多种埋点方式的组合，比如全埋点+后端埋点，或者代码埋点+后端埋点等…

App的行为事件主要可以分为这几大类，分别是页面事件、展示事件、交互事件、其他事件。

页面事件主要指页面的打开、停留、访问等，埋点主要是为了获取页面访问时长、访问深度等数据。

展示事件通常情况下就是我们说的曝光事件，比如一个Banner曝光了多少次，从曝光到点击的转化率是多少，这类数据主要是通过展示事件来进行埋点。

交互事件主要指的就是用户与产品发生交互的行为，最常见的是点击事件，比如点击人数、点击次数等数据的获取…

其他事件指的是一些不需要用户触发的事件，比如客户端日志信息，错误上报等，这些可以帮助我们更准确的定位问题，进而加以解决。

上面的部分主要是关于埋点的一些知识，下面简单的说一下我们公司目前的埋点流程，大致可参考下面的流程图。

从上面的文章中也能够看到埋点的方式和事件类型都有很多种，那具体采用什么样的方式和事件类型，就需要从业务需求来出发。

比如对于按钮，埋点的需求可能就只是简单的曝光、点击，而对于消费型的详情页面，可能需要了解用户的访问时长、访问深度，甚至是跳出率等等…

明确了埋点需求之后，需要对应的人员整理出来埋点文档，文档主要是面向开发的，后续开发会按照这个文档进行埋点。

一份埋点文档通常会包括页面ID、页面、埋点事件ID、埋点事件、埋点类型、Key、Value、记录规则等内容，我没有写过埋点文档，这里就不再展开，感兴趣的可以去网上搜索更多相关内容。

指的就是按照埋点文档进行埋点，此处需要开发人员，一般是负责开发某个功能的开发再进行数据埋点。

埋点完成之后需要有专门的测试人员进行埋点测试，如果是代码埋点的话，整个周期会比较长，而且需要App发版且用户更新了App才行。

所以测试一定要慎重，不要等功能上线之后才发现没有埋点，或者数据存在问题。

最后就是数据的收集、上报流程了，接文章的第一部分，后续需要数据的话去找对应的人获取即可。如果是一次性的取数需求直接找开发跑跑SQL就好，如果是常规化的数据，最好做成数据看板的形式。

整个数据埋点的流程大致就是这个样子，数据埋点很繁琐、很枯燥、很容易出错，但是它又非常非常重要…

数据埋点有点类似于盖房子打地基的感觉，埋点出了问题的话，后面的数据分析就不用说了，那基于这种数据分析得到的决策是否靠谱，也需要打一个很大的问号了。

可以说，再怎么强调埋点的重要性也不为过，当然后续的数据存储、计算、入库与可视化展示等环节也都很重要…

以上，就是本文的主要内容，欢迎斧正、指点、拍砖。