数据驱动经验分享：从方法到实践

目录

1.数据驱动价值：驱动决策、驱动产品智能

2.数据驱动闭环：数据采集—数据建模—数据分析—数据反馈

3.数据驱动各环节方法与实践

一、数据驱动价值：驱动决策、驱动产品智能

数据驱动能做什么？

我们认为主要包含驱动决策、驱动产品智能两方面的价值。

图 1 数据驱动价值

驱动决策包括运营监控、产品迭代、营销分析、商业决策。

其中涉及的每一个场景在今年数据驱动大会都会有专门的讲师来介绍。

驱动产品智能，现在基本上已成为所有的电商类、资讯类产品的标配，如“产品推荐”、“猜你喜欢”等。企业要么组建团队实现智能化的应用场景，要么应用外部工具来解决问题，因为在流量红利逐渐消失的今天，千篇一律的内容会让你的“留存”数字非常难看。

我们曾为某一家很知名资讯类企业做 Feed 流的改版，神策来提供具体的推荐策略。通常，个性化推荐的评价指标是 CTR——展现了一千种内容，有多少人点击？

在 2018 年，我们认为再评价一个算法的好坏，用 CTR 非常不合适。神策从关注指标CTR 转为衡量“命中了策略的人”跟“命中热门随机内容”的两大用户群体，观察他们在平均访问深度、7 日留存、停留时长等更深层指标上的差异。

二、数据驱动闭环

数据采集——数据建模——数据分析——数据反馈，这是一个完整的数据驱动闭环。我们在很多场合提到此，这里不再赘述。

PPT 下载 | 神策数据曹犟：数据驱动从方法到实践

图 2 数据驱动闭环

有很多企业来找我做关于数据采集方面的分享，我用这张图描述了典型的数据分析平台，一个为数据驱动而构建的数据分析平台，各位可以参考。

PPT 下载 | 神策数据曹犟：数据驱动从方法到实践

图 3 一图全面展示数据分析平台架构

三、数据采集：一切数据应用的根基

1. 采集内容：数据类型、数据所有者、数据来源

数据采集是一切应用的根基，“大、全、细、时”由桑文锋提出（详情可戳此查看桑文锋谈大数据分析的四个重要环节），是神策一贯坚持数据采集理念，具体到采集内容上，包括数据类型、数据所有者、数据来源。

数据类型包括用户行为数据、用户数据、业务运行数据、内容数据：

用户行为数据，可以描述用户在什么时候、什么地点、以什么方式、用什么样的手机、通过哪种浏览器做了一件什么事情；

用户数据，描述用户本身的属性，比如某顺风车给乘客打上各种各样的标签，这些标签肯定会用于后续产品迭代；

业务运行数据，在线下业务比较重的场景同样很多；

内容数据，包含用户浏览的具体内容，也包括与用户发生交互的对象。

从数据所有者上来讲，我们采集第一方数据——也就是“我们自己的产品，我们自己的用户，自己用户在自己产品上发生了什么。”这是第一方数据。

第一方数据采集在完全可控环节下发生，不仅比较便捷。

在隐私策略方面，我们完全符合最严格的 GDPR 标准。

目前我们采集第一方数据为主；而第三方数据，市面上一些免费的 SaaS 工具可以做采集和统计，并做一些处理、脱敏；用这些数据作为第三方数据，提供给客户。这是有悖我们价值观的，我们绝不涉及。

从数据来源上来讲：新零售的火热，线下数据采集还是非常火的，不管是摄像头、蓝牙探针等，是线下场景很好的补充。

不过从目前实践经验来看：摄像头、ID 识别的准确度非常低，基本不太可用。

对这一部分，我们保持持续关注，一些客户会将通过二维码、店员主动拿 Pad 做展现等方式，将用户从线下行为引到线上，从而保证用户数据的可采集、可衡量。

2. 根据需求采取合适的采集方案

我们一贯的观点，是数据采集没有万能灵药，要根据需求选择合适的采集方案，这一点我在不同场合讲很多次，这里不再展开。

PPT 下载 | 神策数据曹犟：数据驱动从方法到实践

图 4 根据需求采取合适的采集方案

3. 数据采集的接入

这是宏观上对于不同内容，不同来源数据的采集统一架构。

PPT 下载 | 神策数据曹犟：数据驱动从方法到实践

图 5 一个典型的用户行为相关数据采集

这是一种典型的用户行为采集方案。客户端采集轻交互的内容；服务器日志采集 Nginx、UI、Server 浏览、检索、理财产品等内容。

而对于一些业务操作，例如客户跟客服之间的交互，或者内部的客户运营，主要是在业务采集上搞定的。

4. 客户端采集

我来介绍下目前被提及最多的客户端采集。客户端是直接跟用户发生交互关系的一端，可以是 APP、小程序、网页、H5、公众号等，客户端采集数据操作，包括点击按钮、浏览页面、下拉框选择、提交表单、上传照片、切换导航条等。

这些操作是轻交互的，它的采集在通常意义上被称为埋点，我个人觉得埋点更多指客户端采集。

（1）客户端采集的基本原理

客户端采集的基本原理有三点：

第一：提供 SDK 与使用者的应用“编译”到一起

客户端采集有各种各样的模式，但本质上都是提供 SDK 和使用者的应用编译在一起。

抛开埋点方式，完成这样的事情，很多容易被忽视的，基础属性要覆盖我们能想到的所有内容，包括简单的用户行为相关、操作系统版本、物理分辨率等，还有很多客户通过 SDK 提供部分风控数据的采集。

比如说 iphone 手机有没有越狱，浏览的时候是横屏还是竖屏，以及电量等等。（之所以要用 SDK 采集当前的电量，是因为如果用户用模拟器访问，那么它的电量变化跟真正的手机有非常大的不同。）

所以基础属性虽然看起来比较简单，但是很多时候可以发挥很大的作用。

第二：SDK 完成匿名 ID 生成、基础属性采集、数据打包压缩加密、本地缓存、网络传输等工作

数据打包和加密，不仅可以在本地打包，还可以在必要的时候删掉，神策现在服务很多银行证券客户，对加密要求的非常高，比如给某一个字段要用什么加密等，这些都是 SDK 要完成的。

本地缓存在 IOS 与安卓中特别重要，因为为避免影响用户体验，当发生一次点击，对应的数据不会立刻传到后端，所以都是缓存到本地等待最佳网络时机。本地缓存、网络缓存这些都是SDK 来做的。

第三：一般使用 HTTP(S) 协议通过公网传输数据

有人问，所谓的代码埋点、全埋点、可视化埋点有什么不一样？我们可以这样理解：SDK 完成基础数据的采集、数据储存打包、传输等，同时向上埋点应用层提供 API，所谓的代码埋点就是直接利用 API，告诉采集了什么数据。

全埋点则是在用户完成某个操作的时候，自动的调用 SDK。所以说 SDK 完成一些基础工作，代码埋点开发者直接调用 API；而全埋点开发者不用直接调用，可以比较自动的完成。

说到这里会打一个广告，我们会马上出版一本书，专门讲安卓 8 种全埋点，到时候有兴趣的话可以看看。（白皮书 |《Android 全埋点技术白皮书》重磅推出！开源所有项目源码！）

（2）ID-Mapping 构建多设备用户管理体系

多设备下的用户关联是今年新的进展，新的趋势。

ID-Mapping 解决的是不同用户多设备的使用情况。

PPT 下载 | 神策数据曹犟：数据驱动从方法到实践