You need to enable JavaScript to run this app.
导航
增长分析（私有化）
  • 文档首页
    • /增长分析（私有化）/数据分析与治理/多应用/多主体/多ID类型分析/使用多ID类型
使用多ID类型
最近更新时间：2024.11.04 16:24:19首次发布时间：2024.11.04 16:24:19
我的收藏

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

注意事项

注意项细分

详细说明

功能开关

该功能为进阶用法，目前主针对业务相对复杂的客户按需开放。

  • 新购Finder的客户：云原生与私有化4.4版本后可自由按需开启，多应用功能默认开启；多主体、多ID类型功能默认关闭。
  • 已购Finder的客户：仅针对使用one_id服务的环境支持开启，如需要历史数据迁移需要人工执行。

绑定关系

  • 一个DataFinder项目支持绑定多个应用。
  • 一个应用仅支持选择绑定一个主体。
  • 一个主体支持被多个应用绑定。
    当一个主体被多个应用绑定后，后续数据分析时支持分析当前主体在多个应用中的行为数据，也可通过应用ID过滤筛选仅分析主体在其中某些应用的行为数据。

注意

由于一个应用仅支持绑定一个主体，因此，如果您需要使用多主体功能对多个主体进行数据分析时，您需要在项目中创建多个应用，每个应用绑定一个主体。

相关的其他产品

使用多主体功能时，您还需同时开通CDP产品。

更多关于多ID类型的功能逻辑介绍请参见多应用/多主体/多ID类型概述。

操作流程

准备工作：调研与规划

您需要先对待分析的业务场景进行调研与规划，规划清楚共有多少业务应用、可能有多少ID类型、彼此间的绑定关系等，输出对应的ID设计方案，后续即可根据ID设计方案进行数据上报与分析。
以下以某银行app上报多用户ID口径为例，为您示例调研与规划的概要流程与要点。
梳理ID数据现状。根据业务系统需求进行调研，收集需要参与上报的用户ID类型，如客户号和手机号，根据业务场景设计ID方案（ID类型，ID之间的优先级关系，以及不同应用场景下上报哪种ID）。

Image

添加多ID类型

开启多ID类型功能后，您需要联系DataFinder技术支持人员根据ID设计方案在后台配置添加需要的ID类型。

说明

DataFinder为您预置了ssid、uer_unique_id、设备id(web_id、device_id、anonymous_id)这五种ID类型，其他ID类型可由技术支持人员后台配置添加。
ID类型当前只能为小写字母，可以由 _ 进行字符间连接。

以银行app为例，新增两种用户id类型： cust_num 和 phone 。

数据上报

上报口径ID与ID类型

开通多ID类型功能后，上报用户标识的ID值时，您需标注清楚上报的ID数据是哪个ID类型。

注意

在上报多口径ID时，请务必确保ID类型已经在后台配置，未配置的ID类型上报后会造成数据在接收端直接丢弃，而不会在用户细查和数据治理的错误信息中展现。
如果在一个有登录状态的应用中涉及到user_unique_id_type的切换, 请务必在新ID类型上报前重新设置user_unique_id和 user_unique_id_type。以免造成ssid的关联/生成错误。

DataFinder各端均支持在涉及多ID口径数据上报时配置ID数据的ID类型，以银行app上报用户id为客户号为例，各端的用户ID配置代码示例如下所示，事件其他代码介绍请参见各端的数据接入文档。

Web

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

更多数据接入SDK介绍请参见Web/JS SDK 集成。

Mp（小程序）

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

更多数据接入SDK介绍请参见小程序SDK埋点与属性。

Android

@param uniqueID 用户id，如无特殊需求，请勿传 空字符串 或者 全是空格的字符串
@param type  用户id类型
AppLog.setUserUniqueID(String uuid, String uuidType)

配置示例：

//第二个参数cust_num为id类型枚举值，同id设计方案
AppLog.setUserUniqueID("12345656788888" ,"cust_num");

更多数据接入SDK介绍请参见Android SDK 集成。

iOS

*! @abstract UserUniqueID发生变化时设置
 @discussion 有值，则设置为ID值；登出 请调用 [BDAutoTrack clearUserUniqueID] 或者传 nil
 @discussion SDK会保存，因此只需要变化的时候设置。
 @param uniqueID 用户id，如无特殊需求，请勿传 空字符串 或者 全是空格的字符串
 @param type  用户id类型
 @return 是否成功设置或登出。
 */
- (BOOL)setCurrentUserUniqueID:(nullable NSString *)uniqueID withType:(nullable NSString *)type;

配置示例：

//第二个参数cust_num为id类型枚举值，同id设计方案
 [[BDAutoTrack sharedTrack] setCurrentUserUniqueID:@"12345656788888" withType:@"cust_num"];

更多数据接入SDK介绍请参见iOS SDK集成。

服务端

在事件上报的user部分，通过增加user_unique_id_type 字段来上报ID类型。
配置示例：

{
    "user": {
        "user_unique_id": "12345656788888",
        "user_unique_id_type": "cust_num"
    },
    "header": {
        //省略
    },
    "events": [
       //省略
    ]
}

更多数据接入SDK介绍请参见Java SDK。

上报ID口径间关联：id bind

通过上述方式实现了基础的口径切换，但在一些场景下，我们可以获取到主体关联的其他ID类型，为保证关联关系的准确性，我们建议通过设置id bind来实时上报口径与口径之间的关系。
id bind的时机：建议ID关系尽可能在上报事件前先绑定好，如通过Http API 通过业务系统里的数据先绑定ID关系。若通过端侧上报，且设置用户登录状态前可以先获取用户需要绑定的ID关系，可以先绑定，在绑定的成功回调函数中进行登录状态(user_uniqe_id)设置（可参考Android示例）。
以银行某app的的id绑定为例，各端的配置要点和示例如下所示：

注意

  • 各端SDK进行ID bind时，均要求已经设置了应用ID(app_id)，相关方法请参见相关数据接入的SDK文档。
  • 服务端绑定时，由于使用事件上报格式，因此需显示配置app_id值和上报时间，具体见下文的服务端示例。
  • ID bind可以一次绑定多种类型的ID和ID值（如手机号、客户号、和其他ID号在一个id bind调用中实现关联），但要求同一种ID类型只能出现一次。

web

js sdk 5.2.0版本以后支持，具体引用方式见SDK接入文档，核心部分代码示例如下。

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

更多数据接入SDK介绍请参见Web/JS SDK 集成。

Mp（小程序）

$$Rangers.bind({
    phone: '1230000000',// key为id类型枚举值，同id设计方案
    cust_num: '12345656788888'// key为id类型枚举值，同id设计方案
}).then((status) => {
    // 业务根据status进行后续处理
});

更多数据接入SDK介绍请参见小程序SDK埋点与属性。

iOS

客户端目前android/ios 在6.14.1 之后版本支持。

@interface BDAutoTrack (OneID)

- (void)bind:(NSDictionary<NSString *,NSString *> *)idmappings
  completion:(void (^)(BOOL success,NSError *error))completion;

@end

示例

NSDicitionary *idMappings = @{
    @"phone":@"1230000000", // 第一个参数phone为id类型枚举值，同id设计方案
    @"cust_num":@"12345656788888" //第一个参数cust_num为id类型枚举值，同id设计方案
}

[BDAutoTrack.sharedTrack bind:idMappings completion:^(BOOL success,
                      NSError *error) {
    if (success) {
        //
    }
            
}];

更多数据接入SDK介绍请参见iOS SDK集成。

Android

客户端目前android/ios 在6.14.1 之后版本支持。

// Bind API
interface IDBindCallback {
    void onSuccess(IDBindResult result);
    void onFail(int code);
}

class IDBindResult {
    String newSsid；
    String failedIdList；
}

// AppLog
void bind(Map<String, String> identities, IDBindCallback callback);

示例

Map<String, String> ids = new HashMap<String, String>
ids.put("phone", "1230000000"); // 第一个参数phone为id类型枚举值，同id设计方案
ids.put("cust_num", "12345656788888"); //第一个参数cust_num为id类型枚举值，同id设计方案
AppLog.bind(ids, new IDBindCallback() {
    void onSuccess(IDBindResult result) {
        // 请求成功并设置登录状态
        AppLog.setUserUniqueID("12345656788888" ,"cust_num");
    }
    void onFail(int code) {
        // 绑定请求失败
    }
});

更多数据接入SDK介绍请参见Android SDK 集成。

服务端

服务端ID绑定通过上报特殊的事件完成：

  • 事件名："__id_bind" 固定值
  • user_unique_id固定为__rangers。
  • 在params中增加需要绑定的id，key为id_code，value为id的值

示例：

{
    "user": {
        "user_unique_id": "__rangers" // 固定格式和值
    },
    "header": {
        "app_id": "1000****" //必传
    },
    "events": [
        {
            "event": "__id_bind", // 固定格式和值
            "local_time_ms": 1668755974348, //当前的时间戳
            "params": {
                "phone": "1230000000",// key为id类型枚举值，同id设计方案
                "cust_num": "12345656788888", // key为id类型枚举值，同id设计方案
            }
        }
    ]
}

更多数据接入SDK介绍请参见Java SDK。

数据分析

开启配置多ID类型功能后，后续您在进行事件分析时，上报的同一个自然人的不同类型的ID数据均会经由DataFinder的ID-MAPPING计算关联至同一个ssid，尽可能准确、真实的通过ssid去标识一个自然人，以提高数据的准确性、可靠性。
在用户细查板块中，既可以通过生成的ssid进行跨ID类型的同一个用户的事件查询，也可以通过切换ID类型（可以选择到ID方案配置的ID类型），通过上报的业务ID查询仅通过该ID上报的埋点事件。
Image