数据采集的方式根据采集数据端的不同，主要分为网页数据采集、APP数据采集。网页数据的采集主要是使用JS采集，常用的数据分析工具主要是Google Analytics，APP数据采集主要是通过埋点采集，主要有前端埋点和后端埋点之分，相应的移动端数据分析厂商也很多。
常见的前端埋点技术有三类：
1.在某个控件操作发生时，通过预先写好的代码来触发数据的代码埋点
2.通过可视化界面，配置控件操作与事件发生关系的可视化埋点
3.先收集所有数据，再在后端筛选需要分析对象的“无埋点”。
代码埋点
代码埋点出现时间很早， Google Analytics 年代，就已经出现了类似的方案。
目前，国内的主要第三方数据分析服务商都提供了这一方案：
↘ 百度统计
↘ 友盟
↘ TalkingData
Sensors Analytics 也提供了 iOS、Android、Web 等主流平台的代码埋点方案。
代码埋点技术原理很简单，在APP、界面初始化时，初始化第三方数据分析服务商的SDK，然后在某个事件发生时就调用SDK里面相应的数据发送接口发送数据。
例如，我们想统计APP里面某个按钮的点击次数，则在APP某个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口来发送数据。
代码埋点的优点是使用者可以非常精确地选择什么时候发送数据，同时使用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。代码埋点也有一些劣势。
首先，埋点代价大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术人员才能完成。
其次，更新代价比较大，每一次更新埋点方案，都必须改代码，然后通过各个应用市场进行分发，并且总会有相当多数量的用户不喜欢更新APP，这样埋点代码也就得不到更新了；
最后，所有前端埋点方案都会面临的数据传输时效性和可靠性的问题，这个问题就只能通过在后端收集数据来解决。
可视化埋点
从前端埋点到可视化埋点是一种自然的演进。代码埋点代价大，每一个埋点都需要写代码，那么，参考软件的常用思维，用可视化交互手段来代替写代码。
代码埋点每次更新都需要等待APP的更新，因此，参考大部分游戏的做法，把核心代码和配置、资源分开，在APP启动的时候通过网络更新配置和资源。
正是这样做法演进，以 Mixpanel 为首的数据分析服务商，相继提供了可视化埋点的方案。国内的 TalkingData、诸葛IO 等也都提供了类似的技术手段。
而且，Mixpanel 非常无私地开源了它们的iOS 和 Android 端的 SDK 的源代码，大家在开发中可以参考它们的贡献，并且贡献了一些 bug 的提交。
iOS 和 Android 平台的可视化埋点
下图是iOS SDK 使用 Mixpanel 的 codeless 埋点功能：
使用起来非常简单，点击某个支持的控件类型的实例，然后在弹出的窗口中，设置点击这个按钮的发送事件。再让 Deploy 按钮，把这个配置下发下去。
这时，所有安装有嵌入了 Mixpanel SDK 的APP ，都会在 APP 启动时或者定时获取相应的配置，真实的用户使用时，点击按钮，就发送对应的事件到后端了。
整个 iOS 端的埋点的流程图，如下图所示：
Android 端的可视化埋点方案，与 iOS 端基本一致。
Web端的可视化埋点
Mixpanel 没有提供 Web 端可视化埋点方案，我们以Sensors Analytics 的 Web 端可视化埋点方案来举例：
首先，使用者在自己网页内引入 Sensors Analytics 的 JavaScript SDK 代码
然后，从 Sensors Analytics 后台可视化埋点管理界面跳转到使用者的网站界面时，会自动进入到可视化埋点模式。
接下来，在这个模式下，使用者在网页上点击任意 html元素，Sensors Analytics 都会取到这个元素的url，层级关系等信息来描述这个 html 元素，当使用者设置了这个元素和某个事件相关联时，SDK 会把这些关联信息和客户生成配置信息，并且存放在 Sensors Analytics 提供的相应保存位置。
最后，用户以普通模式访问网页时，SDK 就自动加载配置信息，在相应的界面元素被点击时，使用 Sensors Analytics 的数据发送接口来收集事件。
从上面的可视化埋点的方案可以看出，可视化埋点很好地解决了代码埋点的埋点代价大和更新代价大两个问题。
但是，可视化埋点能够覆盖的功能有限，目前不是所有的控件操作都可以通过这种方案进行定制。
Mixpanel 为首的可视化埋点方案不能自己设置属性的，例如：
一个界面上有一个文本框和一个按钮，通过可视化埋点设置点击按钮为“提交”事件时，并不能将文本框的内容作为事件属性进行上传
因此，可视化埋点方案上传事件，只能上传 SDK 自动收集的设备、地域、网络等默认属性，以及一些通过代码设置的全局公共属性了；
另外，可视化埋点做为前端埋点的方案，依然没有解决传输时效性和数据可靠性问题。
“无埋点”
“无埋点”方案出现的也较早，Heap在2013年就推出了“无埋点”技术方案。百度在2009年用无埋点的方案分析一个页面各个元素的点击情况；2011年，百度质量部推出了一项内部服务，录制安卓 App 的全部操作，通过回放找出 App 崩溃的原因
下图是Heap 的例子：
和可视化埋点很像，二者的区别在于可视化埋点通过界面，配置哪些控件的操作数据需要收集；“无埋点”是先尽可能收集所有的控件的操作数据，再通过界面配置哪些数据需要在系统里面进行分析。
“无埋点”的优点：
1.解决了数据“回溯”的问题
例如，某一天，突然想增加某个控件的点击的分析，如果是可视化埋点方案，只能从这一时刻向后收集数据，“无埋点”，则从部署 SDK 的时候数据就一直都在收集了；
2.“无埋点”方案可以自动获取很多启发性的信息
如“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大，哪些控件值得做更进一步的分析等等。
但与可视化埋点一样，“无埋点”依然没有解决覆盖功能的范围，灵活地自定义属性，传输时效性和数据可靠性欠佳这几个缺点。
甚至在所有的控件事件全部搜集时，反而给服务器和网络传输带来更大的负载。
前端采集与后端采集的对比
我们以京东的一个订单提交页面为例来进行对比：
前端埋点获取数据
用可视化埋点，在购物车页，能采集到某时某刻某人提交了一个订单；再使用前端代码埋点，还能拿到订单金额、商品名称、用户级别等在前端有记录信息
后端埋点获取数据
在后端接入数据，还能拿到商品库存、商品成本、用户风险级别等只在后端有记录的信息。
可见，可视化埋点使用、部署简单，但数据获取能力相比代码埋点要弱；另外，前端埋点天然劣势拿不到未在前端保存的信息。
因此，后端数据采集是用户行为数据采集的另一个重要方案。但后端数据采集同样存在其优缺点：
优点：
↘ 实时收集，数据很准确，不存在延时上报
↘ 当要改变埋点时，只要改变，上报数据就会改变
↘ 能够收集不在APP内发生的行为，只要请求服务器就行，而客户端只能收集在客户端中的操作行为，如统计从其他APP引流的安装量。
缺点：
↘ 不能收集不需要请求服务器的数据
↘ 用户没联网的时候不能够采集数据