神策数据

神策大数据用户行为分析入门，主要涉及的知识点：

• 神策分析简介

• 神策产品优势

• 神策解决痛点

• 神策分析作用

• 神策分析如何解决

• 神策数据来源

• 用户行为分析

• 如何描述用户行为

• 如何正确地标识用户

• 神策标识用户原理

image

神策分析简介

神策分析是针对企业级客户推出的深度用户行为分析产品，有以下特点：

• 支持私有化部署

• 客户端、服务器、业务数据、第三方数据的全端采集和建模

• 驱动营销渠道效果评估

• 用户精细化运营改进

• 产品功能及用户体验优化

• 老板看板辅助管理决策

• 产品个性化推荐改造

• 用户标签体系构建等

image

神策产品优势

1. 私有化部署

2. 基础数据采集与建模

3. 实时多维度分析

4. PaaS 平台深度开发

image

神策分析解决痛点

业务痛点

• 营销分析断层：渠道追踪功能，用渠道直观评估渠道拉新能力，分析注册转化和付费转化

• 产品迭代无法量化

  • 神策提供漏斗分析，帮助企业提升用户在产品上的转化

  • 神策提供留存分析，帮助企业提高用户留存，用数据验证用户最喜欢的产品功能

• 用户运营不精准

  • 锁定具有相似特征的用户群体，“投其所好“的推送营销内容

  • 对长期未登录即将流失的用户群体，及时推送消息和优惠券召回挽救

  • 神策建立用户标签体系和用户画像，将用户行为结合运营数据交叉分析，洞察核心用户特点，勾勒精准用户画像

• 全局运营指标监控不实时：

  • 管理人员邮箱可定时定期接收已订阅的报表自动推送

  • 同时提供自定义的指标预警能力

技术痛点

1. 自建成本高

2. 日常配合效率低

3. ETL工作繁琐

4. 共性需求重复开发

神策分析作用

支持产品进行功能评估，提升转化率

产品角色作为产品规划者，重点关注产品

• 流程设置和功能设计是否给予用户良好的使用体验，

• 如何确保用户充分体验产品的核心价值。

数据驱动产品优化

image

支持运营进行用户分群，实现精准营销

运营角色重点关注

• 用户构成现状及变化

• 从用户行为角度剖析用户的活跃程度、流失情况

image

支持渠道把控拉新的“量”与“质”

渠道角色重点关注

• 渠道拉新的数量及质量

• 比较不同渠道投放的 ROI

image

为数据采集技术人员提供解决方案

技术角色重点关注

• 如何快准细全地完成数据的采集及接入

• 如何充分理解业务人员的分析需求

• 如何协同完成产品的指标增长任务

神策分析如何解决

标准电商核心流程

电商用户通常会经历以下核心行为流程：

1. 启动 App

2. 开始浏览首页

3. 点击并浏览商品详情页

4. 看到合适的商品，将商品加入购物车

5. 有购买意向，提交订单

6. 决定付款，支付订单

产品核心流程可描述为

启动 App - 浏览首页 - 浏览商品详情页 - 加入购物车 - 提交订单 - 支付订单

电商行业常见数据分析问题

不同人员关注点

1. 渠道投放业务人员：各个渠道获客的数量和质量

2. 运营人员：进行用户分群并且采取针对性的营销

3. 产品人员：各个核心流程转化及各个功能的用户体验

常见电商需求问题

• 各个推广渠道获取新客的数量如何？哪个能力最强？

• 从激活APP到支付订单的过程中表现的差异

• 支付过程中流失的用户的原因

• 面对支付流失用户采取什么措施等

新客数量及比例

查看新客总数，同时按照日期、渠道等维度拆分下钻

用户核心过程转化率

查看各渠道新客的核心流程总转化率及各步骤间的转化率，寻找总转化率提升空间

用户支付行为表现

• 查看各渠道来源用户从 App 激活到支付订单的转化时间

• 查看各渠道来源用户从支付订单金额人均值分布以及支付订单金额总值分布，判断渠道对用户消费能力的影响

支付环节流失的原因

神策支持查看特定用户群的历史行为序列，找到提交订单行为，对此之后的行为进行人工标注，以推测后续未进行支付环节的原因

分析各渠道来源活跃用户情况

解各渠道来源用户的活跃程度，以及目标行为——支付订单行为发生的频率

获得流失用户名单

针对特定人群实现精准营销，支持将特定用户设备 List 同步到极光/小米，向流失用户进行 App 内的精准推送，以期重新激活挽回流失。

全面监控渠道获客的数量及质量

神策支持将分析结果添加到概览，使业务分析人员无需配置快速获得所关注的指标现状

神策数据来源

神策分析中的所有数据均来自于客户的自有数据接入。

神策分析主要支持采集客户的自有数据有三类，分别是前端操作、后端日志及业务数据(包括历史数据)，接入的方式主要是有3种：

• 前后端SDK接入

• 外部数据导入工具

• API导入

用户行为分析

常用名词

image

实际问题

日常工作中，我们遇到的实际问题：

• 新上线的产品功能，每天有用户在使用？新设计后的订单页面成交比率有没有提高？

• 运营刚上线的活动，用户参与情况怎么样？用户是在哪一步发生流失的？

• 渠道投放的广告，有多少用户点击了？这些用户后来有在落地页上发生注册吗？

为了回答以上问题，需要对产品上的各种行为进行分析和统计。

问题解决

对上述的行为进行统计，得到的如下指标：

用户行为分析3大步骤

1. 提出业务问题

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

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

如何描述用户行为

神策分析使用事件模型来描述（Event 模型）用户行为，描述用户行为的关键要素：是谁、什么时间、什么地点、以什么方式、干了什么

主要是涉及到两个核心事件：

• Event

• User

image

Event实体

一个完成的事件包含几个关键要素：

• who：参与事件的用户

• when：发生的时间

• where：在哪里发生，地点

• how：从事这个事件的方式

• what：所做事件的具体内容

User实体

每个 User 实体对应一个真实的用户

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

如何正确地标识用户

常用用户标识2种方案

神策解决方案

简单来说，在用户未登录的情况下，神策会选取设备 ID 作为唯一标识

登录状态下选取登录 ID 或者 userid，一个用户既有设备ID（亦称作“匿名ID”）又有登录ID

通过用户关联将同一个用户的设备ID 和登录 ID 关联到一起，这样不管用户是匿名和登录的状态发生的行为，我们都能准确识别到是同一个用户。

用户关联方案

• 一对一关联：设备ID和登陆ID一对一（神策默认）

• 多对一关联：多设备ID和一个登陆ID之间的多对一（用户使用登陆ID在不同的设备之间登陆）

神策标识用户原理（重点内容）

基础知识

神策分析使用 神策 ID (即 events 表里的 user_id 和 users 表里的 id )来对每个产品的用户进行唯一的标识。

image

神策ID是基于 distinct_id 按照一定规则生成的，两种典型的distinct_id：

• 设备ID：设备ID并不一定是设备的唯一标识

• 登陆ID：通常是业务数据库里的主键或其它唯一标识

  • 用户在使用时不一定注册或者登录，此时没有登录 ID

  • 登陆ID会存在users表里的second_id字段

  • 一旦确定尽量不要修改

神策分析里的用户是发生事件的主体，不一定是终端用户，也可以是一个企业、商家等

users表中的fisrts_id指的是设备ID，second_id指的是登陆ID

3种方案

只使用设备ID

1.特点

只要设备不变，那么设备ID不变，神策ID不变

• 用户更换设备，前后的行为无法关联上

• 不同的用户在用一个设备上使用，归属于同一个用户的行为，不合理

2.案例说明

image

案例解释说明

• 某用户进行了一系列的操作，在小米手机上安装了APP，SDK生成的设备ID：X，发送的distinct_id：X，对应分配的神策ID：1，users表中对应写入神策ID：1，设备ID：X

• 该用户进行了注册和登陆，登陆ID为A，设备ID：X和登陆ID：A关联成功，将登陆ID：A也写入到users表的second_id中

• 该用户的其他操作，不改变id、first_id、second_id（前面的4条记录）

• 该用户把手机给了朋友（已经注册但没有接入神策系统），朋友用自己的账号登陆设备X，发送的distinct_id仍然是X，神策ID仍为1

• 该用户换了一个新的苹果手机，进行了一系列操作，神策使用全新的设备ID：Y来标识此设备，发送对应的distinct_id为Y，对应的神策ID为2，将其对应写入到users表中（记录7）

• 后续只要设备不改变设备，神策ID 都以2来标识（记录8，9）

关联设备ID和登陆ID(1对1，默认方式)

关联设备 ID 和登录 ID 的方法虽然实现了更准确的用户追踪，但是也会增加埋点接入的复杂度。

1.适用场景

1. 需要贯通一个用户在一个设备上注册前后的行为

2. 需要贯通一个注册用户在不同设备上登录之后的行为

2. 局限性*

• 一个设备 ID 只能和一个登录 ID 关联，而事实上一台设备可能有多个用户使用。

• 一个登录 ID 只能和一个设备 ID 关联，而事实上一个用户可能用一个登录 ID 在多台设备上登录。

3.案例说明

image

案例具体解释

• 某用户进行了一系列的操作，在小米手机上安装了APP，SDK生成的设备ID：X，发送的distinct_id：X，对应分配的神策ID：1，users表中对应写入神策ID：1，设备ID：X

• 该用户进行了注册和登陆，登陆ID为A，设备ID：X和登陆ID：A关联成功，将登陆ID：A也写入到users表的second_id中

• 该用户的其他操作，不改变id、first_id、second_id（前面的4条记录）

• 该用户把手机给了朋友（已经注册但没有接入神策系统），朋友用自己的账号登陆设备X，登陆ID为B。由于设备ID：X 和A已经关联，此次关联失败，分配给新的神策ID 2 来标识此用户，并将登陆ID：B 同时存入到users表的first_id和second_id中（第5、6条记录）

• 该用户换了一个新的苹果手机，进行了一系列操作，由于尚未登陆，神策使用全新的设备ID：Y来标识此设备，发送对应的distinct_id为Y，对应的神策ID为3，将其对应写入到users表中（记录7）

• 该用户使用账号A进行登陆，神策将尝试将设备ID：Y 与登录ID：A 进行关联，A和X已经关联，导致关联失败，切换到以A为登陆ID的用户，对应的神策ID为1。后续的操作将发送distinct_id为A，神策ID 为1（记录8，9）

关联设备ID和登录ID(多对1)

1.使用场景

一个登陆ID绑定多个设备，比如 Web 端和 App 端可能都需要进行登录。

支持一个登录 ID 下关联多设备 ID 之后，用户在多设备下的行为就会贯通，被认为是一个神策 ID 发生的。

2.局限性

• 一个设备 ID 只能和一个登录 ID 关联，而事实上一台设备可能有多个用户使用。

• 一个设备 ID 一旦跟某个登录 ID 关联或者一个登录 ID 和一个设备 ID 关联，就不能自动解除。设备 ID 和登录 ID 的动态关联更合理。

3.案例说明

image

操作同上面的流程，重点关注第七条记录

由于设备 Y 被关联到登录 ID A 下，修复设备 Y 上登录之前的数据：神策 ID 3 ->神策 ID 1