【m端是什么意思】b端数据埋设点

指南编辑：在B端设计业务场景中，非产品或数据分析师经常忽略数据商店，但在提高用户体验和改善产品更新迭代方向的过程中，数据掩埋点起着重要作用。(威廉莎士比亚，Northern Exposure(美国电视剧)，Northern Exposure(美国电视剧)，Market)本文作者详细分析了B端产品业务场景的数据商店，我们一起看一下吧。(大卫亚设)。

哈哈~不知道大家奋斗在一线的B方合伙人会不会经常遇到以下困惑。

现有的设计最适合用户吗？如何通过科学手段进行验证？设计了多个版本的方案，到底哪个版本更好？为什么这个版本好？设计师在输出设计稿时，通常使用多种方法来辅助设计(如用户调查、竞品分析、可用性测试等)。但是，这种方法论无法客观验证我们的设计。为了客观地验证我们的设计，必须通过数据挖掘方案中的问题，并验证最终方案是否有效。数据的掩埋点是我们打开数据思维的重要部分。

什么是数据埋设点？

“应用商店数据”也称为“商店数据”或“前端页面数据”，“通过技术手段从应用程序(网站、客户端、小程序等)中获取用户的操作行为数据。”也就是说，用户和界面交互，系统向服务器发送请求，返回请求，将这些请求预先埋在计数代码中，就可以获得页面的曝光数据和用户的操作数据。——摘自《腾讯文档 | 数据化设计》

举个通俗的例子，数据商店就像我们城市街道内的摄像头。所有的摄像头，都是城市这个大系统的掩埋点。监视该地区发生的一切事情，满足交通、市政、企业管理等要求。(阿尔伯特爱因斯坦，Northern Exposure(美国电视)，交通管理名言)通过这个比喻，我们能很快知道埋着数据的是什么吗？

我们对门店的定义有基本的认识。那么，各位，我们在日常工作中数据质量惨淡的原因是什么呢？请在这里思考5秒钟~

5

4

3

2

1

我相信大家都会有一定的小想法！所以这里可以分享一下我们公司数据混乱的一些原因。一开始我刚来公司的时候，整个接受的业务数据质量有很大的提高空间。审查现有数据后，主要问题是数据收集没有做好。今天要提到的数据掩埋点又是数据收集的主要方式，总结了我们公司数据混乱的原因如下。

早期的产品线没有考虑卖场地点。埋葬后，模块数据无法正确上报，或者无法处理上报错误。卖场方式错误，找不到核心数据指标。PC方采用M方门店方式，B方产品采用C方门店方式。不知道树有小伙伴的情况与我们一致吗？如果是这样的话，要清醒地看12分钟的话，下面就谈谈如何优化这种情况的一些方法。(大卫亚设)。

首先，数据源真的正确吗？

在总结门店的方法之前，我与在B端行业深耕多年的许多设计伙伴进行了交流后，发现了一个非常梦幻的现象。

实际上，随着互联网环境的变化，在处理产品迭代需求或运营活动时，将数据用作决策参考。但是一般来说，我们不会质疑数据源。设计师的数据源一般是从产品中获取的，但从来没有想过产品是从哪里获取的数据。(David Assell，Northern Exposure(美国电视)，数据名言)深挖后才发现，产品对手的数据真实性实际上没有得到验证，所以产品端的数据都很模糊。更别说把手伸到设计方面了。(莎士比亚)。

那么，如果我们能自己推动卖场需求，获得想要的数据，就能从源头上解决数据真实性问题~

二、B端设计师需要了解的卖场知识有哪些？

前面提到的摄像头是监控一个城市是否运行良好的重要工具，同样，数据掩埋点也是监控我们产品体验的重要手段。成为一个城市

埋点的两种模式？

1）私有化部署

在一些对数据安全性要求比较高的工地，他们会自主研发或私有化部署适合自身的独立数据系统。

2）接入第三方服务

目前大部分公司更多是专注业务本身，埋点直接使用第三方的技术服务；接入第三方技术服务优势在于研发成本低，几乎能满足企业对数据埋点的要求。同样缺点也是蛮明显的，无法定制个性化埋点方案，存在数据风险等。

目前市面上有很多的数据支持公司，例如：神策、GrowingIO、友盟等。

三、B端那些地方需要进行埋点？

B端产品，尤其是业务系统，埋点的作用往往观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据。因此就很清晰我们的埋点思路了。

1. 上线新的功能时

在产品设计前，产品和设计师都会进行一定的调研，依据调研结果判定功能是否符合用户的真实需求，但是前期的调研结果其实是主观的，无论是采用问卷、访谈等形式，用户的反馈并不能其真实的想法。

通过埋点新功能相关点位，我们发现用户使用量符合预期，那说明这是一个正确的决策。如果发现没有人用，那可能这个功能宣传太弱，用户没发现，也可能这个决策根本就是错误的。

此处埋点的目的主要在于功能的优化，常用于对新上线功能的检测。

举个例子：比如我们产品新上线了一个功能，该功能属于方便用户进行表格筛选。那么我们就需要对这个筛选功能的使用频率进行检测，用以判定我们的业务结果；具体需要测量其那种类型数据指标，这里可以提前说一下是点击量这个指标，具体的类型后面会提到。

2. 核心业务功能

与业务关联性强的都可以算为重点功能，比如我们是做电商零售平台的，那么订单管理，商铺管理这些模块毫无疑问是重点功能，与这些模块相关的用户操作路径上的交互控件都应该受到监控。

举个例子：我们公司是做电商零售平台的，最近用户反馈在订单管理里面能不能将近三个月订单放在第一个table上方便他不用去切换。当然不是有单个用户反馈就去改产品的结构的，这时候我们就需要提取这几个table的点击情况来判断这几个table的权重了。如果大部分用户需要来回切换近三个月订单，我们便可以考虑将其放在进入页面的首位。

3. 判断设计方案

在C端我们可以通过A/BTest的方式来观察数据，看哪个位置或者形式更能引起用户的注意，达到想要的效果。

B端产品也会采用类似这个的方式，此处也举个例子：比如最近想要改版一下关于消息通知是从顶部右侧弹出还是从底部右侧弹出更不干扰用户，当然我们可以看竞品怎么做，但是总是借鉴竞品也不是解决根本问题的方法。此时我们可以将时间维度作为测试基本盘，通过不同的方案获取不同的数据来进行决策。

四、用户会触发哪几类行为？

在检测用户数据之前，需要了解用户在PC端上会触发哪几种行为？按照获取数据的类型和用户触发的行为不同，通常可以将用户行为分为点击事件、曝光事件、页面事件三种类型。

1. 点击事件

用户在系统内部的每一次点击行为，都可以记为一次点击事件。比如按钮的点击、输入框的点击、订单的点击、每一条消息的点击等，都可以成为一个点击事件。

2. 曝光事件

曝光事件简单来说是为了统计系统内的特定区域是否被用户有效浏览。比如工作台，订单中心的表格，系统内的广告位等等。

通常来说我们在衡量页面某个区域用户的点击率的时候，首先需要搞清楚的就是这个区域到底被多少用户看到了，点击人数除以看到了该广告位的人数，才能计算点击率。如何统计曝光事件才算合理比较复杂，这个点如果大家感兴趣可以考虑再出文章细讲。

3. 页面事件

页面事件通常是指页面的各种维度信息的统计。常见的比如页面浏览PV，页面浏览UV。

页面事件通常统计的信息包括以下几个部分：

• 浏览器信息：浏览器版本，浏览器语言，浏览器编码，屏幕分辨率等等；
• 访问信息：用户账号，当前页面url，上次访问时间，访问时长，页面停留时间等等；
• 来源信息：用户到这个页面的来源，上一页面url等等；
• 物品信息：不同的业务，这部分信息会区别很大。

通过了解事件的分类我们再做指标时就不会无从下手了，举个小例子。

我们的业务最近上新了一个新功能“消息通知”那么我需要知道这个功能上线后倒地有多少人去使用，那么我就需要获取想消息通知icon的点击率（点击事件），同时我还需要知道这个消息通知列表页面用户一般会看几条信息，因为业务可能会推送多条的更新信息，所以我需要页面停留时长和浏览高度（曝光事件），后续我还得知道用户是那个信息来源来到消息通知页面的，是自主点击“消息通知”icon进来的、还是点击通知提示进来的（页面事件）？

通过上面这个例子是不是就很容易理解事件的类型呢？

五、在B端需要获取的关键指标有哪些？

与C端所需要采集的数据不同的是，B端的应用场景主要是web端居多，B端主要采集的数据也更侧重于业务数据、PVuv 、点击量、浏览器的类型 、 页面停留时长、操作路径等。

B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯，从而进一步评估功能设计是否合理，是否帮用户降低了使用门槛，提升了工作的效率。从这一点来说B端与C端还是有些区别的。

1. 业务数据

业务数据包含用户的基础信息，比如拿一个电商零售平台来说店铺有几个客服、有几个角色；也包含用户的交易数据，比如说订单数量、订单金额。

虽然这些埋点数据可以要求后台直接导出，但是如果这样每次导出都需要开发单独去处理，无法获得实时的数据也很不利于团队氛围营造，所以建议埋点的时候也将此部分的数据统计进去。

2. PV/UV

• PV：页面访问量，每打开一次页面PV计数+1，刷新页面也是算是加1个访问量的；
• UV：独立访客访问数，一台电脑终端为一个访客，通常是算IP的。

这是设计师必须要懂得的两个数据之一。

3. 点击量

常用于页面中按钮、选择的点击量统计。比如上面的例子：近三个月订单、全部订单、待发货订单的table，是否是高频操作，将那个放在前面，这样排列的顺序是否合适？该数据利于细节优化。

4. 浏览器类型

B端业务大部分场景都是在PC端上完成，我们可以通过埋点了解用户的浏览器类型、屏幕分辨率，做好适配。就像是表格表单等等相关业务控件数据字段特别多，可能在1920px下，正好能看全，但是在720px下，会有一部分数据看不到。这时候要等比压缩，还是做拖拉？

5. 页面有效停留时长

B端用户在页面的停留时长还是能说明一定的问题。比如说我们的业务会有一个店铺装修的业务，这个业务通常交互都会比较复杂，通过检测页面的有效停留时长可以反映目前这个业务用户在使用上是否存在难点，针对性去优化该部分的用户的体验；

6. 操作路径

操作路径就是跟着业务流程，来监控用户的操作行为。比如说我们业务上其中一部分流程是这样的：

但当时有另一个方案流程是这样的：

我们可以总结出最常用的流程，来优化使用的路径。但操作路径的埋点，工作量非常大，所以需要在埋点的设计上思考好关键的数据指标。

六、实操：一个埋点需求从开始到落地

上面已知我们要对批量发货、批量标记、批量免运费进行监测，由于我们不能自己去进行埋点，或者你也可以将这个需求告知给产品经理让他帮你出这一份文档。但是我觉得如果设计能写出来给到开发而且能直接跟开发沟通是一件很酷的事情，不妨学习写一下文档。

1. 整理埋点需求并输出文档

此处可以看到，一份规范的埋点文档会包括：事件名称、事件属性、数据类型、属性说明、埋点形式、触发时机等，只有将埋点文档梳理规范了，前端小哥才不会和你打架哦。

2. 埋点代码的植入

不同于摄像头，数据的采集工具通常为埋点代码，不用的产品形态采取不同的埋点代码植入，通常有三种：js文件、SDK、http请求，具体对应的是M端，网页端和服务器。这块通常是研发来做，产品经理和设计在旁边加油打气就行了。

在研发完成埋点注册后，研发就开始Coding了，通常研发都会采用第三方公司的SDK（可以理解成代码包）这样可以节省大量的工作量，当然如果公司自研SDK期可扩展性会高很多，可以实现全埋点可视化埋点的采集方式，当然这样成本也会高。

现有市面上主流SDK数据分析公司的埋点方式比较：

3. 埋点测试与校验

这一部分的内容通常是由测试同学来完成的，测试同学通过测试这些埋点数据，通过后才可以部署上线，此处粗略讲讲他们需要测些啥：

• 测试埋点数据是否正常报出；
• 在数据库里面能不能检测到埋点数据；
• 事件和对应属性是否能对的上。

当他们将这些点验收完成，研发人员部署上线，就可以等着收数据了。

4. 线上数据追踪

埋点上线后，如果采用的是第三方的SDK公司都会提供对应的数据可视化产品用于数据展示，当然如果自研SDK并没有做数据可视化产品也可以直接叫后台同学提取SQL提数，当然这对设计师和产品经理就很不友好了。

5. 如何利用好数据

1）同一版本只验证一个设计点

有时候我们需要验证某个数据时，需要考虑到是否会有其他的改动点影响到当前的数据，比如上面我们在研究批量发货、批量标记、批量免运费三个table的使用情况，而恰巧这个时候开发小哥说要不要做一个用户可以自定义拖拽table的功能，这样做起来很方便。但是如果这两个优化点同时上线，我们就无法知道这3个Table点击率结果是哪个优化点所带来的效果了.

因此我们可以将自由拖拽table放在下一个版本中，避免数据是由多种原因所造成的。

2）保持数据的稳定

C端场景中，用户基数大，可以很轻易确定设计改动结果，比如通过一个改动数据提升1%2%乘以用户基数都是一个客观的数字。

但是在B端场景中，更多的反倒是体现在流程的优化上，用户在使用整体流程是否有增加效率。因此我们需要明白验证的数据指标是否正确，其指标是否真实代表此次改动的结果。只有更为精准的数值指标，才能验证设计改动的价值。

七、总结

B端的业务场景中，我们经常会忽视数据埋点，功能都是踩点才赶完的，哪里还有时间和精力做这个，活又多又细，老板、客户还看不到。

但是当主要功能已经逐步完善，将数据埋点提上日程是很有必要的一件事，B端与C端不同，不再是依靠功能的叠加，而是依靠单个强功能去打开市场。在用户访谈效率低下的情景下，数据埋点是一个很好的工具，可以反映出很多问题来，指导我们精细化设计产品，指导我们前进的方向。

以前我们只需要做好设计，数据埋点常常是产品和数据分析师的事。但是随着互联网的发展，整个行业对体验设计师的要求也会越来越严苛（真是怀念以前只要画图的日子）。

未来不再是只需要执行者，还需要对业务的深入了解，以项目合伙人的心态去做产品，尽可能发挥设计的最大价值，特别是在B端设计方向，随着组件库的完善，界面搭建门槛也越来越低。整个行业的水平也会随着时间发展而往上走，深入业务、理解业务、赋能业务才是最终归宿。

参考文献：

《如何利用数据驱动设计》——Natalia Babaeva

《埋点还是埋雷？ 十年数据分析经验，教你如何结构化埋点！》

《数据埋点对B端产品的意义》

《腾讯文档 | 数据化设计》——isux

作者：Weiyehe

原文链接：

本文由 @Weiyehe 授权发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议