前言  

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

• 打点需求： 每新上一个功能，数据产品便会同步加上打点需求，当数据打点上线后一段时间，数据产品/业务产品便会针对数据的转化率分析和对业务需求的调整；

• 打点正确性验证：当某一天数据转化率大幅度变化不符合预期，数据产品/业务产品便会和开发确认打点的位置是否出现纰漏;

• 线上问题排查： 接到上报一个线上问题，然而开发们却无法重现该case，此时需要有线上对应该case的数据才能进一步分析问题，倘若没有数据，那这个问题很可能将变成一桩“悬案”，便会遭受多合作方的质疑和对于业务稳定性的安全感大大降低。

由此数据是很重要的，我们接下来从数据采集的重要性、数据的划分、采集方式以及在微信小程序中的埋点方案几个方面来一起详细聊一下数据采集。

一、数据采集的重要性

本篇我们重点讨论数据采集，暂不详细论证数据的作用，先归纳总结一下数据对于性能优化、业务增长和线上问题排查的重要作用，这也是我们为什么需要埋点的原因。

数据对于线上问题排查的作用：

• 用户行为数据还原“现场”，帮助分析和定位问题，提高问题定位效率

• 对于问题分析提供有力证据
  

数据对于性能优化的作用：

• 帮助发现和监控在线业务的关键成功指标

• 帮助发现最需要优化环境及其优先顺序

• 帮助发现所面临的挑战的信息和改进决策

• 帮助提供对应用测试和优化更好的分析

数据对于业务增长的作用：

• 帮助衡量市场营销效果

• 帮助发现激活转化效果的策略

• 帮助发现用户留存和用户活跃分析

• 帮助产品营收变现分析

二、采集数据划分梳理

从第一大点，我们总结了数据的重要性，不同的业务项目对于数据重要性的侧重点会有不同，那数据采集到底要采集哪些数据呢？

首先闭环数据包括：

  1. 用户行为

  2. 用户信息、CRM（客户关系）

  3. 交易数据、服务端日志数据

以上三项数据，才算是一个完整数据流闭环，当然不同的业务场景中数据还可以再更细划分，大体的关键点基本不超出这三项。对于前端的数据收集来讲，闭环数据中前两项主要由客户端上报数据，而第三点主要由服务端记录数据，客户端辅助，因为交易请求真正到达服务端完成处理才算是完成交易的一个闭环。用户行为数据又包括——时间（when）、地点（where）、人物（who）、交互（how）、交互内容（what）五个要素，和新闻五要素有点类似；用户信息有的业务涉及到用户敏感信息和隐私等需要授权，所以用户信息由业务场景定夺具体维度，最基本的数据需求是能唯一标识用户；CRM、交易数据和用户信息类似，具体所需数据细节由业务场景定夺，CRM基本数据需求是登陆信息、会员相关信息，交易数据包括——交易时间、交易对象、交易内容、交易金额、交易状态。

三、数据上报方式

聊完数据，下一步便是需要知道如何获取到我们真正所需要的数据。数据上报方式大体上可以归为三类：

  1. 第一类是代码埋点，即在需要埋点的节点调用接口直接上传埋点数据，友盟、百度统计等第三方数据统计服务商大都采用这种方案；

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

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

重点讨论无埋点，可视化埋点其实可以算是无埋点的一个衍生故可视化埋点在此不讨论，主要对比代码埋点与无埋点。

3.1代码埋点或Capture模式的埋点缺点

对于数据产品来说：

  1. 依赖人的经验和直觉判断。
业务相关的埋点位置需要数据产品或者业务产品主观判断，技术相关的埋点则需要技术人员主观判断。

  2. 沟通成本高
数据产品确定所需要的数据，需要提出需求与开发沟通，且数据人员对技术不是特别熟悉，还需与开发人员明确相关信息否能上报的可行性。

  3. 存在数据清洗成本
随着业务更迭变化，之前主观判断所需的数据会存在更改变化，此时对之前打点的数据就需要手动清洗，且清洗的工作量占比并不小。

对于开发来说：

  1. 开发人员精力消耗
埋点对于业务团队来说，常常被相关开发人员所诟病。开发技术人员不能只关注技术，还需分散精力做埋点这样高度重复且机械性的任务。

  2. 埋点相关代码侵入性强，对系统设计和代码可维护性造成负面影响
大部分的业务相关数据点都需要手动埋点完成，埋点代码不得不与业务代码强耦合在一起。即使业界已有无埋点sdk，数据产品关注的业务特殊点也逃离不了手动埋点。
在业务不断变化下对数据的需求变更，埋点相关代码也需要跟着变化。进一步增加开发和代码维护成本。

  3. 易错、漏
由于人工打点存在主观意识差异，打点位置的准确度难控，且易漏数据

  4. 存在打点流程成本
当数据漏采或错采时，又要经历一遍开发流程和上线流程，效率低下。

3.2无埋点优势

与手动埋点相比较，无埋点优势便不用多解释。

  1. 提高效率

  2. 数据更全面，按需提取

  3. 减少代码侵入

四、微信小程序无埋点sdk方案

4.1 无埋点数据需求

• 小程序的初始化执行情况上报

• 接口请求上报

• 错误上报

• 用户行为上报
  

  2017-12-192017-12-192017-12-19

       由于小程序不同于web服务，不存在js /css资源加载一说，所以更关注的是小程序初始化状态和执行情况的记录和捕获上报情况，图中资源完整性检查对应初始化完成性检查。线上小程序中的请求域名都必须是https协议的，故dns劫持概率大大降低甚至不大可能发生，且从客户端监控DNS劫持可行性较低（存在悖论），暂不考虑DNS劫持捕获情况。

4.2 针对微信小程序开发无埋点sdk的难点及重点

• 无法直接拦截/监听请求
  微信请求统一通过微信API完成 ，请求模块已被微信方封装，且小程序的运行环境不是浏览器对象，不像web应用那样重写封装很自如。

• 三种运行环境的监控兼容性保证
  
  

• Android 上，js运行环境是 X5 内核

• iOS 上，js 运行环境是 JavaScriptCore

• 开发工具上， j s运行环境是 nwjs（chrome内核）

• 用户行为无法直接监听

• 强拓展性
  需要适用于多种架构设计场景（小程序）下使用

• 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的难点及重点所面临的问题外，还遇到了一些新的问题。

  1. SDK本身会对业务性能造成一定成都影响，数据暂存放在了小程序的localstorage中，多次较频繁的存/取小程序的localstorage在业务方本身较耗费性能的情况下会暴露出操作卡顿问题。减少localstorage的存/取操作，只在页面关闭时未上传的数据才存入localstorage

  2. 全量无埋点的数据量庞大，灰度上线时遇到过服务器过载导致服务器可用性下降的问题。后续对于数据上报的量有所控制，只自动上报关键节点数据，其他业务关注节点可通过接入初始化时针对性配置再上报，避免上报过多冗余数据。此外对于上报数据结构的设计也需要尤为注意，结构目标是要清晰、简洁、便于数据检索（区分）。

  3.初期原本想针对灰度上线做一个SDK使用与否的“开关”，避免小程序回滚流程。由于“开关”依赖server接口控制，而请求是异步的，意味着初始化过程以及小程序启动都必须等到控制开关的接口返回才可进行，否则“开关”就相当于失效的。 考虑到SDK不能影响到业务性能，丢弃“开关”，在SDK内部做好try、catch，避免对业务可用性造成影响。

有了无埋点上报获得数据，后续便可以利用数据来解决很多问题。对于数据的利用请期待下节——数据的应用篇。

作者：美团点评点餐