本文根据神策数据治理研发负责人王灼洲、神策 SDG 负责人徐缓题为《ID-Mapping 用户打通那些事儿》的演讲整理，主要内容如下：

• 什么是 ID-Mapping

• 全域用户打通面临的挑战

• ID-Mapping 方案演进

• 关于 ID-Mapping 的认知迭代

近些年，神策数据一直在帮助客户落地数据驱动，在此过程中，ID-Mapping 一直是一个非常关键的问题，包括广告行业的 ID 标准化，金融行业的反欺诈风控及个人信息安全、隐私保护、合规等。

今天主要围绕全域用户经营，从数据采集和数据治理两方面，以及我们遇到的挑战出发，以点带面讲一讲我们在 ID-Mapping 上取得的一些进展。

一、什么是 ID-Mapping

在深入讲解 ID-Mapping 之前，我们先讲一下什么是用户 ID。用户 ID 是描述真实世界中用户的数字化标识。在特定的上下文和生命周期中，这些标识通常具有唯一性。

ID-Mapping 要做的就是将同一个用户在各个不同渠道、生态及业务系统中的身份标识串联起来，生成一个统一的用户标识。

如果你觉得这个描述过于抽象，那么我们以神策 2021 数据驱动大会为例。为了呈现一场精彩、圆满的大会，市场部同学在全域、全渠道、全链路都做了全方位的努力。某电商企业产品经理小徐，通过媒体渠道的文章了解到神策 2021 数据驱动大会，他对大会非常感兴趣并主动搜索神策数据的宣传稿件，然后进入神策的官网了解大会详情。此时，我们在小徐知情同意的情况下，可以获取到小徐的 Cookie ID、Android ID、IDFA 以及 IDFV 等一些设备 ID。当小徐报名大会时，需要提交姓名、手机号码、邮箱以及公司的相关信息等。报名结束后，小徐希望在会前对神策的产品做进一步了解，所以，他会主动浏览神策数据官网的帮助文档、关注神策学堂服务号等。通过关注神策学堂服务号这一动作，我们又可以获取到小徐的 Union ID、Open ID 等。

神策 2021 数据驱动大会的宣传渠道覆盖官网、微信、小程序、企业微信等，像小徐一样报名本次大会的用户有近万人，用户旅程是千差万别的，他们在各个触点上的行为也是大不相同的。对于神策数据市场部的同学来说，面临的问题包括：如何判断这些用户中哪些是神策的客户？有多少能够通过此次大会转变成神策的客户？各个宣传环节的转化率如何？联动城市的宣传方面能够做什么样的优化等等。

要想解决这些问题，需要借助 ID-Mapping 的能力。

ID-Mapping 能够通过对各个渠道、生态、业务系统中用户 ID 的关联，将其识别成统一的用户。也就是说，ID-Mapping 要做的工作是通过统一的实体去识别和连接，打破数据孤岛，最终实现数据融通。在《全域用户经营与营销闭环产品体系构建》中，我们已经了解到，全域用户经营是指通过打通线上线下全渠道、全触点、全链路的多主体用户数据，从洞察、拉新、转化和留存等多个层面帮助企业精准触达和营销，以此促进企业与用户的深度沟通，深入进行用户行为分析和业务经营的全过程。ID-Mapping 作为全域用户经营过程中的关键一环，是打通全域用户数据精准触达和实现公域私域联动运营的基础。

二、全域用户打通面临的挑战

ID-Mapping 在独立应用到跨业务系统、单一场景到全域打通过程中，面临挑战不断。

举个例子，在某服装品牌的用户旅程中，用户从社交媒体、电商平台等渠道了解该品牌，产生兴趣之后通过电商平台完成第一次购买，当使用产品过程中感知到产品的价值后，用户会主动完成分享裂变等动作，以及持续复购。

该用户旅程涉及数十个渠道，品牌与用户的触点有成百上千个，会产生各种各样的用户行为和用户标识，而打通这些数据刻画完整的用户旅程并非易事。

同样，我们以用户小徐为例。小徐在电商平台购买了某品牌的子品牌 C 的产品；扫描线下门店的海报二维码，添加了子品牌 A 的企业微信；通过朋友分享的小程序，小徐下单了子品牌 B 的产品；同时，小徐通过同事的朋友圈关注了品牌的微信公众号。通过以上场景，我们可以看到该品牌拥有多个子品牌，每个子品牌有自己不同的营销渠道，覆盖线上线下、公域私域等。

但因为构建渠道的时间不同，各个子品牌的用户 ID 是否打通也并不一致，甚至有可能子品牌 A 和子品牌 B 的会员系统是完全独立的。

总结来说，全域用户打通面临的挑战有两点：

1、全域数据多杂乱。企业数据大多来源于多个业务线，包括自有系统、集团 ERP、CRM 以及第三方电商平台、线下会员体系等。

2、方案复杂难维护。主要表现在：各业务线业务逻辑盘点、跨业务线方案协同、线上线下/公域私域打通、复杂繁琐的 ETL 处理等。

三、ID-Mapping 方案演进

神策数据的初代 ID-Mapping 主要解决的是用户匿名行为和登录以后行为数据前后打通的事情，也就是在 SDK 埋点数据上报以后，通过数据预处理的方式，把用户的设备 ID 和登录后的业务 ID 进行关联，生成一个映射 ID 作为统一标识，来打通用户在登录前后的行为数据。

详细来讲，用户在登录之前会有一个匿名 ID，也可以叫做设备 ID，所有的用户行为都可以通过设备 ID 来进行标识。当用户完成注册并登录后，会遵照《隐私政策》及《用户使用协议的约定》为其分配统一的用户 ID，即登录 ID，此时便可以将设备 ID 与登录 ID 同时上报，在数据处理管线中，负责 ID-Mapping 的模块会依照规则来更新关联关系，获取或者生成映射 ID，通过此 ID 洞察用户在 App 中的所有行为。

针对现阶段的两个问题，我们有两个解决方案：一是全端覆盖的开源 SDK，二是简单直接的关联接口。目前，神策数据已开源的 SDK 覆盖前后端、小程序、游戏、第三方框架等 50+ SDK。

但是，初代 ID-Mapping 解决的是单域内登录前后的行为数据打通，对跨域、多系统场景无能为力。

回到刚才的服装品牌案例中，多个系统有多个业务 ID、多个登录 ID，如果想要打通多个业务系统的数据，是很难仅依靠匿名 ID 和登录 ID 的打通来实现的。对于服装品牌来说，大部分的应用和系统可能都是外包建立的，并且根据不同子品牌的业务诉求分时间建立，因此很难在一开始便完成从上到下的统一 ID 规划；同时，对于微信、支付宝中的用户数据也没有被很好的采集治理；各应用、渠道分别由不同的部门运营，看数的计算口径不统一，对 ID 的定义千差万别，因此亟需一个新的方案来做数据打通。

比如，在微信小程序中，我们可以通过合规途径获取到它的 Open ID 和 Union ID，当用户完成授权后，会被自动分配一个登录 ID 或业务 ID，如果用户同意的话，用户的手机号码也会一并上传给小程序。当用户进入 App 时，通过多端 ID 自动识别匹配，企业可以有效地将小程序和 App 两个场景中的用户 ID 进行关联。

对于第三方电商平台来说，他们通常会通过公用的 ERP 电商系统，对用户做精准 ID 识别，然后通过用户的手机号将多场景中的 ID 进行关联打通。

所以，多域系统打通的本质就是通过各种用户标识，寻找到能够公用的关联 ID，然后提供一个统一 ID 来完成用户行为数据的关联与打通。

进一步详细来讲，用户匿名访问期间，一般使用 Union ID 来记录用户行为，此时还可以获取到对应 Open ID，需要在外部的关系库中，记录 Open ID 和 Union ID 的对应关系；当用户授权手机号后，可以获取/生成该用户的 User ID，先正常关联 User ID 和 Union ID，然后使用 User ID 来记录用户行为。同时，外部逻辑需要根据之前记录的 Open ID 和 Union ID 的对应关系，额外触发 User ID 和 Open ID 的关联，以及 User ID 和手机号的关联，最终保证该用户的所有 ID 都与对应的 User ID 进行关联。

上述逻辑看起来不复杂，但是需要在所有的端都做一遍，在公众号、自建应用中，整体的实施成本非常高，需要维护复杂的 ETL 程序，来进行 ID 之间的关联逻辑处理，代码里大量逻辑判断，成百上千的 if/else、并集差集对比等。

在我们过往服务客户的过程中，遇到过极其复杂的 ID 关联逻辑，这对我们是巨大的挑战，单纯通过简单的 SDK 已经无法满足客户的需求，使用定制化的 ETL 手工程序来做 ID-Mapping 的扩展性和维护性较差，导致打通成本高、交付周期长，后续的交付与迭代也难以开展。

因此，新一代的 ID-Mapping 围绕全域数据接入能力和自动化的关联识别，为解决以上问题而生。

基于平台化的数据接入框架，神策数据提供多种预置数据源的接入，包括文件、数据库等。同时，企业也可以在平台上自定义开发插件，将其部署到生态平台完成接入。

对于新一代的 ID-Mapping 来说，能力本质依旧是有一个或多个共同 ID 能够将多个体系关联起来。这里需要额外关注四个要点：

第一，梳理各系统的用户 ID。比如在微信小程序里，通常是通过 Union ID 来做整体的数据关联，不同的商城里有不同的 Open ID，在不同系统里可以拿到用户授权使用的用户 ID，包括你的自建应用生成的用户 ID 或者手机号等，都可以通过自定义作为 ID-Mapping 的 ID。

第二，微信公众号默认适配，无需额外做数据处理。像 Open ID、Union ID 之间的父子关系等关联关系我们已经做好了，企业只需要拿到授权接入数据即可。

第三，微信小程序、自建应用调用 Bind 接口上报需要关联的 ID。

第四，第三方平台、客户内部系统的数据表可通过统一数据接入平台进行接入，在界面上进行 ID 映射的配置。

在该过程中，神策数据能够帮助企业统一地定义和规范 ID。

关于数据上报，我们以 MySQL 举例，企业可以通过 MySQL 的界面化配置连接数据库，完成同步后通过关联关系的映射，自动化完成用户关联。

综合来说，神策数据的 ID-Mapping 流程首先是一个域关联的流程，包括对 ID 的基本格式检查，ID 跟 ID 之间有无定义冲突等，在真正进行用户关联时，会通过图计算的方式帮助企业完成用户关联。

用户关联之后，不同渠道用户属性的合并也是不容忽视的环节。比如，对于一个保险系统来说，用户在 App 端和微信公众号均会进行个人信息的提交，对于年龄这一属性来说，应该以哪个场景上报的数据为准呢？当前我们默认提供了基于 ID 优先级和上报时间的合并策略，未来我们会提供更丰富的策略以及可配置的能力，比如企业可以自定义某个渠道的数据源为唯一信任的源，只有该渠道上报的值在合并时会被采用。

四、关于 ID-Mapping 的认知迭代

在神策数据 ID-Mapping 方案的迭代过程中，伴随着我们的认知变化，从单一场景到全域经营，数据源在变多，ID 体系在变复杂，因此需要复杂的解决方案。但越是复杂，落地方案越要简单且可持续迭代。

整体来说，神策数据关于 ID-Mapping 的认知与方案的演进历程如下：

1、多端打通，贯穿前后。基于全端 SDK 和一行关联，减少自研 SDK 的成本，并增强用户关联体验。

2、全域用户打通。通过全域数据采集，预置数据源的接入，帮助企业节省开发导入工具的成本，进而实现自动化关联。

3、全场景智能化。结合神策数据目前的平台化战略，未来我们将继续向下沉淀核心功能，向上丰富场景库，满足不同行业、不同运营场景中的 ID-Mapping 需求，帮助企业实现自动化、智能化。

神策数据自成立以来，持续通过技术 + 服务为客户带来价值。在 ID-Mapping 用户打通方面，我们提供全域数据接入平台帮助客户降本增效，借助智能管理引擎帮助客户摆脱维护复杂 ID 关系的困境，始终坚持为客户提供卓越的产品体验；同时通过基于平台插件的定制化服务和行业化的场景库，为客户提供完善的服务支持，进而帮助客户打破数据孤岛，实现数据融通，实现真正意义上的数字化经营。