一键采集上传常见的细节问题(一下主流的前端埋点方案的技术细节做一个方案介绍)

　　一键采集上传常见的细节问题(一下主流的前端埋点方案的技术细节做一个方案介绍)

　　内容

　　在这个文章中，我们将解释数据采集的一些基本概念，然后我们将重点介绍目前市场上一些新的前端埋点技术，例如视觉埋点和“无埋点” ”。对“dot”的技术细节做一个具体的介绍，并说明自己对这些技术的一些理解和认识。

　　数据的核心问题采集

　　一个典型的数据平台，用于数据处理，由以下5个步骤组成：

　　

　　其中，我们认为第一步，即数据采集是核心问题。采集的数据是否丰富，采集的数据是否准确，采集是否及时，都直接影响到整个数据平台的应用效果。

　　虽然我们知道前端埋点有些问题。例如，需要等待网络状况良好才能发送数据，需要积累一定的数据才能发送数据，需要在本地临时存储且本地临时存储空间有限，以及数据传输和数据可靠性的一系列问题。但是有一些后端采集数据是前端埋点无法替代的。比如分析前端界面设计是否合理，分析一些前端不与后端交互的行为等等，还是需要用到前端埋点。方案。前端埋点是一种比较成熟、应用广泛的数据访问方式。因此，在这里，

　　一、什么是埋点

　　将采集数据定期固定地放置在目标应用程序/网站上，并以日志的形式上报给服务器的过程。

　　二、为什么要埋东西

　　企业端获取用户对产品的使用数据并进行分析，方便产品优化迭代。

　　三、埋点方法有哪些

　　3.1个代码埋点

　　代码嵌入点很早就出现了。在谷歌分析时代，类似的方案已经出现。目前国内主要的第三方数据分析服务商，如百度统计、友盟、TalkingData等都提供了该解决方案。

　　它的技术原理也很简单。APP或接口初始化时，会初始化第三方数据分析服务商的SDK，然后当有事件发生时，调用SDK中对应的数据发送接口发送数据。比如我们要统计APP中某个按钮的点击次数，当APP的某个按钮被点击时，可以在该按钮对应的OnClick函数中调用SDK提供的数据发送接口来实现发送数据。

　　下面，我们看一下友盟提供的两个例子。

　　第一个例子是统计用户在一个Android APP中访问一个由Activity组成的页面的次数。以下是友盟官方给出的例子：

　　public void onResume() {  

    super.onResume();

    MobclickAgent.onPageStart("SplashScreen"); //统计页面(仅有Activity的应用中SDK自动调用，不需要单独写。"SplashScreen"为页面名称，可自定义)

    MobclickAgent.onResume(this);          //统计时长

}

public void onPause() {  

    super.onPause();

    MobclickAgent.onPageEnd("SplashScreen"); // （仅有Activity的应用中SDK自动调用，不需要单独写）保证 onPageEnd 在onPause 之前调用,因为 onPause 中会保存信息。"SplashScreen"为页面名称，可自定义

    MobclickAgent.onPause(this);

}

　　这个例子其实很简单，就是在Activity控件对应的触发函数中调用友盟提供的接口统计。

　　第二个例子稍微复杂一些。不再是统计页面访问等默认事件，而是自定义事件。例如，对于一个电商APP，当用户点击“购买”按钮，想要统计自定义事件“购买”对应的信息时，可以使用如下代码：

　　HashMap map = new HashMap();  

map.put("type","book");  

map.put("quantity","3");  

MobclickAgent.onEvent(mContext, "purchase", map);  

　　需要说明的是，友盟归根结底还是一个统计工具，并没有提供完整的多维分析功能。更别说数据传输的时效性和自定义属性的各种限制了，只是针对某个值的统计而已。联盟还需要分别区分“计数事件”和“计数事件”，这具有一定的局限性。

　　从以上两个例子可以看出，code embedding的好处在于，一方面用户控制精准，可以非常准确地选择何时发送数据；同时，用户可以更轻松地设置自定义属性、自定义事件和传输。向服务器提供更丰富的数据。

　　当然，代码埋点也有一些弊端。首先，埋点成本比较高，每个控件的埋点都需要添加相应的代码，不仅工作量大，而且限制了必须由技术人员完成; 其次，更新成本比较高，埋点方案每次都要更新。，必须改代码，然后通过各个应用市场分发，总会有相当多的用户不喜欢更新APP，所以嵌入代码不会更新；最后，所有的前端嵌入解决方案都将面临数据传输的及时性和可靠性问题，只能通过在后端采集数据来解决。

　　3.2 埋点可视化

　　从前端埋点到可视化埋点其实是一个非常合乎逻辑的进化。既然埋点成本高，而且每个埋点都需要写代码，那么，参考Visual Studio等一系列现代IDE的做法，用可视化交互手段代替写代码；既然每次埋点更新都需要等待APP的更新，那么，参考现在很多手游的做法，将核心代码从配置和资源中分离出来，在APP启动时通过网络更新配置和资源。

　　正是出于这种自然的做法，在国外，以Mixpanel为首的数据分析服务商陆续提供了视觉埋点解决方案，Mixpanel称之为无代码。国内的TalkingData、诸葛IO等也提供了类似的技术手段。顺便说一下，在1.3 版本的更新中，Sensors Analytics 也为用户提供了可视化埋藏方案，以降低用户的数据访问成本。

　　需要强调的是，Mixpanel 已经无私地开源了他们的 iOS 和 Android SDK 的源代码。我们在开发过程中也参考了他们的贡献，并促成了一些 bug 的提交。感谢 Mixpanel 对整个领域的贡献。贡献。

　　3.2.1 Android平台可视化点

　　下图演示了一个简单的 iOS SDK 使用 Mixpanel 的无代码埋葬功能：

　　

　　从这个界面可以看出，使用起来还是很简单的。单击支持的控件类型的实例。在这个例子中，是右上角的刷新按钮，然后在弹出窗口中，设置按钮发送“刷新”。事件。然后单击 Deploy 按钮将这个配置发送下来。然后，所有在 Mixpanel 中嵌入 SDK 的应用程序都会在应用程序启动时或定期获得相应的配置。将来，当真实用户单击此按钮时，它实际上会向后端发送“刷新”事件。

　　3.3“无埋点”

　　和可视化的埋点一样，“无埋点”的解决方案出现的时间也比较早。作为第三方数据分析服务商，Heap早在2013年就已经推出了“无埋点”技术方案。而如果不限于第三方，百度在2009年就已经有了“点击猴”技术，使用的是非埋点技术。埋藏方案，分析页面各个元素的点击情况；2011年，百度质量部还推出了一项内部服务，用于记录Android App的所有操作，并通过回放找出App崩溃的原因；而豌豆荚也是2013年左右。在自己的App中，添加了所有控件的操作记录。. 第三方数据分析服务GrowingIO也在2015年推出了类似Heap的服务。

　　下图是一个使用 Heap 的例子：

　　

　　从接口的角度来看，它与视觉嵌入点非常相似。从实际实现来看，两者的区别在于需要通过可视化埋点的接口配置来采集哪些控件的运行数据；“无埋点”就是尽可能采集所有控件的运行数据，然后通过界面配置系统中需要分析哪些数据。

　　与可视化埋点相比，“无埋点”的优势在于解决了数据“回溯”的问题。比如某天，突然想增加某个控件点击的分析。如果是可视化埋点方案，那么数据只能从这一刻开始向后采集，如果是“无埋点”，则从SDK部署时开始采集数据；另一方面，“无埋点”解决方案也可以自动获取很多启蒙性信息，例如“无埋点”可以告诉用户这个界面上的每个控件被点击的可能性有多大，哪些控件是值得进一步分析，等等。

　　当然，与可视化埋点一样，“无埋点”仍然没有解决覆盖功能的优先级、无法灵活定制属性、传输时效性和数据可靠性差的缺点。即使因为所有的控制事件都被采集起来，也会给服务器和网络传输带来更大的负载。

　　四、各种埋法优缺点对比

　　各种采集方案的数据采集能力对比

　　上一节我们介绍了三种前端埋点方案：代码埋点、视觉埋点、“无埋点”，并强调我们始终推荐后端采集数据。所以，在这里，我们觉得有必要对比一下可视化埋点、代码埋点和后端采集数据三种方案在数据获取能力上的差异。要点基本一致，这里不再单独列出。

　　(1) 代码埋点

　　原理：当应用App或界面初始化时，埋点的SDK被初始化，当某个节点（如事件/页面）被触发时调用SDK对应的方法，并通过发送数据界面。一般来说，为了减少用户上报数据时对过多流量的消耗，常见的解决方案有两种：

　　（一)进行数据映射（简化数据，不传递具体参数值，而是根据MAP-KEY映射关系）。比如应用发送(0/0、1/)数据，服务器会根据协议，将文档映射到(Homepage/Module一、第二次点击事件)；

　　（二) 非立即发送数据，压缩打包多条数据，等待网络良好或定时发送到服务器（5min）。

　　优势：

　　个性化定制，可根据企业业务特点定制属性和事件，获取定制化数据。

　　缺点：

　　（一)人工成本高。埋点项目涉及从运营-产品-前端-服务器-后端的一系列所有数据团队。不同的系统/版本不容易管理。所有方法都需要手动注入，数据采集后，由服务器分析；

　　（二)版本更新前后，容易出现数据混乱（如果重要负责人辞职，相关文件没有沉淀，可能会造成“前功尽弃”）；

　　（三) 上手难度大，前期简单统计；需要公司长期稳定提升，根据业务不断更新。

　　（2)可视化埋点（也称框架埋点）

　　原则：将核心代码与资源和配置分开。当应用程序启动时，从服务器更新配置和资源（plist）。通知应用后，根据配置和部署信息上报数据内容。

　　优势：

　　解决代码嵌入人工成本和更新成本高的问题。只要版本中有对应的SDK，老版本迭代后不会出现embedding问题；而对于不懂代码的产品操作，可以通过后台可视化界面操作进行配置，并生效。

　　缺点：

　　（一)无法自定义数据采集，可视化埋点覆盖功能有限；

　　（二)对于企业来说，SDK开发难度大于代码嵌入，使用第三方SDK资源存在共性问题，下面解释一下。

　　(3) 无埋点(全埋点)

　　原理：在App内嵌入SDK，统一“全埋点”，尽可能多的在App内丢数据采集，通过接口配置定义关键行为，对定义的数据进行分析。

　　实现方法：

　　SDK嵌入在应用程序中，通过可视化方法（即上面的可视化方法）定义对象。服务器分析定义的数据并在后台显示。

　　优势：

　　为嵌入点提供“后悔药”（数据回溯问题）。只要部署了SDK，数据就会开始采集；可以自动获取大量启蒙信息，通过热图点击向用户展示各种控件和事件的概率更大；方便用户查找页面僵尸按钮等。

　　缺点：

　　（一)缺点和视觉埋点一样，没有解决个性化、定制化的数据获取问题，缺乏数据获取的灵活性；

　　（二)企业开发SDK难度较大，一般由数据分析公司提供，采用第三方提供的埋点方案，存在以下缺陷：

　　1、 数据源丢失，应用上报的数据上传到第三方服务器，可能导致公司泄露或丢失用户关键数据；

　　2、供应商数据丢包问题无法根据应用特点改善。

　　五、其他

　　（1)目前流行的第三方数据产品体验

　　（一) 友盟，阿里数据分析产品，通用功能覆盖，部分特定页面缺失，定制性弱，适合初创企业应用。

　　（二) Google Analytics个人体验更好，可以满足个人网页和应用所需的数据埋点。更喜欢展示数据结果，缺点是需要翻墙查看；

　　（三)神策数据。位于上海的神策公司可以根据企业部署特定服务器，进行个性化定制，并有相应的业务员和开发工程师进行企业*敏*感*词*对接，服务体验比较好；但是数据分析背景不在工作范围内，没有经历过，也没有深入研究过；

　　（四)诸葛io，国内领先的数据分析公司，2013年在国内率先推出非埋点解决方案，但有运营朋友表示丢包比较严重，没有确认是否准确。

　　其他知名数据产品：TalkingData、Mixpanel之前没用过，希望能分享给大神们，或者用完后再补充。

　　最后，数据埋藏团队必须保留数据埋藏标准定义文档。如果埋地队的相关负责人辞职，就会形成一个大坑。

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

　　（1) 为什么报告的数据粒度级别最好是“原子”最小化和报告而不是关系链？

　　关系链的上报虽然很方便还原用户的真实操作，但是服务器根据用户访问的时间顺序将事件连接起来，一步步分析，非常方便关系跳转的挖掘；但是对于快速迭代的应用产品，一旦产品相关的逻辑发生变化，所有的业务分析（服务器）和逻辑关系（前端）都必须重写。对于前端服务器来说，这将是巨大的人力投入和新旧版本的数据关系链之间的冲突。

　　（2) 代码嵌入方式需专门负责人长期稳定“付费”

　　一旦数据被埋没，产品运营已经形成了数据量化、数据驱动决策的习惯，就必须进行持续的维护。由于数据埋藏在研发团队中，需要高额的人力资源；在测试位置时，需要进行完整的覆盖测试，以确保没有遗漏。

　　参考连接：

　　1、

　　2、