帮助中心 > 接入指引 > 高级分析

高级分析

通用分析满足了我们基本的分析需求,若您想要做基于业务数据的相关分析,您需要增加业务埋点,我们平台提供了九大分析工具帮助您洞察数据趋势。业务分析的完整流程如下:

1 业务需求梳理

需求梳理需要挖掘您的核心痛点,明确主要想解决的问题是什么,再对该目标进行拆解到具体的分析任务和指标。为了构建一个行之有效的指标体系,建议可以参考以下步骤:
定义核心指标→拆解用户旅程→指标拆解

1.1 定义核心指标

即寻找公司现阶段最重要的指标。该指标有如下标准:

  1. 需要贴合目前公司/产品发展的现状,比如是处于初创期获客阶段(关注新增)、成熟期营收阶段(关注营收转化)、饱和期阶段(关注留存)等等。
  2. 能反映用户是否体验到产品的核心价值。比如对于电商类的应用,其核心业务是购买转化,所以其核心指标应该和用户购买行为有关,如GMV、客单价等。
  3. 常见的商务模式和核心指标如下

使用权限: 不同的项目角色操作权限如下

商业模式 核心关注 核心指标
电商 线上购物的体验和转化 GMV
社区 参与度和活跃度 总提问回答数
游戏 活跃深度 人均游戏时长
线上教育 在线获取知识的全面性和便捷度 DAU、WAU
双边市场 如物流平台,满足货主端和司机端不同需求 总订单量

1.2 拆解用户旅程

定义好核心的指标后,需要思考用户在应用中是如何一步步达到期望目的的。
例如电商行业,其核心指标为GMV,对应的用户行为为“支付订单”,那么用户可能经过如下步骤:访问—注册—点击运营位—浏览商品详情页—点击购买—提交订单—支付订单

1.3 指标拆解

产品、运营、市场等团队在该旅程基础上不断进行策略的制定、执行、迭代,促进团队完成各自的KPI,以及核心指标的提升。这其中不同团队将涉及不同的业务场景。我们可以精细化地梳理出这些场景,然后在该基础上搭建相应的指标体系。
仍然以电商产品为例,假设其核心指标为GMV。按照团队可列举出如下常见业务场景,拆解指标:

职能 业务场景 场景核心指标 重要分析维度
产品 商品购买流程、体验流畅性 商品购买人数、访问时长、页面退出top10 新老用户、注册来源、运营位来源、商品SKU、是否使用优惠券···
市场 推广拉新 新增用户数 推广渠道、推广活动、地区、推广内容···
运营 活动运营、内容运营 活动转化率、内容阅读量、用户留存 新老用户、推送渠道、推送活动、操作系统、首次渠道来源···

一个完善的指标体系对于后续的埋点方案设计至关重要,它能确保设计的逻辑性和全面性,使得我们能够利用追踪的事件和属性来配置出不同团队在不同业务场景中所关注的指标,从而产生有价值的业务洞察。

2 埋点设计与上传

基于上一节梳理出的核心需求,如果想要深入分析业务,形成数据驱动,则需要在预置事件的基础上,补充更多的自定义代码埋点。自定义埋点的灵活性、自主性、应用性更高。设计埋点人员应根据业务核心诉求,形成事件设计文档,交付给研发团队进行数据接入。
埋点采集文档模版详见附件[海纳嗨数埋点采集文档模版]

2.1 事件表的设计

表头中带有“ 必填 ”的字段为必填项,请勿漏填,否则会导致埋点方案上传失败。

  1. 编号:按序号1、2、3等依次递增。
  2. 事件名:必填,需是合法的变量名,即不能以数字开头,且只包含:大小写字母、数字、下划线和 H_,其中以 H_ 开头的表明是系统的预置事件,自定义事件名请不要以 H_ 开头,且事件名长度最大为 50。
  3. 事件显示名:必填,事件在使用过程中的显示名称,不超过100字符。
  4. 事件描述:非必填,对该事件的描述信息,便于更好的理解业务,不超过256字符。
  5. 属性名:该事件的具体属性,以dict的形式存在。其中以 H_ 开头的表明是系统的预置属性,它的类型和中文名已经预先定义好了。自定义属性名需要是合法的变量名,不能以数字开头,且只包含:大小写字母、数字、下划线,自定义属性不能以 H_ 开头;同一个名称的属性,在不同事件中,必须保持一致的定义和类型;同一个名称的属性如果已经存在小写属性就不可再导入对应大写属性(比如元事件中有 abc 属性名,不能再传 ABC,Abc 等属性名),否则数据会校验失败不入库。属性名不超过50字符。
  6. 属性显示名:属性在使用过程中的显示名称,不超过100字符。
  7. 数据类型:常用的为文本(VARCHAR)、整数(INT)、布尔(B00LEAN)、日期(DATETIME)、数值(DOUBLE)数据类型。
  8. 埋点平台:必填,只能按照枚举值进行填写,目前可支持Android、iOS、JS、微信小程序MiniProgram、百度小程序ByteDanceMini、QQ小程序QQMini、字节跳动小程序ByteDanceMini、支付宝小程序AlipayMini、快应用 QuickApp、We 码小程序WeCode、小游戏MiniGame。请填写英文,多个平台请用“/”符号分割开。
  9. 若所上传事件/属性已存在,将自动过滤,并以已存在内容为准。
  10. 同一属性英文名所对应的中文名称需保持一致,若有不同,将以第一个名称为准。
  11. 事件的触发时机:需说明每一个事件应在何时触发,如一个事件在多个时机均有可能会被触发,则需要整理出所有的触发时机。例如:“点击开始注册事件”的触发时机应为点击注册时,但注册通常有多个不同的入口,因此,业务人员需要明确地枚举出哪些注册入口是需要研发人员进行埋点的,如果有属性值的区分也要标注,避免遗漏。

2.2 公共事件属性表的设计

公共属性为所有事件均有的属性,例如事件发生的平台、事件所属的业务模块等。没有该业务需求时可忽略公共属性。

表头中带有“ 必填 ”的字段为必填项,请勿漏填,否则会导致埋点方案上传失败。

  1. 编号:按序号1、2、3等依次递增。
  2. 属性名:需要是合法的变量名,不能以数字开头,且只包含:大小写字母、数字、下划线,自定义的公共属性不能以 H_ 开头;同一个名称的属性如果已经存在小写属性就不可再导入对应大写属性(比如元事件中有 abc 属性名,不能再传 ABC,Abc 等属性名),否则数据会校验失败不入库。属性名不超过50字符。
  3. 属性显示名:必填,属性在使用过程中的显示名称,不超过100字符。
  4. 数据类型:支持支持文本、布尔、日期等数据类型
  5. 若所上传属性已存在,将自动过滤,并以已存在内容为准。

2.3 用户表的设计

用户属性需是描述用户较为长期状态的属性,例如性别、账号信息、VIP等级等不。当用户属性发生变动时,如所在地发生了变更,我们会更新用户表中的属性,用户表永远存储的是当前最新状态的值。

表头中带有“ 必填 ”的字段为必填项,请勿漏填,否则会导致埋点方案上传失败。

  1. 编号:按序号1、2、3等依次递增。
  2. 属性名:以 H_ 开头的表明是系统的预置属性,它的类型和中文名已经预先定义好了。自定义属性名需要是合法的变量名,不能以数字开头,且只包含:大小写字母、数字、下划线,自定义属性不能以 H_ 开头;同一个名称的属性如果已经存在小写属性就不可再导入对应大写属性(比如元事件中有 abc 属性名,不能再传 ABC,Abc 等属性名),否则数据会校验失败不入库。属性名不超过50字符。
  3. 属性显示名:必填,属性在使用过程中的显示名称,不超过100字符。
  4. 数据类型:支持支持文本、布尔、日期等数据类型
  5. 若所上传属性已存在,将自动过滤,并以已存在内容为准。

2.4 整体设计思路

  1. 确立观察指标
    根据前期建立的指标体系,逐个梳理。

  2. 找出关联行为
    抽象观察指标的行为事件,例如想要观察支付转化率?明确支付转化率的定义为应用启动-进入商品列表页-浏览商品详情页-提交订单-支付成功转化率,把每个行为抽象为一个事件。

  3. 补充事件属性
    观察支付转化率,可能还想知道不同的商品类目/不同的商家···的转化率,因此需要在能够记录这些相关信息的事件增加事件属性,方便后期做维度拆分。如图所示展示了浏览商品详情页可增加的商品相关属性。

  4. 设计事件要素
    将事件的触发形式、英文命名、埋点端、属性值类型、属性值示例补充完整。

  5. 补充公共属性
    如果想看不同的操作系统、不同的运营商客户的转化情况,这些不是某事件特有的信息但是每个事件都可以获取到的信息,可以将其设定为公共属性。

  6. 补充用户属性
    如果想看不同性别、不同注册时间、不同用户等级的转化率区别,则需要增加用户属性。

2.5 确定可行性和排期

设计人员应与研发逐个确认事件和属性采集的可行性与成本,对于实现成本高,需要重要性不高的需求可做取舍,并制定整体埋点优先级的排期。

2.6 常见问题

  1. 多重身份用户的设计?
    在一个物流平台中,使用平台的用户可能有货主也有司机;对于一个招聘系统,使用平台的用户可能有学生和企业;对于一个在线教育平台,使用平台的用户可能有老师和学生。对于不同身份的用户,需要给一个用户属性对用户进行身份标识。

  2. 相似场景是埋为一个事件还是多个事件?

(a)各事件所需属性相差不大,但平时分析场景单一分析,并且业务含义区别较大。此时建议设计为不同的事件。

例如:收藏商品、浏览商品详情,虽属性差异不大,但是收藏和浏览业务关系不大,且通常为单独分析。

(b)各事件所需属性相差很大,分析场景多分别分析。此时建议设计为不同的事件。

例如:例如一个内容平台,有视频也有文章,因视频和课程所记录属性差异较大,浏览内容详情应区分为浏览视频详情和浏览文章详情

(c)各事件所需属性相差不大,平时分析场景多整体分析。此时建议设计为同一个的事件。

例如:点击banner、点击热门活动位,都是点击首页的推荐位,可通过增加属性区分。

(d)对于全局性的事件,我们建议设计为同一事件,通过特定的属性值对特定操作进行区分,而不是针对每一个操作设计一个事件。

例如:相似场景下的按钮点击可合并,不必一个点击一个事件,需合并为一个事件。如有不同的注册入口,不必分为多个事件,使用一个注册入口字段区分入口,备注好触发时机让开发均埋上即可。

2.7 埋点方案上传

操作路径:开发者中心-元数据管理-元事件

注:埋点方案上传平台后,系统才开始接收数据。

3 埋点开发

3.1 如何接入

  • Android SDK接入
    接入地址路径:帮助中心 > 技术文档 > 客户端SDK > Android SDK > SDK配置
    A、初始化:参考”SDK配置”菜单, 进行初始化处理。
    B、全埋点:参考“SDK接入”菜单中标题为“1. 开启全埋点”接入
    C、设置用户唯一标识:为了将行为数据标记为对应您的业务用户,参考“SDK接入”菜单中标题为“2 用户关联 –> 2.1 关联用户ID”接入即可
  • iOS SDK接入
    接入地址路径:帮助中心 > 技术文档 > 客户端SDK > iOS SDK > SDK配置
    A、初始化:参考”SDK配置”菜单, 进行初始化处理。
    B、全埋点:参考“SDK接入”菜单中标题为“1. 开启全埋点”接入
    C、设置用户唯一标识:为了将行为数据标记为对应您的业务用户,参考“SDK接入”菜单中标题为“2 用户关联 –> 2.1 关联用户ID”接入即可

  • JS接入
    接入地址路径:帮助中心 > 技术文档 > 客户端SDK > Web Js SDK > SDK配置
    A、初始化:参考”SDK配置”菜单, 进行初始化处理。
    B、全埋点:参考“SDK接入”菜单中标题为“1. 开启全埋点”接入
    C、设置用户唯一标识:为了将行为数据标记为对应您的业务用户,参考“SDK接入”菜单中标题为“2.2 用户关联 –> 2.2.1 关联用户ID”接入即可

  • 微信小程序接入
    接入地址路径:帮助中心 > 技术文档 > 客户端SDK > 小程序 SDK > 微信小程序 SDK >SDK配置
    A、初始化:参考”SDK配置”菜单, 进行初始化处理。
    B、全埋点:参考”SDK接入”菜单, 初始化代码将全埋点开关全部打开即可。
    C、设置用户唯一标识:为了将行为数据标记为对应您的业务用户,参考”SDK接入”菜单中标题为“2.2.1 用户登录关联”接入即可

  • Uni App接入
    接入地址路径:帮助中心 > 技术文档 > 客户端SDK > 跨平台框架 > Uni App 插件
    A、初始化:参考”SDK配置”菜单, 进行初始化处理
    B、全埋点:参考“SDK接入”菜单中标题为“1. 开启全埋点(自动采集)”接入
    C、设置用户唯一标识:为了将行为数据标记为对应您的业务用户,参考“SDK接入”菜单中标题为“3. 用户关联 –> 3.1 关联用户ID”接入即可

3.2 接收地址

由于每个项目的数据是相互独立的,您可在对应项目的开发者中心-数据接入-埋点数据接入中获取数据接收地址,将数据接入:

4 数据检测

埋点方案上传且数据接入后,您需要对数据是否上报进行检测:

  1. 您可以使用开发者中心-数据检测模块,在数据名称处选择用户属性/某个元事件查看有没有数据上报记录:

  1. 若您习惯使用SQL查询,您也可以使用分析配置- SQL查询:

其中demo1替换为对应项目编号:
· SELECT * FROM dwd_event_demo1,——查询事件表的全部数据(对应埋点方案中事件表和公共事件属性两个sheet)
· SELECT * FROM dwd_users_demo1,——查询用户表的全部数据(对应埋点方案中的用户表sheet)
· SELECT * FROM dwd_event_demo1 WHERE event = ‘H_WebClick’ ,——查询某元事件有没有数据上报,其中’H_WebClick’ 替换为想要查询的元事件

5 指标自定义配置

若您已经完成了数据接入工作,接下来就可以自由的使用海纳嗨数进行数据分析。您可以使用事件分析、漏斗分析、属性分析等分析模型查看想要分析的数据;也可以使用用户标签、用户分群等模型查看用户行为特征,为用户打标签,圈选目标人群;同时,您可以将日常查看的指标添加为书签或保存到分析看板,方便日常的运营监控。
对于后续的使用若您有任何疑惑,可以联系海纳嗨数工作人员,我们会帮助您快速熟悉平台的使用流程。

5.1 如何使用分析模型?

不同的分析模型适用于不同的应用场景。若想对某段时间内用户产生的特定行为指标进行聚合计算,可以使用事件分析,如统计一段时间内的新用户数、活跃用户数;若想了解某个产品在各个关键步骤环节的转化状况,可以使用漏斗分析,如分析用户从点击链接-注册-登录-付费的操作行为。

想要创建一个分析模型,需要进行以下几个操作步骤:

第一步:选择想要计算和统计的指标,若想筛选满足条件的用户,可以使用「全局筛选」来增加筛选条件;若想按某分组进行查看,可以使用「分组项」进行设置。

第二步:可在结果展示区查看结果,支持更改查询的时间范围(默认过去7天)、展示内容、展示图表等。

第三步:若想保留查询配置,可将查询结果保存为书签/分析看板:

可至分析看板或书签中查看该图表:

5.2 如何创建用户标签?

用户标签模块支持用户基于埋点数据自定义标签规则生成新的标签,描述用户的行为特征。用户标签可以单独管理分析,也可以在分析模型中细分分析,同时可添加至空间进行日常的数据监控。

想要创建一个标签,需要进行以下几个操作步骤:
第一步:点击标签管理主页的「新增」创建标签,选择好想要使用的标签创建方式后,点击进入标签配置页面。

各种创建方式的功能说明如下:

  • 数值标签:对用户的行为事件进行聚合计算,输出数值型标签。如统计用户近一年内登录的总次数。
  • 自定义标签:根据若干条件筛选出满足条件的用户,自定义其标签值。如将近一年充值笔数小于10的人群定义为低价值人群,大于等于10的定义为高价值人群。
  • 初末次标签:将用户初次/末次完成某件事件的日期/距今天数/属性值作为标签值。如统计用户首次登录距今天数。
  • SQL标签:使用自定义的SQL查询语句为指定的用户进行标记。
  • 导入标签:使用导入的标签值为指定的用户进行标记。

第二步:进行标签规则的配置,标签的配置包括三个部分,分别是标签基础信息、标签规则配置、更新与备份。

第三步:标签基础信息、标签规则配置、更新与备份均设定好以后,点击「保存并计算」按钮即可创建标签,并同步至标签管理主页。

第四步:若想查看标签的数据详情,可点击标签名称进入标签详情页:

5.3 如何配置分析看板?

在后续的使用过程中,我们首先建议您创建分析看板。分析看板可将日常运营需要关注的数据以可视化的方式进行批量展示,并支持实时更新。创建好的空间可在项目成员内进行共享,有利于日常监控产品的运营状况,了解用户的使用习惯。

分析看板的特点有:

  • 分析看板可以共享给项目其他成员查看,并支持添加协同者一起管理编辑空间。
  • 分析看板支持自定义展示内容和结构排版。
  • 初始化配置后,每次加载分析看板时数据会进行更新,方便日常的监控。
  • 分析看板支持二次筛选、调整时间窗、数据导出等操作。

想要配置一个看板,需要进行以下几个操作步骤:

第一步:在分析看板中新建一个分组和一个看板:

第二步:在分析配置中配置分析指标,并将其计算结果添加到分析看板/保存为书签:

  • 若将计算结果保存到分析看板,则可至分析看板直接查看该结果:

  • 若将计算结果保存为书签,则可至分析看板主页添加该书签至看板:

第三步:重复步骤二,基于数据分析或用户标签模块的分析模型配置想要在分析看板模块进行统一管理和查看的指标。可在分析看板主页对图表的大小和展示方式进行调整,并可拖拽调整图表的顺序,自定义数据空间的布局和内容,完成分析看板的创建。

6 查看数据结果

完成以上几个步骤以后,您就可以在「分析看板」中查看业务数据:

作者:顾航博  创建时间:2023-08-15 16:22
最后编辑:超级管理员  更新时间:2024-10-31 14:08