在进行用户行为分析时,通常我们需要先明确分析的对象(即主体),查询、分析其在某个应用中的的行为数据,DataFinder为您提供了多应用、多主体、多ID类型的分析能力,支持您在DataFinder项目中创建多个应用、多个主体,并支持为主体设置多个标识ID类型,提高分析的灵活性,本文为您介绍DataFinder的多应用、多主体、多ID类型的分析能力概述。
注意事项
注意项细分 | 详细说明 |
---|
功能开关 | 该功能为进阶用法,目前主针对业务相对复杂的客户按需开放。 - 新购Finder的客户:云原生与私有化4.4版本后可自由按需开启,多应用功能默认开启;多主体、多ID类型功能默认关闭。
- 已购Finder的客户:仅针对使用one_id服务的环境支持开启,如需要历史数据迁移需要人工执行。
|
绑定关系 | - 一个DataFinder项目支持绑定多个应用。
- 一个应用仅支持选择绑定一个主体。
- 一个主体支持被多个应用绑定。
当一个主体被多个应用绑定后,后续数据分析时支持分析当前主体在多个应用中的行为数据,也可通过应用ID过滤筛选仅分析主体在其中某些应用的行为数据。
注意 由于一个应用仅支持绑定一个主体,因此,如果您需要使用多主体功能对多个主体进行数据分析时,您需要在项目中创建多个应用,每个应用绑定一个主体。 |
相关的其他产品 | 使用多主体功能时,您还需同时开通CDP产品。 |
基本概念
术语 | 概念说明 |
---|
应用 | 数据的基本载体,可以直接对应一个APP、网页、小程序等。 |
主体 | 数据分析的对象,例如:用户、消费者、商家、车等,用于描述事件属于谁,即是谁触发的行为。 |
ID类型 | 对于分析对象的标识,例如:一个自然人可以通过身份证号精准标识,但此类精准标识过于敏感,一般需要通过设备ID、邮箱、手机号、注册账号等ID近似定义一个用户。 |
应用场景
功能概述 | 应用场景示例 |
---|
多应用 | - 针对同时运营多个触点/应用的企业,在DataFinder单应用层级只能看到单端的数据,对用户分析的视角相对孤立割裂。
- 开通多应用/多主体/多ID类型功能后,可在单一项目中汇集多个应用,实现多应用之间的汇总统计,明确真实的用户资产,分析用户跨触点全生命周期的用户旅程。
- 通常埋点规划时,各端沿用同一套埋点设计,但在DataFinder单应用视角需要分别独立维护元数据,引入了较多额外的工作和出错的风险。开通此能力后,同一项目下的应用将共享埋点方案,从而可以更优雅的实现数据管理。
| - 在抖音业务体系下,产设研需要知道抖音本体与抖音极速版之间用户重合度如何,行为模式上是否一致,从而判断某功能是否需要做差异化设计和实现。
- 某DTC品牌线上维护了多个触点,在认知、兴趣、首购等不同阶段的用户需要借由不同触点设计内容和活动进行触达,用户旅程愈发复杂,营销人员需要通过跨触点的归因能力准确衡量营销效果,从而确认后续的营销动作和预算分配。
- 某新势力车企发力智能化,通过OTA能力上新了APP与车机大屏联动的功能,团队希望可以了解该能力是否实现了预期的联动效果,驾驶员操作是否存在断点,从而确认后续的迭代方向。
|
多主体与多ID类型 | 从数据模型的角度来讲,DataFinder目前默认统一通过“用户”模型定义分析对象,ID体系也相对单一。针对较为复杂的业务体系,仅通过一个用户主体往往不足以描述目前的业务状态,甚至出现错误。 | - 电商等平台类APP中,用户往往需要区分商家和消费者两种身份,每一身份下有独立的ID标识,此前虽然可以通过历史的分析主体切换功能实现使用不同ID去重统计用户数,但如果存在一个用户同时是商家又是消费者,描述该用户的属性(如:信用等级)会基于最新的值覆盖,业务分析时就会出现消费者的信用等级用于描述商家的错误情况。
- 某银行存在零售、对公和对内员工等各位业务支持系统,各业务服务的主体之间存在不同的口径ID,但其值有可能一致,如仍使用一套ID口径会导致主体之间错误关联。例如,某员工和某对公业务的操作员的工号都是1号,如不区分主体和口径,将默认两类主体的行为都是一个“用户”触发的。
|
功能逻辑
开通DataFinder的多应用/多主体/多ID类型功能后,每个项目中可创建多个应用,并支持设置多个分析主体和分析的口径ID类型,经过多应用的数据融合多口径下的ID-MAPPING计算,我们可以最大程度还原出一个消费者或一个自然人,从而串联起不同主体在多个应用中的行为。
其中:
- 开通多应用/多主体/多ID类型功能后,后续数据上报时您需标注清楚上报的是哪个应用/主体的数据(通过标明上报数据的appid)、数据的口径ID类型是哪种(标明user_unique_id_type)。
- 在一些场景下,我们可以获取到主体关联的其他ID类型,为保证关联关系的准确性,数据上报时,建议您使用DataFinder提供的id_bind能力,实时上报口径与口径之间的绑定关系,通过多口径下的ID-MAPPING计算,将上报的device信息、user信息进行mapping,最终通过DataFinder提供的ssid来尽可能准确的还原一个消费者或自然人。
例如,客户在登录状态下可以获取到手机号phone_id,在绑卡之后可以获取到卡号card_id,并且在绑卡时能够获取到phone_id和card_id的关系。假设有个用户在登录状态下获取到了phone_id1,phone_id1绑定到了ssid1上,那么所有以phone_id1进行上报的事件,都会归属于ssid1,假设在绑卡之后可以获取到card_id1,如果直接以card_id1来进行上报,由于id服务未收到任何与card_id1的关系,那么会新生成一个ssid2,用card_id1来进行上报的事件,都会归属到ssid2上。使用卡号前后的行为无法进行关联,这显然不符合预期。
因此,服务端以及客户端都提供了id_bind的方式,提前将绑定关系上报。
在使用card_id1进行上报之前,就应该调用id_bind,把phone_id1和card_id1进行绑定,card_id1也会绑定到ssid1上,之后用card_id1来进行上报的事件,都会归属到ssid1上,使用卡号前后的行为就可以进行精准关联。
功能使用
此功能为进阶功能,您需按需申请开启,开启后的使用详情可参见对应操作指导文档:
常见问题
Q1:主体和item(业务对象)有什么区别?
Finder默认的主体是用户,引入item业务对象主要解决的场景是在用户操作了某个物品时,对这个物品本身进行属性的扩充,主体本身没有发生变化,依旧是“人”。
而对于多主体,最常见的场景是区分“人”与“非人”的场景,例如:人、车,以人为主体分析行为,以车为主体分析车的行为。采用不同的主体核心原因是分析主体的ID体系不一样,就像车有车牌号、人没有车牌号;人有身份证号,但是车没有身份证号;从功能通用性上来说,我们也支持判定“司机”和“乘客”、“医生”和“患者”等作为不同的分析主体,因为他们的ID体系不一样,虽然他们都是“人”。
Q2:DataFinder原先的分析主体功能和这个多主体功能有什么区别?
除数据模型层面的概念外,新的主体在分析场景下主要用于快速找到与主体关联的所有应用数据,而原分析主体则仅用于确认分析时用哪一属性为标准去重计算对应的主体数。为避免产生歧义,我们已将原有的“分析主体”更名为“统计口径”。
视频解读