数据是数据中台的燃料。搭建数据中台的一项比较重要的工作就是采集企业内所有产品线的数据。这篇文章介绍一下数据中台需要采集哪些数据、如何采集数据，以及数据采集涉及的相关技术。

1.1 数据采集的分类

数据中台要采集的数据分为两种类型，一种是用户的行为数据，一种是业务数据。

我们先看一下什么是用户行为数据。用户无论在哪个客户端（iOS端、安卓端、小程序端、H5端）操作，用户产生的行为数据都分为两种：一种是浏览，一种是点击。这些隐性的行为数据，一般不会存储在业务线的数据库中，而是通过异步传输的方式传输并存储到数据采集服务器中。为什么要花那么多的资源采集这些行为数据呢？因为这些数据对后期数据的挖掘应用是十分有用的。举个例子，对于电商产品，如果没有行为数据的采集，我们是无法判断用户对某个商品的感兴趣程度，但是如果有了这些数据，我们就可以定义用户对商品的感兴趣程度，比如用户对某商品的1次点击，代表用户对该商品的兴趣度增加10分，而用户的3次点击代表他对这件商品非常有兴趣。


(相关资料图)

接下来介绍一下什么是业务数据。业务数据一般存储在业务数据库或者业务中台中，业务数据库一般存放产品线的个性化的业务数据，业务中台一般存放通用的业务逻辑数据。比如对于电商产品来说，对坑位的管理、对活动页的管理属于个性化业务，其他产品线通常不会用到，这种业务的数据会存放在业务数据库中，而用户模块的登录数据、交易模块的订单数据等则会存放在业务中台中。

1.2 用户行为数据采集

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

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

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

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

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

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

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

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

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

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

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

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

图2-1 百度移动统计

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

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

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

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

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

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

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

图2-2 电商产品主路径示意图

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

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

坑位转化率=坑位UV/支付人数。

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

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

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

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

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

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

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

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

表2-1 数据采集SDK对比

维度

维度细项

Sensors Analytics

GrowingIO

诸葛io

TalkingData

Mixpanel

Google Analytics

商业性质

开源

Y

N

N

N

N

N

免费

Y

N

N

N

Y

Y

商业/付费版本

Y

Y

Y

Y

Y

Y

支持平台

Android App

Y

Y

Y

Y

Y

Y

iOS App

Y

Y

Y

Y

Y

Y

Web/H5

Y

Y

Y

Y

N

Y

微信小程序

Y

Y

Y

Y

N

N

unity

Y

N

N

Y

N

Y

前端数据采集方式

代码埋点

Y

Y

Y

N

N

Y

可视化埋点

Y

Y

Y

Y

Y(Only App)

N

无埋点

Y

Y

Y

Y

Y(Only App)

N

部署方式

私有化

Y

N

Y

N

N

N

SAAS

Y

Y

Y

Y

Y

Y

采集范围

前端采集

Y

Y

Y

Y

Y

Y

后端采集

Y

N

Y

N

N

N

服务器日志

Y

N

N

N

N

N

数据库

Y

N

N

N

N

N

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

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

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

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

表2-2 埋点接口公共字段的定义

字段归类

字段中文名称

字段英文名

字段类型

说明

设备及浏览器信息

操作系统名称

$os

String

终端操作系统

操作系统版本

$os_version

String

终端操作系统的具体版本号

屏幕高度

$screen_height

Number

屏幕的物理高度

屏幕宽度

$screen_width

Number

屏幕的物理宽度

浏览器名称

$browser

String

访问该系统当前浏览器的名字

浏览器版本

$browser_version

String

当前浏览器版本

用户代理

user_agent

String

当前SDK信息

SDK名称

$lib

String

当前埋点采用的SDK的类型，如iOS端、安卓端

SDK版本

$lib_version

String

当前SDK的版本号

网络信息

IP地址

Ip

String

当前用户的公网IP

国家

Country

String

当前用户所在国家

省份

Province

String

所在省份/州

城市

City

String

所城市

经纬度

纬度

latitude

String

当前用户所在纬度

经度

longitude

String

当前用户所在经度

时间信息

服务器时间

server_time

Float

事件发送到服务端处理后的时间

客户端时间

clientTime

Float

事件发生时客户端时间

来源渠道

流量来源ID

trafficSourceID

String

识别用户是从哪里来的编码，也就是访问渠道ID

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

表2-3 浏览页面事件的接口定义

事件名

字段中文名

字段英文名

字段类型

说明

举例

页面浏览事件

唯一标识

$distinct_id

String

用户的唯一标识，如果有登录账号，则填入登录账号；否则填入相应的设备ID

13900000000

会员ID（登录名或者手机号）

$user_id

String

用户注册的会员ID，如果未登录则为空

手机号码

$phone

String

用户登录的手机号码

页面名称

page_name

String

用户当前进入的是哪一类页面

比如HomePage

页面浏览时长

view_dur

Float

用户从进入页面到离开页面的时长（毫秒）

当前页面URL

$url_path

String

当前页面的URL

前向URL

$referrer

String

跳转至当前页面的前向页面URL

事件名称

event

String

只有两种时间类型：浏览及点击

浏览：$pageview

点击：$pageclick

事件类型

Event_type

String

仅针对点击事件（$pageclick）的情况才传入。

需要传入按钮的名称，例如收藏按钮传入collect，加入购物车按钮传入addshop

$是否首次访问

$is_first_time

Bool

是否首次访问

$是否首日访问

$is_first_day

Bool

是否首日访问

平台信息

平台名称

Platform

String

产品线信息

1004=产品线A

1005=产品线B

客户端名称

Client

String

用户登录的客户端，需要传回客户端的名称，如公众号、小程序、PC等

微信公众号：wxh5

微信小程序：wxapp

浏览器：mobile

安卓App：android

iOS App：ios

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

表2-4 商品详情页特殊字段信息定义

页面名称

字段英文名称

字段中文名

字段类型

字段描述

商品详情页

spm

坑位ID

String

如果是从坑位过来的，需要返回坑位的ID，否则为空

sourceStyle

来源类型

String

1=活动

2=搜索

3=分类

4=推荐

activityID

来源活动ID

String

如sourceStyle=1，这里返回相应的来源活动页面ID, 否则为空

keyWord

搜索条件

String

如sourceStyle=2，这里返回相应的搜索条件，否则为空

recSceneId

推荐场景ID

String

如sourceStyle=4，需要填入相应的推荐场景ID，否则为空

algorithmid

推荐算法ID

String

如sourceStyle=4，需要填入相应的推荐算法ID，否则为空

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

表2-5点击事件的接口定义

模块

字段英文名

字段中文名

字段类型

按钮点击

clickButton

buttonID

按钮ID

String

buttonName

按钮名称

String

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

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

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

{

"client":"wxh5",//wxh5（微信H5端）、wxapp（小程序端）、mobile（浏览器端）、android（安卓端）、ios（iOS端）

"spm":"201900000036", // spmId、search、catalog

"sourceStyle":1, //1=专场、2=活动、3=搜索条件、4=推荐

“wxappScene”：//微信场景值ID

“shareClient：”//取CLIENT

"activityId":"1333",//活动ID

"recSceneId":"10005", // 推荐场景ID

"algorithmId":"11212" // 算法ID

"keyWord":"毛衣" // “毛衣”搜索关键字}

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

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

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

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

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

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

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

图2-3 可视化埋点界面

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

图2-4 可视化埋点采集的信息

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

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

··············end··············

推荐内容