You need to enable JavaScript to run this app.
导航
使用多ID类型
最近更新时间:2024.12.03 18:49:05首次发布时间:2024.10.31 19:39:52

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

注意事项

注意项细分

详细说明

环境限制

仅SaaS-云原生环境、私有化环境支持,SaaS-非云原生环境不支持。

功能开关

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

  • 新购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;使用HTTP API进行上报时的配置方式类似,详情请参见HTTP API

上报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