Hey 有埋点吗?我想看个数据

-回复 -浏览
楼主 2019-10-08 16:07:34
举报 只看此人 收藏本贴 楼主

之前的基金备考,加现在连续3个月的出游计划,让我的周末填充的满满当当,难得在这个暖融融的周末有空闲时光,不写点儿什么都对不起这大好春光啦,许久未更的公众号,我又回来啦。今天让我们来聊一聊设计师参与产品埋点抓取数据的事儿吧。


1. 为什么做埋点?


数据验证对于产品设计效果验证的重要性不言而喻,但在实际工作中,种种原因导致分析查看数据成了一件非常麻烦的事。如我们正在做的一款分期支付产品,产品经理更在乎用户的消费金额、逾期率等等业务数据,而从体验层面上讲,用户在关键页面的停留时长、流失率等是重要数据。为了弥补在这一xx的遗漏,作为交互设计师我的参与度从一开始跟产品要数据,说明埋点重要性;到后面与产品一起整理埋点内容;到现在直接自己整理、补充埋点内容,与前后端沟通,区分埋点上线的优先级、建立更好的数据采集规范,也运用得到的数据进行后续分析。

有人会说,这个不是产品经理的工作吗?但是当产品的侧重点不在这里时,为了守护好用户体验,就要求设计师前行一步,获取所需内容(如数据),在一定程度上指导后面的设计方向。大家采用不同的方式,同心协力打造更好产品。当然当规范建立好以后,后期不必再继续自己完成,可以交给其他人去做。



2. 不同限制条件下的行动方式不同


实际工作中需要根据自己公司的数据采集提供情况决定埋点的方式。如之前在大厂实习时,平台本身提供了大量的数据采集工具,也有专门的数据分析团队给出结果,此时我们的工作就会简单一些。目前我司BI部门提供的数据采集工具有一定局限性,具体埋点过程中:

一方面要基于BI平台特点,尽量把数据要求提的清楚明白。了解数据识别的可行性和后台数据分析的边界,区分哪些是能够直接获取的,哪些一定要内部的前后端主动埋点提供数据,有针对性的进行差异化处理。如之前我们制作单页后,url中?后面的内容BI就无法识别,对于这类内容为了从而保证能够看到更加精准的数据,需要我们的开发主动埋点,从而补充数据完整性。

另一方面,对于一些不太合理或者不够好用的功能,可以根据需要主动向BI部门提出需求,说明使用痛点和新功能的重要性后,由BI评估是否可行,如果可以那么后续方便很多,如果不行,也可以考虑要求拿到数据接口,然后自己团队内部页面分析呈现数据。

对于此类需求,重点要考虑成本问题,如果数据需求的周期性较长,如一个月收集一次,那么短期内人工提取也是可行的。


【埋点的优先级】

产品设计评审过后,马上补充埋点,内容过多后,可能会出现量太大而需花大量时间完成的情况。容易劳心劳力,且遗落内容。

1. 核心数据:

埋点前思考好数据采集的目的,对于核心页面、核心用户路径、一些特殊观察点,并根据目的拆分数据,必须进行完整的埋点,或确保有地方可以查看数据。上线后观测数据,然后再补充其他更多的,以及遗漏的内容。


2. 其他数据

首先保证所有可点击项、跳转页面等都有完整的埋点需求,然后根据项目时间情况分步完成,除了上面提到的核心数据之外,有些数据采集一开始不是很清楚其目的,但是后面在查看时却能够带来意想不到的启发。



3. 如何保证埋点清晰?


几个实用性规则:

1. 按照项目 - 端 -  大功能模块 - 页面 - 埋点项的专属名称为维度分别整理埋点内容

2. 命名精简,清晰易懂,具有独一性

【一般形式】

项目名_操作_具体事件[_其他备注](中括号内为可选)

具体事件可以驼峰单词组合。平时几乎没有写代码的情况,因此命名时为了更容易读懂内容,想当然的使用了中划线-、斜杠/等符号,但与开发核对时才发现,这样的方式进入代码后会引起混乱,根本不能使用,因此一起整理了如下的命名规范,供后续埋点时参考。


【事件ID规范】

1)字母、数字、下划线组合,长度≤50

2)不能以数字开头

3)单词以下划线分隔

4)单词尽量精简,以名词为主,请勿主谓宾定状补都写全,没有意义。

命名一个容易记忆 & 后期容易识别的,有逻辑关系的。确保埋点名称的独一性,避免低级错误。以错误码为例,之前产品埋点时使用了wrongmessage1~100的表述方式,每次使用都要回去查看对应表格,麻烦低效。且在后续检查或补充埋点时容易出错。


【使用简写】

“需在内容可轻松识别 & 长度精简间寻找平衡。”避免url过长出现问题。

* MA — modal_appear 弹窗出现

* ST — StayTime  页面停留时间

* CB — ClickButton  点击按钮


3. 合理分类,分合清晰

有时,可以打破页面的限制,提取出全局公共的模块统一维护。也可以把同类内容的埋点放在一起。

eg1. 把核心流程中涉及到的多个用户协议整理到一起。

eg2. 我们的某个产品中有大量的表单内容,使用一个大的Form把所有表单报错放在一起,既减轻了前端埋点的工作量,又方便后期分析不同表单项报错的占比,只要能够在查看参数时能够看到url链接,就能有效区分错误来源,从而帮助我们定位具体的错误原因。


4. 用好参数,提高效率

另外当同一个内容涉及不同属性时,应搭配使用不同的参数进行区分,方便后期修改、拓展和区分查看,命名也更规范统一。否则可能出现大量的单一埋点。

eg.同一个页面采集用户信息时,需要针对新老用户分别记录数据,就适合把新用户、老用户作为内容项的参数进行埋点。  {user: 'new' || 'old'}



4. 如何保证埋点不遗漏?

目前为了提高团队协作效率和可用性,我们采用Google表格整理了“明确的数据埋点需求表”,并实时同步调整。对于新的调整内容标注不同的颜色,并在群里同步所有相关人员。


我在表格中补充了针对“需求、走查、测试”的不同勾选栏,并基于我们的业务特征区分了“PC、mc”,实际产品的两端功能有差异时,相应的埋点也是不同的,对应埋点条目做好端的勾选,方便开发确认信息,减少多次沟通的成本。


5. 写在最后的几个注意事项


1. 你以为自己以为的可能不是你以为的,你以为别人跟你一样以为的,其实不是别人以为的你以为的,或者别以人为Ta以为的。所以一定要明确的把需求讲清楚。eg. 页面停留时长,要考虑各种进入和跳离页面的情况,尽量避免误读。


2. 早定规则,严格执行

旧的不规范内容:按优先级逐步整理更新。否则越积越多,庞大的数量会让人更不愿意整理,后患无穷。

新的内容:按照规则补充进去。

让信息的规范性一致性更佳,方便后续查看和补充。有新的伙伴加入时也能降低认知成本。


3. 和开发哥哥处好关系。需要数据支持就赶紧找人解决。他们的敬业和耐心会让你效率更高,也能够及时发现需求中不恰当、有所遗漏的地方,有时候他们也会提出更简便的解决方案。


4. 警惕反对和质疑声,以正确态度回应

当你认定埋点是非常重要的事情时,面对质疑和反对,请有理有据的说明需求原因,并在后续实际使用数据解决问题,让大家意识到它的重要性。


5. 做好产品发生变更记录!!做好产品发生变更记录!!做好产品发生变更记录!!

重要的事情说3遍。如果没有清晰记录功能内容的改动点,可能导致后续看到数据时分析出现偏差,影响结果指向。


6. 埋点只是获取用户反馈的一种手段,后续的数据分析和创新优化方案才是重点。

最近正在考虑学习数据建模和分析,目前市面上也有很多便捷的埋点数据(eg. Growing io),我也在研究学习中。经历过这次埋点后,我发现后续自己要学习的东西还有很多。前进路上,勿忘初心。


我要推荐
转发到