无规则采集器列表算法(【干货】一下数据采集的重要性、数据划分、采集方式)

　　无规则采集器列表算法(【干货】一下数据采集的重要性、数据划分、采集方式)

　　前言

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

　　这个数据非常重要。下面从数据采集的重要性、数据的划分、采集的方法、微信小程序的埋点方案等方面详细说说数据。 采集。

　　一、数据采集的重要性

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

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

　　从第一点开始，我们总结了数据的重要性。不同的业务项目对数据的重要性有不同的重视。 data采集需要采集什么样的数据？

　　一、闭环数据包括：

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

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

　　三、数据上报方式

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

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

　　第二类是可视化埋点，即采集节点通过可视化工具配置，自动分析配置并在前端上报埋点数据，从而实现——称为“无痕埋点”。代表性的解决方案是开源的Mixpanel；

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

　　重点是非埋点。视觉上的埋点实际上可以看作是非埋点的衍生物。这里不讨论视觉上的掩埋点。主要比较代码埋点和非埋点。

　　3.1 代码埋点或Capture模式埋点的弊端

　　对于数据产品：

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

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

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

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

　　用于开发：

　　开发者能耗

　　对于业务团队来说，经常受到相关开发者的诟病。开发和技术人员不仅要专注于技术，还需要分散精力去做埋点等高重复性和机械性的任务。嵌入式代码具有很强的侵入性，对系统设计和代码可维护性产生负面影响

　　大部分业务相关的数据点都需要人工进行埋点，埋点的代码必须与业务代码强耦合。即便业界没有sdk，数据产品专注的特殊业务点也逃不过人工埋葬。

　　由于业务不断变化下数据需求的变化，embedding的相关代码也需要做相应的改变。进一步增加开发和代码维护成本。容易出错和遗漏

　　由于人工管理的主观差异，放置位置的准确性难以控制，管理过程中存在成本，容易数据泄露

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

　　与人工埋点相比，无埋点的优势无需说明。

　　提高效率，数据更全面，按需抽取减少代码入侵四、微信小程序无埋点sdk解决方案4.1无埋点数据需求4.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。操作卡住了。减少本地存储的存储/检索操作。只有关闭页面时没有上传的数据才会存储在localstorage中。没有埋点的全量数据是巨大的。灰度上线时，遇到了服务器过载、服务器可用性降低的问题。后续控制上报数据量，仅自动上报关键节点数据，其他业务重点节点可在访问初始化时通过针对性配置上报，避免上报过多冗余数据。此外，应特别注意报告数据结构的设计。结构目标是清晰、简洁、便于数据检索（区分）。初期想对是否使用SDK进行灰度在线做一个“切换”，避免小程序回滚过程。由于“开关”依赖于服务器接口控制，并且请求是异步的，意味着初始化过程和小程序的启动必须等到控制开关的接口返回，否则“开关”就相当于失败考虑到SDK不会影响业务性能，舍弃“开关”，做好SDK内部的try-catch，避免影响业务可用性。

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