​当企业在选型数据分析及运营工具的时候，和供应商对接的过程中，会不断沟通自身需求与对方的产品技术是否匹配，这也是选型期双方逐力的焦点。有对数据分析及运营的需求，企业自身也必然拥有线上线下的数字化触点，只有通过用户触点、用户行为的数据化，才有数据分析和后续运营的基础来源，这也是易观提倡了很多年，在未来数字企业，数据就是企业血液般存在的“新能源”。

对于双方而言，需求梳理及埋点设计，也成了选型沟通阶段的重要的内容。我们可以从下图了解一下对于企业行为数据基础建设的基本流程。





任何一家企业客户购买数据分析或运营工具，其实都是出于一定的诉求，希望达成某种目的。因此我们的技术服务团队就需要深入了解客户的需求。如若没处理好需求的话，也就无法进行后续的埋点方案，因为技术服务团队也不知道埋点方案要实现什么内容。

因此需求梳理往往需要客户与易观技术服务团队的携手并进。最简单的需求梳理方式，就是把客户直接把要实现的目的告诉易观技术服务团队，然后团队把客户要实现的目的明确出来。





什么是需求梳理？



需求梳理是对需要实现的目标进行整理，这里描述的需求特指在涉及行为数据分析的业务中所需要实现目标的整理。



我们为什么要需求梳理呢？



需求梳理是数据基础建设过程中的关键步骤，是指导行为数据采集方案以及验证最终数据建设结果的参考性文档，缺乏良好的需求梳理的行为数据采集方案容易漫无目的，也难以验证。所以，需求梳理对于数据基础建设的重要性有三：



第一，  为数据建设确立目标。这里我们要思考数据建设是为哪些部分服务的，最终需要为各部门实现哪些目的。



第二，  分析需求是否可以实现。有时候，部分需求可能利用目前的工具、技术手段暂时没法实现，需要在需求阶段由有经验的设计者进行判断，明确大家对可实现目标的一致性。



第三，  支持需求排期计划。数据建设是一个随着应用版本迭代而迭代进化的过程，不同的产品阶段会需要进行不同深度的数据分析，所以在整理需求后，可实现对需求进行优先级评估，实现对需求实现的排期计划。

如何做需求梳理？



在做需求梳理之前，我们需要对需求做要素的衡量，即衡量需求的SMART要素。



第一个要素是具体（Specific）。这是指每一个需求都必须是具体的，比如希望查看用户的DAU、想了解用户注册转化率等，这都是非常明确的需求；然而如果用户需要一个指标体系，或希望提升业务增长，那这些需求就不具体且无法衡量了。



第二个是可衡量（Measurable）。目标没有衡量就没有意义，在这里我们更多的是衡量是否能在工具中以某种形式实现，比如以配置概览的形式实现需求，以SQL或其他形式实现需求等。



第三个是可达成（Attainable）。易观技术服务团队会根据目前具备的条件，判断需求是否为可达成的目标。行为工具产品主要以行为数据为主，因此需求也往往基于行为分析，如果客户存在财务分析、库存分析等类似需求，易观技术团队则会评估是否可以转化成行为的方式进行计算。



第四个是务实的（Realistic）。需求是无穷尽的，但资源确是有限的，合适的需求是满足当前及未来一段时间内，分析、挖掘所需达到的目的。希望一次建立未来所需的所有数据采集是不可能的，所以需求梳理务实于当下所需要的做的分析，既能节省成本，又能促进当下业务发展。



第五个是时间阶段（Time Phrase）。时间是限制需求的重要因素，对于时间紧、上线要求快的项目，梳理需求时，必须考虑需求实现时间的影响。



具体的需求梳理的思路有哪些？





当易观技术服务团队对接客户进行需求梳理的时候，首先会按部门、按场景方式先提出需求，其次希望能对不同场景下面提出的目标以对应的指标的形式进行细化。



比如客户市场部的需求，他们喜欢使用易观方舟的渠道推广分析。那他们在渠道推广分析的时候，需要关注哪些指标？这些指标又应该如何定义？我们需要额外关注这一点，因为不同的公司对同一个指标可能存在不同口径的定义。



易观方舟可以实现多维度的分析。所谓多维度分析，是指针对某一个指标，可以从多种维度去查看这个指标变化的情况，从而得到更多的信息。因此易观技术服务团队与客户对接好，并确定不同指标及其相关维度之后，就可以明确所需采集的数据，之后埋点方案的设计就会如同水到渠成一般。

如何设计埋点方案？



首先，我们应该明确埋点的概念。埋点是指在应用的特定流程中，通过技术手段收集用户发生的行为信息，从而通过后续分析的手段还原用户的场景，指导产品功能改进、验证客户服务的质量等。这里的应用既可以是H5，也可以是小程序，还可以是客户端或者app等。



埋点其实有不同种类，且彼此存在区别。



对于目前移动互联网时代的应用，从用户行为的形式划分，常见的有：浏览页面、点击按钮、手势滑动、长按等，或者从功能划分，常见的有：验证行为、交易行为、加入清单、搜索等功能行为。



针对不同行为的埋点采集，从埋点在应用中的位置也可以区分成客户端埋点、服务端埋点等，从实现手段上划分，可划分：代码埋点、可视化埋点、全埋点等，具体不同的埋点方案的特点如下图所示：



为什么说埋点很重要？





在这里简单举个例子，比如我们有方案A和方案B，两个方案拿到的数据如上图所示。如果想要还原用户当时做行为的场景，哪个数据会更符合我们需求？哪个方案可以把用户当时行为的场景想象得更清楚一些？



从上图其实可以看到，方案A是传统的常规件数据采集方式，而方案B是经过一定设计的方案。当我们需要去还原用户场景的时候，方案B能分析的信息量显然更多。虽然方案B仍不是一个完备的方案，但经过一定的埋点设计，可以让我们采集的信息量变得更大。

如何实现埋点设计？



每一份埋点就像一个产品，而设计师的工作就像产品经理的工作，所以参考一个产品的实现流程一样，当设计一份埋点方案时，不是直接开始设计，而是从用户的需求开始，具体的需求我们可以参考：





01、收集各部门的需求



埋点采集的数据面向的最终用户是各个部门需要使用数据的人员，所以在进行埋点采集设计之前，有必要访问最终用户的需求，比如常见的有：市场部门、产品部门、运营部门、销售部门。



 02、需求梳理文档



由于各部门收集的需求可能形式不一，也会有很多重合的部分，所以需要对需求进行统一的整理，并根据目前公司资源的现状实现优先级的排定。我们推荐具体以数据指标的形式进行统一整理。



03、需求解读



为了实现从指标到埋点方案的落地，我们需要知道每一个指标是如何使用数据计算出来的，比如指标PV、UV等，当我们能解读每一个指标的计算方式之后，就可以着手实现埋点设计了。



04、埋点方案设计



• 设计一个具体的埋点事件



埋点事件是一个一个做的，所以每一个事件都需要进行全面的考虑。那当我们采集某个行为的时候，要具体采集哪些信息呢？



如果我们要采集页面浏览的话，应该采集哪些相应的属性信息呢？



其实在进行行为采集的时候，常常会提及五个要素，我们可以将之简单称为“4W1H”要素。





倘若用自然语言表达“一个人做了什么事情”的话，可以这么描述：什么样的人，在什么时间，在什么地点，用什么方式，做了什么。



如果通过自然语言把这些行为属性数据收集、表达出来，你是否能够想象或还原当时的场景？



这就是我们在设计埋点的时候，要思考的最重要的东西：我们要尽可能把信息采集全。当用户发生某个行为的时候，会涉及哪些东西？那些东西又会涉及什么样的属性？这些都值得我们思考。



• 确定需要采集的行为属性



在需求梳理中，我们有整理一列下钻维度的部分，当我们需要分析一个商品浏览的时候，会希望知道不同商品类别的受欢迎程度，具体是那些商品浏览量最高等，所以我们需要根据需求为用户浏览商品时，需要添加相应的行为属性，并确定不同属性的类型。



• 确定行为的触发时机



当用户发生一个行为时，往往有多个不同的埋点时机，而真实的应用场景中，大部分行为是需要向服务器发起请求的，面对这类行为的时候，埋点的触发时机就有多种可以选择。



如需求方面，若想实现用户购买商品路径埋点的话，那用户购买商品的流程应该是从 Banner 点击到浏览商品，再到加入购物车，再到提交订单，最后支付订单。

那这些流程里应该如何埋点呢？一个事件下面，需要采集哪些信息呢？



只要你使用方舟 SDK 去采集任何响应的事件或行为，方舟 SDK 都会有一些默认的属性。关于这一点大家可以去访问易观方舟的官网文档，不同的 SDK 会有不同的属性；一般在设计的时候，除了这些预置的信息之外，其实还需要采集其他信息，比如 Banner ，这时我们需要 Banner  ID,  Banner 的名称， Banner 的位置，以及跳转链接等。除此之外，我们还需要知道：在什么地点去埋，在什么时候去埋。

在这里简单举一个例子：用户提交一个订单，这个请求会经过哪些过程？



比如你在手机上提交了一个订单，你的手机会向它的服务器去发送一条数据，告诉它，现在有这么一个用户，需要提交这样一个订单，是不是可以提交。然后服务器会对所有的逻辑进行处理，去检查这个商品还有没有库存，你是否符合提交订单的条件。所有的都检查完了以后，它会在数据库里面去写下所有的信息，当它确认数据库里写信息已完成后，它会把写完之后的结果发送给你的 app，它会告诉你可以进入下一个阶段——支付订单阶段。你的 app 收到了这个信息，才会让你进入下一步，进入支付订单的页面，这就是你提交订单的简单的逻辑。

由于大多数人提交订单都基本成功的，因此大家可能不会有明显的感知。不过大家参加双十一活动的时候，其实就能发现你所提交的订单失败了，因为你所选中的商品已经卖完了。但实际上流程的逻辑是，你提交订单的请求发送到服务器，但服务器判定你的请求是不成功的，目前已经不能再提交了。因此我们要确定行为触发的时机。

不同位置的埋点其实是不同的。不同埋点位置的优势和劣势可以参考下图：





①处埋点特点：



1. ⽤户触发⽴即埋点，易于理解。

2. 埋点后，数据经过公⽹传输，有⼀定概率会丢包，造成数据不准确。

3. 业务请求可能出现失败情况，导致和业务数据库对不上，⽐如：⽤户点击加⼊购物⻋，但 是服务器加⼊失败，⽽这个时候埋点已经完成了。

4. 连续多次点击可能造成多次上报，⽐如：当⽤户点击注册按钮时，可能1s内连续点了4 次，这时如果前端没有考虑这种情况，则可能上报4次注册，和业务数据库⽆法匹配。

5. 多端埋点，每⼀类型客户端都得埋⼀次数据采集代码。

6. 错误处理难，当出现埋点错误时，需要更新版本才能解决。

②处埋点特点：



1. 埋点数据在内⽹传输，丢包概率极低。

2. 业务请求尚未完成，可能出现失败情况，会和业务数据库对不上。

3. 缺少前端相关属性（如操作系统、应⽤版本、公共属性等信息）。



一般而言，很少会选择在②处进行埋点。

③处埋点特点：



1. 埋点数据在内⽹传输，丢包概率极低。

2. 业务请求已完成，对于常⽤的如注册、订单等数据基本都能和业务数据库保持⼀致。

3. 缺少前端相关属性（如操作系统、应⽤版本、公共属性等信息），可以通过发起请求时， 将相应属性携带在请求头中，服务端解析之后，再⼀起上报该数据，实现成本稍⾼，但数据可靠，修改⽅便。

4. 同⼀个事件埋点，只需要埋⼀次，埋点成本低。

5. 更改⽅便，埋点不受客户端发版本限制，随时修改，即时⽣效。

6. 错误解决成本低，发现错误时，修改⼀处即可，且⽴即⽣效。



⼀般对于重要的与业务分析相关的数据，如注册、订单、发帖、评论等⾏为，在此处埋点 可以获得更准确的数据。

④处埋点特点：



1. 埋点后，数据经过公⽹传输，有⼀定概率会丢包，造成数据不准确。

2. 业务请求完成后再埋点，对于注册等需要和业务端⽐对的数据，⼀般⽐①要好⼀些。

3. 对于功能按钮，⼀般不会造成连续多次埋点。

4. 多端埋点，每⼀类型客户端都得埋⼀次数据采集代码。

5. 错误处理难，当出现埋点错误时，需要更新版本才能解决。



⼀般对于像搜索⾏为的埋点，在分析时，需要考虑⽤户获取的搜索结果情况，所以若选择前端埋点，在此处埋点较为合适。

如何选择埋点时机



1.⼀般的纯前端交互⾏为，如：下拉框选择、按钮点击等，选择在①处埋点即可。

2.业务⾏为多选择在后端埋点；如评论、点赞、购买、提交订单、⽀付等⾏为选择在③处更为合适，其次选择前端 ④ 处埋点。

3.前端、后端都可以获取数据时，有资源情况下，建议优先选择③处埋点。