神策数据易向文：打造券商上层数据应用的坚实基础

本文根据神策数据解决方案顾问易向文《打造券商上层数据应用的坚实基础》直播整理而成，本文的主要内容如下：

• 浅析券商数据采集

• 常见的埋点方式介绍

• 如何做好用户数据关联

• 数据管理与数据校验

注：图中数据均为虚拟数据。

一、浅析券商数据采集

1

数据驱动四部曲

从整体上来说，数据驱动的完整闭环可分为四步：采集数据、数据接入与存储、可视化查询分析、驱动决策和产品智能。

采集数据：业务中有多种数据来源，包含终端「web、App、H5 等」，后端服务器日志「Log」和业务数据「Database」。首先就要将全端的数据采集、汇总。

数据接入与储存：通过多种数据接入方案，确保提供适合业务需求的数据接入手段，便捷将各不同源数据入库，保证格式的统一性。

可视化查询与分析：结合分析模型，配置具体维度与指标，获取分析结果，保证实时性需求

驱动决策和产品智能：通过业务指标分析业务表现从而驱动决策；实现产品智能，画像洞察，精准营销，千人千面。

这个框架的重点在于数据采集，引用神策数据咨询师徐美玲的一句话：“不可用的数据不是资产，而是负资产。”我们甚至会非常头痛如何提升数据质量，让它变得可用起来。

2

数据采集流程与原则

下图是常见的数据采集流程：

在数据采集流程中，可以总结出 4 个关键原则：

大 ：做好长期的数据建设，要充分考虑用户规模与数据规模的增长，做好数据资产的积累

全：多端采集，针对全量用户行为而非抽样，贯穿用户使用产品的整个生命周期

细：尽可能采集足够全面的属性与维度，尽量保存数据细节，让积累的数据资产更加优质。例如，从 （5W） 这 5 个角度来采集用户行为数据

时：在技术条件与成本允许的情况下，尽可能地提高数据采集的时效性，从而提高后续数据应用的时效性

3

数据模型选择

数据采集还需要考虑一个问题，如何选择数据模型？

（1）Event Model VS Page View

首要考虑，是选择事件模型，还是页面浏览模型。Web 时代，流行使用 PV 分析页面的流量。但移动互联网及 O2O 时代，PV 已经无法满足分析需求。

比如，采集同一个页面浏览事件，一个用户在券商 App 上浏览了某一基金。页面浏览模型仅能简单记录“用户有一次浏览行为”。但用户到底浏览了哪个页面就受限于代码的规范程度。而事件模型可以灵活编辑需要采集的属性，如基金名称、基金代码、基金收益率、基金经理等。

（2）客户端 vs 后端

从客户端还是后端采集数据也是需要考量的问题，神策更加建议从后端采集数据，主要原因如下：

• 前端拿不到部分数据。比如说在做理财产品的申购时，一般情况下需要等后端确认后才能得到购买成功的结果。所以，从后端传输结构数据更加符合业务逻辑。

• 前端采集存在数据传输丢失的风险。而从后端采集数据，可有效避免。

理想情况下，在前端新增埋点，需要将 App 更新到最新的版本，才可以真正发挥埋点的作用；而后端，仅需改动代码。但因为特殊行业限制，考虑到风险问题，大多数金融公司都是在必须情况下才会改动后端代码。

（3）Event 5 要素

采集事件后，可用 5 要素定义：

WHERE：位置环境场景。神策的 SDK 可以解析用户 IP，分析出当前用户的位置。自有 APP 也可以获取用户定位，并上报到事件中。当然，这就需要去做一定的自定义开发；

WHO：用户身份，ID 识别；

WHEN：用户当前时间；

WHAT：做了什么事情，是什么；

HOW：维度特征。

（4）字段设计原则

• 从业务需求出发，通过指标需求，倒推需要哪些字段；

• 尽量复用已使用过的字段，不改变原字段含义，减少数据库的资源的损耗。

（5）字段记录在 E/U

字段到底是记录在用户表还是事件表里面呢？建议如下：

• 易变化数据，如用户级别、设备类型、地域、是否是 Vip 可以直接记录在事件表里面；

• 固定数据，如用户的性别、出生年份记录在用户表里。

二、常见的埋点方式介绍

1

各端 SDK 能力

开展埋点工作时，我们都会接触到厂商提供的 SDK。那 SDK 有什么作用呢？

• SDK 核心是通过埋点来采集数据；

• 在 SDK 配置 Schema 将采集的数据传输到指定的服务器端；

• SDK 支持我们去定义相关的策略，最大限度的保证数据的准确性和完整性，如：缓存策略、同步策略、网络策略等。

2

常见埋点方式

（1）全埋点（无埋点）

全埋点，也叫无埋点、无码埋点、无痕埋点、自动埋点。它可以直接把 SDK 集成到不同的应用端，而无需开发工程师写代码或者只写少量的代码，就能预先自动收集用户的所有行为数据。

全埋点支持的事件类型 ：

• 激活

• App 启动（$AppStart）

• App 退出（$AppEnd）

• App 页面浏览（$AppViewScreen）

• App 控件点击（$AppClick）

• 曝光

• Crash

上述 7 类事件，各有用途。激活事件普遍应用于渠道追踪，比如 H5 的落地投放，用户在 H5 落地页上自动上报设备属性；或者合作的渠道商回传了一些用户的设备、ID 等信息；神策的 SDK 也会自动采集当前用户的设备信息，然后与渠道投放时传输的相关属性匹配。这三种方式都可以获取到用户的渠道来源属性，以便后续市场营销进一步评估。

App 启动可以对用户属性进一步细化、下钻，比如说用户是主动启动 App，还是从后台或者第三方平台唤醒 App；App 退出会有一些内容做相关的限制；页面浏览和控件点击，就是用户对每一个页面的浏览和每一个控件的点击都会自动上报一条数据内容。

券商的科技部门比较关心平台的崩溃率，通过 Crash 事件的自动化采集，就可以知道各端的崩溃率情况，便于后续分析崩溃的原因以及针对性的去优化平台。

全埋点的优点在于：

• 周期短，埋点代价比较小；

• 无需更新 App，便于后续优化迭代；

• 自动化上传数据，解决了数据“回溯”的问题；

• 网页的点击热力图强烈依赖全埋点，需要它去支撑相关内容。

当然，全埋点也有应用缺陷：

• 覆盖的功能有限，仅有上述 7 类事件是能够通过全埋点自动采集；

• 无法自动采集业务相关的数据。数据厂商提供的 SDK 是按照满足市场的统一需求来的，并没有一个针对某一个行业的 SDK；

• 无法满足更精细化的分析需求。SDK 仅能采集一些相对比较统一的事件，无法满足行业继续下钻、细分的诉求；

• 各家的开发框架不一样，SDK 的兼容性可能会存在问题；

• 传输的数据量太大、浪费资源。因为用户的任意行为都会被采集上报，从经济上考量，数据量成本可能过大；

（2）代码埋点

代码埋点的前提是需要集成 SDK，在 App 启动的时候初始化 SDK，然后在某个事件发生时调用 SDK 的接口触发（track）事件。

• 显而易见，代码埋点的优点如下：

• 精准控制埋点；

• 方便、灵活自定义事件、自定义属性；

• 采集数据丰富；

• 可以满足更精细化的分析需求。

当然，代码埋点也有两个缺点：

• 埋点代价比较大，在排期紧张的时候，代码埋点不易推进；

• 埋点的更新和新增需要伴随着 App 发版。

（3）可视化全埋点

全埋点和代码埋点各有优劣，那可视化全埋点就是结合了两者的优点，在全埋点的基础之上，通过可视化的方式对 $AppClick 事件进行一些配置或者自定义操作。比如说，一旦应用端的集成好 SDK 和配置好数据接受地址后就可以直接扫描页面上的二维码，同步 App 端和网页端的动作。

图中是一个已经集成好 SDK 电商 App，可以看到 App 首页有不同的 icon 位和推荐位等相关内容。手机上任意可以点击的位置都会自动命中一个埋点的点位，我们可以自定义一个相关的事件名，比如说首页数码电器 icon 的点击。另外也可以根据条件进行筛选，比如需要的内容文本中，是数码电器需要埋点，还是首页第一个推荐位需要埋点？

页面上所有可点击的元素，只要有价值去做分析的都可以通过简单操作将埋点细分下钻，而不是像全埋点一样，所有的 icon 点击都定义为一个事件。因此，可视化全埋点不用再去区分每一个元素的内容，业务人员也可以自主定义埋点动作。

下一步，就需要设置页面浏览事件相关的埋点。如下图，在可视化页面的右上角直接点击【创建页面浏览事件】，我们可以直接灵活定义一个事件的名称，其次还可以标记出当前页面的唯一标志，即在代码中可以找到一个类似 screen name 的参数。

下方表格是对几种不同的埋点方式的总结：

3

如何选择埋点方案？

一般情况下，所有行业内并没有一个普适的、完美的埋点方案。因为各家的诉求不一样，其次还要考虑自己科技部门或者专门负责埋点的人员的排期以及平台的发展情况。

因此，建议的做法是针对不同的应用场景，选择最合适的数据采集方案。比如说，如果平台重视 UV、PV、点击量等基本指标，通过全埋点就可以直接采集；如果要做精细化分析，那代码埋点会更加清楚、更加精确地还原用户行为数据。

当然，我们更加推荐全埋点和代码埋点相结合的方案。举例而言，一般在项目一期上线时，主要采用全埋点；之后再结合业务的分析情况和最核心的应用场景采用代码埋点，比如说注册开户的流程、客户入金的流程、客户投资的流程等。

三、数据关联

数据采集上来后，它中间还有一个非常复杂的过程，即数据清洗。

比如，一个用户张三，他在自己的 App 上产生了投资理财的操作，但是操作未成功。然后一个客户经理用自己的手机辅助张三完成开户动作。这样的话就会存在一个问题，张三的用户行为数据分散在两个不同的端，因为他在自己手机和客户经理的手机上都操作过。这时，就需要把不同端的数据关联到统一的用户身上来。

场景一：用户在多家公司产生开户行为

某个券商公司，在用户开户时会分配给用户一个客户号以及一个相关的资金账号。同时，用户在开户前也会在券商 App 端注册留下手机号码和设备信息。采集该用户的数据后发现，该用户在不同的券商公司做过多次开户，而用户的客户号可以统一关联到一个类似一码通的证券账户上。

这时做用户数据关联就比较复杂，神策的建议如下：

第一点，券商比较关心的是投资行为的全流程的分析，所以建议使用唯一的客户号。客户号的好处在于可以从自然人的视角去判定客户在全生命周期里的行为路径。

第二点，同时上报用户的其它属性，保证数据的完整性，例如用户 ID、注册手机号、主资金账号、辅助资金账号等。

场景二：券商希望单独分析注册开户流程，引入互联网运营经验，对没有开户但平台认为有价值的用户进行运营，促进用户转化。

这时存在两种情况：

第一种，用户所有行为都是在自己的手机端完成，那可以直接以匿名 ID 将其开户前所有行为进行关联。后续用户开户成功后，就可将开户获得到的客户号作为用户的唯一 ID 与匿名 ID 关联；

第二种，用户在自己的手机端、在客户经理的手机端、在自己亲朋好友的手机端等都有相关操作。面对这种情况，神策的建议是直接用手机号作为用户的一个动作 ID 进行关联起来。后续再将客户号、资金账号等补充到用户表里。

下面简单介绍下如何保证埋点数据的完整性和准确性

首要说明，一个成熟的 SDK 必须能够支持同步策略的配置。SDK 并不是每采集到一条信息就立即与服务端通信，而是先缓存到本地经过压缩后才会进行数据上报。

因此神策建议几种不同的等待同步机制：

• 本地缓存一定条数量的事件会同步（默认 100 条）；

• 固定时间间隔同步（默认 15 秒）；

• 核心事件同步（trackInstallation、login 等）；

• App 退出尝试同步；

• 本地缓存太多事件时的处理。

此处强调下 App 与 H5 打通的必要性：

目前平台的一个普遍应用场景是 App 上有内嵌联储的页面，比如证券类 App 的基金产品和理财产品的介绍页。用户点进介绍后，会进入到 H5 的落地页。如果不打通 App 与 H5，就会存在以下问题：

• 不同的匿名 ID。一个用户在 App 端和 H5 上各有一个 ID，如果没有打通，那用户的行为数据就是割裂的。

• 数据的准确性。H5 的页面是无法直接获取到设备相关信息的，它只能够通过解析 UA 的值去获取一些相对来说比较有限的信息，而且 UA 值解析也存在问题，可能采集的内容不全甚至有些事件根本无法采集到。而打通后，APP 端和 H5 就可以互补共同完善数据的采集。

• H5 无缓存，数据易丢失。一般而言，H5 页面采集的流失率可能在 5% 左右，而将 App 与 H5 打通，流失率可以降到 2%，甚至 1%。

四、数据管理与数据校验

数据采集后，非常重要的一步是数据管理。因为随着产品的迭代、人员的流动、KPI 等的变化，我们关心的数据内容也会发生变化。那这时候再不断上报无用数据的埋点，也就没有必要了。

在此，我们推荐一个相对比较成熟的数据管理功能——数据入库强校验模式。在该模式下，一旦用户做了某个行为被采集上报后，系统会进行自动化检测，看这个数据符不符合我们的规范。如果不符合，就可以直接拒绝数据入库，进而最大程度上保证数据的纯净性和准确性。

数据入库后，我们希望能够回溯数据是否存在报错情况，并且明确报错原因，针对性处理解决。如下图，共有 3748 条数据报错。在明细中，我们可以直接查看错误原因。图中模拟的是时间戳的报错情况，可能因为数据错过时间，与服务端不匹配，而无法入库。下一步，就可以定位问题，比如说，是否平台端的数据上报能力存在异常。

数据校验也是数据采集过程中非常核心、非常必要的一个环节。很多时候并不是没有采集数据，而是采集的数据无法满足诉求，以及其准确性也欠考虑。神策分析的埋点管理有实时导入数据查询功能，可对用户的每一个动作进行判断，其是否入库准确数据。其次，还可以通过用户行为序列查看最终入库数据是否准确。

本文主要从埋点方式上分享了券商行业如何做好数据建设，打好上层数据应用的坚实基础，感谢大家的聆听。

✎✎✎

【更多内容】

• 神策数据张涛：企业服务客户全生命周期运营三步曲：执行&反馈
  

• 神策数据刘伟：产品用户体验数据化评估
  

• 我在神策做研发
  

点击“阅读原文”，体验产品 demo~