数据埋点是我们打开数据思维的重要一环

　　

数据埋点是我们打开数据思维的重要一环

　　

　　你好~不知各位在一线苦苦挣扎的B端朋友是不是经常有以下困惑？

　　

　　设计师在输出设计稿时，通常会使用各种方法论来辅助设计，例如用户研究、竞品分析、可用性测试等。但是这些方法论并不能客观地验证我们的设计。为了客观验证我们的设计，我们只能通过数据来发现方案中的问题，验证最终方案是否有效；数据的嵌入是我们数据思维的重要组成部分。

　　

　　什么是数据埋点？

　　“应用嵌入点数据”也称为“嵌入点数据”或“前端页面数据”。我们可以简单的理解为“通过技术手段获取应用中用户信息（网站、客户端、小程序等）的操作行为数据”。其背后的原理是：用户与界面交互，系统需要向服务器发送请求和返回请求，这些请求中嵌入了一个计数代码，以获取页面的曝光数据和用户的操作数据。 ——摘自《腾讯文档|数字设计》

　　举一个流行的例子。数据埋点就像我们城市街道上的*敏*感*词*。每个相机都是城市大系统中的一个埋点。它监视并记录该区域发生的一切。 ，满*敏*感*词*通、市政、企业管理等方面的需要。我们能否通过这个类比快速了解数据中隐藏的内容？

　　

　　我们对埋点的定义有了一个基本的了解，那么请朋友们思考一下，我们日常工作中数据质量差的原因是什么？在这里，让大家5秒思考~

　　5

　　4

　　3

　　2

　　1

　　相信大家或多或少都会有一些想法！所以这里有一些导致我们公司数据混乱的原因。刚开始我刚来公司的时候，接受的业务数据的质量还有很大的提升空间。在查看现有数据后，我发现主要问题在于数据采集。一块没做好，今天说的数据埋点就是数据采集的主要方法。我总结了造成我司数据混乱的原因如下：

　　

　　不知道有没有和我们一样情况的小伙伴？ ，如果你有一个，你要跟上十二点的精神。以下是一些优化这种情况的方法。

　　一、你的数据来源真的准确吗？

　　在总结埋点方法之前，和很多在B端行业工作多年的设计伙伴交流后，发现了一个很神奇的现象。

　　诚然，随着互联网环境的变化，无论是处理产品迭代需求还是运营活动，都会以数据作为决策参考。但通常我们不会质疑数据的来源。设计师通常从产品中获取数据，但我们没有考虑产品从哪里获取数据。深入挖掘后发现，其实产品对手的数据真实性并没有得到验证，所以产品端的数据都是模糊的，更不用说设计端了。

　　那么如果我们能够推动埋点需求，自己获取我们想要的数据，就可以从根源上解决数据真实性的问题了~

　　

　　二、B 端设计师需要知道哪些隐藏知识？

　　如前所述，相机是监控一个城市是否运转良好的重要工具。同样，数据埋藏也是监控我们产品好体验的重要手段。当一个城市发生交通事故时，我们可以依靠*敏*感*词*来还原事件发生的过程，从而得出结论和处理方法。当用户反馈问题时，我们也可以利用埋藏的数据给我们的产品开处方，避免出现头疼脚疼的尴尬情况。

　　两种埋点模式？

　　1）私有化部署

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

　　2）访问第三方服务

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

　　目前市场上有很多数据支持公司，如：神测、GrowingIO、友盟等

　　

　　三、B 到底需要埋在哪里？

　　B端产品，尤其是业务系统，经常观察和研究用户对各种产品功能、使用情况、用户操作习惯的接受程度，以进一步评估功能设计是否合理，是否帮助用户进行了改进效率等，为持续优化提供基础。因此，我们的思想埋点非常明确。

　　1.新功能上线时

　　

　　在产品设计之前，产品和设计师会进行一定的研究，并根据研究结果确定功能是否满足用户的真实需求。然而，初步的研究结果实际上是主观的。无论是问卷调查、访谈等形式，用户的反馈都不是真正的想法。

　　通过对新功能的相关点进行埋点，我们发现用户使用情况符合预期，说明这是一个正确的决定。如果发现没有人在使用，可能是该功能宣传太弱，用户没有注意到，也可能是决策完全错误。

　　这里埋点的目的主要是为了优化功能，常用于检测新上线的功能。

　　比如：比如我们的产品新增了一个方便用户过滤表格的功能。然后我们需要测试这个过滤功能的使用频率来确定我们的业务结果；数据指标的具体类型需要衡量，这里可以提前说一下是点击量指标，具体类型后面会说到。

　　

　　2. 核心业务功能

　　

　　与业务密切相关的可以算作关键功能。比如我们是一个电商零售平台，那么订单管理和门店管理模块无疑是关键功能，与这些模块相关的用户操作路径所有交互控件都要监控。

　　例如：我们公司是一个电子商务零售平台。近日有网友反映，订单管理中近三个月的订单是否可以放在第一台，让他不用切换。当然，并不是因为单个用户的反馈就改变了产品的结构。这时候我们就需要提取这些表的点击量来确定这些表的权重。如果大部分用户需要来回切换近三个月的订单，我们可以考虑将其置于页面顶部。

　　

　　3.判断设计方案

　　

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

　　B端产品也将采用类似的方式。这里也举个例子：比如我最近想修改一下消息通知是从右上角弹出还是从右下角弹出的消息，以免干扰用户。当然，我们可以看看竞品是怎么做的，但总是向竞品学习并不是解决根本问题的方法。这时候我们就可以将时间维度作为基本的测试盘，通过不同的方案获取不同的数据来进行决策。

　　

　　四、 用户会触发哪些类型的行为？

　　在检测用户数据之前，需要了解用户在PC端会触发什么样的行为？根据数据获取的类型和用户触发行为的不同，用户行为一般可以分为三类：点击事件、曝光事件和页面事件。

　　

　　1. 点击事件

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

　　2.曝光事件

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

　　一般来说，当我们衡量用户在页面某个区域的点击率时，首先需要弄清楚有多少用户看过这个区域，点击次数除以看过广告位的人数可以计算点击次数。速度。如何统计暴露事件被认为是合理且复杂的。有兴趣的可以考虑文章详解。

　　3.页面事件

　　页面事件通常是指页面各个维度的统计。常见如页面浏览量PV、页面浏览量UV。

　　页面事件的一般统计信息包括以下部分：

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

　　我们的商家最近推出了一个新功能“消息通知”。然后我需要知道这个功能上线后有多少人使用。然后我需要获取消息通知图标的点击率（点击事件）。同时，我还需要知道用户在这个消息通知列表页面一般会查看多少条信息，因为业务可能会推送多条更新的信息，所以我需要页面停留时间和浏览高度（曝光事件)，而且我必须知道将来的用户是谁。那个信息源来到了消息通知页面。是点击“消息通知”图标进来的，还是点击通知提示进来的（页面事件）？

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

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

　　C端需要的采集数据的区别在于B端的应用场景主要是web端，B端采集的数据也更侧重于业务数据、PVuv、点击次数、浏览器类型、页面停留时长、操作路径等

　　B端产品，尤其是业务系统，经常使用嵌入式点来观察和研究用户对各种产品功能、使用情况、用户操作习惯的接受程度，从而进一步评估功能设计是否合理，是否有帮助用户减少 提高使用门槛，提高工作效率。从这个角度来说，B端和C端还是有一些区别的。

　　1. 业务数据

　　业务数据收录基本的用户信息，例如一个商店在电子商务零售平台上有多少客户服务和角色；它还收录用户交易数据，例如订单数量和订单金额。

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

　　2. PV/UV

　　这是数据设计师必须了解的两个之一。

　　3.点击量

　　通常用于统计页面上按钮和选择的点击次数。比如上面的例子：最近三个​​月的订单表、所有订单、挂单是不是高频操作？把那个放在前面。这样的顺序合适吗？这些数据有利于细节优化。

　　4.浏览器类型

　　大部分B端业务场景都是在PC端完成的。我们可以通过嵌入点来了解用户的浏览器类型和屏幕分辨率，并做出很好的适配。表格、表格等相关业务控件的数据字段太多了，1920px下可能碰巧能看到整体，但是720px下就会有部分数据不可见。这个时候，我们需要按比例压缩，还是拖延？

　　5.有效页面停留时间

　　B端用户停留在页面上的时间长短还是可以说明某个问题的。例如，我们的业务将有一个店铺装修业务。这种业务通常交互更复杂。通过检测页面的有效停留时间，可以反映当前业务用户是否存在使用困难，有针对性地优化用户的表现。经验；

　　6.操作路径

　　操作路径是按照业务流程监控用户的操作行为。例如，我们业务中的部分流程是这样的：

　　

　　但当时还有一个类似的项目流程：

　　

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

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

　　由上可知，我们需要监控批量发货、批量打标、批量包邮。既然我们不能自己埋点，或者你可以把这个需求告诉产品经理，让他帮你做这个文档。不过我觉得如果设计能写给开发用，能直接跟开发沟通是一件很酷的事情，不如学着写文档。

　　1.整理需求和输出文档

　　

　　这里可以看到，一个标准化的embedding文档会包括：事件名称、事件属性、数据类型、属性描述、embedding形式、触发时机等，只有embedding文档被整理和标准化，前端是小。哥不会跟你打的。

　　2.嵌入嵌入代码

　　与*敏*感*词*不同的是，采集数据工具通常是内嵌代码，不同的产品形态采用不同的内嵌代码植入。通常有三种类型：js文件、SDK、http请求，具体对应的是M端。 、Web端和服务器。这通常是由研发完成的，产品经理和设计只是在一旁欢呼。

　　研发完成埋点登记后，研发将开始编码。通常，研发会使用第三方公司的SDK（可以理解为代码包），可以节省很多工作。性能会高很多，可以实现可视化所有埋点的采集方法。当然，成本也会很高。

　　市场上主流SDK数据分析公司的埋点方法对比：

　　

　　3.埋点测试与验证

　　这部分内容通常由测试学生完成。测试学生通过对埋点数据的测试，通过后即可上线部署。以下是他们需要测试的内容的粗略概述：

　　完成这些点的验收，研发人员上线后，就可以等待接收数据了。

　　4.在线数据追踪

　　埋点上线后，如果使用第三方SDK公司，将提供相应的数据可视化产品进行数据展示。当然，如果自研SDK没有提供数据可视化产品，可以直接请后端同学提取SQL数据。 ，当然，这对设计师和产品经理来说是非常不友好的。

　　

　　5.如何善用数据

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

　　有时当我们需要验证某些数据时，我们需要考虑是否会有其他变化影响当前数据。例如，我们正在研究在批量运输、批量标记和批量免费运输中使用三个表。 ，而且恰巧这时候开发者问要不要做一个自定义的拖拽表格功能，很方便。但是如果这两个优化点同时在线，我们就无法知道哪个优化点带来了3个表格点击率结果的效果。

　　这样我们就可以随意拖放表格，放到下一个版本中，避免多种原因造成的数据。

　　2）保持数据稳定

　　在C端场景中，用户基数大，设计变更的结果很容易判断。比如数据变化1%乘以用户基数就是一个客观数字。

　　但在B端场景，更多体现在流程的优化上，用户是否在使用整体流程来提高效率。因此，我们需要了解经过验证的数据指标是否正确，该指标是否真正代表了这种变化的结果。只有更精确的数值指标才能验证设计变更的价值。

　　七、Summary

　　在B端业务场景中，我们经常会忽略数据埋点。功能只是冲到重点。哪里还有时间和精力去做这件事，哪里就有很多工作和细节，老板和客户还是看不到。

　　但是当主功能已经逐渐完善之后，就要把数据提上日程了。 B端不同于C端。它不再依赖于功能的叠加，而是依赖于单个强大的功能来打开它。市场。在低效的用户访谈背景下，数据嵌入是一个非常好的工具，可以反映很多问题，指导我们进行产品的精细设计，指导我们前进的方向。

　　过去，我们只需要做好设计，数据埋点往往是产品和数据分析师的工作。但是随着互联网的发展，整个行业对体验设计师的要求会越来越严格（我真的很怀念那些只需要画图的日子）。

　　未来，您将不再只需要一名高管，还需要对业务有深入的了解。以项目合伙人的心态来做产品，将设计的最大价值发挥到极致，尤其是在B端设计方向。随着组件库接口的完善，接口构建的门槛越来越低。整个行业的水平也会随着时间的推移而提升。深入业务、了解业务、赋能业务才是最终归宿。

　　参考文献：

　　如何使用数据驱动设计-Natalia Babaeva

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

　　“数据嵌入点对B端产品的意义”

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