数据采集是数据应用的源头，指导企业在产品、运营和业务等多方面决策。本文作者王灼洲从数据采集需求出发，详细解读了如何实现高效、可用的数据采集方案。主要内容如下：

• 数据采集的定义和重要性

• 业内常见的数据采集方案

• 数据采集的原则

• 数据采集案例分析

一、数据采集的定义和重要性

所谓数据采集，即为了满足数据统计、分析和挖掘的需要，搜集和获取各种数据的过程。通常情况下，数据采集指的是采集企业内部的数据。

在当前互联网领域，随着流量红利的衰退，越来越多的企业通过精细化运营，深度挖掘每一位用户的价值。当下流行的数据驱动、精细化运营等方法论和实践方式，也变得越来越重要，并且被越来越多的企业所接受和采纳。而数据驱动、精细化运营都要基于数据来做各种决策。数据采集，正是它们的基础和前提条件。

数据采集，本质上是为了数据应用。如果我们没有任何数据上的应用需求，投入再大的精力，去做好数据采集其实也是没有任何意义的。而数据应用，其实是一个比较大的范畴，包含最简单的统计报表，复杂的交互式在线分析，当下非常热门的个性化推荐等。

不管哪一类数据应用，都可以在大体上分成五个环节，如下图：

在进行数据应用的时候，我们首先要通过各种方式采集数据；然后将采集得到的数据，通过实时或者批量的方式，向后进行传输；对于这些传输过来的数据，选择合适的数据模型进行 ETL 和建模，并且根据后续的应用选择合适的存储方案；在数据完成建模并且存储下来之后，就可以对数据进行统计、分析和挖掘等数据应用；而这些数据应用的结果，一方面，可以通过数据可视化的方式，直接展现，并帮助我们做出各种产品、运营和商业等方面的决策；另一方面，这些数据应用的结果，也可以直接反馈给产品，以类似于「猜你喜欢」的产品形态，直接作用在产品上。

很显然，在一个典型的数据应用上，数据采集是第一个环节，是源头，是一切数据应用的起点。如果数据采集没有做好，影响了整体的数据质量，那么，在后面环节再想进行弥补，其代价会很大，效果也会大打折扣。最终的数据应用，以及基于应用得到的决策与反馈的质量也必然会受到影响。

从这个意义上来讲，无论我们如何强调数据采集的重要性，也都不为过。

正是因为我们意识到了数据采集的重要性，神策数据的愿景随之诞生，即“帮助中国三千万企业重构数据根基，实现数字化经营”，希望通过我们的努力，能够帮助我们的客户和合作伙伴更好、更全面地采集数据，从而最大化地发挥数据的价值。也正是坚守于此，过去五年，不论是在数据采集技术，还是数据治理方案等方面，我们都做了很多的工作，也帮助了很多的客户。比如我们建立强大的数据采集 SDK 研发团队，并将 SDK 全部开源，也维护着近 1500 人的开源讨论社群，同时不断向业界输出我们的积累、经验和沉淀，让数据采集技术不再神秘，更让数据采集技术的生态更好、更健康的向前发展。

二、业内常见的数据采集方案

目前，市面上常见的埋点方式主要有三种：代码埋点、全埋点和可视化埋点。

1.代码埋点

所谓代码埋点，即客户端集成 SDK，在客户端启动的时候初始化 SDK，然后在某个事件（行为）发生时，客户端显示调用 SDK 的接口触发相应的事件。

代码埋点，是最常见的埋点方式，同时也是“最万能”的埋点方式。

其优点如下：

（1）可以精准控制埋点；

（2）可以灵活添加自定义事件和属性；

（3）可以满足更精细化的分析需求。

同时，代码埋点也有一些缺点：

（1） 前期埋点代价比较大；

（2）埋点的变更，需要伴随客户端的发版。

2.全埋点

全埋点，也叫无埋点、无码埋点、无痕埋点、自动埋点等，是指无需开发工程师写代码或者只写少量的代码，就能预先自动采集用户的所有行为数据，然后在数据分析产品上通过点选和配置，来筛选要分析和统计的对象。

全埋点优点如下：

（1）前期埋点成本相对较低；

（2）若分析需求或事件设计发生变化，无需应用程序修改埋点和发版；

（3）可以有效地解决“历史数据回溯”问题。

同时，全埋点也有一些缺点：

（1）由于技术方面的原因，对于一些复杂的操作，比如缩放、滚动等，很难做到全面覆盖；

（2）无法自动采集和业务相关的数据；

（3）无法满足更精细化的分析需求；

（4）各种兼容性方面的问题；

（5）传输的数据量太大、浪费资源。

戳图下载 iOS 全埋点技术白皮书

3.可视化埋点

所谓可视化埋点，即通过可视化的方式进行埋点。可视化埋点，一般需要依赖全埋点相关的技术。

可视化埋点一般有两种表现方式：

一是默认情况下，不进行任何埋点，然后通过可视化的方式进行圈选，圈选哪些就采集哪些。

二是默认情况下，开启全埋点全部采集，然后通过可视化的方式对全埋点的事件进行重命名。

比如，对于登录页面上的登录按钮，全埋点采集的事件名一般都是固定的，比如叫：$AppClick，借助于可视化埋点，我们就可以对 $AppClick 事件进行重命名，比如 login。

与代码埋点和全埋点相比，可视化埋点看起来非常酷炫，但它也有相应的优缺点。

优点：比如整个埋点比较贴近业务场景，同时也降低了埋点的技术门槛，运营人员、数据分析人员等非技术人员均可埋点。

缺点：由于可视化埋点是依赖于全埋点，因此他天然继承了全埋点的缺点，比如兼容性问题、无法采集和业务相关的数据问题。

那么，埋点方案未来发展的趋势是什么呢？

我理解，未来会逐步向场景化、行业化、智能化方向发展，比如如何通过可视化的方式，给事件添加动态属性，类似于可视化动态属性关联。

三、数据采集的原则

面对这么多的数据采集方案，我们究竟该如何选择呢？

神策这 5 年来，已累计服务 1500+ 家企业客户，通过深度服务客户，我们发现其实目前并没有一种非常完美的埋点方案能够适应所有的场景。不同的埋点方案，它们各有优缺点，都有他适应的场景和不适应的场景。面对这么多的埋点方案，不能一味追求省事，更不能追求埋点方式的「酷炫」，最主要的还是要根据实际的分析需求和业务场景，选择最能满足我们需求的埋点方式。若有多种埋点方案都能满足，我们可以再追求「省事」和「酷炫」的方案。

比如对于上图中的搜索页面，我们的需求是，当用户点击搜索按钮时，触发一个事件，并将用户输入的关键词作为事件属性。

对于这个数据采集需求，若使用代码埋点方案，操作和实现非常简单；若使用全埋点方案，无法单独完全满足，这是因为全埋点虽然可以自动采集点击搜索按钮的点击事件，但无法自动获取关键词并作为点击事件的属性，但也可以通过写一定的代码配合全埋点来满足；如果使用可视化埋点的方案，如果我们能实现动态属性关联，也能实现上面的埋点需求。

因此，在数据采集领域，根本不存在什么银弹，即不存在普适的完美方案能够适合所有的应用场景。我们能够做的，是针对不同的应用场景，选择最合适的数据采集方案。

当然了，虽然没有银弹，但是数据采集中还是有一些比较通用的原则供我们参考，我们总结为四个字，即大、全、细、时。

大：充分考虑用户规模与数据规模的增长，做好数据资产积累的准备。

全：多端采集，针对全量用户行为而非抽样，采集要贯穿用户使用产品的整个生命周期。

细：尽可能采集足够全面的属性与维度，尽量保存数据细节，让积累的数据资产更加优质。例如，从 Who、When、Where、How、What 这 5 个角度来采集用户行为数据。

时：在技术条件与成本允许的情况下，尽可能地提高数据采集的时效性，从而提高后续数据应用的时效性。

四、数据采集案例分析

案例一：App 与 H5 打通

近年来，App  的混合开发越来越流行，App 与 H5 的打通需求也越来越迫切。那什么是 App 与 H5 打通呢？所谓“打通”，是指 H5 集成 JavaScript 数据采集 SDK 后，H5 触发的事件不直接同步给服务端，而是先发给 App 端的数据采集 SDK，经 App 端数据采集 SDK 二次加工处理后入本地缓存再进行同步。

App 为什么要与 H5 打通呢？主要是从以下几个角度考虑。

1.数据丢失率

在业界，App 端采集数据的丢失率一般在 1% 左右，而 H5 采集数据的丢失率一般在 5% 左右（主要是因为缓存、网络或切换页面等原因）。因此，如果 App 与 H5 打通，H5 触发的所有事件都可以先发给 App 端数据采集 SDK，经过 App 端二次加工处理后并入本地缓存，在符合特定策略之后再进行同步数据，即可把数据丢失率由 5% 降到 1% 左右。

2.数据准确性

众所周知，H5 无法直接获取设备相关的信息，只能通过解析 UserAgent 值获取到有限的信息，而解析 UserAgent 值，至少会面临如下两个问题：

（1）有些信息通过解析 UserAgent 值根本获取不到，比如应用程序的版本号等；

（2）有些信息通过解析 UserAgent 值可以获取到，但内容可能不正确。

如果 App 与 H5 打通，由 App 端数据采集 SDK 补充这些信息，即可确保事件信息的准确性和完整性。

3.用户标识 

如果用户在 App 端注册或登录之前使用我们的产品，我们一般都是使用匿名 ID 来标识用户。而 App 与 H5 标识匿名用户的规则不一样（iOS 一般使用 IDFA 或 IDFV，H5 一般使用 Cookie），进而就会导致一个用户使用了我们的产品，结果产生了两个匿名用户的情况。如果 App 与 H5 打通，就可以将两个匿名 ID 做归一化处理（以 App 端匿名 ID 为准）。

那如何打通呢？在实现 App 与 H5 打通的过程中，神策数据经历了三个阶段，相对应地设计三个方案以应对不同时期的需求。

方案一：设想一个场景，你的 App 中嵌入了一个 H5，如果用户启动 App 但没有进行注册或登录，这个时候该如何标识用户？我们可能会用匿名 ID 或者设备 ID 进行标记，但是 H5 和 App 的匿名 ID 生成规则是不一样的，H5 常用的是 Cookie；Android 常用的是 Android ID，或者最近比较流行的 OAID，或者 UUID；在 iOS 系统中，我们常用的是 IDFA，当 IDFA 被限制后，可以用 IDFV。因此，不管是 Android 还是 iOS，在跟 H5 进行混合的时候，用户在产品上没有注册或的登录的时候，会产生两个匿名 ID，就相当于有两个匿名用户存在，这明显与实际不符。

所以我们最初做数据打通时就面临着户标识的问题。在启动内嵌入 H5 的时候，主动把 App 端生成的匿名 ID 传给 H5，这样 H5 产生的所有事件都可以用 App 传来的匿名 ID 进行标识，完成用户标识统一，这是 2016 年神策在处理 App 与 H5 打通的第一版解决方案。

方案二：为了解决数据准确性的问题，神策数据升级出第二版解决方案。

众所周知，在浏览器查看网页的时候，浏览器没有办法获取到用户的设备信息，就像用户在电脑端打开网页，网页无法访问用户的磁盘，在手机端打开网页，它也没有办法访问用户的相机、传感器等，所以 H5 是如何获取设备信息的呢？

一般情况下，H5 通过获取当前 UA 值来做解析；但 UA 值的解析会存在很多问题，主要体现在 Web 和 Android 上，特别是 Android 系统中的很多浏览器，UA 值的规则无法统一，所以经常会遇到以下几种情况：

（1）在数据采集的时候难以解析 UA 值；

（2）解析的数据非真实数据；

（3）对于 Android 和 iOS 来讲，为了实现一些特殊功能，很多开发工程师会获取修改 UA 值。有的工程师会在获取之后进行追加，这是最好的方式；但也有工程师会在获取后替换标准 UA 值，从而导致我们解析不到或者解析到的 UA 值不正确。

在 H5 中触发的事件，通常需要采集其基础属性，如 App 版本号、当前操作系统版本号、操作系统的类型、屏幕尺寸等，此时单纯通过 UA 值无法完成解析，就意味着对“打通”提出了更高要求。

基于此，神策把 H5 产生的事件通过一定的技术，传给 App 集成的数据采集 SDK ，当 App 数据采集 SDK 接收到事件之后，对事件里的属性内容进行二次加工，甚至是修正。一方面保证数据采集的准确性，另一方面保证数据的完整性。

因为神策客户大多数采用私有化部署，神策难以统计用户数据丢失率，但是在业界普遍标准是“App 的数据丢失率在 1% 左右，H5 和 Web 的数据丢失率在 5% 左右”，之所以有 5 倍差异，是因为 H5 的本地缓存是有限的，数据上传失败就意味着丢失；另外，大多情况下 H5 在 App 中以单页面形式存在，H5 发送网络请求之后，如果用户退出页面，其网络请求随之被取消，没有办法实现完全同步，这种情况下数据“打通”便朝着更高要求、高标准迈进——如何“打通”App 与 H5 降低数据丢失率？

App 采集的事件并非实时同步，因为 App 内事件多、频率高，每次采集后立即同步会给服务器带来很大的压力，所以一般情况下，App 内会增加本地缓存，所有采集到的事件先存入本地缓存，达到一定条件后再进行同步。也就是说，根据缓存制定相应的数据同步策略。如果按照以上方案，将 H5 的事件传给 App 进行二次加工，进入 App 端的本地缓存，走 App端事件同步策略，就能大大降低 H5 事件丢失的概率。

这是我们在 App 与 H5 打通的第二版中着重处理的内容，在该解决方案中，不管是用户标识、数据准确性，还是数据完整性，都能得到解决。

方案三：第三版解决方案的问世是神策针对第二版方案持续完善、迭代的结果。

假设场景如下，某 App 内基层 H5 的开发者是第三方供应商。在这个情况下，会产生以下两个问题：

（1）第三方供应商不是神策的客户，没法实现数据采集，更没办法完成“打通”；

（2）第三方供应商是神策的客户，此时 App 与 H5 可以实现真正打通，但很多情况下会被迫收到很多不需要的数据，我们叫“脏数据”，而 H5 的供应商则会发现他们无法采集到完整数据，很多事件“莫名其妙”地丢了……这是因为 App 与 H5 打通后，H5 的事件默认传给了 App。因此，在这种情况下，我们需要对更多的细节进行考虑，通过 H5 给 App 白名单的形式，实现 H5 的向 App 的事件上传。

这个时候，我们就会面临新的场景需求，第三方供应商答应把数据传给 App，但是自己也要求保留一份。综合来看，App 与 H5 的打通看起来是一个比较常见的场景，但在执行的过程中往往面临较多挑战。

从 2016 年到今天，面对 App 和 H5 的打通，我们一直在更新迭代中，目的是为了能够适应各种复杂的场景，特别是涉及第三方开发框架、第三方浏览器等的“打通”。

戳图了解《Android 全埋点解决方案》

案例二：App 启动与退出

1.App 启动 

什么叫“App 启动”？有人说，使用 App 即“App 启动”，那如果使用音乐播放器，播放器退出后台音乐继续播放，这样可以算做“启动”吗？也有人说，用使用时长来定义“App 启动”，那么在当用户在“京东”有支付需求，跳转到“微信”完成支付后又跳转回“京东”内，可以计算为微信的“启动”吗？或者使用“微信”期间有骚扰电话来电，用户立马挂断但中间仍持续了两秒，在这两秒的时间从“微信”跳转到“来电”又转回“微信”，算“启动”吗？

在前几年，手机功能非常多，App、H5 等都是一座座孤岛，随着技术的发展，这些孤岛在当前环境中相互之间建立了连接，实现了打通。那么，我们实现“App 启动”也就会有很多方式：

第一，用户点击图标完成 App 启动，这是我们最常见的启动方式。

第二，通过后台唤醒，也即所谓的“热启动”。

第三，通过 H5 唤醒启动，例如朋友通过微信给你分享了京东的商品，你点击链接后一般情况下会在右上角提示“使用 App 打开”，如果你的手机里安装了京东 App，那么就会实现京东 App 的启动。

第四，通过一个 App 唤醒另外一个 App，比如地图跳转、支付跳转、推送跳转、小程序跳转等。

明确了“App 启动”的定义之后，如何采集 App 启动就是接下来的重要工作，在这个过程中面临如下挑战：

挑战一：是否首次启动

首次启动指的是用户安装 App 后的第一次启动，这个场景通常叫做激活，通过一定的机制去判断是否为首次启动。有人说，可以在本地做标记来区分是否为首次启动，但 Android 和 iOS 系统的设置都可以实现“清除本地缓存”的操作，难以通过本地标记来做区分；也有人说，可以通过 SD 卡完成标记，但读写 SD 卡需要权限，实际操作亦有难度。所以说，如何区分用户是否为首次启动存在着技术上的挑战。

挑战二：冷启动和热启动

很多时候，我们会通过 Home 键让 App 进入后台，但由于时间过长或者系统资源等原因，App 可能会系统被回收，下一次启动其实就变成了冷启动，但是根据我们之前的定义，它实际上还是热启动。所以说，如何判断冷启动和热启动是一件非常复杂的事情。

挑战三：是否从后台恢复

常见从后台恢复方式有两种：①点击图标恢复；②双击 Home 键弹出应用列表，点击应用列表完成恢复。所以说，采集方案能否覆盖以上不同的恢复场景，对技术来说有一定的考验，在数据分析过程中也需要去考虑复杂多变的场景。

挑战四：iOS 被动启动

这个内容很多人没有接触过，也不太了解，这是神策基于某些场景特定发明的。什么叫被动启动？它是 iOS 系统内特有的，比如我们正在使用某个 App，由于一些其他原因将 App 转入后台，过了一定时间（iOS 官方文档内称作“特定时间”），系统会让此 App 进入“僵尸状态”，此时，App 后台会给用户进行推送。在 iOS 设备收到 App 的推送后，会对 App 进行初始化，从第一个页面开始，这个过程对于用户来说是透明的，按照全埋点的采集原理，初始化操作会触发 App 启动和页面浏览事件，此种场景下的启动我们称之为“被动启动”。

正是因此，我们在大概两年多的时间里，经常听到客户抱怨，为什么采集的事件中很多用户只有「启动」和「页面浏览」而没有「退出」？这个问题在当时阶段受技术限制，通常会被粗略判定为“刷量”。随着场景越来越多，我们追求极致，深入探究，最终得以把这个问题搞明白。

但随之而来的是，用户不理解为什么神策采集到的日活数据（通常根据“启动”来判断）比其他工具采集到的量要低，这是因为我们把“正常启动”和“被动启动”做了区分。

这也是跟神策的价值观息息相关，我们要在真实场景中采集真实数据，给企业带来价值。

挑战五：Android 多进程

多进程如何理解？我们常见的很多 App 会有“扫一扫”功能，这个时候必然会用到相机，在 Android 里会有很多 ROM，兼容性复杂，因此“扫一扫”页面很容易崩溃；但是“扫一扫”在 App 中不一定是核心组件，即便它出现了问题，也不应该影响 App 的正常运行。所以一般情况下，会把“扫一扫”的业务逻辑或者页面单独设置一个进程，这样“扫一扫”和主业务可以作为两条独立的、互不影响的进程并行存在。

在这个情况下，会对 Android 内的 App 启动判断带来问题，因为无法判断这两个进程是否来自同一个 App。所以说，Android 和 iOS 的启动的概念是不一样的。

当用户打开了一个页面，与他打开该 App 上一个页面的退出时间如果超过了 30 秒，我们就认为是 Android 内的一次“App 启动”，这个叫“session 机制”；同样，当用户退出了一个页面，30 秒内没有打开新的页面，就会被计算为一次“App 退出”。

挑战六：合规

关于合规，大家了解的比较多，对于神策来说，因为我们的 SDK 是开源的，所以神策 SDK 的采集行为清晰可见，必然是合规的。

那么，合规会对启动产生什么样的影响呢？在数据采集的时候，必然要采集用户的相关信息，比如设备 ID 等，这个时候，“合规”就会要求在数据采集之前必须经过用户同意，也就是我们常见的 App 弹出的隐私政策说明等；另外，数据采集也会涉及到系统权限，只有用户明确同意了，企业才能够去做数据采集相关工作。

但是，以上流程是在用户启动 App 之后才完成的，这个时候就会错过 App 启动的数据采集时机，所以，为了达到合规，对于“App 启动”的采集是有一定影响的。

2.App 退出 

大多数情况下，App 不显示就算作一次退出，常见场景有：用户点击 Home 键；App 崩溃；App 跳转等；但是对于音乐播放器、运动相关等的 App 来说，就需要对应地做一些特殊判断。在采集“App 退出”的过程中，我们同样会面临挑战：

挑战一：App 退出原因

清晰了解用户退出 App 的原因有助于对产品和业务开展分析。

挑战二：App 使用时长

我们不仅要采集“App 退出”的动作，更要了解用户使用 App 的时长。有人说，在“启动”和“退出”分别记录时间戳，通过计算得出 App 使用时长即可，但这个时间戳如何标记？

大多数情况下，我们会用客户端时间来标记时间戳，但是如果用户在“启动”和“退出”之间，手动或者因为网络原因，修改了手机设备时间又会怎样？

通常会有以下几种场景：“退出”减“启动”等于 0 或接近 0；“启动”的日期为 8 月 1 日，“退出”的日期为 8 月 30 日，使用时间过长，或者退出的日期被用户手动调整为 7 月 30 日导致使用时间为负值等，这些情况明显不符合实际。因此，采集 App 使用时长不能纯粹依靠设备时间。

那么，神策是如何应对该挑战的呢？在 Android 和 iOS 两个操作系统中，都有一个特殊功能叫“计数器“，就是说在你的操作系统开机的时候，计数器从 0 开始计数，这也是我们从手机“设置”里能看到的手机开机时长，因此，用这个时间来计算用户的 App 使用时长，得到的数据 100% 是正确的。

挑战三：退出事件补发

前些年有人提出这个场景：假如用户的手机掉水里了，神策能否采集到退出事件？我的回答是，如果用户的手机能从水里拿出来，能正常开机并正常启动 App，那么就可以实现退出事件补发。

什么叫补发？因为用户在使用 App 的时候，可能会随时退出，针对此，我们在用户启动页面的时候，完成计数，每隔一定时间记录一次，如果在用户下一次启动 App 的时候，我们发现这个时间戳还在，但是没有触发启动事件，那么我们就会立即把上一次的退出事件补发。

不管是“启动”还是“退出”，都是我们在实际数据采集与业务分析时的常见场景。神策面对客户的每一个场景、每一个挑战都能迎难而上，这是秉承对客户负责的责任感，更是神策追求极致的表现。

作者介绍

王灼洲先生是《Android 全埋点解决方案》《iOS 全埋点解决方案》作者，神策数据治理研发部负责人。有 10+ 年 Android & iOS 相关开发经验，是国内第一批从事 Android 研发工作，开发和维护国内第一个商用的开源 Android & iOS 数据埋点 SDK。

王灼洲先生曾就职于北京天宇朗通通信设备股份有限公司，担任 Android 系统工程师。毕业于北京理工大学，软件工程专业。

本期分享分为「数据采集」和「数据治理」上下两篇，以上仅涉及数据采集相关内容。“数据治理的方案解读和落地实践”即将推出，敬请期待！

✎✎✎

【相关阅读】

• 我在神策做研发丨 幸好优秀无声，否则震耳欲聋

• 签约丨老乡鸡携手神策数据，共同推动餐饮数字化创新

• 神策数据潘书荟：解读千人千面，洞悉数据智能的价值