埋点是数据采集的专用术语,在数据驱动型业务中,如营销策略、产品迭代、业务分析、用户画像等,都依赖于数据提供决策支持,希望通过数据来捕捉特定的用户行为,如页面访问、按钮点击量、阅读时长等统计信息。因此,数据埋点可以简单理解为针对特定业务场景进行数据采集和上报的技术方案,在政采云,前端团队已经有自研 SDK 来解决这个问题。在数据埋点于政采云的落地实践过程中,我们发现另一个可供探讨的方向,即获取到数据后,我们要如何进行埋点数据的分析? 以下我们展开聊一聊埋点数据分析的用户诉求、团队的探索实践和存在的痛点。
关心埋点数据的人群以及他们关注的侧重点,可以分为以下几类:1、产品经理:我的需求上线后,用户使用量怎么样?(我并不关心埋点怎么埋,也不关心明细数据,看个日活和趋势就可以了) 2、研发:一些紧急需求、插入需求、加班需求上线后,及时投放使用了吗?用户使用量怎么样?(这个需求是伪需求吗?真的要做吗?看看数据验证下) 3、Team Leader 及以上管理层:投入产出比怎么样?人员分配合理吗?(可以得出什么结论吗?有一些指导性建议吗?) 4、BI:我可以挖掘哪些业务价值比较高的信息呢?(这些明细数据有点晦涩,我要怎么分析加工?有简便的方式吗?) 可以看到,不同的用户角色对数据关注的侧重点是不一样的;同样,她们对数据获取加工和分析能力也是差别较大。总结下来,用户对埋点数据的产出诉求可以分为以下几个阶段。
其中,数据准确性和数据可读性保证了数据的基本产出但已经无法满足用户对数据的更高诉求,他们更期望的是数据易读性和数据指导性。 数据易读,即要结合数据分析场景给予用户恰当优美的数据展示形式,常用表格、折线图、柱状图、饼图等图表组件。最好一目了然,降低理解成本。数据指导性,即通过这些数据展示,可以明确得到结论吗?这些结论对业务有哪些帮助?通常需要人为加工分析。带着这些疑问和诉求,政采云埋点数据可视化平台-浑仪,是这样做的。
基于事件的指标统计、属性分组、条件筛选等功能,建立模型对用户行为或业务过程进行分析。
展示形式有表格、多维度折线图、分组柱状图。支持下载导出。
支持按路径和按页面编码双重方式进行搜索,一键获得页面全量信息。内置推荐功能,会将路径与系统内维护的页面信息进行匹配,提升搜索性能的同时提升数据准确性。
漏斗模型主要用于分析一个多步骤过程中每一步的转化与流失情况。
以桑基图的形式展示以目标时间为起点的所选事件组内各页面间用户的完整路径,并支持查询单一用户行为路径。
默认为用户处理透出的看板,可查看 PV/UV/平均停留时长关键指标外,也透出了用户类型、浏览器、操作系统等重要用户属性进行分析,方便用户感知查询。
用户可以保存事件分析-查询结果的数据,将会在个人看板中展示保存的数据结果,之后能直接查看所有保存的图表数据,将多次查询结果整合对比,提升查询效率。并且支持分类,编辑、删除图表,还可以分享给他人,实现全组共享。看板支持数值、条形图、折线图、表格四种组件形式自由搭配并自由切换。
通过以上获得的数据,可以人为分析,加以评论,以数据报告的形式进行整理,得到更好的数据效果。
以上不同的功能基本覆盖了用户不同场景下的数据分析诉求,但也同样存在着一些用户痛点。
数据埋点的整个流程是从产品或交互侧提出需求开始的,中间经历了研发人员的代码植入、配置维护、测试上线等流程,最后才能查看数据。事实上,一个原始需求通常需要拆解成多个“埋点动作”,一个数据查看诉求也是由多个查询条件组合进行筛选。而查看埋点的人却不止该需求植入埋点的人,他们对如何组合查询条件的感知相当薄弱,通常是一头雾水。由谁查,如何查到想要的数据就成了一个需要平台团队日常答疑支持的事项。另外,考虑到埋点数据量过于庞大的问题,仅仅产出明细数据就已经存在查询性能瓶颈,很难支持数据的二次加工,因此用户在获取明细数据时,认为过于晦涩,往往还需要手动加工聚合。
以上,便是政采云埋点团队对于埋点数据可视化方面的探索和实践。