一、前言

随着大数据时代的到来,越来越多公司注意到数据带来的价值,开始自建或购买一些第三方的数据平台。从数据流的角度看,平台对于数据的处理,一般有以下几个步骤:

其中,数据采集工作是后面几个步骤的基础,数据采集的丰富性、准确性和及时性,都直接影响整个数据平台的应用效果。神策数据在大数据行为分析和数据采集行业积累了丰富的实战经验,神策数据推出的移动端(Android 和 iOS) 数据采集埋点 SDK 具有安全、透明稳定等特点:

  • 安全:神策分析 SDK 支持 HTTPS 数据传输以及对采集的数据进行加密,保障客户的数据隐私安全;
  • 透明:神策分析 SDK 所有源码都是开源的,SDK 代码托管在 GitHub  上,开源是对客户的一种保障;
  • 稳定:超过 2000+ 家的付费客户使用我们的 SDK,其中包括中国银联、翼支付、中国移动等客户。

在功能上覆盖了代码埋点、全埋点、点击图可视化全埋点等,接下来我们将对这些功能逐一进行介绍。

二、功能介绍

2.1 代码埋点

2.1.1 功能介绍

代码埋点出现的时间很早了,在 Google Analytics 年代,就已经出现了类似的方案了。目前,国内的主要第三方数据分析服务商,如百度统计、友盟等都提供了这一方案。是一种最原始的埋点方式,同时也是 “最万能” 的埋点方式。其实现原理是在 SDK 初始化之后,对于每一个关注的事件,调用 SDK 中的  track  等相关接口,将需要采集的事件名、属性字段等先保存到本地,然后按照一定的发送策略将数据发送到数据服务器。

2.1.2 使用场景

代码埋点有很多优点:

  • 精准控制埋点位置;
  • 灵活的自定义事件和属性,方便采集丰富的业务相关数据;
  • 可以满足精细化的分析需求。

当然,代码埋点也有相应的缺点:

  • 前期埋点成本相对比较大,每一个控件的埋点都需要添加相应的代码;
  • 更新代价比较大,每一次更新埋点方案都需要修改代码并发版;
  • 所有前端埋点方案都会面临的数据传输时效性和可靠性的问题,这个问题就只能通过在后端收集数据来解决了。

因此,代码埋点适用于需要精准控制埋点位置、灵活的自定义事件和属性等精细化需求的场景。

2.2 全埋点

2.2.1 功能介绍

全埋点,也叫无埋点、无码埋点、无痕埋点、自动埋点。全埋点是指无需应用程序开发工程师写代码或者只写少量的代码,就能预先自动收集用户的所有或者绝大部分的行为数据,然后就可以根据实际的业务分析需求从中筛选出所需行为数据并进行分析。

全埋点目前可以采集的事件有:

App 启动事件

是指应用程序启动,同时包括冷启动和热启动场景。热启动也就是指应用程序从后台恢复的情况。
这里需要注意的是,在 iOS 中有一种特殊的启动事件叫 App 被动启动事件。这是一种通过系统后台唤醒的启动事件,事件属性和 App 启动事件相同。对于 iOS 设备,除了用户主动启动 App,设备中某些条件触发时(例如收到通知、用户位置信息变化等),系统可能会唤醒 App,使程序在后台运行。当程序在后台启动并运行时,SDK 触发 App 被动启动事件。 关于 iOS 设备后台启动和运行的更多信息,可参考 Apple 文档 About the Background Execution Sequence

App 退出事件

是指应用程序退出,包括应用程序的正常退出、进入后台、应用程序被强杀、应用程序奔溃等场景触发的事件。这里需要注意在 Android SDK 中有一个 Session 的时间概念,例如应用程序进入后台,并不会马上触发退出事件,需要等待超过一个 Session 时长后才算触发退出事件。

App 浏览页面事件

是指应用程序页面浏览,对 Android 应用来说是指切换 Activity 或 Fragment。对 iOS 应用来说是指 ViewController 的 – viewDidAppear: 被调用。

App 元素点击事件

控件被点击时,触发 App 元素点击事件,例如点击一个 Button。

2.2.2使用场景

全埋点有如下优点:

  • 前期埋点代价相对比较小;
  • 分析需求或事件设计若发生变更,无需应用程序更改埋点和发版;
  • 可以有效的解决 “历史数据回溯” 问题。

同时,全埋点也有一些缺点:

  • 由于技术方面的原因,对于一些复杂的操作,可以覆盖的功能有限,比如缩放、滚动等
  • 无法自动采集业务相关的数据
  • 无法满足更精细化的分析需求
  • 各种兼容性方面的问题(比如不同系统版本之前的兼容性)

因此,可以知道全埋点适用于以较小的埋点代价收集尽可能多的用户行为数据的场景。

2.3 点击图

2.3.1 功能介绍

点击图,即应用一种特殊高亮的颜色形式,显示页面或页面组区域中不同元素点击密度的图示。在上图中,清晰展示某个(些)元素被点击的次数和占比,从而帮助使用者直观的判断用户热衷的区域,评估页面设计的科学性。点击图功能依赖于全埋点中的点击事件,因此需要先开启全埋点点击事件的采集。开启点击图后,点击事件会采集控件路径信息属性。

2.3.2 使用场景

一般而言,大多数用户行为分析产品的功能,是将发生在多页面的用户行为采集并进行分析。但运营人员难于知道:特定某页面上用户都进行了哪些具体操作?这些操作都发生在什么位置?点击图能够帮助运营人员了解用户和页面上各元素的交互情况,判断哪些元素对用户最有吸引力,为优化和调整页面设计提供了科学依据。然而,在使用 “点击图” 功能时,以下两个问题值得注意:

  1. 不要忽视位置等因素对点击率的影响,以及元素之间的交叉影响。点击分析的目的和页面上某个元素所处的位置密切相关,但我们在分析时常常忽视位置对点击次数和占比的影响,也不会在意页面上其他元素受到的交叉影响。
  2. 仅通过页面的整体表现,是无法实现精细化运营的。基础的点击分析功能是对页面宏观层面的了解,仅能从中知道页面上各元素的整体表现,功能相对基础,无法满足精细化运营需求。

2.4 可视化全埋点

2.4.1 功能介绍

可视化全埋点,是指通过可视化的方式进行埋点。它的前提是要开启全埋点,然后通过设备连接神策分析的可视化全埋点界面,该界面上标识了已埋点元素和可埋点元素,对于可埋点元素可以创建新的埋点,并标识显示名和事件名;对于已埋点元素只能修改显示名。可视化全埋点的实现原理与创建 虚拟事件 基本类似,是基于全埋点的 App 元素点击事件创建虚拟事件;若该事件删除后再次被添加,则历史数据也会生效。

2.4.2 使用场景

可视化全埋点对非技术人员是很友好的一个功能,它在全埋点基础上提供了自定义配置的功能,同时避免了代码埋点的繁琐,降低研发成本的同时也提高了分析的效率。

三、数据采集和发送

一般来说,数据采集分为三种方式:客户端埋点、服务端埋点和工具导入(历史数据导入)。我们目前讨论的是移动端,直接使用 SDK 进行埋点就可以实现数据采集。采集的数据需要同步到服务端,然后再经过服务端的存储、抽取、分析和展现,才能充分发挥数据的价值。因此,下面我们主要介绍如何发送采集的数据:

默认情况下,为了保证用户体验、减少性能和电量损耗,SDK 中事件触发后不会立即上报,而是先将事件缓存在本地,然后定时、批量进行上报。如果预制的条件不满足需求,可以在 SDK 初始化后,调用相关接口修改发送条件,如设定触发发送条目数、发送时间间隔以及是否在 App 进入后台时发送数据等,来定制自己的需求。下面我们来看下具体的数据发送策略。

3.1 普通模式

SDK 每次触发事件时会检查如下条件,以判断是否向服务器上传数据:

  1. 当前网络是否符合「预设的允许发送网络策略 flushNetworkPolicy」 (2G、3G、4G、5G、WiFi);
  2. 与上次发送的时间间隔是否大于「预设的发送时间间隔 flushInterval」 (默认 15 秒);
  3. 本地缓存的事件条目数是否大于「预设的触发发送条目数 flushBulkSize」 (默认 100 条);
  4. 当 App 进入后台时是否立即尝试发送数据(默认 YES)。

只有 1、2 或 1、3 或 1、4 满足时,SDK 才会进行发送数据。以上参数支持自定义,可以通过修改相应参数值来达到控制事件上报的频率。

3.2 Debug 模式

在 Debug 模式下,对于任何操作,无论什么网络条件,都会立即发送数据,并校验返回的结果。

注意:Debug 模式是为方便开发者调试而设置的模式,该模式会逐条校验数据并在校验失败时抛出异常,性能远低于正常模式。线上环境使用 Debug 模式会严重影响性能并存在崩溃风险,产品上线前请务必替换掉/关闭 Debug 模式。

3.3 手动触发

用户可以在任何时候,调用 「flush 接口」来尝试发送本地数据。当数据发送失败时,会继续缓存在本地;发送成功后,事件数据会被删除。当缓存数据量超过「最大缓存阈值」时,会删除最旧的 100 条数据,然后再存入新的数据。

四、总结

本文对于神策数据官方移动端 SDK 的功能进行了简明扼要的介绍,旨在让大家对于 SDK 的功能有一个初步的了解。关于 SDK 的具体使用和实现原理等相关知识,会在后续的文章中逐步向大家介绍。