ID-Mapping在心动公司探索实践

1.背景介绍

心动公司创立于 2003 年，是一家全球游戏开发和发行商，拥有丰富的研发、发行和代理运营经验。截至 2022 年中，心动运营 38 款免费和付费游戏，在全世界拥有 5,000 万月活跃用户，主要分布在大中华地区、东南亚、北美和南美。2016 年，心动推出手机游戏社区和应用商店 TapTap，2022年中，TapTap 在全球拥有超过 5,000 万月活跃用户。

在研发侧，TapTap当前正在持续加强内容建设及版本迭代，提升用户规模与社区黏性。在此过程中，用户ID的精准映射是关键基础能力之一。在用户隐私数据保护的基础上，数据中台团队基于长时间的数据建模和业务经验为数据探索到算法迭代的整个研发周期提供数据能力和工程化能力的双输出。

在手机游戏领域，典型的情况是：同一个玩家在多个游戏发行平台上有多个游戏账号，在其他渠道也有该游戏的账号，这些账号分散在各个游戏或平台本身中，没有进行打通。基础数据建设不完善会带来各种问题。例如客户在做精准营销时不能精准刻画同一个用户，流量在跨渠道使用效率很低，需要idmapping技术助力基础数据建设，帮助客户做精准营销或个性化推荐等。

idmapping可以实现将分散在各处的账号进行映射，同时赋予这个自然人一个id（即oneID），作为这个自然人的唯一id。

2.相关方法

idmapping通常利用的资源是已有的两类信息表，

一类是用户属性信息，如userid、注册邮箱地址等；

另一类是用户行为信息，如用户登录游戏信息、用户在游戏中的交易信息、用户在游戏中的交流信息等等。这类信息中会记录用户userid和移动设备id等。

在一个典型的游戏社区平台中，一般提供两张数据表，一个是平台账号行为表game_platform_info，记录用户登录游戏平台的具体信息，如下表所示：

另一个是游戏账号行为表game_info，记录的是用户登录游戏账号的具体信息，如

我们需要将平台账号game_platform_info.user_id和game_info.user_id按“同一个人”的标准进行idmapping，同时一些设备id，如device_id,oaid,ip等也进行idmapping。

一般idmapping方案分两个步骤：

首先要确定核心账号ID，例如在淘系中通常是淘宝ID和支付宝ID，在这个游戏域是game_platform_info.user_id、game_info.user_id的聚合体，他会对应一个真实意义上的自然人uid；

​然后将无线设备挂靠到核心账号上来，在这里就是device_id、android_id、googleid等挂靠到自然人uid上来。

一种idmapping方案是根据经验，将game_platform_info和game_info直接通过表join的方式，按指定列(如oaid、ip)关联起来，同时遍历所有没有指定列的设备id(device_id、android_id、googleid等)，将能够匹配的设备id关联起来。

这种方式优势在于思路清晰，可解释性强，开发成本低。既然要把id进行关联，那把id完全相同的值关联就可以了。但这个方案也有很多缺点，第一，它是以完全匹配的方式，必须某个id完全相等才能认为是同一id，匹配较“硬”，泛化性不够。第二，对异常数据处理能力较弱，无法进行多源判断。它是以表join的形式关联，即如果这两个表中各自存在一行中的某两个字段相同，那么这两个表的这一行的其他数据就关联到一起了，即使这两个字段可能是因为错误而匹配的，也只能继续错下去。第三，无法利用正确的信息进行优化，如果我们已知一组正确的关系数据，比如知道一组game_platform_info.user_id、game_info.user_id的映射关系，我们无法在表join的框架下利用这些关系优化idmapping的结果。

另一种idmapping方案是基于机器学习模型来完成的。这种通常是在有一些标注数据的前提下，利用这些已有的映射关系，构建特征，判断给定的两个id是否属于同一个人。

游戏中存在一些标注数据：game_platform_info.user_id、game_info.user_id的映射关系。我们可以建立一个分类模型，特征可以选取和user_id关联的列（device_id，oaid，IP等）。当我们给定一个game_platform_info.user_id，利用这个分类模型对game_info.user_id进行打分，高于一定阈值则认为这两个user_id是属于同一id。

基于机器学习的方法的优势是健壮性强，不要求列能强关联，即使两个数据没有强关联信息，只需要构造的样本特征不全为空就能计算出一个合理的值。而且计算的过程中不用一次性做全表扫描，只需要一定量的训练样本就行，需要的计算资源少。同时，我们可以通过设置不同的阈值来调控准确率。

这类方法也有一些缺点：一是可解释性弱，从直观上来看很难判断没有关联关系的game_platform_info.user_id与game_info.user_id为什么是属于一个id，因为都把要判断的数据映射成相关的特征了，是一组由浮点数构成的特征向量，对比两个id的特征向量本身并不能看出异同。二是这类方法必须要有正确的结果作为标注数据，但往往在项目一开始可能并没有正确的结果集合。三是这类方法每次必须指定两列作为基础数据，将其他关联数据作为其特征数据构造特征向量。对于有较多id列的情况下，需要做两两组合进行模型训练预测，开发效率低，实用价值低。

3.我们的方案

无论是基于表join的方法、还是基于机器学习的方法都存在一些问题。我们提出了一种基于机器学习的图模型方案来处理idmapping问题。

我们先看基于图模型的方案如何处理idmapping的。

首先，我们将所有的id值都看成一个顶点，例如game_platform_info的某个device_id(0b887f9e1e915e355)，然后将这些点构成一个图网络。同一行的id类数据每个列两两存在一个边。图中的最大连通子图里的元素可以看成一组idmapping的结果。

如下图所示，通过构造图网络，得到

[game_plaform_info.user_id1,game_plaform_info.user_id2,game_plaform_info.device_id,game_plaform_info.android_id,game_plaform_info.oaid,game_plaform_info.IP,game_info.user_id1,game_info.user_id2,game_info.imei,game_info.idfa,game_info.google_id]这些ID会互相关联。

同时，我们考虑边在这些图中出现的次数和出现的时间戳来计算边的权重。边出现的次数越多，证明两个点关联的越紧密，权重越高；出现的时间越晚，说明是最近的行为，置信度越高，权重越大。

这个图模型相比传统join表，它不用考虑join的列信息，开发成本较低；同时，考虑了多账号之间存在的传递关系，可以发现一些只靠join发现不了的边关系；而且它考虑了权重，我们可以通过设置合理的权重阈值来得到不同准确率/召回率的结果。

但这个基于图模型的方案没有考虑到节点类型本身的因素。比如IP这个特征它的置信度本身是存在一定问题的。很多用户可能会共用一个IP地址，例如在网吧、在宿舍，大家可能会共用一个IP。而且有些IP是和手机的基站相关的，并不能真实反映用户ID信息。

所以我们需要考虑节点类型的权重。然后把节点类型的权重加入到边的权重中来，从而再设置阈值，将置信度较低的边过滤掉。

如上图所示，我们通过构建连通子图后，可以得到game_plaform_info.user_id1,game_plaform_info.user_id2,game_info.user_id1,game_info.user_id2这四个节点会关联到一个id上，但因为IP的权重较低，删除了被IP关联的边。也即是在连通子图中去掉game_info.user_id1这个点。

此时，我们引入机器学习分类模型来学习节点类型权重。

具体流程如下：

首先，我们先利用已有的用户行为表构建图模型，且得到连通子图；

第二，我们利用游戏中存在一些标注数据：game_platform_info.user_id、game_info.user_id的映射关系来设置边的权重信息。我们可以建立一个分类模型，特征可以选取和user_id关联的顶点类型（device_id，oaid，IP等）以及时间戳。特征值是user_id和其他顶点的边的出现次数、距离现在的时间长度归一化的结果。下图是样本示例：

这样我们可以计算出每个节点的权重。

第三，把这些节点权重代入到图模型中校正每个边的权重。

第四，通过调节边权重的阈值来剪枝，在准确率和召回率中达到平衡。

4.效果

我们利用这个方法，在一年的数据(十亿量级数据)上做了实验，构造了一个连通子图用于idmapping，准确率为97.8%。平均每个game_info.user_id有1.09个game_platform_info.user_id，表join的方法是1.01个。每个oneID下有21.8个基础id。表join的方法是5.1个。

同时，我们提供的解决方案还可以根据业务数据不同，人工运营不同顶点类型的权重，比如当我觉得IP这个因素不应该考虑进来，可以将IP类型的权重置0，这样和IP相关的边就不作为构图的边了。

我们还可以根据应用场景的不同，人工运营边的阈值，以满足场景对不同准确率、召回数量的需要。例如，在同人模型中，我们可以提高边的阈值以保障高准确率要求。在用户画像扩展中，我们可以降低边的阈值以提高召回数量。

5.ID-mapping服务

阿里云在PolarDB上推出了ID-mapping的能力，可以通过PolarDB for AI使用ID-mapping的解决方案。用户只需要按要求提供原始的数据表，执行几条SQL命令后即可得到ID-mapping的结果。PolarDB for AI是基于PolarDB的一站式数据库原生机器学习组件，通过扩展SQL支持多种数据智能能力；提供机器学习模型创建，训练，预测及部署等全生命周期的操作及管理服务，提供用户增长，智能搜索，智能推荐，问答机器人等开箱即用的解决方案。

6.未来展望

idmapping是本质是将稀疏的信息通过实体之间的关系汇集起来，是id类数据加工的最重要的基础工作之一。idmapping在企业中常常是用户画像构建的最底层、也是最重要的环节。

我们提供了一些idmapping构建在游戏域的一些思路，idmapping工作可以在基础数据入库后进行，加工后形成新的基础数据。

实际上，游戏域也有很多业务逻辑需要处理，比如底层设备账号如何在数据采集阶段的统一，设备其他属性信息（设备型号、屏幕分辨率、系统版本等）如何加入idmapping体系中进行校验逻辑。由于篇幅有限，就不深入展开了。欢迎大家在评论中留言讨论。

7.附：idmapping其他应用场景

7.1 用户行为增强

idmapping技术可以对数据加工后，可以为上层业务（个性化搜索、精准推荐）提供更优质的数据支撑，提高上层业务的效果。例如利用idmapping技术可以把同属于一个自然人的不同应用id上的用户行为合并，增强数据。比如在电商业务中，可以将本地购物行为数据和电商网站上的行为数据合并，补全用户购物链路，分析用户喜好。

7.2 黑灰产团伙发现

在电商营销域中，常常会遇到“羊毛党”“刷单党”等，他们会拥有多个设备、多个用户id，参与赚取电商佣金、抢优惠券、刷好评等电商活动，极大破坏电商的健康生态，给商户和平台带来极大困扰。通过idmapping技术，可以将不同id关联起来，通过一些运营经验，可以发现账号异常情况，例如会得到同一设备下有超多活跃userid、或者同一userid在一段时间内拥有超多的设备id等。再通过关联好的账号之间一些互动行为来发现更大的团伙。

7.3 用户画像扩展

通过对用户的基础数据或者行为分析，可以得到一些用户画像，比如某人属于男性、某人对某品牌、商品类目有偏好等等。由于用户行为存在的马太效应，有些用户可能在某些域的行为缺失，加上用户基础数据本身的不完善，导致用户画像并不能完全覆盖所有用户。通过idmapping的技术，挖掘id之间的关系，从另一个角度来补充用户画像的信息，完成对用户画像的扩展。例如某id对某商品类目有偏好，他可能属于一个家庭中的一员，和它相关的id可能是另一个家庭成员，他也会对该类目也有偏好。

7.4 营销圈人

在广告域会根据用户的兴趣、设备类型等定点投放广告。例如在某游戏平台上存在有多款游戏，同一个人会拥有不同游戏的账号，也可能在多个设备上都有登录。通过idmapping技术，将同一个人的不同游戏账号、不同设备信息进行互通，这样针对性地对一个人的广告曝光可以跨设备、跨游戏，让用户在玩不同游戏、或者在不同设备登录后都能看到该广告，比仅仅利用用户偏好在单一游戏上投放的效果要更好。

本文转载自公众号：阿里云数据库