惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

小众软件
小众软件
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
WordPress大学
WordPress大学
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
博客园 - 聂微东
博客园 - 【当耐特】
博客园_首页
The Cloudflare Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Apple Machine Learning Research
Apple Machine Learning Research
Last Week in AI
Last Week in AI
酷 壳 – CoolShell
酷 壳 – CoolShell
大猫的无限游戏
大猫的无限游戏
雷峰网
雷峰网
量子位
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Tailwind CSS Blog
IT之家
IT之家
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
GbyAI
GbyAI
V
Visual Studio Blog
F
Fortinet All Blogs
Martin Fowler
Martin Fowler

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
数据埋点设计实践案例解析
用户体验大学堂 · 2022-12-01 · via 人人都是产品经理

用户行为研究是产品优化、用户精准运营的基础,而良好的数据采集方案,则是进行用户行为研究的基础。其中,埋点是一个非常重要的数据采集方式,本文作者对埋点设计实践案例进行了解析,一起来看一下吧。

用户行为研究是产品优化、用户精准运营的基础,而良好的数据采集方案,则是进行用户行为研究的基础。

埋点作为最重要的数据采集方式,如果企业没有埋点,那么基本也就丧失了数据来源的大半江山。这篇文章,特别结合了某头部车企的数据埋点设计案例来阐述数据埋点的相关内容。

一、什么是埋点

数据埋点设计实践案例解析

典型的数据埋点处理流程

数据埋点是数据采集的一种重要方式,主要用来记录和收集终端用户的操作行为。比如进入某个页面、点击某个按钮时,会自动触发记录和存储,然后这些数据会被收集并被传输到某个平台或终端。

如果说小伙伴们对埋点还是一知半解,那么我们可以打个比方:埋点相当于路上的摄像头,能够采集到诸如驾驶速度、行车路线等相关的数据,通过布置合理的摄像头位置,研究人员就能够将获取到的数据经过多维度的交叉分析,还原出用户的使用场景,并从中挖掘出新的用户需求,进而提升用户全生命周期的价值。

二、埋点类型介绍

本文讨论的埋点类型有两种:普通埋点和事件埋点。

普通埋点:采集用户(设备)属性、页面属性、元素操作等常规内容。通过安装在平台上的SDK包就能采集,无需设计。

数据埋点设计实践案例解析

普通埋点又叫全埋点、无埋点、自动埋点等,仅适用于一些简单的分析场景。比如通过可获取页面浏览相关指标:PV、UV、浏览时长、退出率、用户ID、用户地理位置、用户设备信息、应用系统相关信息等。

缺点是数据采集不全、数据传输时效性差且数据可靠性无法保证。因此,如果需要做一些精确分析的话,必须依靠事件埋点。

事件埋点:收集用户对前端页面元素的操作,及元素的详细属性。需要根据页面及业务需求,定制化设计并进行埋码开发采集。

数据埋点设计实践案例解析

通过一个具体事件的埋点设计可以收集用户在某个页面或页面元素的操作行为,从而进行一些精细化场景分析。比如可通过事件埋点设计预设用户的行为指标:动作发生次数、动作发生时间、发生动作的具体内容、动作发生相关的属性值等。

三、埋点采集——用户行为数据的“5+1”要素

埋点的采集对象是用户的行为数据,但并不是所有的行为都是有效的数据,采集时要遵循“5+1”要素:“谁 who、什么时间 when、什么地点 where、做什么 what、怎么做 how”+“产生了多少结果 how much”。

  • Who:不仅仅是指用户的姓名、联系方式和身份信息,还包括用户的访问终端和 ID信息以及与之相关联的信息。
  • When:用户行为发生的具体时刻。
  • Where:这里地点指的是线上用户的来源渠道,即用户进入页面的源头是什么。
  • What:针对的是内容还是产品功能,为分析提供细分的维度。
  • How:是指产品内容互动,如滑动、点赞、评论、分享等;产品功能互动,如功能使用等。
  • How much:将产品内容/功能属性信息上与用户行为信息数据进行融合,综合分析。

四、数据埋点的应用

根据埋点采集到的数据,可以分析运营机制的合理性、产品功能的合理性以及监控产品功能的流畅性,并通过分析不同渠道用户行为的差异,不同用户的行为挖掘痛点和流失点,从而支撑产品的业务目标验证,设计效果验证,进一步完善用户画像/用户行为流程和用户体验指标。

1. 埋点设计流程

埋点设计流程分为三个阶段:需求阶段,开发测试阶段以及数据应用阶段。

埋点需求及埋点设计文档形成系统的管理,有助于产品/业务/设计/运营团队了解哪些页面或者功能已埋点、埋了哪些字段、上报了多少、多久的数据,减少查询埋点需求及埋点事件的链路与沟通成本,增加各部门沟通效率,减少数据分析和利用的过程中的不利因素。

数据埋点设计实践案例解析

结合多方视角进行埋点采集方案设计,并进行长期闭环的数据动态研究。埋点设计阶段,结合业务、平台、用户三方视角,对埋点方案进行考虑然后再进行详细的设计。

数据埋点设计实践案例解析

下面我们结合一些例子来进行说明。

1)基于交互文档进行埋点标注

针对用户的交互行为,对埋点位置、埋点事件名称和触发时机一一进行标注。

数据埋点设计实践案例解析

2)埋点设计的事件属性继承

简单来说就是流程后续埋点属性的设计保留上一页面埋点属性的关键,从而保证页面属性之间的连贯性,确保埋点的效用和效率。

比如说在线购物流程,用户会首先选择喜欢的产品,然后再确定版本/外观、数量,最后进行支付。整个选择流程也是用户需求与行为不断细化的过程,这就需要埋点设计在流程起始页面的后续页面保留之前页面埋点设计的属性:点击商品时获取店铺名称、商品名称等属性,确认商品内容时在保留店铺名称、商品名称的基础上,获取最终选择的版本/外观、数量、价格;最终支付按钮点击事件在继承之前事件属性的基础上补充获取订单地址、配送时间等信息。

通过属性的继承可以有效的分析整个流程的转化/流失率,这个过程很直观地展现了埋点继承的必要性和重要性。

3)基于业务使用与分析场景的埋点设计

有关内容资讯方面的埋点设计中,常用的数据使用场景是:通过埋点数据收集并分析针对特定内容的“点赞、评论和收藏的数量以及具体对应的用户与操作时间”。

结合业务数据使用场景的需求,可以在事件公共属性新增用户昵称的属性,将用户昵称与用户 ID 相对应。在分析平台上可以把客户的需求拆分为两点进行查看:首先是看到某个时间段,有多少人进行点赞评论收藏;其次如果想看具体的用户是谁,则要在相应的时间内点击这些数据,来查看用户昵称。

这里面有一个值得思考的点。事件埋点也分前端(客户端)埋点与后端(服务端)埋点,像这种内容资讯相关的埋点,理论上来讲应该在后端数据库进行埋点数据采集,效果与数据准确性会更好。因此,对于埋点设计需要针对不同的情况,选取合适的埋点方式也是在埋点设计过程中值得思考的内容。

4)页面来源属性设计

这也是属于埋点设计中比较有难度的一个点。像下图中的页面,可以从首页推荐模块进入,可以在搜索列表结果页进入,也可以在某个专题模块里进入。

这种我们可以明确总结出页面来源入口的,只要在该页面的浏览事件里新增一个页面来源属性,通过埋点获取进入该页面的上一事件名称,就可准确分析进入该页面的渠道来源分布。

但还有一些比较难以通过设计来追踪来源的情况,比如登录注册页。如果用户选择不登录,直接选择某项功能时,会出现各种触发登录注册页面跳转的机制,这很难进行来源统计。

对此,可以根据页面跳转逻辑与机制,对页面来源进行大致分类,用不同的类别作为页面来源属性的具体属性值,用以支撑页面来源渠道的分析。比如:有固定入口的可以进入的;无固定入口,通过触发某个功能的跳转逻辑进入的;登录失效进入等情况。

五、数据埋点开发上线常见问题

数据埋点不仅在设计阶段需要进行大量思考,开发测试阶段也需要对上线的埋点数据进行具体的质量验证。常见的数据质量问题我们简单归纳为三类:埋点设计事件缺失、埋点属性值缺失或不准确、埋点事件触发时机不准确或事件操作后触发无关事件

在开发过程中会出现埋点事件遗漏或设计的属性值出现偏差等现象,比如说点击位置 tab名称是综合推荐,获取到的却是综合排序,以及其他的一些属性值获取不准确的问题。这些问题可以在测试阶段发现并作出弥补。

但埋点事件触发时机不准确或事件操作后触发无关事件则是比较让人头疼的点。

事件触发时机不正确有一种表现:点击按键1进入页面2,自动触发 tab2的点击事件;点击按键2进入页面3,自动触发 tab3的点击事件。这种问题可能是页面之间的逻辑关系导致的,具体原因还需要跟开发同事进一步了解探讨。

还有一种情况:进入某个有 tab的页面,会自动触发默认 tab点击事件点击的触发。对此我们进行了一些有针对性的思考,并跟开发约定这种情况的应对方式:在页面浏览时,页面浏览事件属性获取进入该页面时的默认 tab,通过该属性区分用户进入该页面前端显示的具体 tab内容,不要触发跟用户操作无关的行为,以免影响真实的用户的行为。从而避免默认触发事件数据影响最终分析用户行为与路径的结果。

埋点设计是一个很容易上手,却很难精通的工作。随着不断深入地接触,我们发现埋点设计与新系统的设计复杂程度不相上下。埋点设计过程,不仅需要对埋点数据的应用场景进行独立分析,还需要考虑到各个关联因素的影响。因此,埋点设计需要持续不断地深耕挖掘,才能保证数据的真实有效和数据分析结果的可用和有用。

来源公众号:伊飒尔UXD学院,专注用户研究和用户体验设计

本文由人人都是产品经理合作媒体 @伊飒尔UXD 授权发布,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。