大众创新网官方网站首页,app开发自学,网站加网页,精准营销英文作者#xff1a;lxj#xff0c;点餐终端团队成员前言 相信业务团队对这样的场景不会太陌生#xff1a;打点需求#xff1a; 每新上一个功能#xff0c;数据产品便会同步加上打点需求#xff0c;当数据打点上线后一段时间#xff0c;数据产品/业务产品便会针对数据的转化…作者lxj点餐终端团队成员前言 相信业务团队对这样的场景不会太陌生打点需求 每新上一个功能数据产品便会同步加上打点需求当数据打点上线后一段时间数据产品/业务产品便会针对数据的转化率分析和对业务需求的调整打点正确性验证当某一天数据转化率大幅度变化不符合预期数据产品/业务产品便会和开发确认打点的位置是否出现纰漏;线上问题排查 接到上报一个线上问题然而开发们却无法重现该case此时需要有线上对应该case的数据才能进一步分析问题倘若没有数据那这个问题很可能将变成一桩“悬案”便会遭受多合作方的质疑和对于业务稳定性的安全感大大降低。
由此数据是很重要的我们接下来从数据采集的重要性、数据的划分、采集方式以及在微信小程序中的埋点方案几个方面来一起详细聊一下数据采集。
一、数据采集的重要性本篇我们重点讨论数据采集暂不详细论证数据的作用先归纳总结一下数据对于性能优化、业务增长和线上问题排查的重要作用这也是我们为什么需要埋点的原因。
数据对于线上问题排查的作用
用户行为数据还原“现场”帮助分析和定位问题提高问题定位效率对于问题分析提供有力证据
数据对于性能优化的作用
帮助发现和监控在线业务的关键成功指标帮助发现最需要优化环境及其优先顺序帮助发现所面临的挑战的信息和改进决策帮助提供对应用测试和优化更好的分析
数据对于业务增长的作用
帮助衡量市场营销效果帮助发现激活转化效果的策略帮助发现用户留存和用户活跃分析帮助产品营收变现分析
二、采集数据划分梳理从第一大点我们总结了数据的重要性不同的业务项目对于数据重要性的侧重点会有不同那数据采集到底要采集哪些数据呢
首先闭环数据包括
用户行为用户信息、CRM客户关系交易数据、服务端日志数据
以上三项数据才算是一个完整数据流闭环当然不同的业务场景中数据还可以再更细划分大体的关键点基本不超出这三项。对于前端的数据收集来讲闭环数据中前两项主要由客户端上报数据而第三点主要由服务端记录数据客户端辅助因为交易请求真正到达服务端完成处理才算是完成交易的一个闭环。用户行为数据又包括——时间when、地点where、人物who、交互how、交互内容what五个要素和新闻五要素有点类似用户信息有的业务涉及到用户敏感信息和隐私等需要授权所以用户信息由业务场景定夺具体维度最基本的数据需求是能唯一标识用户CRM、交易数据和用户信息类似具体所需数据细节由业务场景定夺CRM基本数据需求是登陆信息、会员相关信息交易数据包括——交易时间、交易对象、交易内容、交易金额、交易状态。
三、数据上报方式聊完数据下一步便是需要知道如何获取到我们真正所需要的数据。数据上报方式大体上可以归为三类
第一类是代码埋点即在需要埋点的节点手动调用接口上传埋点数据友盟、百度统计等第三方数据统计服务商大都采用这种方案第二类是可视化埋点即通过可视化工具配置采集节点在前端自动解析配置并上报埋点数据从而实现所谓的“无痕埋点” 代表方案是已经开源的Mixpanel第三类是“无埋点”它并不是真正的不需要埋点而是前端自动采集全部事件并上报埋点数据在后端数据计算时过滤出有用数据代表方案是国内的GrowingIO。
重点讨论无埋点可视化埋点其实可以算是无埋点的一个衍生故可视化埋点在此不讨论主要对比代码埋点与无埋点。3.1代码埋点或Capture模式的埋点缺点对于数据产品来说
依赖人的经验和直觉判断。业务相关的埋点位置需要数据产品或者业务产品主观判断技术相关的埋点则需要技术人员主观判断。沟通成本高数据产品确定所需要的数据需要提出需求与开发沟通且数据人员对技术不是特别熟悉还需与开发人员明确相关信息否能上报的可行性。存在数据清洗成本随着业务更迭变化之前主观判断所需的数据会存在更改变化此时对之前打点的数据就需要手动清洗且清洗的工作量占比并不小。 对于开发来说
开发人员精力消耗埋点对于业务团队来说常常被相关开发人员所诟病。开发技术人员不能只关注技术还需分散精力做埋点这样高度重复且机械性的任务。埋点相关代码侵入性强对系统设计和代码可维护性造成负面影响大部分的业务相关数据点都需要手动埋点完成埋点代码不得不与业务代码强耦合在一起。即使业界已有无埋点sdk数据产品关注的业务特殊点也逃离不了手动埋点。在业务不断变化下对数据的需求变更埋点相关代码也需要跟着变化。进一步增加开发和代码维护成本。易错、漏由于人工打点存在主观意识差异打点位置的准确度难控且易漏数据存在打点流程成本当数据漏采或错采时又要经历一遍开发流程和上线流程效率低下。3.2无埋点优势与手动埋点相比较无埋点优势便不用多解释。
提高效率数据更全面按需提取减少代码侵入
四、微信小程序无埋点sdk方案4.1 无埋点数据需求
小程序的初始化执行情况上报接口请求上报错误上报用户行为上报 由于小程序不同于web服务不存在js /css资源加载一说所以更关注的是小程序初始化状态和执行情况的记录和捕获上报情况图中资源完整性检查对应初始化完成性检查。线上小程序中的请求域名都必须是https协议的故dns劫持概率大大降低甚至不大可能发生且从客户端监控DNS劫持可行性较低存在悖论暂不考虑DNS劫持捕获情况。4.2 针对微信小程序开发无埋点sdk的难点及重点
无法直接拦截/监听请求微信请求统一通过微信API完成 请求模块已被微信方封装且小程序的运行环境不是浏览器对象不像web应用那样重写封装很自如。三种运行环境的监控兼容性保证 Android 上js运行环境是 X5 内核 iOS 上js 运行环境是 JavaScriptCore 开发工具上 j s运行环境是 nwjschrome内核 用户行为无法直接监听强拓展性 需要适用于多种架构设计场景小程序下使用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的存/取操作只在页面关闭时未上传的数据才存入localstorage全量无埋点的数据量庞大灰度上线时遇到过服务器过载导致服务器可用性下降的问题。后续对于数据上报的量有所控制只自动上报关键节点数据其他业务关注节点可通过接入初始化时针对性配置再上报避免上报过多冗余数据。此外对于上报数据结构的设计也需要尤为注意结构目标是要清晰、简洁、便于数据检索区分。初期原本想针对灰度上线做一个SDK使用与否的“开关”避免小程序回滚流程。由于“开关”依赖server接口控制而请求是异步的意味着初始化过程以及小程序启动都必须等到控制开关的接口返回才可进行否则“开关”就相当于失效的。 考虑到SDK不能影响到业务性能丢弃“开关”在SDK内部做好try、catch避免对业务可用性造成影响。
有了无埋点上报获得数据后续便可以利用数据来解决很多问题。对于数据的利用请期待下节——数据的应用篇。参考文献
[1] 【美】培基译者姚军等《深入理解网站优化》出版社:机械工业出版社出版时间:2013-08
[2] 张溪梦《首席增长官》出版社:机械工业出版社出版时间:第1版 (2017年11月6日)
