多主体的主要作用？ #

• 实际业务分析过程需明确进行分析的核心对象或焦点，通常“主体”是指使用产品或服务的用户。但是某些场景下也可能需要分析多个主体，例如汽车行业，需以消费者、汽车、商家等不同视角去进行数据分析，此场景下您即可开通使用DataFinder的多主体功能。
• 开通多主体功能后，数据上报时您需标注清楚上报的是哪个主体的数据。DataFinder通过在数据接入初始化时设置上报的应用ID（appid），以appid标识上报的应用信息，通过应用与主体间的绑定关系即可标识上报的数据是哪个主体的数据。
• 开启配置多主体功能后，后续您在进行数据分析时，支持在分析工具中切换分析的主体，切换后即可分析某个主体关联的所有应用数据，也支持在细分筛选中，通过应用ID过滤筛选，仅分析某一些应用的主体数据。

一个自定义埋点会属于两个主体吗？ #

开通多主体功能后，上报埋点数据时需指明上报的应用ID（appid），通过应用来关联上报的数据是哪个主体的数据，由于一个应用只能绑定一个主体，因此：

• 如果自定义埋点上报时指定了某个应用，则上报的数据属于应用关联的主体。
• 如果您在埋点数据上报一段时间后，修改了上报的应用ID，且修改后应用关联的主体也与之前的主体不一致，则修改后埋点数据会上报到另外一个主体中。但不会存在一个埋点数据同时上报到两个主体中。

DataFinder上用户数据的统计口径是什么？ #

DataFinder默认的统计口径为用户，DataFinder使用ssid来唯一标识用户，并使用ssid来统计用户的行为数据。您也可以自行修改统计口径为其他的统计口径。

• ssid介绍请参见：用户标识（uid、ssid、did）
• 创建并使用其他统计口径的操作指导：统计口径

某个用户在 web 和 app 上分别登录了账号a，那么 ssid 应该是同一个吧？ #

是的，一个uuid对应一个ssid。

UV的统计口径是什么？ #

• 使用DataFinder默认的用户（ssid）作为统计口径时，UV指ssid去重后的数据。
• 如果您创建并使用了其他自定义统计口径，UV指自定义统计口径属性去重后的取值，不再是常规以用户为口径的用户UV值。创建并使用其他统计口径的操作指导：统计口径

如使用自定义统计口径，需要怎么做？ #

如果您希望使用自定义统计口径，需要先看下后续使用的分析工具是否支持切换使用自定义统计口径，需要确保使用自定义统计口径的属性数据能正常上报，然后去DataFinder的控制台创建并使用，相关详情请参见：统计口径。

通过H5公众号点击活动页跳转到小程序，能否识别为一个ssid？ #

H5和小程序是两端产品，生成的设备标识不同，所以匿名访问ssid是不同的。如果想做用户标识的统一，可以做到打通登录后的行为，即两端上报同样的实名uuid。匿名情况下无法打通两端。

多ID类型的应用场景？ #

通常在进行用户行为数据分析时，我们用以标识用户的标识ID可能有多种，例如手机号、应用账户号、用户设备ID等，DataFinder为您预置了常用的用户标识ID类型，也支持您新增更多ID类型，并为您提供ID-MAPPING计算能力，将多类ID进行MAPPING计算，通过ssid来尽量还原一个真实的自然人，提高数据的准确性、可靠性。

多ID类型的ID标识逻辑？ #

使用多ID类型时，即user_unique_id的类型为n个，因此在mapping生成ssid时，会使用n type（user_unique_id）与ssid进行mapping，示意图如下。

您可以参考示例2：全局关联标识，以一个具体的示例了解当开启多ID类型后，ssid的mapping生成逻辑，更多关于用户标识id的介绍请参见用户标识（uid、ssid、did）。

多ID类型的数据接入注意事项？ #

• 您需要联系DataFinder技术支持人员根据ID设计方案在后台配置添加需要的ID类型，ID类型当前只能为小写字母，可以由 _ 进行字符间连接。

• 上报口径ID与ID类型：上报用户标识的ID值时，您需标注清楚上报的ID数据是哪个ID类型，以web端为例：

  window.collectEvent('config', {
   user_unique_id: '12345656788888' // 业务id的实际值
   user_unique_id_type: 'cust_num' // 用户id类型.同id设计方案
  })
  

• 上报ID口径间关联：id bind。在一些场景下，我们可以获取到主体关联的其他ID类型，为保证关联关系的准确性，我们建议通过设置id bind来实时上报口径与口径之间的关系，id bind的时机：建议ID关系尽可能在上报事件前先绑定好，ID bind可以一次绑定多种类型的ID和ID值（如手机号、客户号、和其他ID号在一个id bind调用中实现关联），但要求同一种ID类型只能出现一次。以web端为例：

  window.collectEvent('bindToken', {
     phone: '1230000000' // key为id类型枚举值，同id设计方案
     cust_num: '12345656788888' // key为id类型枚举值，同id设计方案
  }, (result) => {
    // 根据返回成功失败做相应操作
  })
  

更多关于多ID类型场景下的数据接入、数据分析等操作指导请参见使用多ID类型。

用户实名后，ssid变了，用户在匿名到实名过程中，服务端生成了新的ssid，而不是使用原来的ssid。 #

这个问题可能是由于在客户端实名之前，服务端上报了用户的profile，然后生成了一个新的uuidssid。解决这个问题的方法是，在客户端实名之后，服务端再上报。同时，需要注意的是，用户的实名顺序应该是匿名 > 实名 > 用户属性 > 实名行为。

用户在不同浏览器上进行匿名和实名操作时，如何确保这些数据被记录到同一个SSID？ #

在SaaS-云原生环境中：

1. 现有产品逻辑：A浏览器上的匿名和实名事件会被记录到同一个SSID，同时实名状态也会被记录到同一个SSID。但B浏览器上的匿名状态大概率不会被记录到同一个SSID。
2. SaaS-云原生暂无多设备修复功能，因此设备2的匿名态数据会被归属到SSID，其他数据在SSID1上。目前暂无其他标准方案能实现多设备修复。
3. 对于同一用户在不同浏览器上进行匿名和实名操作，可以使用用匿名ID来统计数据，因为匿名ID不会上报web_id，因此不存在优先级问题。
4. web_id的组成和与cookie的关系：用户登入登出不会影响web_id值，清空cookie不会影响web_id值，但清空浏览器localStorage会改变web_id值。
5. web_id的生成逻辑：web_id永远是自增的，不管参数是什么，只要重新请求就会生成新的web_id。更换浏览器、变更域名、变更appid或清空缓存都会重新请求web_id。

同一浏览器同一接口中有多个user_unique_id是什么原因？ #

1. 检查是否在同一个浏览器中登录了多个账号，如果是，尝试关闭异步操作。
2. 如果使用了devtool，关闭devtool，因为devtool会内置一个上报地址用于统计其使用状况。
   3.确认是否存在多个sdk实例，并检查webid是否一致。
3. 如果问题依然存在，建议检查框架是否有问题。

设备标识生成逻辑 #

1. web_id: 请求参数为：app_id，当前URL，URL的referer，当前浏览器的useragent，以及user_unique_id(一般为空值)，主要依赖的是appid和当前所处环境请求会在服务端生成一个唯一的webid返回;
2. device_id：
   • ios的优先级是idfv>idfa
   • Android 是Androidid>google_aid>oaid+device_brand
     再根据相关优先级进行匹配，如果匹配不到会根据后台的算法生成一个新的did,并且device_id是在SDK初始化的时候就生成了，是早于事件上报的时间的；
     device_id的生成只跟设备信息有关，跟APP(app_id)无关。如果不同APP实际采集到的设备信息一致，那么理论上device_id也是一样的。
3. ssid：根据获取到的device_id，和请求中的user_unique_id和user_unique_id_type请求ssid服务相关接口获取ssid

微信小程序webid获取规则 #

a、在没有使用自定义web_id时，SDK会去数据流接口获取web_id，并缓存到storage，在之后重复使用；
b、如果开启了自定义web_id的话，需要客户自己手动设置web_id（需要数字类型的值），或者通过使用setWebIDviaUnionID方法设置unionid来生成web_id，或者通过使用setWebIDviaOpenID方法设置openid来生成web_id，这种情况下都是由业务自己控制；
另：webID的生成规则和H5是一样的，具体规则如下：
在sdk初始化，即调用init方法时，会向服务器发起webid的请求，请求参数为：app_id，当前URL，URL的referer，当前浏览器的useragent，以及user_unique_id(一般为空值)，请求会在服务端生成一个唯一的webid返回，同时会返回ssid。（说明：小程序侧这边的url、referer这些值都是空值）。

小游戏中的device_model在什么情况下会变化，web_id是如何生成的？ #

小游戏的device_model和web_id的生成逻辑是通过系统API获取的。如果device_model发生变化，可能是由于使用了模拟器。模拟器可能会影响device_model的值。此外，如果只是更换了设备型号但没有重新创建模拟器，device_model也可能发生变化。建议使用真实的Android设备进行测试。

用于识别新老用户的属性有哪些？ #

新老用户（user_is_new）是如何定义的？ #

根据用户事件首次上报时间是否在查询时间段内，来判断这段事件内该用户是否为新用户。
例如：查询时间范围是2020年1月1日至2020年1月3日，日期粒度是天级，某用户首次激活时间是2020年1月1日18点27分，则该用户在当前查询条件下算作2020年1月1日的新用户。

新增预置事件属性 $is_first_day （是否首日访问）后，关于新老用户（user_is_new）的一些问题 #

1. 如何在分析中区分新老用户？
   新增预置事件属性 $is_first_day后，我们在进行分析时，需要通过选择“是否首日访问”来进行区分新老用户，事件属性为$is_first_day=true为新用户，$is_first_day=false为老用户；
   以事件分析为例说明如下：
   想要分析做过页面访问行为的新用户情况，需要通过过滤条件进行“是否首日访问”选择，选择“首日”为新用户；同理，选择“非首日”为老用户，；
   
   同时，启用按事件属性分组展示，选择“是否首日访问”后，即可按照新老用户进行分组；
   
2. 已经有“新老用户”这个属性进行新老用户的区分，为什么需要新增$is_first_day这个属性来区分新老用户？计算逻辑有什么变化？
   $is_first_day的计算逻辑和新老用户的计算逻辑完全一样，只是新老用户的计算会受到时间粒度的影响，而$is_first_day只按天进行计算：
   • 在“新老用户”的判断逻辑中：
     新用户判断逻辑是目标事件和用户首个事件发生在同一个周期内，否则就判定为老用户。这样会导致一些问题。比如：一个用户在30天的周期内看是新用户（比如1号发生了首事件，5号发生了目标事件，算新用户），但是在1天的周期内看就是老用户了。
   • 在“是否首日访问”的判断逻辑中：
     新用户判断逻辑是目标事件和用户首个事件发生在同一天内，而不是同一周期内。当首次发生了某个事件时，DataFinder会记录一个激活时间属性：first_event_time，后续其他事件的事件发生时间如果等于first_event_time，那$is_first_day=true；否则为false。
3. “新老用户”这个属性会继续保留吗？
   考虑历史数据的问题，这个属性平台会进行一定时间的保留。

是否首日访问$is_first_day 和是否新用户 user_is_new 有什么区别？ #

是否首日访问是事件属性依据事件，不会变化，是否新用户和查询时间范围有关系，详细验证可以查看 是否首日访问和是否新用户的使用差异。

is_first_time的计算逻辑是什么？ #

is_first_time构建的前提：需要在params里上报$is_first_time(注意要加美元符号)；
app端的launch、predefine_pageview、小程序端的app_launch这三种事件不需要客户自定义上报$is_first_time即可构建（saas暂不支持app端的launch，后续会支持）
上报侧逻辑：
按照(ssid,event,is_first_time)来在本地上记录某个事件是否是第一次产生，如果该事件已发生过，$is_first_time直接设置为"false"，否则设置为"true"（注意是字符串不是布尔值）
接收侧逻辑：
（1）接收的事件如果$is_first_time为"false"，不作任何处理；
（2）接收的事件如果$is_first_time为"true"，则会将【该用户该事件】【首次】上报的客户端时间(local_time_ms)记录下来，只设置一次，记录下来的时间戳会与后续上报的【该用户该事件】的客户端时间做比较，如果相等，则保留$is_first_time="true"，否则修正为"false"

应用首次安装上报的用户数据里面有老用户数据是什么原因？ #

安装首装的判断是按照应用判断的，首日访问是整个项目的判定，如果一个项目包含了多个应用，如果其中一个应用第一天激活，另一个应用第二天激活，那么后面那个激活是首装，是否首日访问是非首日。

事件分析新用户一段时间的合计值与按天统计的值的总和有差异是什么原因？ #

1，如果指标计算是计算总次数，细分筛选是新用户，那么一段时间的合计值的含义大概可以总结为：这段时间属于新用户的所有事件总量。
2，按天的计算值的含义是：当天属于新用户的上报事件量。
3，合计值和按天计算的总和是有数据差异的。差值主要是：新用户在非注册日期的事件量

当前支持哪些时长数据（duration）属性？ #

• APP端：Android/iOS/Harmony

  事件	事件属性	属性描述
  app_terminate	duration	duration属性为本次打开应用的会话时长，基于设备位于前台的时长求和统计。 单位：秒(s)。
  $crash	$session_duration	$session_duration属性，为本次 Session 持续时间，Session 的意思是单次会话，每次 launch 后会有一个 Session 对应。 单位：毫秒（ms）。
  时长事件（DurationEvent）	$event_duration	$event_duration属性为事件发生的时长，例如采集视频播放时长事件时上报的视频播放时长数据。通过事件开始、事件结束的的时间戳来进行统计计算。 单位：毫秒（ms）。
  全埋点事件	$page_duration	$page_duration属性为页面时长属性。 单位：毫秒（ms）。

• Web

  事件	事件属性	属性描述
  predefine_page_alive	duration	duration属性是活跃时长，简单的说就是用户在实际使用的时长。 单位：毫秒（ms）。
  predefine_page_close	duration	duration属性是活跃时长，简单的说就是用户在实际使用的时长。 单位：毫秒（ms）。
  	total_duration	total_duration属性用户访问页面，从开始到关闭的整个时长，包含了非活跃状态下的时长（用户切换了页面没有在实际使用的时长）。 单位：毫秒（ms）。
  全埋点事件	refer_page_duration_ms	refer_page_duration_ms属性为来源页面访问时长，取值与duration属性的取值一致。 单位：毫秒（ms）。

• 小程序

  事件	事件属性	属性描述
  app_terminate	session_duration	session_duration属性为session时长，在app_launch时记录一个时间，然后在app_terminate时计算出时间差。 单位：秒(s)。
  predefine_page_hide	duration	duration属性是活跃时长，简单的说就是用户在实际使用的时长。 单位：毫秒（ms）。

web端上报的页面停留时长「total_duration」属性和「duration」属性有什么区别？ #

区别说明如下：

• duration：是活跃时长，简单的说就是用户在实际使用的时长;
• total_duration：是页面打开到关闭的总时长，包含了非活跃状态下的时长（用户切换了页面没有在实际使用的时长）。比如最小化、后台等，切换页面会被理解为“离开页面”这时候会上报一次close事件。

APP端的时长「duration」数据是根据什么计算的？为什么数据库记录的时长与DataFinder计算结果有差异？ #

时长是通过session ID来计算的。

• 对于Android设备，terminate事件duration计算逻辑为：
  terminate.time = last_page.time + duration，terminate.duration = 当前session里面所有的page.duration总和。
• 对于iOS设备，duration的计算逻辑为：(terminate-launch)/1000。

Android设备的page.duration是系统自动计算的，而iOS设备的duration需要手动开启。
计算逻辑不同因为android terminate上报逻辑有差异，一般都会补报而非实时上报。

predefine_pageview、predefine_page_close、predefine_page_alive、predefine_pageview_hide这几个事件的触发时机分别是什么？ #

predefine_pageview：页面打开，sdk初始化完成的时候发送；
predefine_page_alive ：开启停留时长，每隔1分钟发送一次，切换页面发送一次，关闭页面发送一次；
predefine_page_close ：开启停留时长，记录用户每次【进入页面，切换状态，离开页面】的时间戳，然后在离开或者关闭页面的时候上报predefine_page_close事件；
predefine_pageview_hide：这个是小程序特有事件，会在每个页面离开时上报这个pv_hide事件。

应用退出（app_terminate）事件上报逻辑 #

• iOS：是在用户切后台后（包括锁屏），立刻算作Session结束，会产生一个Terminate事件
• Android：是当用户在后台停留30s后（（包括锁屏）），然后在下一次打开监听到超过30s才会生成terminate

app_terminate事件是在移动端进行补充上报的事件，每次离开页面都会产生bav2b_page事件，下次打开APP时会根据bav2b_page事件来判断是否补上报app_terminate事件，并且明确app_terminate事件的产生时间。如果程序崩溃没有采集bav2b_page事件则无法补上报app_terminate事件。

app_channel 属性的取值逻辑 #

• 小程序SDK预定义位置留有这个字段，但是小程序SDK本身不设置这个字段值，您可以自行跟进业务情况进行设置；
  • iOS和Android可以在初始化的时候设置channel，如“XiaoMi、HuaWei、Baidu”等渠道。iOS如果不设置，一般默认"App Store"渠道。
• 如果没有上报app_channel值，SaaS-非云原生会为您自动构建取值为unknown；SaaS-云原生环境不会构建，因此目前SaaS-云原生的筛选条件下不会显示渠道为null的数据。

app_name 属性是否支持自定义 #

app_name字段是在创建应用时设置的应用名和App Name；
应用名称可以在应用列表中修改，但是app_name设置后不支持修改。

app_platform 的取值逻辑？为什么在属性管理页面搜不到这个属性？ #

app_platform属性并非真实采集上报而来的属性，是DataFinder根据您采集上报的数据推导计算而来的，因此在属性管理页面搜不到这个属性。

app_platform 和 platform 这两个属性有什么区别？ #

• app_platform：应用的端，比如客户的应用有app端，有web端，有小程序端
• platform：平台，这个字段是区分不同端的字段，字段值有ios、android、mp（小程序）、web、wap（H5）

整体来说，platform分的更细。

app_launch 和 app_terminate 的上报时机是什么？ #

app_Launch：当用户启动App或者进入前台的时候，AppLog内部会产生一个Launch事件；
app_terminate：iOS是在用户切后台后（包括锁屏），立刻算作Session结束，会产生一个Terminate事件；而Android是当用户在后台停留30s后（（包括锁屏）），然后在下一次打开监听到超过30s才会生成terminate。

app_launch 事件是从后台启动触发的，此场景下app_launch事件会入库吗？ #

SaaS-非云原生（含海外BytePlus环境）会过滤掉后台启动的app_launch事件，但是SaaS-云原生没有过滤掉，因此SaaS-云原生场景下会入库。是否是从后台启动触发通过上报的is_background属性来识别。

network_type属性值里面的mobile 是什么含义呢？ #

mobile：移动网络连接
取值逻辑：是移动网络连接的兜底，比如我们无法识别是3G，4G，5G就返回mobile（移动网络连接）

network_carrier 数据生成逻辑？为什么有时候获取不到？ #

• network_carrier 是SDK通过系统接口获取的carrier属性，然后数据流将其清洗为 network_carrier 属性。如果为空（或空字符串）则说明获取不到，多发生在 Android 设备上。
• 从 iOS 16起，官方 API 已经把运营商获取的API废弃，不再支持获取。所以 IOS SDK 目前不支持 network_carrier 事件公共属性的获取。

小程序sdk mp_platform字段数字（0、1、2、……）对应的值分别是什么意思？ #

0 微信小程序
1 支付宝小程序
2 头条小程序
3 快应用
4 小游戏
5 百度小程序
6 QQ小程序
7 uniapp小程序

client_ip属性的取值支持使用自定义取值来覆盖吗？ #

client_ip属性是DataFinder的预置属性，由DataFinder服务端基于已采集到的数据自动计算生成的，您可以通过在集成SDK时直接上报client_ip的取值来进行覆盖，例如，通过服务端SDK上报时，可在header中直接上传IP来覆盖client_ip字段。

如何覆盖自动生成的client_ip字段取值？ #

您可以通过在集成SDK时直接上报client_ip的取值来进行覆盖，例如，通过服务端SDK上报时，可在header中直接上传IP来覆盖client_ip字段。

origin_ab_version 与 ab_version 的属性数据计算逻辑？ #

客户端上报的数据有什么去重机制？ #

客户端上报的事件生成一个key,同时在服务器有一个缓存区,大概可以缓存10w的数据量,缓存区缓存的数据实时更新。数据流在同一缓存区进行判断key一样的数据进行去重,多的数据丢弃。但是这种场景重复数据不在同一个缓存区的话就不会去重了,一般就现象是erver_time间隔的比较久