无关紧要的开头
最近去办理了爷爷奶奶的死亡证明，最后在派出所的努力下终于办成功了。证明中写明了老人的出生在1920年代，也就是说老人的人生历史距今已经足足100年了。三代人已经横跨了整整一个世纪，而这三代人生活在完全不同的三个阶段，第一代生活在旧中国，第二代生活在新中国建国初期，第三代生活在国盛民强的时代里。世界的变化可能是瞬息万变的，短短的100年中国实现了历史性的大逆转，所以什么不可能发生呢？
我们做数据业务的人在最近这短短10多年内也发生了明显的变化，基本三年一个显著变化：
2010年
开始正式在传统制造企业里从事数据分析工作，数仓采用SAP系统通过简单交互下载数据后用excel做分析，数据基本月度统计一次，尽可能通过不同维度对比、趋势、单价等总结出结论。此时市面上大量excel可视化教程开始普及，其中可视化理论“data ink”已在国内悄无声息的初成气候，但此时完全没有听说大数据、数据中台、AI等；
2014年
咨询公司、广告公司都已强烈地感受到数据变现的价值，通过各种办法收集商业数据对品牌主进行广告效益的评估及指导。其中拥有海量数据的运营商也在数据商业领域进行探索。大数据平台、更快速的spark都已陆续进入一些企业的视野内，但此时真正把玩olap的企业并不多，对生产环境下实时应用的能力和意识并不强烈。只有个别企业不停地探索实时推荐、DMP变现；
2017年
大企业无一例外地在探究用户画像、模型、风险、千人千面、爬虫、埋点等相对更深层次的数据服务。企业对数据生产应用的需求越发旺盛，原本冷落的数学专业顿时峰回路转成为热门专业，贵州等地成为了孵化大数据专业的地方。数据运营的优劣直接决定了企业的生死，A/B测试也成为企业精益求精的主要手段之一；
2021年
员工与数据的关系越来越紧，很多曾经被IT拒绝的分析需求逐步都实现了，市面上可视化工具就像excel一样在一线、二线企业中成为基础工具，甚至像预测回归等都像手机拍照按钮一样供运营人员一键分析。分析的成本越来越低，参与分析的人越来越多，分析人员的能力愈发专业。所以一些似乎不太现实的需求没准未来几年都能工业化地顺利落地。
正文
做了几年的埋点产品兼行为分析师，我有一个关于埋点的梦想，这个埋点梦建立在高度标准化的产品架构之上，没有测试、没有人负责命名、没有人去做分析，只有结果和指导意见。
埋点工程可以大致分为以下几个环节：
1）命名，核心任务是保障每个独立的按钮、页面其id不重复
2）测试，验证埋点采集逻辑、次数、参数是否正确
3）分析，找出产品问题在探索中不断优化转化及体验
那我就来阐述下这三个环节在梦中的样子——
一、命名
首先产品或业务线需要通过类似电影胶片一样接近连续性地将故事内容一一介绍给用户，所以一个场景是由多个被切片的页面组承接用户来办理业务的，于是有了首页、详情页、确认页、结果页等等，代表不同业务进程的页面需要通过不同的控件组合实现信息收集、信息展示及用户授权等操作，控件交互过程中会携带大量的参数信息，如商品id、订单id、规则id等，于是场景+页面（及页面状态）+事件+参数构成了产品元素的全部信息。所以命名这块最高的梦想是自动命名：
控件中文中I、II代表入口等级
为此需要配套一个采集后台，这个后台需要实现以下几个功能：
1）场景的页面id与图自动匹配，事件id与页面内控件自动匹配
2）管理场景库、页面id库、页面状态库、控件库、参数库
3）确认具体某一事件是否要部署埋点
4）确认具体某一事件下采集哪些参数
说白了有了这个后台就可以跳过开发、测试直接配置APP版本对应的采集范围，而且场景内每个页面、按钮都与对应的id产生了对应关系，便于后续数据直接同步到页面流中打下扎实的基础。
二、测试
因为采用了工业流水方式生成和决定埋点与否，已无需额外执行测试任务。工业流水方式生产的页面有以下几个优点：
1）页面设计规范统一
2）生产效率高，变相节约生产成本
3）零件升级则全局同步升级
4）信息结构化便于查询、问题溯源
近几年国家要求用户信息收集时需按照最低标准收集，则第四条就能帮助法务同事快速将所有场景名为confirm的页面，即可根据相关法律法规一一排查。
生产
流水线
三、分析
分析这个活儿非常考验人的水平。可今儿说的是梦想，所以分析这个活得交给人工智能，将用户行为特征、画像、产品指标相结合自动识别问题，当发现问题后自动生成阈值并报警，当产品经理想要提高产品的效益和体验时人工智能能提供切实有效的建议和调整方案。那退一步或许线实现以下功能吧：
1）产品流量前意图——页面逻辑设计诊断
就是检查一个场景内所有页面间的路径是否通畅，是否能顺利地在每个页面上直接离开场景或者直接从某个页面跳转至另一个页面。设计师和产品可以查看任意一个场景内所有页面间流量迁移数据，注意这个可视化分析并不是传统意义上的漏斗或者路径统计，因为后两者只关注于结果而不是场景内全部页面正反走向的通畅性。系统应自动提供诊断异常场景的流量迁移图供设计、产品和开发商议解决方案。
场景1页面间转化通畅性排查
2）异常行为诊断
很少有用户会完全按照产品经理的意愿进行操作，原本看似几秒的转化成本最终在用户行为数据表现为转辗反侧或早早离去。所以系统应该建立几套异常行为识别算法，可以设想到的是：
1）单一事件连续多次操作，如系统崩溃无响应导致部分用户反复确认性点击
2）人均访问、点击次数较高的页面、事件
3）停留时长过高的页面或场景
4）系统异常监控及报警
以上监控模型更侧重于实时监控，系统自动分析需结合用户关于场景的标签、自身的画像标签自动进行综合分析，如进行异常操作的用户与未出现异常操作用户的差异，如对场景的熟悉程度（累计转化次数）、行为差异（如从不同入口访问）、用户年龄、消费性格差异等，帮助产品和设计掌握异常行为背后的真正原因，这种分析可能不得不采用暴力方法用接近哈希的方式计算所有组合找出差异原因，而这类工作是人类望尘莫及无法实现的。因为具备了转化标记（页面id为result，页面状态为success）就能统计出当页面加载时长在不同区间内或发生某个报错时所产生的损失，此种量化将有利于开发在排期时决策优先级并评估改造回报率。
3）常规运营分析
对于某个场景的产品而言，单单关注自己场景的转化率远远不够，因为干扰转化的变量非常地多。入口流量大小及质量、获客渠道质量、用户生命周期阶段、活动内容及效果等都应该纳入监控分析范畴之内。在排除外部变量干扰后就可以进入用户分群分析，系统自动根据用户转化进程与意向等级分组并统计规模，自动通过历史对比说明当前产品是否整体健康，针对不同分组的用户可采用不同的营销策略促转化。
用户分组
4）上帝视角
既然页面和事件都被唯一命名，那么页面流量、事件点击、页面转化率将不再被表格或者sankey图所束缚。我们完全可以采用类似SNS或病毒传播可视化方式展示流量的转化过程，不同入口采用不同颜色，场景内流量的逐级变化过程都可以通过页面间连线的粗细直观地还原出来。平台上通过场景筛选、流量方向（正、反）、APP版本、画像标签、行为标签、是否转化等进行下钻。当分析师点击流量线条时可以提供更多的分析信息，如人均迁移次数（迁移次数对应人数占比）、迁移耗时、迁移前点击特征、转化人群等排摸未转化的原因。当然，最好是AI直接告诉我放弃的用户有什么特征而非大海捞针一般去推演、去逐一排摸。
上帝视角
网友评论