神策应用-数据基础（二）

导读：因涉及其他平台，并包含部分行业敏感信息，故该系列文章不设置全开放，敬请见谅！

 

2.数据基础

• 因为前面并没有说到神策的底层数据逻辑，该章节会涉及

2.1 什么是用户分析

回过头来，我们要重新学习一下数据底层

日常工作中，您可能会遇到如下问题：

• 新上线的产品功能，每天有用户在使用？新设计后的订单页面成交比率有没有提高？
• 运营刚上线的活动，用户参与情况怎么样？用户是在哪一步发生流失的？
• 渠道投放的广告，有多少用户点击了？这些用户后来有在落地页上发生注册吗？

 

在做行为分析需要经历的3个步骤：

1.提出业务问题

2.定义问题的分析对象，具体是哪几个行为

3.对行为进行统计和分析

 

2.2 如何描述用户行为

在神策分析中，我们使用“事件模型（Event 模型）”来描述用户的各种行为，事件模型包括事件（Event）和用户（User）两个核心实体。

2.2.1 Event 实体

一个完整的事件（Event），包含如下的几个关键因素：

Who：即参与这个事件的用户是谁。

When：即这个事件发生的实际时间。

Where：即事件发生的地点。

How：即用户从事这个事件的方式。

• 这个概念就比较广了，包括用户使用的设备、使用的浏览器、使用的 App 版本、操作系统版本、进入的渠道、跳转过来时的 referer 等，目前，神策分析预置了如下字段用来描述这类信息，使用者也可以根据自己的需要来增加相应的自定义字段。
• 也比如是使用支付宝还是微信支付等

What：以字段的方式记录用户所做的事件的具体内容。

• 买的是什么，电脑衣服背包？等
• 不同的事件需要记录的信息不同，下面给出一些典型的例子：

$app_
version：应用版本
$city： 城市
$manufacturer： 设备制造商，字符串类型，如"Apple"
$model： 设备型号，字符串类型，如"iphone6"
$os： 操作系统，字符串类型，如"iOS"
$os_version： 操作系统版本，字符串类型，如"8.1.1"
$screen_height： 屏幕高度，数字类型，如1920
$screen_width： 屏幕宽度，数字类型，如1080
$wifi： 是否 WIFI，BOOL类型，如true

 

2.2.2 User 实体

• 每个 User 实体对应一个真实的用户，每个用户有各种属性
• 常见的属性例如：年龄、性别
• 和业务相关的属性则可能有：会员等级、当前积分、好友数等等
• 这些描述用户的字段，就是用户属性

 

技术背景：

【关系存储的数据库和链式存储的数据库】

“神策”使用的是链式存储数据库，从大数据角度这种宽表的运算速率要远高于关系型数据库

• 在菜单栏上“分析”找到“自定义查询”，输入SQL语句可查询events表格和users表格

 

2.3 埋点方案的制定——事件设计

采集用户行为数据，首先需要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋什么样的点。这个环节的输出物一般被称之为“埋点需求文档（DRD）”。在大部分互联网公司，规范的产品迭代流程是，业务侧产品经理在输出“产品需求文档（PRD）”的同时，数据产品经理或分析师等角色需要同步输出 DRD，双方的需求同步进入开发和测试验收。

由于神策的底层数据模型是 Event + User 的事件模型，因此埋点在神策分析里被称之为“事件”，埋点需求文档则被统称为“采集方案设计”，本节的工作需要借助神策方提供的《数据采集方案》模板来完成。

 

2.3.1. 采集方案思路

采集方案设计的核心思路，大体来说分为如下几点：

1. 将用户指标拆解为单个或多个行为动作；

2. 将需要分析的目标动作抽象为“事件”，添加事件维度；

3. 根据业务需求，整体完善采集方案设计；

 

例子模板：

内容媒体-事件设计模版.xlsx

神策&内容媒体事件梳理-.xlsx

 

2.3.2. 不同事件设计

行为颗粒度

• 对于相似场景，比如，提交门票订单，提交机票订单，在设计事件时是针对每个场景单独设计还是合并成一个事件？有两种设计思路共参考：

A.设计为同一事件，适用场景：各事件所需属性相差不大；平时分析场景多整体分析。

B.设计为不同事件，适用场景：各事件所需属性相差很大；分析场景多分别分析。如果采用本思路，也建议在一些相同属性上用一样的属性名称，便于今后使用“虚拟事件功能”来整体分析。

• 例 : 简单 的统计三个按钮 A、B、C 的点击情况时，不需要做成 “点击 A 按钮”、“点击 B 按钮”、“点击 C按钮” 三个事件，而是做成 “点击按钮” 事件，将 A、B、C 三个按钮以属性 “按钮名称” 进行传递。

 

被动事件

被动事件：由于神策分析中的漏斗分析、留存分析等都需要事件的触发主体是同一个人，所以在一些场景下需要给用户触发被动事件，如用户提交认证后，需要审核，审核并不是由用户主动触发，可设置为被动事件。

 

User表注意

• 单边，双边用户
  • 单双边是针对产品有多个身份使用用户时才会进行区分。
  • 单边用户，即仅有一 类用户的产品，如健身产品Keep，聊天工具 QQ 等 ;
  • 双边用户如 O2O 产品，用户可能是普通消费者，也可能是商家用户。
  • 需要根据产品的不同，提前对用 户识别和相应属性进行设计。
• 缓慢变化维
  • 如果遇到一些会发生变化的属性，比如用户的 VIP 等级，不能只作为用户属性传进用户表中，还需在事件表中，记录一个“当前发生事件 VIP 等级” 这个属性。
  • 因为当前会员等级的统计，和发生事件时用户的会员等级统计是两种情况。