设备品牌：Apple
设备型号：iPhone 6s
操作系统：iOS
屏幕分辨率：1920\*1680
运营商：中国联通
网络类型：Wifi
……
自定义采集的事件：EventID
事件属性：Key-Value
add\_to\_cart
product\_name：耳麦
product\_price：666
所有基于事件的原子指标都可以通过事件分析来构建，比如常见的活跃用户数、启动次数、支注册用户数、人均支付金额等指标；
也支持原子指标之间进行四则运算构建衍生指标
| | Session分析 | 会话级别的指标，比如访问次数、访问时长、跳出率等指标 | | 渠道分析 | 会话级别的指标，细分渠道维度，比如不同流量来源的访问用户数、不同着陆页的页面浏览量等 | | 留存分析 | N日/周/月留存用户、留存率、流失用户、流失率等 | | 转化漏斗 | 关键路径的转化用户数、转化率、转化时长等 | | 属性分析 | 用户构成，比如地理位置分布、会员类型分布等 | | 分布分析 | 维度值的区间分布，比如使用次数分布、使用时段分布、支付订单金额分布 | ## 1 基于事件分析构建指标 ### Web 页面浏览量（PV） 指 Web 页面浏览的总次数，同一页面刷新多次也会被重复计入。  ### Web 访问用户数（UV） UV（Unique Visitor），通常用以表示Web端网站的去重访问用户。对于网站而言，根据cookie生成的ID为判断标准，如果访客更换浏览器或清除cookie，会计为新的UV。  ### APP 活跃用户数 传统意义上活跃用户是指一段时间里启动APP的设备数，时间粒度往往是日、月，按日统计时就是 DAU，按月统计就是 MAU {% hint style="info" %} 在方舟中用户是指与网站、APP、小程序等产生交互的主体，使用方可以自己在上报数据的时候决定使用设备ID标识，还是注册用户标识。 可以自定义什么是活跃用户，可以是启动的用户数，也可以是发生任意行为的用户，也可以是登录的用户……根据实际业务口径去构建即可 若同时有Web、APP、小程序的数据接入，也可以添加条件过滤或者是细分平台维度 {% endhint %} **示例：** > 定义：移动端启动的用户数，同一用户在一天内访问多次仅被计为一个用户 > > 指标：启动的触发用户数 > > 条件：平台 = Android、iOS > > 分群：所有用户 > > 时间粒度：按日  ### APP 启动次数 指启动 APP 的总次数。启动多次会被累加。  ### 新增用户数 通常意义上新增用户是以首次启动 APP 或首次访问网站来定义，APP 卸载后再安装，后者网站被清除cookie ，都会被计为新增用户。 {% hint style="info" %} 方舟当中预置了 **新访问用户** 动态分群，方便在各个分析模块中快速选择查看新用户表现。 {% endhint %} 在 *新访问用户* 的分群下，选择 *启动的触发用户数* 即为常规意义上的新增用户数，若Web、APP等多平台数据上报在一个项目中，则可以条件过滤，或者细分平台维度 在图表区域选择不同的时间粒度，即按日、周、月去查询各个粒度下的新增用户数，也可以选择数值图，查看选定区间里的新增用户  {% hint style="info" %} 预置的新访问用户是根据首次访问时间是哪一天来判断用户是哪一天新增的，所以选择在所有用户下，选择启动的触发用户数，添加首次访问时间 是在启动当天 也可以得到相同的结果 ⚠️首次访问时间是 SDK 判断用户是首次访问时调用 profile\_set\_once 上报，所以在接入阶段一定要验证是否正确集成 {% endhint %}  {% hint style="warning" %} 1. 不建议在新访问用户分群下的基础上，选择任意事件的触发用户数保存为新增用户，因为任意事件可能包含了一些被动事件，比如消息推送成功、服务端返回的成功事件等。 2. 在所有用户基础上，选择启动的触发用户数，添加条件是否安装后首日访问 = 是，也可以作为新增用户的定义，但与系统预置的新访问用户的口径不一致，因为数据上报的差异可能会出现偏差，不具有可比性，所以尽量在同一产品中使用相同口径。 {% endhint %} ### 新增注册用户数 对于有帐号体系的产品来说，相较于访问用户数，用注册用户数衡量有效用户会更精准。在选定时间段内注册成功的用户会被计入新增注册用户。 {% hint style="info" %} 方舟当中预置了 新增注册用户 动态分群，但当且仅当在用户属性中上报了注册时间，且属性ID 使用预置的 $signup\_time 另外，为了更准确的获取注册成功的时间，建议在服务端而非客户端埋点。 {% endhint %} **除了上述基础指标之外， 事件分析可以基于事件、事件属性构建出任意指标，在指定分群下、指定时间范围、时间粒度下分析**  {% hint style="info" %} **事件和属性都来自于SDK埋点上报或数据导入。** {% endhint %} ### 事件 X 的触发用户数 指点击了事件 X 的用户数。同一用户在同一个时间粒度里发生多次行为时仅被计为一个用户。 如下图，表示本月每天支付成功的用户数，当同一个用户在同一天里多次购买成功支付时，在这一天里这个用户只会被记1。  ### 事件 X 的触发次数 指点击了事件 X 的总次数。同一用户在同一个时间粒度里发生多次行为时会累加。 如下图，表示本月每天支付成功的次数，当同一个用户在同一天多次购买支付成功时，次数会被累加。  ### 事件 X 的人均触发次数 指人均点击事件 X 的次数 = X 的触发次数 / X的触发用户数 如下图，表示本月每天人均支付成功的次数。  ### 事件 X 的属性 Y 的去重数 指在触发事件 X 时 属性 Y 出现的独立去重个数。 如下图，表示本月里每天用户支付成功的商品类别数量。比如11月11日里，3个用户成功购买，分别购买了如下，则支付成功的商品分类数量为5 | 商品一级分类 | 小明 | 小李 | 小王 | | ------ | -- | -- | -- | | 电子设备 | 1 | 1 | 1 | | 服装 | 2 | 3 | 1 | | 家具 | 1 | 0 | 2 | | 植物 | 2 | 0 | 0 | | 食品 | 4 | 1 | 4 | | 虚拟商品 | 0 | 0 | 0 |  ### 事件 X 的属性 Y 的总和 指选定事件的属性的属性值总和。 如下图，表示本月里每天用户支付成功的订单金额总和。  ### 事件 X 的属性 Y 的均值 指选定事件的属性的属性值的算数平均数 = 属性值总和 / 属性值个数。 如下图，表示本月里每天用户支付成功的订单的平均金额，即订单金额总和/订单数。  ### 事件 X 的属性 Y 的最大值 指选定事件的属性的属性值中的最大值。 如下图，表示本月里每天用户支付成功的最大订单金额。  ### 事件 X 的属性 Y 的最小值 指选定事件的属性的属性值中的最小值。 如下图，表示本月里每天用户支付成功的最小订单金额。  ### 事件 X 的属性 Y 的人均值 指选定事件的属性的属性值总和 / 事件的触发用户数。 如下图，表示本月里每天平均每个用户支付的订单金额。  ### **自定义指标公式** {% hint style="info" %} 除了事件相关指标外，方舟支持自定义指标公式，构建无法通过选择事件得出的指标，比如 ARPU、ROI 等。 支持加、减、乘、除、括号及常数的四则运算 {% endhint %}  比如通过支付订单金额总和 - 退货金额总和 即可创建出实际完成订单金额的指标，如下图表示过去7天实际完成订单金额的趋势，可以增加额外指标对比分析。  更多使用详见 {% content-ref url="/pages/-LaQ9KePDb\_g--gmYFI1" %} [事件分析](/features/analytics/event) {% endcontent-ref %} ## 2 基于 Session 分析的指标 事件是指何人何时在何地用何种方式做何事的单点用户行为。会话（Session）则指一系列的事件，用以描述用户在一次访问中做了一些什么事儿。进而分析用户来访的频次、时长、深度等，从不同角度指导精细化运营。 {% hint style="info" %} 怎样一系列的行为？方舟默认session切割的规则详见：
商品类别
上报的属性值：
3C电器、服装、化妆品……
3C电器：12人
服装：12人
化妆品：18人
按离散值
自定义区间分组
商品价格
上报的属性：
12、20、90、300……
按离散值：
12：2人
20：3人
90：13人
300：1人
按用户自定义区间的话可能是：
(-∞,50)：5人
\[50,200)：13人
\[200,+∞]：1人
是否使用优惠券
上报的属性值：
true、false
使用了优惠券的：12人
没有使用优惠券的：18人
按分钟、小时、日、周、月、季、年
按时段汇总：按分钟、小时、日、周，月
下单时间
上报的属性值：
2017-03-12 12:12:32、
2018-03-15 12:12:32、
2018-04-12 12:12:32……
不按时段汇总，按月：
2017年3月：23人
2018年3月：27人
2018年4月：12人
按时段汇总，按月：
每年3月：50人
每年4月：12人
用户爱好
上报的属性值：
\[网球，摄影]、\[户外，摄影]、\[户外、壁球]……
\[网球，摄影]：34人
\[户外，摄影]：53人
\[户外、壁球]：23人
用户匹配度
广告出价
展示量
点击量
渠道选择
人群优化
智能出价
用户匹配度
创意吸引度
创意优化
A/B测试
着陆页质量 （与创意的符合程度、着陆页本身的内容）
用户匹配度
着陆页PV
着陆页UV
加载时长
跳出率
停留时长
访问深度
……
转化用户
转化率
e.g. 下载、注册成功、交易
$utm\_campaign\_id 不为空
$utm\_medium = push\_notification
$utm\_campaign\_id 不为空
$utm\_medium = email
$utm\_campaign\_id 不为空
$utm\_medium = xxx
$utm\_source 不为空
$utm\_campaign 不为空
$utm\_medium ≠ push\_notification,email,xxx
$utm\_campaign 为空
$utm\_medium = search
$utm\_campaign 为空
$utm\_medium = social
$utm\_campaign 为空
$utm\_medium = referral
$utm\_campaign 为空
$utm\_medium = direct
在某一日/周/月发生了初始行为的用户在第 N 日/周/月时发生了后续行为的用户记为留存用户
留存率是指第 N 日/周/月时发生了后续行为的留存用户在初始行为用户中的占比
| | 第 N 日 - 流失用户数 和 流失率 |在某一日/周/月发生了初始行为的用户在第 N 日/周/月时没有发生后续行为的用户记为流失用户
流失率是指第 N 日/周/月时流失的用户在初始行为用户中的占比
| | 之后连续 N 日 - 留存用户数 和 留存率 |在某一日/周/月发生了初始行为的用户在之后连续 N 日/周/月发生了后续行为的用户记为留存用户
留存率是指之后连续 N 日/周/月发生了后续行为的留存用户在初始行为用户中的占比
| | 之后连续 N 日 - 流失用户数 和 流失率 |在某一日/周/月发生了初始行为的用户在之后连续 N 日/周/月没有发生后续行为的用户记为流失用户
流失率是指之后连续 N 日/周/月没有发生后续行为的流失用户在初始行为用户中的占比
| | 同时分析指标 | 可以同时分析留存用户在每个周期里的指定指标的表现，比如选择【初始行为：支付订单】【后续行为：支付订单】【同时分析指标：支付订单的金额】即可分析回购用户的回购金额 | ### 1.4 细分维度 支持同时查看某个维度不同属性值的留存，比如不同城市的新用户留存，细分发现影响留存的特定因素。 对于不同属性值类型支持不同的分组方式，同《[事件分析 - 1.3 细分维度](/features/analytics/event#13-xi-fen-wei-du)》 ### 1.5 人群选择 默认基于所有用户计算留存，可以选择其他已保存人群，e.g.要分析北京地区用户留存，选择北京地区的用户即可。也可点击对比分群，选择对应的人群进行对比分析。 ## 2. 图表展示 图表展示区，可以选择时间范围、时间粒度、 ### 2.1 时间范围 **时间范围限制的是初始行为发生的日期** e.g 选择了【2018/03/01-2018/03/07】【初始行为 = 注册，后续行为 = 任意事件】则计算的是在2018/03/01-2018/03/07这段时间里，每一天注册的用户，在随后30天里再次回访的留存用户。 ### 2.2 时间粒度 可选择的时间粒度，包括： * **按日**，可分别查看次日、7日、14日及 30日留存 * **按周**，可分别查看次周、8周、12周及 24周留存 * **按月**，可分别查看次月、6月、12月及 24月留存 ### 2.3 第 N 日留存/流失 **第 N 日留存用户数**指在某个时间发生了初始行为 X 的用户，在之后的第 N 日/周/月进行了后续行为 Y 的用户（ X 可以等于 Y ）。 例如： > 初始行为 = 点击购买 > > 后续行为 = 点击购买 > > 4月1日发生购买的用户200人，这200人中4月2日再次购买的用户有100人，4月4日再次购买的用户有50人， > > 则第1日留存用户为100，第3日留存用户为50。 **第 N 日流失用户数**指在某个时间发生了初始行为 X 的用户，在之后的第 N 日/周/月没有进行后续行为 Y 的用户（ X 可以等于 Y ）。 例如： > 初始行为 = 点击购买 > > 后续行为 = 点击购买 > > 4月1日发生购买的用户200人，这200人中4月2日没有购买的用户有100人，4月4日仍然没有购买的用户有50人， > > 则第1日流失用户为100，第3日流失用户为50。 **基础计算规则** 假设定义初始行为是 X 事件，回访行为是 Y 事件。 2017/03/01-2017/03/08 小明各天的行为序列为： | 2017/3/1 | 2017/3/2 | 2017/3/3 | 2017/3/4 | 2017/3/5 | 2017/3/6 | 2017/3/7 | 2017/3/8 | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | | XYXY | ABC | YCX | DDY | ABC | BYC | ABC | DDY | 那么计算 2017/03/01的7日留存，则需要在3月1日之后加上7日，查找2017/03/01-2017/03/08范围内，是否发生了后续行为 Y 事件，小明会被算作第2日、第3日、第5日、第7日的留存；则第1日、第4日、第6日被算作流失。 但是若细分维度时，会略有差异，分别说明提供的两类细分维度： **用户属性：** 根据用户属性来分组，e.g. 性别，如果小明是男，则会被算到男性用户的留存当中 **事件属性：** 根据初始行为的事件属性分组。如果用户触发了多次初始行为，并且属性值不相同，会按用户首次初始行为的属性值进行分组，e.g. 设备品牌，如果小明3月1日方开始用 iPhone X 点击了XY，随后更换了华为 Mate8 又点击了 XY 事件，则小明会被算到 iPhone X 的分组中。 可以对比不同人群的留存，探索发现影响留存/流失的原因  ### 2.4 之后连续 N 日留存/流失 **之后连续 N 日留存用户数**指在某个时间发生了初始行为 X 的用户，在之后连续 N 日/周/月进行了后续行为 Y 的用户（ X 可以等于 Y ）。 例如： > 初始行为 = 点击购买 > > 后续行为 = 点击购买 > > 4月1日发生购买的用户200人，这200人中4月2日再次购买的用户有100人，4月3日再次购买的用户有50人，4月4日没有人购买，4月5日有50人再次购买 > > 则之后连续1日后留存用户为100，2日后留存用户为50，3日、4日都为0。 **之后连续 N 日流失用户数**指在某个时间发生了初始行为X的用户，在之后的连续 N 日/周/月没有进行后续行为 Y 的用户（ X 可以等于 Y ）。 例如： > 初始行为 = 点击购买 > > 后续行为 = 点击购买 > > 4月1日发生购买的用户200人，这200人中4月2日没有购买的用户有100人，4月3日都发生了购买，4月4日没有购买的用户有50人， > > 则之后连续1日流失用户为100，2日、3日都为0。  ### 2.5 留存曲线 留存曲线用来表现【目标用户】的回访比例按照天数衰减的趋势。 对于常见的留存曲线，可以将其分为三个部分：第一部分是振荡期，第二部分是选择期，第三部分是平稳期。  对于不同时期，我们应该有不同策略，总的来说，在振荡期和选择期，我们应该关注新用户的留存，进入平稳期以后，着重关注产品功能的留存。  方舟留存曲线展示的是留存表格中的第一行的概括 * 留存用户是已发生日期的累加值 * 留存率是当前列每个数据与初始行为用户数的加权平均数 合计列第N日的留存的计算逻辑为：每一日的第N日留存的留存用户的算术累加和/剔除未发生日期的目标用户数的算术累加和。 例如：当前日期为0923，查询过去7日(0916-0922)的留存。以合计列的第4日留存的计算逻辑举例：已知0920的第4日为0924，从0920开始往后的日期的第4日都是未来时间，未来日期不会有回访行为，因此计算合计列的第3日留存计算公式为：留存率=0.83%=(6+76+65+4)/(6180+5732+5497+800)  ### ### 2.4 人群下钻分析 所有图表中的数据节点，都可以下钻查看人群概览以及保存人群。 下钻人群下钻功能与分群一致，可在[分群](/features/user)中作进一步了解。 ## 3. FAQ ### **3.1 初始行为和后续行为选择相同事件，当日留存率为什么不是100%** 当日留存的规则是：用户在触发了初始行为的当日触发了后续行为，不考虑初始行为和后续行为的发生顺序。但是用户触发的1次行为，不能同时作为初始行为和后续行为，因此初始行为和后续行为选择相同事件时，当日触发次数必须大于等于2次才会被计为当日留存。 {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 转化漏斗 转化漏斗模型，是分析用户使用某项业务时，经过一系列步骤转化效果的方法。 在理想情况下，用户会沿着产品设计的路径到达最终目标事件，但实际情况是用户的行为路径是多种多样。通过埋点事件配置关键业务路径，可以分析多种业务场景下转化和流失的情况，不仅找出产品潜在问题的位置，还可以定位每个环节流失用户，进而定向营销促转化。 ## 转化漏斗能解决哪些问题？ 1. 官网流量很大，但注册用户很少，是过程中哪个环节除了问题？ 2. 用户从“注册 – 绑卡 - 提交订单 - 支付订单” 总体转化率如何？ 3. 不同地区的用户支付转化率有什么差异？ 4. 两个推广渠道带来不同的用户，哪个渠道的注册转化率高？ 5. 上周针对注册环节的问题做了一次优化，转化率趋势是否有提升？ ……  ## 1. 定义指标区 左侧为指标定义区域，建立转化漏斗，细分维度查看，支持条件过滤，支持多个人群的对比分析。 ### 1.1 建立漏斗 每个漏斗至少由两个步骤构成，每个步骤可以选择相应事件，包括页面事件和点击事件。 每个事件都可以增加筛选条件作为约束，例如对于启动事件，可以限定平台属性值为Android，购买理财可以限定购买金额属性值大于10000。 每个步骤的事件为有序关系，第二步用户必定为第一步的用户，后面依次类推。  **转化周期：**是指用户需要在限定的时间内完成所有转化步骤才算转化成功，否则计为流失。 {% hint style="info" %} 默认转化周期为 7 天，支持用户自定义，最短 1 分钟，最长 180 天 **注意：这里的 天 代表24小时，非自然天** {% endhint %} ### 1.2 细分维度：按X查看 点击细分维度后，选择细分的维度即可查看具体维度不同属性值的转化漏斗，细分发现转化率差异。例如查看不同平台的或不同性别用户的转化漏斗。  {% hint style="info" %} 只能选择一个维度展开。 {% endhint %} #### **维度包括3类属性：** * 公共的事件属性 * 各个步骤事件的自定义属性： 假设选择步骤 4 的属性“产品名称”，表示在完成转化/确认流失的用户中，按照转化到步骤 4 时的“产品名称”的值来进行分组。 若没有转化到步骤 4，则按照"(无值)"组处理。 * 用户属性：根据用户属性来分组，e.g. 性别，则会按照 男、女 各自用户来分组。 点击细分维度选择下拉框中，对 **数值型** 和 **日期时间型** 做特殊标识； 当分组个数超出 50 个时，默认展示最近的时间单位内指标数值最大的50个分组，可以在图例自行选择其他的分组。 **A. 数值型维度分组方法**  **B. 日期型维度分组方法**  ### 1.3 公共过滤条件 假设选择的是公共过滤条件是城市-北京市，则A、B 、C、D 4个步骤中的用户都按北京市的值进行转化计算。  ### 1.4 筛选用户群 可点击所有用户下拉菜单选择自定义人群，查看人群漏斗情况；可对比多个人群的漏斗情况，当选择多个人群时，不能再细分维度；可对全量用户进行随机抽样，查看漏斗情况。  ## 2. 图表展示 图表展示区，可以选择时间范围，默认近30日。 ### 2.1 时间范围 时间范围限制的是第一个步骤发生的日期。 ### 2.2 图表展示 不同的漏斗、条件、人群、维度组合可以可视化呈现。 ### 2.3 转化/转化趋势 转化查看所选用户群的总体转化情况。 转化趋势可查看总体转化率，也可按步骤查看每步之间的转化率、转化用户数、转化时间中位数和流失用户数。  #### **A. 单个人群的关键路径转化漏斗**  #### **B. 多个人群的在同一关键路径的转化对比**  ### 2.4 指标算法 **总体转化率** = 最后一步转化的用户数 / 第 1 步的用户数 \* 100%; **各步骤转化率** = 第 n 步转化的用户数 / 第 n -1 步的用户数 \* 100%； **转化用户数 =** 指完成从上一步骤到下一步骤转化的的去重用户数； **转化时间中位数 =** 指完成从上一步骤到下一步骤转化，用户所需时间的中位数； **流失用户数 =** 指上一个步骤的用户数 - 上个步骤到该步骤转化的用户数； #### **基础计算规则** 假设一个注册流程的事件：点击注册-输入邮箱-输入密码-输入手机号-注册成功5个步骤，以下用 A - B - C - D - E 表示，则建立漏斗的事件为 A - B - C - D - E ，选择 2018/03/01-2018/03/07，转化周期为2天**。** e.g.在 2018/03/01-2018/03/07内触发了A事件 1.若在触发A事件后的两天内，按顺序完成了 B - C - D - E，则视为一次完整的转化。 2.若在这个过程中，穿插完成了其他步骤或者事件,用户的行为序列为 A - B - F - C - G - D - H - H - E，则依然视为完成了一次完整的转化。 3.若在触发A事件的两天内顺序触发了 B - C - D - E，两天后才触发 E，则 A - B - C -D 记为转化，D - E 视为流失。 4.若在触发A事件的两天内顺序触发了 B - C - E，而漏掉了 D，也不算一次完整的转化，A - B - C 记为转化， C - D 视为流失。 5.若在触发A事件的两天内顺序触发了 B - D - C - E，则 A - B 记为转化，B - C 视为流失。 > 注：3 、4、5 最终均触发了 E 事件，完成了注册，但并未按漏斗规定的时间和顺序进行转化，所以最终的转化率皆为 0。 若一个用户在所选时间范围里有多个事件都符合某个转化步骤的定义，则优先选择靠近最终转化目标的事件作为转化事件，并在达到目标时停止计算。 **同时发生的事件** 对于一秒内发生的两个事件，如果是不同事件，在计算漏斗时我们会认为他们是“同时”发生的。也就是说，无论他们实际发生的先后顺序是什么，我们都会计算为转化。例如，一个人如果先触发了事件A，然后又在一秒内触发了事件B，对于以下情况都会认为是转化： > 事件A > 事件B 或 事件B > 事件A 如果是同一事件，我们会将计算精度提高到1毫秒来确定他们发生的先后顺序，以得到准确的转化数据。假如两个相同事件发生在同一秒，则我们会认为它们之间没有转化。 {% hint style="info" %} 从5.1版本开始，漏斗分析统一成毫秒精度，假设两个事件发生在同一毫秒，则我们会认为他们之间没有转化。 {% endhint %} ## 3. 人群下钻分析 所有图表中的数据节点，都可以下钻查看人群概览以及保存人群。 下钻人群下钻功能与分群一致，可在[分群](/features/user)中作进一步了解。 ## 4. FAQ ### 4.1 漏斗分组结果与筛选条件下结果不一致 答：漏斗分析中，筛选条件是先筛选再计算出漏斗，而分组是先计算出漏斗再进行分组，即筛选条件是作用于计算漏斗之前，分组是作用于计算漏斗之后，所以二者的结果可能不一致。比如，漏斗定义的步骤是A-B-C。某用户的行为的序列是A1(操作系统=Andriod)-A2(操作系统=iOS)-B-C，此时无论筛选操作系统等于Android还是iOS，那么最终该用户都有转化。当按“操作系统”分组时，按照漏斗的计算规则该用户的漏斗转化为A2(操作系统=iOS)-B-C，即该用户的转化将会被分组到iOS。此时，漏斗分组下Android的分组结果与筛选条件筛选操作系统等于Android的结果不一致。 ### 4.2 漏斗分析的用户数与事件分析的触发用户数不一致 答：区分非分组场景和分组场景。 非分组场景下，漏斗第一步与事件分析不一致，检查二者其他条件是否一致，比如筛选条件、抽样。检查是否缓存导致，都强制刷新。其他步骤结果不一致，是正常的。 分组场景下，漏斗的分组是基于用户的最优转化路径进行分组的。单周期内，单个用户最多只会算1次转划。而事件分析的分组，是明细粒度的。单个用户单个周期内不同的分组取值，所有分组都会被计算。比如，漏斗定义的步骤是A-B-C。某用户的行为的序列是A1(操作系统=Andriod)-A2(操作系统=iOS)-B-C。事件分析中，A事件按操作系统分组，Android与iOS都会计算，漏斗分析中，转划只会被计算到iOS分组。 ### 4.3 漏斗的总体转划率没有按天转划率高 答：因为总体是单独作为一个整体的周期计算的，而单个用户在单个周期最多只会算1次转化，所以当每天转划的用户重叠度很高时，总体的转划率就有可能比按天的转划率低。 比如，1号有a、b、c、d 4个用户，其中b、c、d 都转化了，2号有b、c、d 、e 4个用户，其中还是b、c、d 转化了。3号有b，c，d，f 4个用户，其中还是b、c、d转划了。此时1-3号每天的转划率都是75%。总体是a、b、c、d、e、f 6个用户3个用户有转划，转划率50%。 ### 4.4 按漏斗非首步事件属性分组时，转划率看上去都是100% 答：漏斗定义的步骤为A-B-C-D 。按事件C的属性分组。漏斗的分组是基于用户的最优转化路径进行分组的，当且仅当，用户的最优转化路径中包含C这个事件，对应C事件的分组属性才可能有值。。也就是说，当且仅该用户的最长转化路径大于等于3时，对应C事件的分组属性才可能有值。因此，当按漏斗的第三步的某属性分组时，所有属性有值的分组中，A-B以及B-C的转化都会是100%。未转化的用户，都分到了(无值) 的分组中。 即，当按漏斗非首步事件的属性分组时，该分组步骤之前的环节在分组值有值的分组下，转化率都会是100%。 ### 4.5 调整漏斗步骤后，其他步骤的数据也发生了变化 答：区分非分组场景和分组场景。举个例子，原来A-B-C-D-E 5步漏斗，现在删除漏斗第三步，变为A-B-D-E的漏斗。 非分组场景下，漏斗某一步步骤发生了调整，会影响后面步骤转化的判定。即举例中，漏斗第一步、第二步的用户数以及转划率不会发生改变，后续步骤的转划用户数将有可能改变。 分组场景：漏斗任何一步发生变化，对最优转划路径的判定都会产生影响，因此每一步转化用户数都有可能发生变化。举个例子，某个用户的行为序列为 A-B-D-E-A-B-C-D-E，如果漏斗定义是A-B-C-D-E，那么用户最优转化步骤为A-B-D-E-**A-B-C-D-E**.而漏斗定义为A-B-D-E时，漏斗的最优路径为**A-B-D-E**-A-B-C-D-E。最优路径判定的不同，将导致用户的最终转划所属的分组也不同。分组场景下的合计项与非分组场景一样，变化步骤之前漏斗步骤的结果不会发生变化。 {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 智能路径 路径，是指用户在应用中使用的行为轨迹。在产品的运营过程中，无论是产品、运营还是市场团队都希望能够清晰的了解其用户行为路径，来验证运营思路、指导产品迭代优化，达到用户增长、转化的最终目的。 当有明确的转化路径时，通过预先建立漏斗来监测转化率会比较容易（详见[转化漏斗分析模型](/features/analytics/funnel)）。但是很多情况下，虽然有最终的转化目标，但是用户到达该目标却有多条路径，无法确定哪条路径是用户走的最多的路径，哪条转化路径最短，这时候就需要智能路径分析模型的帮助。  ## 智能路径能解决哪些问题？ 1. 用户主要从哪条路径最终形成支付转化的？ 2. 用户离开预想的路径后，实际走向是什么？ 3. 不同的特征用户行为路径有什么差异？ …… ## 1. 定义指标区 上方为指标定义区域，选择事件范围，定义目标行为，设置用户属性，观察路径转化情况。 ### 1.1 选择参与路径分析的事件范围 支持选择全部事件，也支持选择部分事件，用于比如只关注页面间的跳转的场景，就可以只选择浏览页面；也可以过滤掉一些干扰事件。  ### 1.2 选择目标事件 确定想要观察的目标行为，通常是业务中需要引导用户完成的某个功能或到达的某个页面。  可以将 **目标事件** 设置为 **起始事件** 分析发生该行为后后续的行为路径；或者设置为 **结束事件**，分析其来源路径。 > 在电商中，加入购物车是支付成功这个最终转化目标的前一步，但很多用户在加入购物车之后，并不会提交订单，进而支付，这时选择 **目标事件** 为 "加入购物车" ，并设置为 **起始事件**，分析用户在加入购物车后的行为路径，究竟是被页面上的其他推荐吸引了目光还是走向何处。 #### 限制事件间隔时间（即转化路径的时间范围） 表示查看指定时间段内的行为轨迹 * 目标事件为**起始事件**时，表示查看触发目标事件**后**限定时间段内的行为轨迹 * 目标事件为**结束事件**时，表示查看触发目标事件**前**限定时间段内的行为轨迹 默认 30 分钟，可以根据业务需要自定义 > 比如启动是目标起始事件，时间间隔是 30 分钟 ， > > 某个行为序列是 启动 - A-B-C……X-Y-Z ， 到了X时，已经超过 30 分钟了，则 Y-Z 不算在转化路径内 ### 1.3 细分维度 选择按某一事件的事件维度，展开用户路径；比如查看页面之间的路径时，可以细分浏览页面-页面标题  ### 1.4 过滤条件 支持根据用户属性作为条件，查看比如钻石用户的行为路径  ## 2. 分析用户群 默认基于所有用户计算路径，也可以选择其他已保存人群  ## 3. 图表展示 图表展示区，可以选择时间范围，默认近7日，可以自定义选择日期，通过时间范围筛选出完成过目标事件的用户，再从中计算各条转化路径，展示出最频繁的路径。 通过桑基图的方式查看各个路径转化，每个节点事件的访问次数，从该节点上后续有访问的留存量和直接跳出的流失量。  {% hint style="info" %} 以上内容没有解答我的问题？[点击我进入方舟论坛去反馈](https://www.analysysdata.com/forum/index) 🚀 {% endhint %} # 归因分析（Beta） 归因分析，主要用于衡量和评估站内的用户触点对总体转化目标达成（如订单总金额）所作出的贡献，核心评价指标为“转化贡献度”。 所谓触点，就是用户与产品进行交互的接触点（如运营位、搜索、导航等）。这些触点，承担着引导用户行为、促进用户转化的作用。 ## **概述** 在做运营活动时，运营同学可能会在产品内的多个运营位上投放活动素材，试图在用户与产品交互过程中的各个触点上，吸引用户的注意力，引导流量走向和用户的行为，促成最终的转化。 此外，用户本身可能还会通过搜索、内容推荐等触点获取信息，这些触点对用户是否能达成转化也在发挥着重要作用。 也就是说，在用户的转化路径上，站内的众多触点都参与了对用户的劝说和引导，影响了用户的最终决策。 那么，对比各个用户触点，它们对关键指标的达成分别贡献了多大的力量，是否都如运营人员所预期的那样，具有优秀的转化能力；亦或者，存在被低估的情况？在之后的运营中，该如何调整对各运营位资源投入的权重分配？ 对于以上问题，归因分析提供了一种直观的度量 —— **转化贡献度**，可以非常直接地量化每个运营位、每个触点的转化效果和价值贡献。 结合归因分析以及漏斗分析等功能，您可以更加综合、全面地对各运营位的转化能力进行对比分析，通过运营资源配置的调整，实现产品价值最大化，促进产品数据和运营指标的提升。 ## **功能说明** 通过简单的几步设置，您就可以直观地看到，各触点对总体转化指标的贡献情况。 1\) 定义转化目标——目标事件 2\) 定义用户触点——触点事件 3\) 选择归因模型——方舟目前提供五种常见的归因模型供您选择 4\) 定义窗口期——用户完成一次转化的时间期限 5\) 选择查询时间范围——目标事件发生的时间范围
统计范围内，触点事件对总转化指标（如目标事件总次数）的贡献量
转化贡献量=总体转化量\*转化贡献度
| 通过切换“转化目标”，可以查看触点对不同指标的贡献度。
展示用户在网站上所有点击的位置，聚集的点击越多，颜色越亮。
通常用于分析着陆页
1 是否点击了CTA的内容？
2 是否有被大量点击的重要按钮或元素被放到了很少有用户到达的地方？
3 是否有用户点击的图片或文字其实没有链接？e.g.产品特征，icon+文字
| | 点击元素热图 |  |展示可交互元素的点击情况。
用于分析：
1 具体是哪些元素吸引了多少点击？占据了整页点击多少比例？
2 是否有不符合我们预期的失误诱导？
(需 JS SDK > 4.3.1)
| | 浏览深度线 |  |展示用户抵达某个区域的留存比例。百分比越低，越少用户能够看到这一位置。
通常用于
1 寻找CTA的最佳位置
2 内容营销转换监测e.g.数据骤降时，说明哪里出现了内容上的断裂，用户没有兴趣再看下去
| | 注意力热图 |
| 展示用户在某个区域停留的时长，停留的时间越长，该区域颜色越亮
通常用于分析
1 了解到网页哪些内容吸引访客，哪些内容认为重要却被用户忽略？
2 是否有被用户仔细阅读的内容放到了过于靠下的位置？
| 不同类型的热图各有优缺点，比如，点击位置热图，劣势是上报的数据量会增加，但可以非常直观的定性分析用户的探索性需求，发现非交互元素上意料之外的大量点击；点击元素热图，过滤掉了部分不可点击的内容，对可点击元素可以集中定量分析，但就会不够直观。 在不同场景下选择适合的类型，目前方舟已经支持了 Web 端的点击位置热图、点击元素热图、浏览深度线，APP 端的点击位置热图和点击元素热图。 ## Web/H5 热图 支持网站、H5 页面的点击位置热图、点击元素热图和浏览深度线， 支持两种查看方式： * 嵌入式——在方舟产品中查看页面热图，可切换不同的平台 * 交互式——在原网站页面查看 {% content-ref url="/pages/-Ld3bGKKDsABVPbb3iCz" %} [Web/H5 热图](/features/analytics/heatmap/web) {% endcontent-ref %} ## APP 热图 目前支持原生应用的点击位置热图和点击元素热图。 {% content-ref url="/pages/-Ld3bKftoNnEqsx-wRRM" %} [APP 热图](/features/analytics/heatmap/app) {% endcontent-ref %} {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # Web/H5 热图 Web 端支持点击位置热图、点击元素热图和浏览深度线，支持在方舟网站中查看，也支持在网站原页面上查看 {% tabs %} {% tab title="点击位置热图" %}  {% endtab %} {% tab title="点击元素热图" %}  {% endtab %} {% tab title="浏览深度线" %}  {% endtab %} {% endtabs %} ## 使用前准备 使用**点击位置热图、点击元素热图**功能，需要 SDK 升级到 v4.3.0 及以上，设置 `autoHeatmap` 为 `true`，详见 [《JS SDK 集成指南》](/integration/sdk/js/js#autoheatmap) 使用**浏览深度线**功能，需要 SDK 设置 `autoWebstay` 为 `true`，详见 [《JS SDK 集成指南》](/integration/sdk/js/js#autowebstay) ## 1. 页面/页面组热图列表 支持合参页面、原始页面、页面组三种页面的热图，三者的区别： {% tabs %} {% tab title="合参页面热图" %} |合参页面是指去除尾部参数的相同URL的页面
合参页面解决参数不同但实际是同一个页面的问题，系统自动合并，合参前后页面本身不变。
如上举例，在不同的推广渠道带不同的参数，原始页面会不同，但着陆页相同，为了分析用户在着陆页本身的行为时，就需要将不同参数的同一页面进行汇总。
页面组是具有共同结构特征的页面集合
解决参数不同、页面URL不同、但实际是同一个页面结果的问题，需要手动定义。
有很多页面结构本身是相同的，比如商品详情页、新闻资讯页、博客内容页等，只是其中的内容会有差异，如果需要对同一个结构特征的页面进行分析，就可以创建页面组，如何创建详见《页面组管理》。
原始页面是指没有去除尾部参数的页面，保存原来的URL
拿方舟首页举例，正常来说地址应该是
计算当前页为着陆页时的跳出率，结果为 - 时，表示当前页非着陆页。
跳出率=访问了一个页面的Session数/总的 Session 数。用户进入着陆页就离开。用户来到网站后，除了浏览 LandingPage 之外，没有发生其他任何操作就离开了网站，被视为跳出。用来衡量 landingpage 的质量。
设备品牌：Apple
设备型号：iPhone 6s 操作系统：iOS
屏幕分辨率：1920\*1680
运营商：中国联通
网络类型：Wifi ……
| | What | 事件的内容 | 自定义采集的事件：EventID 事件属性：Key-Value | add\_to\_cart product\_name：耳麦 product\_price：666 | **用户属性** 在分析过程中，需要引入注册用户的更多维度，比如注册用户ID、姓名、用户等级等等，也需要进行梳理，方法同事件属性。 埋点方案整理成方舟提供的埋点模版整理即可  整理完埋点方案后点击批量导入，作为后续研发埋点的需求来源和数据处理的规则。以下将以事件方案为例说明在方舟中如何管理埋点方案： ## 管理埋点方案（以事件方案为例） ### 1 管理计划中的事件方案 计划中即表示在数据上报前做好了规划要采集的事件；计划外表示不在埋点方案中，但实际上报了数据的事件和属性。 {% hint style="info" %} 通过可视化埋点部署的埋点自动会被视为计划中的事件 {% endhint %} #### A 添加方案 按照埋点方案模版的格式整理完成后，即可批量导入； 系统预置部分事件及属性，如有需要可以直接使用，如果不需要也可以清空；后续需要使用时，选择导入预置事件/属性即可。  当已上传过埋点方案，后续有新的产品功能迭代需要新增少量埋点时，可以选择单条添加  对于所有事件都有的通用属性不必在埋点方案中每个事件中添加，在通用属性中导入一份即可，方舟默认会采集部分属性（预置的通用属性），详见
表达式是 argo\*ark
则argoark、argooooark都可以匹配
| | ？ | ？前的字符重复出现0次或1次 |表达式是 argo？ark
则只能匹配出argoark、argark
| **定位符，**基于指定位置的匹配，通常在开始或结束的位置 | 符号 | 说明 | 示例 | | -- | -------- | ------------------------------------------------------------------------------- | | ^ | 从开头匹配字符串 |表达式是 ^ark
则 ark.analysys.cn、arkargo 可以匹配，但 docs.ark、argoark 等不匹配
| | $ | 以结尾匹配字符串 |表达式是 ark$
则 doc.ark.cn、argoark 可以匹配，但 ark.analysys.cn、arkargo 等不匹配
| 更多可参考表达式：^
能匹配以下页面：
不能匹配以下页面：
表达式：^(http | https)://(ark | argo | qianfan).analysys.cn
匹配以下页面：
不能匹配以下页面：
表达式：^
匹配以下页面：
表达式：^(http | https)://\[a-z0-9]\*\[.]\*analysys.cn/view/sign/signup$
匹配以下页面：
表达式：^
匹配以下页面：
不能匹配以下页面：
严格：+/=10%
中等：+/-30%
宽松：+/-50%
| 自行设定百分比，绝对值 | | **告警方式** | 站内消息、邮件 | 站内消息、邮件 | | **告警范围** |管理员控制全局开关
个人控制自己的开关
| 指定邮件接收人 | | **告警详情** | 事件分析 | 事件分析 | {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 智能监控 {% hint style="info" %} 方舟版本 V 4.5.0及以上具备此功能。 {% endhint %} ## 运用场景 自定义监控由于需要手动设定，往往只能覆盖小部分指标，但那些未被设定的指标中也常会发生值得关注的异常。 这时，就可以通过智能监控来覆盖更多的事件。智能监控可以对所有启用事件的每天触发次数和触发人数进行监控，并根据相关算法预测出当日事件的触发次数和触发人数，和实际值进行对比后，如果超过阈值范围则会通过站内消息及邮件的方式进行告警。 ## 具体功能 ### 管理智能监控 点击【管理】-【监控告警】-【智能监控】进入智能监控管理界面，可以设定单条监控指标的阈值范围和订阅状态，也可以点击【取消全部订阅】，一键取消所有监控。  | 监控阈值范围 | 预测值范围上下浮动 | | ------ | --------- | | 严格 | +/-10% | | 中等 | +/-30% | | 宽松 | +/-50% | ### 查询告警消息 通过点击触发的告警消息的【查看详情】按钮，可以进入事件分析，在图表中查看具体异常点和预测值区间，并通过细分维度等方式快速找到异常原因，从而采取有效改进措施。  ## FAQ ### 1 该预测的算法是基于什么原理？ 基于常用的天周期粒度，考虑时间序列的周期性和趋势性两个方面，并根据通用行业历史真实数据和预测数据对比，当前算法模型的预测准确率达到80%，具体模型计算方法如下： 预测数据=（工作日过去12期平均值+周平均值）/2 示例如下图:  预测本周二数据，周平均值=本周一至上周二的平均值 工作日过去12期平均值=过去12个星期二的平均 ### 2 预测基于的过去多久的历史数据？ 基于过去12周的历史数据，通过算法模型预测出最终结果。 ### 3 该预测是否根据不同行业有不同的针对性？ 该预测模型基于通用行业数据和预测数据对比，准确率达到80%；也可以根据您所在行业调整每一条监控的阈值范围：严格（预测值的+/-10%），中等（预测值的+/-30%）和宽松（预测值的+/-50%），从而达到您最终的监控要求。 ### 4 会不会把我的数据分享出去？ 针对公有云客户，我们采用行业内通行的、合理的标准来保护我们所储存的信息的安全性和保密性。包括但不限于：防火墙和数据备份措施；数据中心的访问权限限制等。整个服务过程中，我们会签署一份保密协议，付费版有单独的NDA，免费版在使用协议里，对您的数据进行严格保密。 针对私有化部署客户，数据存储在客户本地，更不用担心数据分享的问题。 ### 5 该功能未来有什么规划？ 未来为了让您发现异常点后，更加快捷的找到异常原因，我们也会探索智能下钻相关功能，让智能监控模块使用更加方便。 ### 6 针对管理员和其他非管理员该功能使用有什么差别吗？ 管理员可以最终控制每条监控的开关，即管理员关闭一条监控，所有成员都收不到该条监控的告警。 而其他非管理人员，可以关闭针对其个人的告警消息提醒，但是不能干预其他人的设置。 {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 自定义监控 {% hint style="info" %} 自定义监控告警功能的使用需要相应方舟版本： v4.1.2 及以上 {% endhint %} 在相对稳定的产品中，运营、市场和产品相关人员都会有持续关注的一些关键数据指标，当这些数据指标波动较大，发生异常数据时，需要及时提醒。 因此，方舟推出了“自定义监控”功能，可以对关键、核心的数据指标进行7\*24小时实时监控，当满足预先设置好的阈值后，通过邮件或告警信息等不同响应级别方式第一时间发送通知。 ## 1 创建监控告警  ### **1.1 设置基本信息** * 监控名称：填写监控告警名称（不超过50个字符） * 监控指标：选择你要监控的指标及条件，该指标类型与事件分析中的指标相同。例如选择监控的某一事件触发的用户数以及转化事件等。  ### **1.2 设置告警条件** * 选择期望计算时间：包含每小时、每天、每周一、每月第一天，以及相应计算计算具体时间（精确到10分钟级别），具体可选范围以及相应计算周期如下： | 计算时间 | 可选小时分钟 | 计算粒度 | | ------ | ------ | ---- | | 每小时 | 分钟 | 小时 | | 每天 | 小时:分钟 | 天 | | 每周一 | 小时:分钟 | 周 | | 每月第一天一 | 小时:分钟 | 月 |  * 选择对比方式： | 比较方式 | 和谁比 | 可以比什么 | | ---- | ----- | ----- | | 大于 | 特定值 | 数值 | | 小于 | 特定值 | 数值 | | 增加超过 | 对比周期值 | 数值 | | 增加超过 | 对比周期值 | 百分比 | | 减少超过 | 对比周期值 | 数值 | | 减少超过 | 对比周期值 | 百分比 | 同时针对不同的计算时间粒度，可选择不同的对比周期值 | 计算周期 | 特定值 | 前一小时 | 前一天同一小时 | 前一天 | 上一周同一天 | 上一月同一天 | 上一年同一天 | 上一周 | 上一月同一周 | 上一年同一周 | 上一月 | 上一季同一月 | 上一年同一月 | | ---- | --- | ---- | ------- | --- | ------ | ------ | ------ | --- | ------ | ------ | --- | ------ | ------ | | 小时 | √ | √ | √ | | | | | | | | | | | | 天 | √ | | | √ | √ | √ | √ | | | | | | | | 周 | √ | | | | | | | √ | √ | √ | | | | | 月 | √ | | | | | | | | | | √ | √ | √ | 示例：下图的选择就是让监控告警“每天07:00:00的时候计算所选指标 本期值（前一天的数据）和对比值（大前天的数据），如果本期值-对比值＞100 时就触发告警信息或告警邮件”  ### **1.3 设置告警方式** 默认为触发告警消息，也可以针对需要及时响应的监控告警添加邮件告警方式  ## 2 查询告警消息 通过点击触发的告警消息的【查看详情】按钮，可以进入事件分析，在图表中查看具体异常点，并通过细分维度等方式快速找到异常原因，从而采取有效改进措施。  ## 3 自定义监控管理 在自定义监控告警列表中可以查看、修改、复制、删除创建过的监控。  ## 4 特别说明 * 权限：仅有管理员可以创建、修改、删除监控告警，其他成员仅可以查看。 * 特别情况：如果设置对比方式为百分比，而对比值为0，则不会触发告警，因为该种情况计算结果为无穷大。 * 发送邮件：如果私有化部署客户，没有配置邮箱设置，需先完成配置。 {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 平台管理 {% content-ref url="/pages/-LaQ9KfekeRdsG3h7eLS" %} [企业概览](/features/enterprise-management/overview) {% endcontent-ref %} {% content-ref url="/pages/-LaQ9KfqXa3yEhyIlz6T" %} [项目管理](/features/enterprise-management/project-management) {% endcontent-ref %} {% content-ref url="/pages/-LaQ9KfLDSxOhJx4MD5m" %} [成员管理](/features/enterprise-management/member) {% endcontent-ref %} {% content-ref url="/pages/-Lj0UgFO3qTlPC-jRKoK" %} [安全设置](/features/enterprise-management/an-quan-she-zhi) {% endcontent-ref %} {% content-ref url="/pages/-LrNzA-TCPeOSwCnmtin" %} [企业设置](/features/enterprise-management/enterprise) {% endcontent-ref %} {% content-ref url="/pages/-LaQ9KdcGGH5LBCDM-pW" %} [帐号设置](/features/enterprise-management/accountsetting) {% endcontent-ref %} {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 企业概览 主要展示平台的一些基本信息，平台项目、平台成员、当前计划以及成员访问记录  ## A. 平台项目 显示平台可以创建的项目数量上限，以及已经创建的项目数据和项目名称，也可以点击更多进入项目列表，查看项目的详细信息 点击添加可以直接添加项目名称 ## B. 平台成员 显示平台可以添加成员的数量上限，以及已经添加的成员数量和成员姓名，也可以点击更多进入成员列表，查看成员的详细信息 点击添加可以直接添加成员 ## C. 当前计划 展示当前部署的方舟的版本情况。  {% hint style="warning" %} **Licence 到期后数据接收会停吗？** Licence 到期前 30 天产品里就会出现更新 Licence 的提示，但若超期产品就会无法使用。不过考虑到某些情况下 Licence 更新会滞后，为避免数据不连续，数据接收不会中断。这样，稍后更新 Licence 之后，就可以看到连续的数据了。 {% endhint %} ## D. 访问记录 显示登录用户姓名、以及访问平台的时间和IP。 > 注：访问记录只展示最新100条的记录  {% hint style="info" %} 以上内容没有解答我的问题？[点击我来反馈](https://support.qq.com/products/118522/) 🚀 {% endhint %} # 项目管理 易观方舟支持在企业平台中，创建多个项目，在企业平台-项目管理中可以进行统一管理， 包括查看项目列表、创建项目、修改项目名称和LOGO、添加项目管理员等。  ## A. 创建项目 点击 **创建项目**，输入项目名称，支持自动生成 AppKey（项目回传数据的唯一标识），若有运维查询数据等特殊需要可以手动输入 AppKey。 {% hint style="info" %} 易观方舟支持将同一个应用的多个平台数据接入到一个项目中；建议您在接入正式数据前先创建一个测试环境项目用于测试，避免污染生成数据。 建议自动生成 AppKey，若手动输入时，仅支持小写字母和数字的组合，且在10\~16位之间。 {% endhint %}
商品类别
上报的属性值：
3C电器、服装、化妆品……
3C电器：12人
服装：12人
化妆品：18人
按离散值
自定义区间分组
商品价格
上报的属性：
12、20、90、300……
按离散值：
12：2人
20：3人
90：13人
300：1人
按用户自定义区间的话可能是：
(-∞,50)：5人
\[50,200)：13人
\[200,+∞]：1人
是否使用优惠券
上报的属性值：
true、false
使用了优惠券的：12人
没有使用优惠券的：18人
按分钟、小时、日、周、月、季、年
按时段汇总：按分钟、小时、日、周，月
下单时间
上报的属性值：
2017-03-12 12:12:32、
2018-03-15 12:12:32、
2018-04-12 12:12:32……
不按时段汇总，按月：
2017年3月：23人
2018年3月：27人
2018年4月：12人
按时段汇总，按月：
每年3月：50人
每年4月：12人
用户爱好
上报的属性值：
\[网球，摄影]、\[户外，摄影]、\[户外、壁球]……
\[网球，摄影]：34人
\[户外，摄影]：53人
\[户外、壁球]：23人
事件发生时所在国家，
e.g. 中国、美国
| S | S | S | S | | $province | 省份 | 字符串 |事件发生时所在省份，
e.g. 北京、上海、福建
| S | S | S | S | | $city | 城市 | 字符串 |事件发生时所在城市，
e.g. 北京、厦门
| S | S | S | S | | $utm\_campaign\_id | 活动ID | 字符串 |根据添加的内容自动生成，
标识一次活动
| Y | Y | Y | Y | | $utm\_campaign | 活动/广告名称 | 字符串 | 特定的推广活动，e.g. 双11推广 | Y | Y | Y | Y | | $utm\_medium | 活动/广告媒介 | 字符串 | 推广类型，e.g. SEM，cpc | Y | Y | Y | Y | | $utm\_source | 活动/广告来源 | 字符串 | 推广来源，e.g. 今日头条 | Y | Y | Y | Y | | $utm\_content | 活动/广告内容 | 字符串 | 广告内容，e.g. 优惠信息 | Y | Y | Y | Y | | $utm\_term | 活动/广告关键字 | 字符串 | 广告关键字，e.g. 用户画像 | Y | Y | Y | Y | | $is\_first\_day | 是否安装后首日访问 | 布尔 | 是否安装后首日访问 | Y | Y | Y | Y | | $channel | 下载渠道 | 字符串 | 下载渠道，SDK 初始化时传入。仅 Android 通过渠道包分发时才有意义，iOS 会统一为“App Store” | Y | Y | - | - | | $lib | SDK类型 | 字符串 | SDK类型，e.g. python、iOS等 | Y | Y | Y | Y | | $lib\_version | SDK版本 | 字符串 | SDK版本， e.g. ：11.2.5 | Y | Y | Y | Y | | $session\_id | SessionID | 字符串 | 会话ID，e.g. 515950b8f1a6221c | Y | Y | Y | Y | | $language | 语言 | 字符串 | 系统语言，e.g. zh-cn | Y | Y | Y | Y | | $time\_zone | 用户时区 | 字符串 | 用户时区，e.g.GMT+08:00 | Y | Y | Y | Y | | $user\_agent | UA | 字符串 | UA | - | - | Y | - | | $web\_crawler | 是否是爬虫 | 布尔 | 爬虫识别 | - | - | Y | - | | $is\_time\_calibrated | 是否与服务端时间校准 | 布尔 | 是否与服务端时间校准 | N | N | - | N | | $device\_id | 设备ID | 字符串 | 设备ID，idfa/oaid > idfv/androidid > uuid | N | N | - | - | | xwho | 用户ID | 字符串 | 用户ID | Y | Y | Y | Y | | xwhen | 触发时间 | 日期 | 事件发生的时间 | Y | Y | Y | Y | | distinct\_id | 唯一ID | 字符串 | 系统在 xwho 的基础上根据一些规则生成的唯一 IDS | S | S | S | S | | $importflag | 是否工具导入 | 数值 | 标识是否是工具导入，1为工具导入 | N | N | N | N | | $debug | Debug模式 | 数值 | 标识数据处理方式，0：非debug 1：debug，不入库 2：debug，入库 | Y | Y | Y | Y | {% hint style="info" %} **非自动采集的属性，会根据相应字段自动解析** **$ip ：**方舟的收数服务会自动记录上报的数据来源 IP，根据 IP 解析为国家、省份、城市三个字段 **$county：**通过 IP 解析 **$province：**通过 IP 解析 **$city ：**通过 IP 解析 **$device\_type：**通过 UA 解析 {% endhint %} {% hint style="info" %} **部分自动采集的属性不会作为独立的属性用于分析** **$debug：**用于标识是否入库 * 0：表示关闭 Debug 模式 * 1：表示打开 Debug 模式，但该模式下发送的数据仅用于调试，不计入平台数据统计 * 2：表示打开 Debug 模式，该模式下发送的数据可计入平台数据统计 **$session\_id：**标识一次会话 **$user\_agent：**UA，用于解析设备类型、浏览器、浏览器版本、操作系统、操作系统版本\ \ **$device\_id：系统唯一标识，默认不采集(4.4.5版本新增)** **Andorid 采集规则：**advertising id > android id > uuid，按照先后顺序获取 **iOS 采集规则：**idfa>idfv>uuid，按照先后顺序获取 {% endhint %} ## 预置 Event 事件自身属性 部分预置事件在通用属性之外，还有自身独有的属性 ### 1 基础预置事件 ### **$startup 启动** {% hint style="info" %} 集成基础 SDK 后自动采集 {% endhint %} | 属性ID | 属性显示名称 | 数据类型 | 属性说明 | Android | iOS | JS | 小程序 | | --------------------- | --------- | ---- | --------------------------------------------- | :-----: | :-: | :-: | :-: | | $is\_first\_time | 是否安装后首次访问 | 布尔 | 是否安装后首次访问 | Y | Y | Y | Y | | $is\_from\_background | 是否从后台唤醒 | 布尔 | 是否从后台唤醒恢复 | Y | Y | - | - | | $start\_source | 启动来源 | 字符串 | 标识APP的启动来源，e.g. 通过点击图标启动、点击通知、URL唤醒、3D touch等 | N | N | - | - | | $scene | 场景值 | 字符串 | 标识小程序的场景值，e.g 顶部搜索框的搜索结果页 | - | - | - | Y | | $scene\_type | 场景值类型 | 字符串 | 标识小程序场景值类型 | - | - | - | S | ### **$end 关闭** {% hint style="info" %} **集成基础 SDK 后自动采集** {% endhint %} | 属性ID | 属性显示名称 | 数据类型 | 属性说明 | Android | iOS | JS | 小程序 | | --------- | ------ | ---- | --------------------------- | :-----: | :-: | :-: | :-: | | $duration | 使用时长 | 数值 |从启动到关闭的使用时长
单位：毫秒
Android
自动采集
iOS
自动采集
JS
自动采集
小程序
自动采集
Android
自动采集
iOS
自动采集
JS
自动采集
小程序
自动采集
Android
自动采集
iOS
自动采集
JS
自动采集
小程序
自动采集
Android
自动采集
iOS
自动采集
JS
自动采集
小程序
自动采集
Android
自动采集
iOS
自动采集
JS
自动采集
小程序
自动采集
从启动到关闭的使用时长
单位：毫秒
收数服务会自动记录上报的数据来源 IP，根据 IP 解析为国家、省份、城市三个字段
| | $country | 国家 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $province | 省份 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $city | 城市 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $utm\_campaign\_id | 活动ID | 字符串 |根据添加的内容自动生成，
标识一次活动
| | $utm\_campaign | 活动/广告名称 | 字符串 | 特定的推广活动，e.g. 双11推广 | | $utm\_medium | 活动/广告媒介 | 字符串 | 推广类型，e.g. SEM，cpc | | $utm\_source | 活动/广告来源 | 字符串 | 推广来源，e.g. 今日头条 | | $utm\_content | 活动/广告内容 | 字符串 | 广告内容，e.g. 优惠信息 | | $utm\_term | 活动/广告关键字 | 字符串 | 广告关键字，e.g. 用户画像 | | $is\_first\_day | 是否安装后首日访问 | 布尔 | 是否安装后首日访问 | | $channel | 下载渠道 | 字符串 | 下载渠道，SDK 初始化时传入。仅 Android 通过渠道包分发时才有意义，iOS 会统一为“App Store” | | $lib | SDK类型 | 字符串 | SDK类型，e.g. python、iOS等 | | $lib\_version | SDK版本 | 字符串 | SDK版本， e.g. ：11.2.5 | | $session\_id | SessionID | 字符串 | 会话ID，e.g. 515950b8f1a6221c | | $language | 语言 | 字符串 | 系统语言，e.g. zh-cn | | $time\_zone | 用户时区 | 字符串 | 用户时区，e.g.GMT+08:00 | | $web\_crawler | 是否是爬虫 | 布尔 | 爬虫识别 | | $is\_time\_calibrated | 是否与服务端时间校准 | 布尔 | 是否与服务端时间校准 | | $device\_id | 设备ID | 字符串 | 设备ID，idfa/oaid > idfv/androidid > uuid | | $debug | Debug模式 | 数值 | 标识数据处理方式，0：非debug 1：debug，不入库 2：debug，入库 | ### **预置用户通用属性** | 属性ID | 属性名称 | 属性值数据类型 | 属性说明 | | ----------------------- | ---------- | ------- | ----------------------- | | $original\_id | 匿名ID | 字符串 | 实名绑定前的匿名ID | | $idfv | IDFV | 字符串 | IDFV（iOS独有） | | $idfa | IDFA | 字符串 | IDFA（iOS独有） | | $mac | MAC | 字符串 | MAC（Andorid独有） | | $imei | IMEI | 字符串 | IMEI（Andorid独有） | | $phone | 手机号 | 字符串 | 非自动采集，需要用户上传 | | $email | 邮箱 | 字符串 | 非自动采集，需要用户上传 | | $platform | 最后一次使用平台 | 字符串 | 最后一次使用平台 | | $lib | 最新版本的SDK类型 | 字符串 | SDK类型，e.g. python、iOS等 | | $lib\_version | 最新版本的SDK版本 | 字符串 | SDK版本，e.g. 11.2.5 | | $country | 所在国家 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $province | 所在省份 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $city | 所在城市 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $is\_login | 是否是注册帐号 | 布尔值 | 是否是调用过alias接口 | | $signup\_time | 注册时间 | 日期时间 | 注册时间 | | $first\_visit\_time | 首次访问时间 | 日期时间 | 首次访问时间 | | $first\_visit\_language | 语言 | 字符串 | 设备语言 | | $time\_zone | 首次访问时区 | 字符串 | GMT+08:00 | # JS 预置事件/属性 ### **基础预置事件** | 事件ID | 属性ID | 数据类型 | 事件显示名称 | 事件说明 | | ------------ | --------------------- | ---- | --------- | ----------------------------------------------- | | $startup | | | 启动 | 打开网站 | | | $is\_first\_time | 布尔 | 是否安装后首次访问 | 是否安装后首次访问 | | | $预制属性 | | | 其他预制通用属性 | | $pageview | | | 浏览页面 | 浏览APP/网站页面 | | | $url | 字符串 | 页面URL(含参) | 页面完整路径 | | | $url\_domain | 字符串 | 页面URL（去参） | 去参的页面URL | | | $title | 字符串 | 页面标题 | 页面标题 | | | $referrer | 字符串 | 页面来源 | 页面来源（$referrer 字段在 App 中手动调用 pageview 接口，默认不采集） | | | $referrer\_domain | 字符串 | 页面来源域名 | 页面来源域名 | | | $预制属性 | | | 其他预制通用属性 | | $user\_click | | | 点击元素 | 全埋点自动采集元素点击行为 | | | $title | 字符串 | 页面标题 | 页面标题 | | | $url | 字符串 | 页面URL | 页面URL | | | $url\_path | 字符串 | 页面地址（不含参） | 页面地址（不含参） | | | $element\_path | 字符串 | 元素路径 | APP 为元素唯一标识；JS 为元素路径 | | | $element\_class\_name | 字符串 | 元素样式的类 | 元素样式的类 | | | $element\_target\_url | 字符串 | 元素链接地址 | 元素链接地址 | | | $element\_id | 字符串 | 元素ID | 元素ID | | | $element\_name | 字符串 | 元素名称 | 元素名称 | | | $element\_type | 字符串 | 元素类型 | 元素类型 | | | $element\_position | 字符串 | 列表控件位置 | 列表控件位置 （可选） | | | $element\_content | 字符串 | 元素内容 | 元素的内容优先级：内容>描述>空 | | | $预制属性 | | | 其他预制通用属性 | | $webstay | | | 视区停留 | 停留在可视区域（用于分析网页浏览深度 | | | $url | 字符串 | 页面URL | 页面URL/页面完整路径 | | | $title | 字符串 | 页面标题 | 页面标题 | | | $referrer | 字符串 | 页面来源 | 页面来源 | | | $referrer\_domain | 字符串 | 页面来源域名 | 页面来源域名 | | | $viewport\_width | 字符串 | 视区宽度 | 视区宽度 | | | $viewport\_position | 数值 | 视区距顶部的位置 | 视区距顶部的位置 | | | $viewport\_height | 数值 | 视区高度 | 视区高度 | | | $event\_duration | 数值 | 视区停留时间 | 视区停留时间 | | $web\_click | | | App点击 | Web热图点击事件（用于热图分析） | | | $page\_width | 数值 | 页面宽度 | 热图页面宽度 | | | $page\_height | 数值 | 页面高度 | 热图页面高度 | | | $click\_x | 数值 | 点击X坐标 | 热图点击X坐标 | | | $click\_y | 数值 | 点击Y坐标 | 热图点击Y坐标 | | | $url | 字符串 | 页面URL | 点击热图时页面URL | | | $element\_x | 数值 | 元素X坐标 | 点击元素X坐标 | | | $element\_y | 数值 | 元素Y坐标 | 点击元素Y坐标 | | | $element\_path | 字符串 | 元素路径 | 热图元素路径 | | | $element\_name | 字符串 | 元素名称 | 热图元素名称 | | | $element\_type | 字符串 | 元素类型 | 热图元素类型 | | | $element\_content | 字符串 | 元素内容 | 热图元素的内容 | | | $element\_clickable | 数值 | 是否可以点击元素 | 是否可以点击元素 | | | $element\_target\_url | 字符串 | 元素链接地址 | 元素链接地址 | | | $预制属性 | | | 其他预制通用属性 | | $alias | | | | | | | $original\_id | 字符串 | 匿名ID | 实名绑定前的匿名ID | ### 预置事件通用属性 | 属性ID | 属性显示名称 | 数据类型 | 属性说明 | | --------------------- | ---------- | ---- | ------------------------------------------------------- | | $platform | 平台 | 字符串 | 应用平台，枚举取值：JS/iOS/Android/Wechat | | $manufacturer | 设备制造商 | 字符串 | 制造厂商， e.g. 小米（通过UA解析） | | $brand | 设备品牌 | 字符串 | 设备品牌，e.g. 华为荣耀（通过UA解析） | | $model | 设备型号 | 字符串 | 设备型号，e.g. iPhone8、小米4（通过UA解析） | | $os | 操作系统 | 字符串 | 操作系统，e.g.Window、MacOS（通过UA解析） | | $os\_version | 操作系统版本 | 字符串 | 操作系统版本，e.g.Windows 10（通过UA解析） | | $browser | 浏览器 | 字符串 | 浏览器名称，e.g. Chrome（通过UA解析） | | $browser\_version | 浏览器版本 | 字符串 | 浏览器版本，e.g. Chrome 62.23.23（通过UA解析） | | $screen\_width | 屏幕宽度 | 数值 | 屏幕宽度/屏幕分辨率，e.g. 1920 | | $screen\_height | 屏幕高度 | 数值 | 屏幕高度/屏幕分辨率，e.g. 768 | | $is\_login | 是否是注册用户 | 布尔 | 是否是注册用户 | | $ip | IP | 字符串 |收数服务会自动记录上报的数据来源 IP，根据 IP 解析为国家、省份、城市三个字段
| | $country | 国家 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $province | 省份 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $city | 城市 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $utm\_campaign\_id | 活动ID | 字符串 |根据添加的内容自动生成，
标识一次活动
| | $utm\_campaign | 活动/广告名称 | 字符串 | 特定的推广活动，e.g. 双11推广 | | $utm\_medium | 活动/广告媒介 | 字符串 | 推广类型，e.g. SEM，cpc | | $utm\_source | 活动/广告来源 | 字符串 | 推广来源，e.g. 今日头条 | | $utm\_content | 活动/广告内容 | 字符串 | 广告内容，e.g. 优惠信息 | | $utm\_term | 活动/广告关键字 | 字符串 | 广告关键字，e.g. 用户画像 | | $is\_first\_day | 是否安装后首日访问 | 布尔 | 是否安装后首日访问 | | $lib | SDK类型 | 字符串 | SDK类型，e.g. python、iOS等 | | $lib\_version | SDK版本 | 字符串 | SDK版本， e.g. ：11.2.5 | | $session\_id | SessionID | 字符串 | 会话ID，e.g. 515950b8f1a6221c | | $language | 语言 | 字符串 | 系统语言，e.g. zh-cn | | $time\_zone | 用户时区 | 字符串 | 用户时区，e.g.GMT+08:00 | | $user\_agent | UA | 字符串 | UA | | $web\_crawler | 是否是爬虫 | 布尔 | 爬虫识别 | | $is\_time\_calibrated | 是否与服务端时间校准 | 布尔 | 是否与服务端时间校准 | | $debug | Debug模式 | 数值 | 标识数据处理方式，0：非debug 1：debug，不入库 2：debug，入库 | ### **预置用户通用属性** | 属性ID | 属性名称 | 属性值数据类型 | 属性说明 | | ----------------------- | ---------- | ------- | ----------------------- | | $original\_id | 匿名ID | 字符串 | 实名绑定前的匿名ID | | $phone | 手机号 | 字符串 | 非自动采集，需要用户上传 | | $email | 邮箱 | 字符串 | 非自动采集，需要用户上传 | | $platform | 最后一次使用平台 | 字符串 | 最后一次使用平台 | | $lib | 最新版本的SDK类型 | 字符串 | SDK类型，e.g. python、iOS等 | | $lib\_version | 最新版本的SDK版本 | 字符串 | SDK版本，e.g. 11.2.5 | | $country | 所在国家 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $province | 所在省份 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $city | 所在城市 | 字符串 | 默认根据用户IP解析获取,或用户手动上传覆盖 | | $is\_login | 是否是注册帐号 | 布尔值 | 是否是调用过alias接口 | | $signup\_time | 注册时间 | 日期时间 | 注册时间 | | $first\_visit\_time | 首次访问时间 | 日期时间 | 首次访问时间 | | $first\_visit\_language | 语言 | 字符串 | 设备语言 | | $time\_zone | 首次访问时区 | 字符串 | GMT+08:00 | # 如何准确识别用户 识别用户是一个比较复杂的过程，尤其是对于有帐号体系的产品来说，用户会有多种使用场景，可能会在匿名的情况下访问，也有可能在登录情况下使用，也有可能在同一台设备上登录不同的帐号，也可能同一个帐号在多台设备上登录。 因此，选择合适的用户标识有助于准确标识用户，提高分析的准确性。 ## 1. 标识用户 方舟的事件模型中，数据上报时会有用户这个实体，使用 `xwho` 来进行标识。在登录前匿名阶段，`xwho` 中会记录一个匿名 ID ，登录后则应该调用 `alias` 方法传入 注册 ID。后续在方舟中就可通过这个注册ID来查询用户相关的行为了。 ### 1.1 匿名 ID 匿名 ID 用来在用户主体未登录应用之前标识，当用户打开集成有方舟 SDK 的应用时，SDK 会给其分配一个 `UUID` 来做为匿名 ID 。 当然，方舟也提供了给用户主体设置匿名 ID 的方式，比如可以使用设备 ID ( iOS 的 IDFA/IDFV，Web 的 Cookie 等)。 ### 1.2 注册 ID 通常是业务数据库里的主键或其它唯一标识，注册 ID 是更加精确的用户 ID，但很多应用不会用注册 ID，或者用户使用一些功能时是在未登录的状态下进行的，此时，就不会有注册 ID。 另外，在方舟系统中，我们以为用户主体来进行分析，这个用户主体可能是一个人，一个帐号，也可能是一个家电，一辆汽车。具体以什么做为用户主体，要根据用户实际的业务场景来决定。 ### 1.3 distinct\_id 即使有了 xwho（ 注册 ID / 匿名 ID)，实际使用中也会存在注册用户匿名访问等情况，所以需要一个唯一标识将用户行为贯穿起来，distinct\_id 就是在 xwho 的基础上根据一些规则生成的唯一 ID。 ## 2. 不同场景下选择不同的识别方案 实际接入分析的应用会有多种情况，可以分为两大类： * **无帐号体系**，e.g. Snapseed、日历 * **有帐号体系** ① 强帐号体系，必须登录 e.g. 钉钉、QQ、微信 ② 强帐号体系，存在访客模式，关键转化需登录 e.g. 淘宝、微博、大众点评、招商银行 ③ 弱帐号体系，存在访客模式，不登录不影响核心功能使用 e.g. 高德地图、今日头条、墨迹天气 ### 2.1 无帐号体系 / 弱帐号体系且不分析登录用户的情况 在这种情况下，无需关心注册 ID，使用方舟的客户端 SDK 时，方舟的SDK会自动生成一个 **UUID** 作为匿名 ID，这个 **UUID** 会做为后续行为数据的匿名 ID（xwho），此时系统生成的 distinct\_id 会与匿名 ID 一一对应，计算的用户数也会是 匿名的用户数。 当然，用户也可以通过调用 **identify** 接口来设置匿名 ID，比如使用设备唯一标识。 **identify** 接口格式如下： ```java void identify(Context context, String xwho) ``` ### 2.2 有帐号体系，需要分析注册用户和匿名用户的情况 这种情况下在集成时需要客户在用户进行登录 / 注册 / 完善个人资料等情况下调用 `alias` 接口获得注册 ID，使得匿名 ID 实名化，然后 SDK 就会将数据的 `$is_login` 属性变成 `true`，表示这是一个注册 ID，后续的行为中上报的`xwho`也会有注册ID。 > $is\_login 用于标识是否是注册用户 但是实际会存在单用户多设备、单设备多用户、注册用户匿名访问等情况下，如何把每一条记录精准识别到各个用户上，贯通一个用户在一个设备上注册前后的行为，贯通一个注册用户在不同设备上登录之后的行为是个比较复杂的问题。 针对这种场景易观方舟提供了一种识别方案： 当调用 **alias** 接口之后，会将匿名 ID 和注册 ID 关联，后台算法根据一定的规则生成一个distinct\_id，用于唯一标识用户，被绑定的匿名 ID 和注册 ID 发生的所有行为都会被认为是同一个用户实体发生的，在进行事件、漏斗、留存等用户相关的分析的时候也只会算作一个用户。 ## 3. 原理说明 下面以一个实际的场景来说明用户识别的机制，其中： 发送的 `xwho`：登录前是匿名 ID ，登录后是注册 ID，调用 **alias** 接口时，两个 ID 会同时发送； 是否是注册 ID：当`xwho`为是否为一个注册 ID； 方舟 distinct\_id：方舟内部给该用户分配的唯一标识，是用于计算触发用户数、漏斗、留存等的最终依据，对应自定义查询中 events 表中的 user\_id 及 users 表中的 id 字段。 > 注意：在识别过程中，一个匿名 ID 只能和一个注册 ID 绑定，同样的一个注册 ID 也只能和一个匿名 ID 绑定。 | 行为顺序 | 发送的xwho | 是否是注册 ID | 方舟 distinct\_id | | ---- | --------------- | ----------- | ----------------- | | 1 | X | 否 | 1 | | 2 | xiaozhou -> X | ID 关联(成功) | 1 | | 3 | xiaozhou | 是 | 1 | | 4 | xiaozhou | 是 | 1 | | 5 | dawang -> X | ID 关联(失败) | 2 | | 6 | dawang | 是 | 2 | | 7 | Y | 否 | 3 | | 8 | xiaozhou -> Y | ID 关联(失败) | 1 | | 9 | xiaozhou | 是 | 1 | | 10 | dawang -> Y | ID 关联(失败) | 2 | 详细说明如下： 1. 某用户在小米手机上新安装了 App，匿名产生了一系列操作，SDK 生成的匿名 ID 为 X，对应分配的方舟 distinct\_id 为 1； 2. 该用户进行了注册并登录，其注册 ID 为 xiaozhou，此时，需要调用 SDK 的 `alias` 接口，此时方舟会将匿名 ID X 与 注册 ID xiaozhou 进行成功关联； 3. 该用户在登录之后继续进行了一系列行为； 4. 该用户退出登录并进行了一系列的操作，SDK 不调用任何方法，此时方舟依然使用注册 ID xiaozhou 来标识当前用户； 5. 该用户使用一个已注册但未接入方舟系统的的帐号 dawang 来进行登录，此时方舟将尝试将 X 与 dawang 进行关联，由于 X 已经和 xiaozhou 关联，所以会关联失败，同时会分配一个新的方舟 distinct\_id 为 2； 6. 该用户使用帐号 dawang 进行了一系列行为，这里方舟都使用注册 ID dawang来标识此用户； 7. 该用户更换了一个全新的苹果手机，并进行了一系列操作，由于尚未登录，此时方舟使用全新的匿名 ID Y 来标识此用户，对应分配的方舟 distinct\_id 为 3； 8. 该用户在苹果手机上使用帐号 xiaozhou 进行登录，此时方舟将尝试将匿名 ID Y 与注册 ID xiaozhou进行关联，由于 xiaozhou 已经与 X 关联，因此会关联失败，但是依然会切换到以 xiaozhou 为注册 ID 的用户，其对应的方舟 distinct\_id 依然为 1； 9. 该用户在苹果手机上的后续行为都以注册 ID xiaozhou来标识。 ## 4. 使用前提 正确集成SDK，遵循接口的调用顺序，否则可能会导致部分用户标识异常，影响数据统计的正确性。 在 SDK 初始化完成之后，SDK 会自动生成一个 UUID 作为匿名用户标识，记录在 `xwho` 中，之后 SDK 采集上报的数据中 `$is_login` 属性为 `false`，来表示这是 匿名 ID 。 {% hint style="warning" %} 如果因业务要求需要对SDK生成的UUID进行调整,可以通过调用接口 **`identify`** 进行修改，接口使用方式请查看SDK指南。 {% endhint %} 当用户进行登录 / 注册 / 完善个人资料等会使得用户有 注册 ID 时的操作时，调用 `alias` 接口，上传匿名ID 和注册 ID 的关联关系。 **alias**接口格式如下： ```java //Andorid SDK 示例，其中aliasId为您业务系统的ID void alias(Context context, String aliasId) ``` 当调用**alias**接口之后，接下来事件数据的 `$is_login` 属性都会被自动设置为`true`，表示事件是由一个注册 ID 触发的，后续行为事件中 `xwho` 都会是注册 ID。 在用户退出登录或者注销帐号时，如果想让匿名期间的行为归属到上一个登录用户时，可以不调用任何接口；反之，不想让匿名记录归属到上一个登录用户时，需要调用 **reset** 接口，之后方舟的 SDK 会自动生成一个 UUID 作为用户标识，上传到服务器时，会根据新生成一个distinct\_id： * 当下一个登录用户是首次注册，没被别的设备绑定时，匿名期间的用户就会归属到新用户上； * 当下一个登录用户已经被其他设备绑定过时，匿名期间的用户行为就既不属于上一个用户也不属于下一个用户，只属于新生成的 UUID 这个匿名用户的行为。 **reset**接口格式如下： ```java //Andorid SDK 示例 void reset(Context context) ``` 当调用**reset**接口之后，接下来事件数据的 `$is_login` 属性都会被自动设置为 `false`，表示事件是由一个匿名 ID 触发的。 ## 5. 方案缺点 虽然该方案可以实现跨设备的用户贯通、以及准确的注册漏斗，但仍然存在局限性： 如果一个已注册用户（即已经和某个匿名 ID 关联过了）在一个新设备上进行操作，那么他在这个新设备的登录前行为是无法被准确识别的； 同样的，如果一个已注册的设备（即已经被关联到某个注册 ID了）上再次有新用户进行注册，也无法再次进行关联。 事实上，在比如如下的场景中， 1. 用户 xiaoming 登录后使用了一些功能后退出； 2. 匿名用户 X 访问； 3. 用户 dawang 登录使用 但匿名 X 到底是 xiaoming 还是 dawang ，或者是其他人都有可能，但是目前的方案还不能对全部场景做出准确判断。 {% hint style="info" %} 以上内容没有解答我的问题？[点击我进入方舟论坛去反馈](https://www.analysysdata.com/forum/index) 🚀 {% endhint %} # 如何设计埋点方案 用户行为是由用户一系列的事件组成，包含5个基本要素：何人，何时，何地，通过何种方式，发生了何种行为。 一份完整的埋点方案由事件、事件属性和用户属性三部分组成。 ## 事件 记录用户在使用网站、APP 或小程序的过程中触发的行为。 用户的行为有一部分会在他们使用的过程中自动被采集上来，常见的如：跟访问有关的“页面浏览”，“停留时长”；另外一部分包含具体业务含义的，则需要通过埋点才能得到，例如：“注册”、“登录”、“支付”等等。 ## 事件属性 可以通过属性为事件补充相关的信息，例如：位置，方式和内容。 用户产生行为时就会上报具体的属性值，比如对“购买事件”定义了“支付方式”的属性值，则根据不同的行为可能上报的是微信支付，支付宝支付。 > 小舟在电商平台上花一万元购买了一台联想电脑。这个动作就会产生一个名为“购买”的事件； 而“购买”事件，同时也可以包含：“品牌”，“价格”这两个属性，而“联想”和“一万元”就是属性的具体值了。 | Event要素 | 要素说明 | 采集的数据 | 示例 | | ------- | --------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | Who | 参与事件的用户 | 用户唯一ID | H522a3bd525a2af | | When | 事件发生的时间 | 自动获取 事件当时时间 | 11月11日00:02:03 | | Where | 事件发生的地理位置 | 自动获取 IP、GPS信息 | 114.242.249.113 | | How | 事件发生的方式 | 使用的环境 |设备品牌：Apple
设备型号：iPhone 6s
操作系统：iOS
屏幕分辨率：1920\*1680
运营商：中国联通
网络类型：Wifi
……
自定义采集的事件：EventID
事件属性：Key-Value
add\_to\_cart
product\_name：耳麦
product\_price：666