2.2 用户行为数据采集

本节以电商产品为例，讲一下如何采集用户的行为数据。

用户行为数据的采集有如下三种方式。

（1）与第三方移动应用统计公司合作完成数据采集。

（2）采用前后端埋点结合的方式完成数据采集。

（3）采用可视化埋点与后端埋点结合的方式完成数据采集。

接下来笔者分别介绍这三种用户行为数据的采集方式以及它们各自的优、缺点。

2.2.1 与第三方移动应用统计公司合作的数据采集方式

第一种方式是与第三方移动应用统计公司合作完成数据埋点。

前端开发工程师需要按照第三方移动应用统计公司的对接要求，集成第三方移动应用统计公司提供的数据采集SDK（Software Development Kit，即软件开发工具包）。一般来说，第三方移动应用统计公司会提供H5端、安卓端、iOS端、小程序端的SDK。前端开发工程师完成了SDK的集成，就能在他们的后台查看自己的应用的数据。市场上比较主流的第三方移动应用统计产品包括百度移动分析、Google Analytics、腾讯移动分析等，接入这些公司的SDK就能完成基础数据的采集。

这种方式的优点是开发工作量少，一般每个客户端花费1～2天的开发时间就可以完成集成，而且数据分析相关功能都不需要开发，这些第三方移动应用统计公司会直接提供相关功能。采集到的数据相对来说比较准确，因为这些产品都是比较成熟的，有很多公司都在使用，一般不会出现数据质量的问题。

不过，这种数据采集方式也有几个缺点。

（1）产品线的流量相关数据比较丰富，但是因为只做了最基础的页面和按钮埋点，很难采集到产品线的业务数据，比如对于电商产品来说，我们不但要看坑位的流量，更要看坑位的转化率，而转化率这个指标就涉及交易额，但是第三方移动应用统计产品是无法获取我们产品的交易额的。如图2-1所示，这是百度移动统计大致的演示页面，我们只能看到流量相关数据，不能看到业务数据。

（2）能看到的数据有限。第三方移动应用统计产品都是标准化的产品，提供的都是标准化的数据，其数据的范围不一定能覆盖公司所有数据方面的需求。

（3）第三方移动应用统计产品提供的数据很难同步到数据中台的数据中心。第三方移动应用统计公司一般不会提供这样的数据同步接口，只有产品用户活跃度很高的大客户才能获得这些分析数据，小型公司则很难获得。

2.2.2 前后端埋点结合的数据采集方式

第一种方式采集到的用户行为数据无法结合用户的业务数据，而通过前后端埋点结合的数据采集方式就可以解决这个问题。所有数据埋点相关的工作都是为了解决实际项目中的问题，接下来笔者以电商产品为例介绍一下如何通过前后端埋点的方式完成产品线的用户行为数据的采集，同时会进一步介绍如何使用采集到的行为数据解决电商产品的实际问题。

（1）如何分析电商产品主路径每天的访问情况

用户访问电商产品的主路径一般为：访问首页→访问商品列表页→访问商品详情页→加购→下单→支付。

有了埋点数据就可以知道访问主路径每个步骤的用户数，从而可以分析出哪两个步骤之间的转化率比较低，接着可以进一步分析转化率低的原因，从而根据原因进一步优化产品。如图2-2所示，这是一个典型的用户访问电商产品主路径示意图。

（2）如何解决坑位的转化率问题

电商产品都由一个个坑位组成，每个坑位分布在不同的位置，不同的商品在不同的坑位中售卖。采用与第三方移动应用统计公司合作完成数据采集的方式只能获得坑位的流量数据，比如PV（页面浏览量）和UV（独立访客数），但是评价一个坑位的好坏不能仅仅靠流量数据。有些坑位的流量比较高但是却没有产生多少交易额，有些坑位的流量很低，放在十分不显眼的地方，却产生了可观的交易额，因此仅用PV、UV两个指标衡量坑位的好坏是不公平的，需要定义一个比较公平的指标——坑位转化率。

坑位转化率即坑位UV与支付用户数的比值。

使用坑位转化率可以很好地判定一个坑位的性价比。如果坑位处于很明显的位置，而转化率很低，那就要分析原因，改变运营策略，比如调整图片、调整商品、调整位置等。

（3）如何打通用户的行为数据和用户的业务数据

我们需要清楚地了解用户在什么时候访问我们的产品、访问了哪些商品、什么时候“加购”了我们的商品、“加购”了哪些商品、什么时候买了我们的商品、买了哪些商品。用户访问商品的数据属于行为数据，用户加购、下单、支付商品的数据属于用户的业务数据。

（4）如何弄清楚用户的留存情况

留存的定义分为两种：第一种是访问留存率，在新用户第一次访问后，看他接下来7天后、14天后、一个月后是否再次访问；第二种是购买留存率，在用户第一次支付后，看他接下来7天后、14天后、一个月后是否再次支付。通过访问留存率，我们能清楚地看到用户对平台的黏性；通过购买留存率，我们能检测平台的价值，因为有价值才会产生交易。

接下来我们看一下如何通过前后端埋点的方式解决以上问题。

首先介绍一下技术方案。电商产品一般包含H5端、移动端（iOS端或安卓端）、小程序端。要解决以上问题，首先要针对电商产品的每个客户端做全面的埋点，如果让前端开发工程师采用手工埋点的方式，工作量是比较大的，而且没有统一的数据采集标准会导致后期的数据质量比较差。市场上有很多数据采集的开源软件供选择，选择这些开源的软件一方面能节省大量的开发成本，另一方面各个客户端的开发工程师都采用同一个采集标准，十分有利于后期的数据处理。如果开源的软件不能满足数据采集的需求，前端开发工程师可以使用源代码进行一些定制开发。

市场上还有比较多的开源SDK，可以从是否开源、SDK是否支持H5端/安卓端/iOS端、部署方式是私有化还是SaaS化（采集的用户数据是公司的重要资源，出于安全考虑，需要本地化部署）这几个方面来考虑。如表2-1所示，这是几个比较主流的数据产品公司的SDK，供大家参考。

在选好SDK后，就可以进行下一步的工作，定义埋点的接口文档。让前端开发工程师按照接口文档完成数据埋点。埋点的接口文档主要定义如下这些内容。

● 哪些公共字段需要统一采集？

● 哪些页面和哪些按钮需要埋点？

● 特殊的页面和按钮需要通过埋点获取什么参数？

首先看一下公共字段的定义。这些信息都封装在SDK中，只要前端开发工程师基于SDK的开发文档进行工程部署即可，当用户浏览某个页面或者点击某个按钮时，SDK就会自动收集用户的这些基础信息。这样，用户在哪里、用户使用什么设备、用户什么时间访问了我们的产品等基础数据的收集问题就解决了。具体埋点接口公共字段的定义如表2-2所示。

接下来我们看一下浏览页面事件的采集。针对浏览页面事件，SDK也会预设公共信息，当用户浏览页面时，我们要获取当前的用户是谁。如果有用户登录信息，我们就可以获取用户手机号，如果用户未登录，可以把浏览设备ID设为用户的唯一身份标识，还要获取当前的页面是什么、从哪个页面过来、当前的产品线信息等，具体信息如表2-3所示。

为了完成用户浏览事件的数据收集，需要梳理一下当前产品的每个客户端都有哪些关键页面。比如电商产品，其核心页面有推广页、首页、商品列表页、商品详情页、加购页、下单页、支付页等关键页面，需要针对这些页面统一进行数据采集，如表2-2所示的字段就会自动收集。对于比较重要的页面，还可以加入自定义的参数，如表2-4所示，比如电商产品的商品详情页，我们要收集用户从哪里进入商品详情页。用户有可能是从坑位进入商品详情页的，也有可能是通过搜索方式进入商品详情页的，还有可能是从分类页面进入商品详情页的，那么就要记录用户的访问来源信息，才能具体确定商品是从哪里卖出去的，这里就需要增加坑位ID、来源类型等关键字段。

接下来笔者讲一下用户点击事件的数据收集，其和用户浏览事件的数据收集一样，需要整理一下每条产品线都有哪些关键按钮，比如电商产品的关键按钮有注册、登录、收藏、加购、下单、支付等，根据这些关键按钮，我们就可以知道用户使用什么设备、在什么时候、点击了电商产品的哪个按钮。前端开发工程师需要针对这些关键按钮的点击进行埋点，点击事件的接口定义如表2-5所示。

埋点有两方面作用。一方面，针对前文提到的“弄清主路径”问题，需要监控“加购”事件。电商产品主路径中的“加购”是按钮点击事件而不是页面浏览事件，这就需要通过埋点方式先收集数据，以后将“加购”事件转化为页面浏览事件来处理，才能更加方便地计算每一步的转化率。另一方面，如果我们要看关键按钮的点击次数、关键页面的转化率（如登录页、注册页转化率等），就都需要统计按钮点击事件。

接下来再看一下如何进行后端埋点。

电商的主路径数据采集有个关键问题：用户在“加购”后可能隔几天才会下单，而同样的商品进入购物车后只是令购买数量发生变化，如果出现这种情况，当用户从购物车中进行商品下单时，我们很难通过前端埋点的方式判断这个商品到底是从什么位置上“加购”的，所以在这种情况下就必须进行后端埋点，当用户“加购”时可以将商品的来源信息记录至数据库，这样当用户从购物车中针对商品支付时，再将商品来源信息取出放入订单，那么后端埋点就解决了用户“加购”再下单这个问题。订单来源信息一般通过JSON的形式存储，具体格式如下。

首先需要记录用户是从哪个客户端“加购”的，即使用CLIENT（客户端）这个参数，接下来要记录“加购”的来源信息。用户可能是从坑位浏览商品并“加购”的，这时需要记录当时坑位的SPM值（SPM是每个坑位的唯一ID）；用户也可能是从某个活动页面进入的，公共信息中有每个事件的地址（也就是活动页面地址），这个地址可以当成来源信息记录下来；用户也可能是搜索过某个关键字，浏览商品后“加购”的，可以通过KEYWORD（关键字）这个字段记录用户的搜索关键字是什么；用户还有可能是通过推荐位“加购”的，可以记录推荐场景ID（RECSCENEID）和算法ID（ALGORITHMID），这为后续做推荐算法效果的分析做基础。

对于微信小程序端来说还有一个比较重要的场景。小程序产生的购买基本都是通过分享商品信息到微信群或者分享给微信好友实现的，那么在分享商品信息时可以记录当前分享的客户端（SHARECLIENT）、微信的场景值（WXAPPSCENE），微信已经定义了一套计算场景值的规则，其他的参数由分享的客户端以及来源信息来填充，这样我们就知道商品是从哪个客户端、哪个坑位分享出去并产生“加购”和下单的。

前后端埋点结合的优点很明显，采集的数据很全面。前端埋点已经有了一些通用的封装，前端开发工程师只需做少量的开发；后端埋点解决了数据流失的问题，保证了关键指标数据的准确性。但是这个方式的缺点也很明显——依赖前端开发工程师和后端开发工程师开发埋点模块，每新增一个页面就需要增加埋点开发的工作量。

首先，数据中台产品经理要和产品线产品经理沟通需求，在评审需求后，需要每个客户端的开发工程师进行开发、部署。然后，还需要测试工程师的测试。埋点的测试比较麻烦，测试工程师需要测试每个客户端并点击所有的页面和按钮，并在控制台查看参数是否设置正确。最后，如果测试没问题，还需要发布App新的版本，等上线后还需要进一步跟踪。

前后端埋点结合的数据采集方式的主要缺点是：工作量比较大，需要依赖多个角色配合才能完成，整个开发过程比较烦琐。

2.2.3 可视化埋点与后端埋点结合的数据采集方式

笔者先讲一下什么是可视化埋点。

上文已经说过，前端埋点会依赖前端开发工程师，而可视化埋点则可以解决这个问题。可视化埋点的主要特点是可以让产品/运营人员通过可视化的界面自行完成页面和按钮埋点配置。可视化埋点目前也有很多比较成熟的开源SDK，只要前端开发工程师将可视化埋点SDK部署完毕，产品/运营人员就可以通过可视化的操作完成普通页面及普通按钮的埋点工作，如图2-3所示。

可视化埋点只能针对普通的页面和按钮（如登录页面、注册页面、登录按钮、注册按钮、个人中心的页面）等使用，这些页面和按钮只用于采集公共的信息（如设备信息、地理位置、当前用户等），如图2-4所示，这样就可以知道哪个用户在什么时间点击了哪个按钮、浏览了哪个页面。一些重要的页面（比如电商产品的商品详情页）所关联的业务参数比较多，还是建议让前端开发工程师使用代码埋点的方式采集。

可视化埋点的优点比较明显，这种方式进一步降低了埋点的开发成本。数据中台在和其他产品线进行埋点合作时，只需提供可视化埋点的SDK给各条产品线，并且定义好哪些页面和按钮是必须进行埋点的，接下来让产品线自行完成埋点即可。在产品线埋点完成后，数据中台再做一次测试，检查哪些页面或者按钮没有埋点，测试通过后就基本能够采集用户对普通页面或者按钮的行为数据。由于产品的大部分页面和按钮都属于普通的页面和按钮，并不需要十分个性化的参数，故可视化埋点可以解决产品的大部分页面和按钮的埋点数据的收集。可视化的埋点不但统一了数据标准，还进一步降低了埋点的工作量。

可视化埋点的缺点在于，将埋点工作都交给各条产品线完成，就必须定义好合作的机制，讲清楚哪些页面和按钮在上线前是必须完成埋点的。另外，可视化埋点没有解决重要按钮、重要页面的埋点问题，也没有解决后端埋点的问题，这些工作还是依赖产品线前端和后端开发工程师一起完成。