前言
近期，应PM要求，对应用的埋点方案进行了调研，特在此写个博客记录分享一下。
需求分析
首先我们需要清楚埋点的实际需求是什么？对于一个产品来讲埋点无非就是想了解用户的使用习惯和产品的使用情况，从而从客户和产品的角度去了解客户群体，及其对产品的一些使用想法。本文将着重关注数据的收集而非数据分析。
数据处理
在这里，我们需要明确的一点是，数据处理的整个过程中，数据的收集是重中之重，它将是我们进行数据的分析的大前提，因为采集的数据会直接影响到最后的分析结果。
因此，数据采集应具备以下几点特性：
多元性
采集过程应从不同的维度去获取数据。比如我们要采集用户相关的部分数据。那么我们可以从身高、体重、兴趣爱好等各个层次、多维度的去采集对应数据。这样的数据还原出来的用户对像才更有活性，对于今后的数据分析、包括描绘用户画像也更为有利。
准确性
准确性包含两个层次的要求：1.数据采集过程的准确性：对于特定的流程分析，我们的埋点方案要具备一定的针对性，避免无关因素的干扰。2.数据的客观性。我们不能代替客户，我们能做的只是观察并记录，臆想的数据对于我们毫无价值。
时效性
对于采集的数据，它只能反映过去的某个时刻或者某段时间的客观情况。得到的结果和结论也只能是对应过去的某个时间段而言。可能是受制于当时的网络情况、社会环境等因素的影响，才会呈现出这样的结果。所以我们在采集数据的同时最好能给它打上时间标签，方便今后的数据对比。
ok，接下里进入正题－－埋点
什么是埋点？
简单的说，埋点就是定时、定点的数据采集，然后上报。
举个简单的🌰
如图，比如我们在到达页面A的时候，进行数据采集和上报，告诉服务器我是谁？我在哪里？我干了些什么？而后进入页面B，进行相同的操作，以此类推。最后后台可以根据得到的数据还原用户的各种行为，最终将这些数据呈现出来，方便运营等进行分析操作。（技术上讲，这里实际上还包含数据存储和传输等问题，不同的埋点方案的处理方式都不尽相同，这里就不做过多的阐述了。）
埋点方案一：代码埋点
代码埋点是很多人一开始就会想到的方案，也是目前最为人所知的一种方案。包括友盟在内的一些服务商目前都在使用这种方案。实现方式相信大家一看就明白，就是在需要数据采集的地方抓取数据，然后上传。
要指出的是，这里的数据采集往往会以事件的方式进行。事件包含事件名称、事件参数等，简单的点击事件统计(比如统计点击事件)仅需事件名称即可，如果想抓住事件内部的一些数据的话，比如电商领域的一些交易统计，就会在用户点击提交购买按钮的时候在事件参数里传递总价等数值。在开发文档里，后者通常会被称为自定义事件，这也是代码埋点最具灵活性的地方。
这种方案的优点在于它的准确性和针对性。指哪打哪，不浪费一发子弹。如果项目较小或者还只是在项目初期，这种方案还算可以接受，但是如果在较大的项目项目或者处于开发后期的项目来做，对于程序员来讲无疑是身心上的摧残。一方面工作量太大，这种特定的页面的数据采集方案（PM：什么？不知道埋哪里？那就都埋了吧！）能偷懒的地方都没有；另一方面，这种方案对代码的入侵性太大，很可能导致代码高耦合，并且这种方式采集的数据维度往往会太过单一。如果今后想从更高的层面或者其他角度去分析，很有可能需要重新埋点和发布版本。
埋点方案二：可视化埋点
代码埋点将核心代码和配置资源进行了分离。在每次启动的时候都会有去请求最新的埋点配置，他在一定程度上降低了代码埋点的门槛，只要客户端集成之后，PM在web上就可以进行操作(让PM自己玩去吧╮(╯▽╰)╭)
那么它是如何实现的呢？
如图，简单来说，客户端集成SDK之后，在用户使用的过程中会定时截图，同时获取应用视图的层级关系，传到服务端。服务端会重新渲染页面，并判断控件是否可以埋点，然后关联对应的埋点事件，最后将配置信息传回客户端。
这种方式从某种程度上大大提升了应用的埋点灵活性，使用方便。当然它也有一定的局限性，比如埋点的内容有限，不能像代码埋点一样采用自定义事件,所以对于较为深入的行为分析要求，这种方案不能很好的实现。
埋点方案三：无埋点
无埋点的的技术方案，早在2013年就已提出了。它在客户端集成之后，会主动的尽可能多的收集数据，甚至连要在那里埋点的问题都省略了，我们不用去设置配置文件，如果我们想要特定的数据直接去查询即可（这就是为什么叫无埋点）。
与可视化埋点相比，无埋点主要解决的是数据的回溯问题。比如，我们想要得到某个页面的访问数量，如果是可视化埋点，就需要去配置一下埋点方案，然后发布，一段时间之后才会得到对应的数据。我们无法获取到发布之前的某个时间内的访问情况。也就是说所有想得到的数据只有在配置文件发布之后才能看到。对于无埋点方案来讲，这些数据的采集早在SDK集成的时候就开始了。某天突然想要看下，查询下就可以看到了。当然，它的缺点也是显而易见的，采集的数据越多，对于数据传输和存储的要求就会越高。
其实，有时候对于某些检测行为，我们并非一定要在客户端做。考虑到数据处理过程中的传输和存储问题（本地数据存储），在服务端进行埋点和分析会显得事半功倍。
一些国内外的服务商
Google Analytics（Firebase Analytics）
https://firebase.google.com/docs/database/ios/start
Firebase Analytics是2016年在Google I/O上推出的针对移动应用的服务。
Flurry
https://developer.yahoo.com/flurry/docs/analytics/gettingstarted/technicalquickstart/ios/
Localytics
http://docs.localytics.com/dev/ios.html
Mixpanel
https://mixpanel.com/help/reference/ios
(支持可视化埋点)
Umeng
http://dev.umeng.com/analytics/ios-doc/integration?spm=0.0.0.0.t9tzbd
Growing IO
https://help.growingio.com/SDK/iOS.html
（国内无埋点方案－无埋点的启发性更好哦）
TalkingData
https://www.talkingdata.com/tracking/documents/AdTracking_SDK_iOS_%E9%9B%86%E6%88%90%E6%96%87%E6%A1%A3.pdf
以上都是集成文档的链接，各家都有自己的特点。具体方案请视自己的情况而定。
自行搭建埋点服务
有时候我们也会遇到数据是有了，但是当要把原始数据做导出分析时又遇到问题。自己产品的数据却不能被我们自己拥有。
这里介绍两款免费开源的私有化部署方案
1.cobub razor
传送门：http://www.cobub.com
2.countly
传送门：https://count.ly
总结：
不同的埋点方案都有各自的优缺点，对于不同的业务需求，一种埋点方案明显无法满足 ，所以往往我们需要结合多种方案进行处理。
最后，希望本文能拓宽大家对于埋点的思路吧：）
若文章中有不对的地方望指正，万分感谢！
本文提到的服务商与本人没有利益关系.
参考文章
1.http://www.itechdog.com/blog/event-tracking?utm_source=tuicool&utm_medium=referral
2.http://www.jianshu.com/p/973d626fa19a
3.http://www.jianshu.com/p/4e1b371ec46a
4.https://www.zhihu.com/question/41831617
