无需规则自动采集(数据采集的重要性本篇方案详细聊数据)

　　无需规则自动采集(数据采集的重要性本篇方案详细聊数据)

　　相信业务团队对这样的场景不会太陌生：

　　因此，数据非常重要。接下来，我们将详细讨论数据采集的重要性，数据的划分，采集的方法，以及微信小程序中的埋点方案。数据采集。

　　一、数据的重要性采集

　　在本文中，我们关注数据采集。我们暂且不详细讨论数据的作用。首先，我们将总结数据在性能优化、业务增长和在线故障排除方面的重要作用。这就是为什么我们需要埋点。

　　数据对在线排查的作用：数据对性能优化的作用：数据对业务增长的作用：二、采集数据划分与排序

　　从第一点开始，我们总结了数据的重要性。不同的业务项目对数据重要性的重视程度不同。那么采集采集应该是什么数据呢？

　　一、闭环数据包括：

　　用户行为用户信息、CRM（客户关系）交易数据、服务器日志数据

　　以上三项数据可视为一个完整的数据流闭环。当然，不同业务场景下的数据还可以进一步细分，一般的重点基本不超过这三项。对于前端的数据采集来说，闭环数据中的前两项主要是客户端上报，而第三点主要是服务端记录，客户端辅助，因为事务请求只有在事务请求到达服务器完成处理。一个闭环。用户行为数据还包括时间（when）、地点（where）、人（who）、交互（how）、交互内容（what）五个元素，与新闻的五个元素有些相似；部分用户信息业务涉及用户敏感信息和隐私需要授权，因此用户信息的具体维度由业务场景决定。最基本的数据要求是唯一标识用户；CRM、交易数据和用户信息类似，具体需要的数据细节由业务场景决定。CRM 基本数据要求是登录信息和会员相关信息。交易数据包括——交易时间、交易对象、交易内容、交易金额、交易状态。所需的具体数据细节由业务场景决定。CRM 基本数据要求是登录信息和会员相关信息。交易数据包括——交易时间、交易对象、交易内容、交易金额、交易状态。所需的具体数据细节由业务场景决定。CRM 基本数据要求是登录信息和会员相关信息。交易数据包括——交易时间、交易对象、交易内容、交易金额、交易状态。

　　三、数据上报方式

　　说完数据，接下来就是要知道如何获取我们真正需要的数据了。数据上报方式大致可分为三类：

　　第一种是代码埋点，即在需要埋点的节点手动调用接口上传埋点数据。优盟、百度统计等第三方数据统计服务商大多采用此方案；

　　第二种是可视化掩埋，即通过可视化工具配置采集节点，在前端自动解析配置并上报掩埋数据，从而实现所谓的“无痕掩埋”，代表开源的 Mixpanel；

　　第三类是“无埋点”。确实不需要埋点，但是前端自动采集所有事件并上报埋点数据，在后端数据计算的时候过滤掉有用的数据，代表解决方案就是国内的GrowingIO。

　　重点是非埋点。可视化埋点其实可以看成是无埋点的推导。所以可视化埋点这里不讨论，主要是对比代码埋点和无埋点。

　　3.1 代码嵌入或嵌入捕获模式的缺点

　　对于数据产品：

　　依靠人类经验和直觉判断。

　　业务相关埋点的位置需要数据产品或业务产品的主观判断，而技术相关的埋点需要技术人员的主观判断。沟通成本高

　　确定数据产品所需的数据，需要提出要求并与开发沟通，数据人员对技术不是特别熟悉，需要与开发人员明确相关是否可行可以上报信息。有数据清洗成本

　　随着业务的变化，主观判断所需的数据也会发生变化和变化。这时候需要手动清理之前管理的数据，清理的工作量不小。

　　对于开发：

　　开发人员的努力

　　对于业务团队来说，埋点往往会被相关开发者诟病。开发技术人员不能只专注于技术，还需要多元化从事埋点等高度重复性和机械性的任务。

　　埋藏相关代码具有高度侵入性，对系统设计和代码可维护性产生负面影响

　　大部分业务相关的数据点都需要人工埋藏，埋藏的代码要与业务代码强耦合。即使业界没有嵌入式SDK，数据产品所关注的特殊业务点也逃不过人工嵌入。

　　随着业务的不断变化，对数据的需求也在变化，埋点相关的代码也需要随之变化。进一步增加开发和代码维护成本。

　　容易出错

　　由于人工打点的主观意识不同，打点位置的准确性难以控制，数据容易泄露。

　　有打点流程费用

　　当数据丢失或错误采集时，必须重新经过开发过程和在线过程，效率低下。3.2 无埋点优势

　　与人工嵌入相比，无嵌入的优势无需赘述。

　　提高效率，让数据更全面，按需抽取，减少代码入侵 sdk的难点和关键点

　　无法直接监控用户行为以实现强大的可扩展性

　　需要适合多种架构设计场景（小程序），sdk的使用需要轻量级

　　每个小程序的包有2M的限制，小程序不支持在代码中引入npm包，所以sdk本身会占用2M的大小限制。小程序虽然有分包的内测，但是这个功能还没有完全放开，作为sdk太大也不合理。

　　采集数据量大，在不影响业务的情况下将性能损失降到最低（基本要求）4.3微信小程序无嵌入式sdk设计

　　数据层设计：

　　设计数据流：

　　采集方法设计：

　　访问方法：

　　sdk npm 包代码在小程序初始化代码之前介绍。小程序打包代码时，将sdk代码引入项目中，初始化后即可自动采集数据。初始化示例如下：

　　import Prajna from './lib/prajna-wxapp-sdk.js';

Prajna.init({channel: 'channel',env: config.IS_PRODUCION ? 'product': 'beta',project: 'yourProjectName',methodConfg: {} // 业务特殊关注的方法执行和自定义打点名称})复制代码

　　无埋点结合埋点：

　　小程序的非埋藏方式可以获取大量数据，基本可以实现用户使用场景的高度还原。SDK管理的粒度是对某个方法的执行。当特殊业务关注的粒度小于 SDK 粒度时，没有嵌入点的 SDK 无法完全解决。可以使用无嵌入点和嵌入点的组合，所以我们的小程序没有 追踪SDK也提供了API接口用于手动追踪，以提高数据的完整性，解决更多的问题（回顾提到的作用参考重要性数据的）。

　　五、小程序无埋SDK遇到的问题

　　除了解决上文提到的微信小程序非地埋sdk开发面临的困难和关键问题外，还遇到了一些新的问题。

　　SDK 本身会对业务性能产生一定的影响。数据临时存储在小程序的本地存储中。频繁访问/检索小程序的本地存储，会暴露业务端本身消耗更多性能时的操作滞后。问题。减少localstorage访问/获取操作，只在页面关闭时将未上传的数据存储在localstorage中

　　没有埋点的海量数据。灰度上线时遇到服务器过载问题，导致服务器可用性下降。后续将控制上报数据量，仅自动上报关键节点数据。其他以服务为中心的节点可以在访问初始化时通过针对性的配置重新配置上报，避免上报过多的冗余数据。此外，还应特别注意报告数据结构的设计。该结构的目标是清晰、简洁且易于检索（区分）数据。

　　最初，我想对灰度启动是否使用SDK进行“切换”，以避免小程序的回滚过程。由于“切换”依赖于服务端接口控制，且请求是异步的，这意味着小程序的初始化过程和启动必须等待控制切换的接口返回才能继续进行，否则“切换”是相当于失败。考虑到SDK不能影响*敏*感*词*能，丢弃“开关”，在SDK内部做try and catch，避免影响服务可用性。

　　有了无埋点上报得到的数据，以后可以用这些数据解决很多问题。关于数据的使用，敬请期待下一节——数据的应用。

　　参考：

　　[1] [美国]裴霁，译者：姚军等，《深入理解网站优化》，出版社：机械工业出版社，出版时间：2013-08

　　[2]张希猛，《首席成长官》，出版社：机械工业出版社，出版时间：第1版（2017年11月6日）