代码埋点、可视化埋点、无埋点几种数据埋点方案的分析报告

代码埋点、可视化埋点、⽆埋点⼏种数据埋点⽅案的分析报告

⽬录

在这篇⽂章⾥⾯，我们会对数据采集的⼀些基本概念进⾏阐述，然后，会针对⽬前市⾯上新增的⼀些前端埋点技术，如可视化埋点与“⽆埋

点”的技术细节做⼀个具体的介绍，并且阐述⼀些⾃⼰对于这些技术的理解和认识。

数据采集的核⼼问题

⼀个典型的数据平台，对于数据的处理，是由如下的5个步骤组成的：

其中，我们认为，第⼀个步骤，也即数据采集是最核⼼的问题。数据采集是否丰富，采集的数据是否准确，采集是否及时，都直接影响整个

数据平台的应⽤的效果。

虽然我们知道前端埋点的⼀些问题。例如，需要等待⽹络情况良好才能发送数据，需要积攒⼀定的量才发送数据，需要在本地暂存⽽本地暂

存空间有限等⼀系列在数据传输性和数据可靠性上的⼀些问题。但是，前端埋点毕竟有⼀些后端采集数据所⽆法替代的地⽅，例如，分析前

端界⾯设计是否合理，分析⼀些在与后端没有交互的前端⾏为等，还是必须采⽤前端埋点⽅案的。前端埋点作为⼀个⽐较成熟并且被⼴泛采

⽤的数据接⼊⼿段。因此，在这⾥，我们觉得有必要详细介绍⼀下⽬前市⾯上主流的前端埋点⽅案的技术细节，并且结合我们的产品，来阐

述我茶宠 们对于这些埋点⽅案的⼀些看法。

⼀、埋点是什么

定时、定点地在⽬标应⽤/⽹站上采集数据，将数据以⽇志的⽅式上报⾄服务器的过程。

⼆、为什么要埋点

企业⽅获得⽤户在产品上的使⽤数据，分析后利于产品优化迭代。

三、埋点有哪些⽅式

3.1 代码埋点

代码埋点出现的时间很早了，在 Google Analytics 年代，就已经出现了类似的⽅案了。⽬前，国内的主要第三⽅数据分析服务商，如百度

统计、友盟、TalkingData 等都提供了这⼀⽅案。

它的技术原理也很简单，在APP或者界⾯初始化的时候，初始化第三⽅数据分析服务商的SDK，然后在某个事件发⽣时就调⽤SDK⾥⾯相

应的数据发送接⼝发送数据1寸照片排版 。例如，我们想统计APP⾥⾯某个按钮的点击次数，则在APP的某个按钮被点击时，可以在这个按钮对应的

OnClick 函数⾥⾯调⽤SDK提供的数据发送接⼝来发送数据。

下⾯，我们看友盟提供的两个例⼦。

第⼀个例⼦是在使⽤者的某个 Android APP ⾥⾯，统计某个由 Activity 构成的页⾯的访问次数，下⾯是友盟官⽅给出的例⼦：

public void onResume() {

me();

Start("SplashScreen"); //统计页⾯(仅有Activity的应⽤中SDK⾃动调⽤，不需要单独写。"SplashScreen"为页⾯名称，可⾃定义)

me(this); //统计时长

}

public void onPau() {

e();

e(this);

}

End("SplashScreen"); // （仅有Activity的应⽤中SDK⾃动调⽤，不需要单独写）保证 onPageEnd 在onPau 之前调⽤,因为 onPau 中会保

这个例⼦其实⾮常简单，就是在 Activity 控件相应的触发器函数⾥⾯，调⽤友盟提供的接⼝统计数据即可。

第⼆个例⼦稍微复杂点，它不再是统计页⾯访问这样⼀个默认的事件，⽽是统计⼀个⾃定义事件。例如，⼀个电商APP，在⽤户点击“购

买”按钮时，想统计“购买”这个⾃定义事件的相应信息，那么，可以使⽤下⾯的代码：

HashMap map = new HashMap();

("type","book");

("quantity","3");

t(mContext, "purcha", map);

必须说明的是，友盟归根结底还是⼀个统计⼯具，并没有提供完整的多维分析功能，姑且不算数据传输的时效性以及对⾃定义属性上的各种

限制，仅仅是为了统计某个数值，友盟还要单独区分出“计数事件”和“计算事件”，这⼀点上，就有⼀定的局限性

从上⾯这两个例⼦可以看出，代码埋点的优点是⼀⽅⾯使⽤者控制精准，可以⾮常精确地选择什么时候发送数据；同时使⽤者可以⽐较⽅便

地设置⾃定义属性、⾃定义事件，传递⽐较丰富的数据到服务端。

当然，代码埋点也有⼀些劣势。⾸先，埋点代价⽐较⼤，每⼀个控件的埋点都需要添加相应的代码，不仅⼯作量⼤，⽽且限定了必须是技术

⼈员才能完成；其次是更新的代价⽐较⼤，每⼀次更新埋点⽅案，都必须改代码，然后通过各个应⽤市场进⾏分发，并且总会有相当多数量

的⽤户不喜欢更新APP，这样埋点代码也就得不到更新了；最后，就是所有前端埋点⽅案都会⾯临的数据传输时效性和可靠性的问题了，这

个问题就只能通过在后端收集数据来解决了。

3.2 可视化埋点

从前端埋点到可视化埋点其实是⼀个赛尔号之圣魔之战 ⾮常顺理成章的演进。既然埋点代价⼤，每⼀个埋点都需要写代码，那么，就参考 Visual Studio 等⼀

系列现代 IDE 的做法，⽤可视化交互⼿段来代替写代码即可；既然每次埋点更新都需要等待APP的更新，那么，就参考现在很多⼿游的做

法，把核⼼代码和配置、资源分开，在APP启动的时候通过⽹络更新配置和资源即可。

正是出于这种⾃然⽽然的做法，在国外，以 为⾸的数据分析服务商，都相继提供了可视化埋点的⽅案，Mixpanel将之称作为 codeless。

⽽国内的 TalkingData、诸葛IO 等也都提供了类似的技术⼿段。 顺带⼀提，个人简历个人评价 Sensors Analytics 在1.3版本的更新中，也已经给使⽤者提

供可视化埋点⽅案，以降低使⽤者的数据接⼊成本。

特别需要强调的是，Mixpanel ⾮常⽆私地开源了它们的iOS 和 Android 端的 SDK 的，我们在开发中也参考了它们的贡献，并且也贡献了

⼀些 bug 的提交，⾮常感谢 Mixpanel 对整个领域的贡献。

3.2.1 Android 平台的可视化埋点

下图是演⽰⼀个简单的 iOS SDK 使⽤ Mixpanel 的 codeless 埋点功能：

从这个界⾯可以看出，使⽤起来还是⾮常简单的，点击某个⽀持的控件类型的实例，这个例⼦中是右上⾓的刷新按钮，然后在弹出的窗⼝

中，设置点击这个按钮是发送 “Refresh” 事件。然后点击 Deploy 按钮，把这个配置下发下去。那么，所有安装有嵌⼊了 Mixpanel 的

SDK 的这个 APP ，则都会在 APP 启动时或者定时获取相应的配置。以后，真实的⽤户使⽤时，点击这个按钮，就会真正地发送

“Refresh” 事件到后端了。

3.3 “⽆埋点”

与可视化埋点⼀样，“⽆埋什么是预算 点”这个⽅案也出来的⽐较早，作为⼀个第三⽅数据分析服务商，在2013年就已经推出了“⽆埋点”这个技术

⽅案。⽽如果不局限于第三⽅，百度在2009年就已经有了“点击猴⼦”这个技术，⽤⽆埋点的⽅案分析⼀个页⾯各个元素的点击情况；在

2011年，百度质量部也推出了⼀项内部服务，⽤以录制安卓 App 的全部操作，并且进⾏回放，以便找出 App 崩溃的原因；⽽豌⾖荚⼤约

也在2013年左右，在⾃⼰的 App 内部，添加了对所有控件的操作情况的记录。第三⽅数据分析服务GrowingIO 在2015年，也推出了类

似于 Heap 的服务。

下图是⼀个使⽤ Heap 的例⼦：

从界⾯上看，和可视化埋点很像。⽽从实际的实现上看，⼆者的区别就是可视化埋点先通过界⾯配置哪些控件的操作数据需要收集；“⽆埋

点”则是先尽可能收集所有的控件的操作数据，然后再通过界⾯配置哪些数据需要在系统⾥⾯进⾏分析。

“⽆埋点”相⽐可视化埋点的优点，⼀⽅⾯是解决了数吃什么防辐射 据“回溯”的问题，例如，在某⼀天，突然想增加某个控件的点击的分析，如果是可

视化埋点⽅案，则只能从这⼀时刻向后收集数据，⽽如果是“⽆埋点”，则从部署 SDK 的时候数据就⼀直都在收集了；另⼀⽅⾯，“⽆埋

点”⽅案也可以⾃动获取很多启发性的信息，例如，“⽆埋点”可以告诉使⽤者这个界⾯上每个控件分别被点击的概率是多⼤，哪些控件值

得做更进⼀步的分析等等。

当然，与可视化埋点⼀样，“⽆埋点”依然没有解决覆盖的功能优先，不能灵活地⾃定义属性，传输时效性和数据可靠性⽋佳这⼏个缺点。

甚⾄由于所有的控件事件都全部搜集，反芍药的功效与作用 ⽽会给服务器和⽹络传输带来更⼤的负载。

四、各埋点⽅式优劣对⽐

各种不同采集⽅案的数据获取能⼒的对⽐

在前⾯，我们已经介绍了代码埋点、可视化埋点、“⽆埋点”三种前端埋点⽅案，⽽也强调了我们⼀直推荐在后端采集数据。因此，在这

⾥，我们觉得有必要⽐较⼀些可视化埋点、代码埋点与后端采集数据三种⽅案在数据获取能⼒上的差异，“⽆埋点”的数据获取能⼒与可视

化埋点基本相当，在这⾥不再单独罗列。

(1) 代码埋点

原理：在应⽤App或界⾯初始化时，初始化埋点的SDK，在触发某个节点(如事件/页⾯)时调⽤SDK相应的⽅法，通过接⼝发送数据。通常

为了减少⽤户上报数据上海居民医保 时消耗过多流量，常见有两种解决⽅案：

(⼀) 进⾏数据映射(简化数据，不传具体参数值，⽽是根据MAP-KEY映射关系)，如应⽤端发送(0/0、1/)数据，由服务端将根据约定⽂档

映射为(⾸页/模块⼀、第⼆个点击事件)；

(⼆) ⾮即时发送数据，将多条数据压缩打包，等待⽹络状况良好、或定时(5min)发送⾄服务端。

优点：

个性化⾃定义，能够根据企业⾃⾝业务特性⾃定义属性、事件，定制化获取数据。

缺点：

(⼀) ⼈⼒成本⾼，埋点⼯程涉及到由运营-产品-前端-服务端-后台⼀系列所有数据团队，不同系统/版本不易管理，所有⽅法均需⼈⼯注⼊，

数据收集后需由服务端进⾏分析；

(⼆) 版本更新前后，容易发⽣数据紊乱(若发⽣重要负责⼈离职，⽆相关⽂档沉淀，则可能造成“前功尽弃”的情况)；

(三) 起步难，前期为简单计数；需要企业长期且稳定地完善、不断根据业务更新。

(2) 可视化埋点(⼜称为框架化埋点)

原理：将核⼼代码与资源、配置分开，当应⽤App启动时从服务端更新配置和资源(plist)，应⽤获知后，根据配置和部署信息相上报数据内

容。

优点：

解决了代码埋点⼈⼒成本和更新代价⼤的问题，只要在版本内有相应SDK，即不存在⽼版本迭代后⽆埋点问题；且对于不懂代码的产品运

营，可通过后台可视化界⾯进⾏配置操作，并且⽣效。

缺点：

(⼀) ⽆法做到⾃定义获取数据，可视化埋点覆盖的功能有限；

(⼆) 企业针对SDK开发难度相⽐代码埋点⼤，使⽤第三⽅SDK资源则有共同通病，下⽂说明。

(3) ⽆埋点(全埋点)

原理：在App中嵌⼊SDK，做统⼀的“全埋点”，将应⽤App中尽可能多的数据采集下来，通过界⾯配置的⽅式对关键⾏为进⾏定义，对定

义的数据进⾏分析。

实现⽅式：

在应⽤中嵌⼊SDK，通过可视化⽅式(即上⽂可视化埋点⽅式)，针对对象进⾏定义，服务端对定义的数据进⾏分析，后台加以展现。

优点：

提供了埋点的“后悔药”(数据回溯问题)，只要部署了SDK，数据便开始采集；可以⾃动获取很多启发性的信息，可以通过热⼒图向⽤户展

⽰各个控件、事件点击的概率更⼤；便于使⽤者发现页⾯僵⼫按钮等等。

缺点：

(⼀) 缺点与可视化埋点相同，未解决个性化⾃定义获取数据的问题，缺乏数据获取的灵活性；

(⼆) 企业针对SDK开发难度较⼤，⼀般由数据分析企业研发提供，使⽤第三⽅提供的埋点⽅案，有如下缺陷：

1、数据源丢失，应⽤上报的数据上传⾄第三⽅服务端，可能造成企业泄密或⽤户的关键数据丢失；

2、供应商数据丢包问题，⽆法根据应⽤特性进⾏改善。

五、其他

(1) 当前流⾏的第三⽅数据产品体验

(⼀) Umeng，阿⾥旗下的数据分析产品，通⽤性功能均有覆盖，在部分特定页⾯上有缺失，定制化弱，适合初创起步的企业应⽤。

(⼆) Google Analytics，个⼈使⽤体验较好，对个⼈⽹页、应⽤所需的数据埋点都能满⾜，对数据结果展⽰较为喜欢，缺点是需翻墙查

看；

(三) 神策数据。位于上海的神策公司，可根据企业部署特定服务器，针对个性化定制，并且晋升空间 有对应业务员、开发⼯程师进⾏企业⼀对⼀对

接，服务体验较为良好；但数据分析后台⾮⼯作范围内，未详细体验、研究过；

(四) 诸葛io，国内领先、先⾏的数据分析公司，2013年是国内⾸家最早推出⽆埋点⽅案，但有运营朋友说丢包较为严重，未确认翔实与

否。

其他较为知名的数据产品：TalkingData、Mixpanel未使⽤过，希望有⼤神分享，或之后使⽤后补充。

最后的叮嘱，数据埋点团队⼀定要留好数据埋点的规范定义⽂档，若发⽣团队埋点相关负责⼈离职，就会形成⼤坑。

Ps：其他思考问题整理如下：

(1) 为什么上报的数据颗粒级最好是“原⼦”最⼩化上报⽽⾮关系链上报？

虽然关系链上报对于还原⽤户的真实操作⾮常⽅便，服务端根据⽤户访问的时间序列，将事件串联，⼀步步分析，对于关系跳转挖掘很是⽅

便；但对于快速迭代的应⽤产品，⼀旦产品相关逻辑变动，则所有业务分析(服务端)、逻辑关系(前端)须重写，对于前端-服务端都将是巨⼤

的⼈⼒投⼊，以及新⽼版本的数据关系链冲突问题。

(2) 需要有专门负责⼈长期且稳定对代码埋点⽅式进⾏“买单”

⼀旦数据进⾏埋点，且产品运营形成数据量化结果、以数据驱动决策的习惯后，则必须进⾏持续维护。因为数据埋点研发团队，需花费较⾼

的⼈⼒资源；测试点位时，要求完整覆盖性测试，确保⽆遗漏。

参考连接：