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

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

《数据驱动经验分享从方法到实践.docx》由会员分享，可在线阅读，更多相关《数据驱动经验分享从方法到实践.docx（17页珍藏版）》请在冰豆网上搜索。

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

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下载|神策数据曹犟：

数据驱动从方法到实践

图6构建多设备用户管理体系

大家可以看下如图的例子。

我们做了一些工作，后台架构有很大改进，可以实现将第二个设备，跟同一个用户绑定，只要用户登录，神策就可以把不同情况下登录的数据完全打通，这是非常典型的ID-Mapping的场景。

同样非常典型的场景是用户行为多端关联机制。

用户产品本身可以多端使用，可以在网页上使用，例如说发了营销H5，用户在微信内置浏览器H5完成注册，跳到Appstore完成激活。

如果不能将营销H5的用户行为，与登录激活之前的行为贯通，那么也没有办法详细分析H5的营销效果。

再如，小程序突然火起来了，客户有需求，为此我们专门做了小程序采集，包括预置采集的事件，以及小程序相关的属性，同时一样带动了代码与自动化采集两种方式，小程序可以充分得到微信里面的社交信息，对小程序分享传播的属性采集是非常重要的。

PPT下载|神策数据曹犟：

数据驱动从方法到实践

图7小程序的采集

小程序最复杂的事情，它有不同的匿名ID或者设备ID。

一个人在设备上，又使用小程序，又使用一个APP，又换了一个小程序，但是两个小程序之间登录帐号打通，最终我们实现可以把两个LoginID与OpenID设备贯通起来。

5.服务器日志采集

PPT下载|神策数据曹犟：

数据驱动从方法到实践

图8服务器日志采集

我现在画了很简单服务器日志采集架构图，看似技术上没什么问题。

从实际经验上来说：

想高质量搭建日志采集非常难，设置日志用哪些内容，一次性工作很难。

更难的还体现在产品迭代上，比如产品两周发一个版本，程序员会说产品功能都测不完，没法搞日志。

要搭建一个高质量的日志采集，要贯穿在整个开发流程，从最早期一直到运维上线，到复盘整个迭代项的时候，每一步都要有意识。

这也是为什么很多SaaS产品都没有采集日志的能力。

PPT下载|神策数据曹犟：

数据驱动从方法到实践

图9用户行为数据应用案例

这是我们在中国银联典型的案例，包括设备指纹采集、加密传输等，当然这个图画出来体现对用户行为数据不同的应用，除了做日常行为之外，还有一些其他的应用。

最后是业务数据的采集，包括CRM系统等。

四、数据建模

数据建模最重要的是数据模型的选择，以及对应的储存。

数据模型选择为什么重要？

因为数据模型抽象好了，后面的分析模型可以做的更好。

如果数据模型抽象的太复杂，整体过程非常复杂。

我们现在的数据模型是Item实体、Event事件、User用户，我们不会把模型搞得太复杂，现在模型下面，数据采集到建模所要做的工作是比较少的，基本可以通用化、产品化。

我们已经有了标准的数据模型，同时通过不同的采集方案采到了很多数据，所要做的工作主要是把采集到的数据映射，这里面非常多的工作不再具体展开。

不同的数据模型选不同的储存方案，储存方案的选择主要根据数据本身的特点，例如是否可追加、可修改、访问是以什么样的访问为主，是否会需要删除等。

五、数据分析

有了标准模型，有非常合适的储存结构，后面是对数据怎么分析。

1.数据统计与分析的两种方法论

数据统计与分析有两种方法论，通常情况下是图片左边方法论，PM给RD提，老板要看这些报表，给RD提要求，RD写一些东西并发邮件出来，改程序后又有新的需求。

老板可能问你PV为什么是这么多？

你可能要把整个计算过程完整讲一遍……在这种情况下，RD为了不想太频繁操作和改变，总是会给PM设置各种限制。

PPT下载|神策数据曹犟：

数据驱动从方法到实践

图10数据统计与分析的两种方法论

右边的方法论，抽象的模型覆盖指标体系以及大部分分析需求，通过友好的交互让需要数据的人自主获取数据。

这种方法论是神策产品提供的，我们不需要问你看什么指标，因为你看的指标可能在整个行业都有通用性，我们会把需求抽象下来，接下来就是模型抽象。

如此，你的工作就变成你自己用分析模型，通过拖拖拽拽，把你要的条件选出来，就能完成一次分析。

这两种方法论区别是，是否让需要数据的人直接使用数据，造成的工作效率相差非常大，这就是为什么现在神策产品能够卖出去，并不是我们造了一个这样的需求，而是真正有这样的需求。

接下来这个图是神策实现的自助式分析：

PPT下载|神策数据曹犟：

数据驱动从方法到实践

图11自助式数据分析

2.针对不同角色的数据分析：

决策者、营销、产品、运营

通过不同角色分析四个不同的场景。

（1）决策者

老板关心的是第一关键指标是什么。

第一关键指标该如何选择？

不同阶段关键指标不相同，每个发展阶段都有最关注的数据，集中注意力，提升第一指标。

有了第一关键指标，如何构建指标体系？

有了第一关键指标，我们要绘制整个用户旅程。

以电商产品为例，我们关心总营收额，如何得到？

先