现状与意义

目前，神策埋点系统中存在大量的匿名埋点，其中 H5 匿名埋点占比 xxx%，APP 匿名埋点占比 xxx%。这些数据无论是在数据洞察还是在数据分析方面，都为进一步探索用户个性化行为带来了极大的局限性。
具体来说，匿名埋点往往以设备 ID 作为最小粒度进行统计，即神策 SDK 会为所有埋点都携带标识当前设备的唯一 ID。然而，由于神策 SDK 在不同语言环境的差异（如 JS、Android、iOS 等），同设备的设备 ID 并不一致，这就导致了无法建立起跨端之间匿名埋点的关联，这是一个巨大的 GAP。
举个例子，目前“下载来源”漏斗中，下载页点击下载–》APP首次打开这个步骤仅仅是基于可关联剪切板信息的埋点进行统计，该人数必定是漏统计的，因为剪切板会因为手机权限、复制信息被覆盖等等因素而失效。
跨端匿名设备匹配的实现可以带来两方面的好处：

• 首先，它能够打破不同语言环境下设备 ID 的不一致性，使得我们可以更全面、更准确地了解用户在不同终端上的行为，从而更好地进行用户画像和行为分析。
• 其次，通过跨端匿名设备匹配，可以实现数据的整合和共享，避免了因为设备 ID 不统一而导致的数据割裂和重复计算，提高了数据的利用效率和分析的准确性。

关键目标

本方案的目标是：

• 对于给定的 H5/APP 设备信息，应能够以高效精准的方式返回最有可能匹配的 APP/H5 设备信息。
  具体而言，需要确保返回结果具备较高的准确率，从而使其具有高度的可信度。这意味着在处理设备信息时，要充分考虑各种因素，如设备型号、操作系统版本、屏幕尺寸、分辨率等，通过精确的算法和数据分析，准确地找到与之匹配的信息。并且，要对返回的结果进行严格的验证和筛选，剔除那些可能存在错误或不准确的匹配，以保证最终提供给用户的是可信且可靠的设备信息。

技术难题

从可行性来看：

匹配任务不仅需要精准地建模出 H5/APP 设备之间的相关性，还需充分考虑工程化实现过程中的各种因素。例如，数据的采集方式是否高效且准确，模型的训练和部署是否能够满足实际的性能需求，以及如何有效地应对可能出现的异常情况和错误。

从易用性来看：

对于下载来源的数据分析，如何将匹配结果有效地运用是一个关键问题。这包括提供便捷的接口和工具，让下游数据分析能够根据自身需求进行灵活的查询和筛选，并进一步校正统计结果。

从稳定性来看：

算法建模需要随着埋点的更新而不断优化迭代，以契合线上数据分布。这意味着要建立一套完善的监控和反馈机制，能够及时发现数据分布的变化，并据此调整模型的参数和结构。同时，还需要进行充分的测试和验证，确保每次迭代后的模型在性能和准确性上都能有所提升，并且不会引入新的问题或风险。在迭代过程中，如何有效地管理和保存历史数据和模型版本，以便进行追溯和比较，也是保证稳定性的重要环节。

方案架构

在初步的方案设备和系统构想中，整个匹配流程实际上与广告推荐系统中正在进行的操作非常相似，具体来说，是将“用户与广告的匹配”转化为了“设备与设备的匹配”。因此，整个方案的设计也与推荐算法工程中常见的做法极为类似。在每一次的排序和过滤过程中，都呈现出一个漏斗状的形态，通过逐步筛选和排除，最终逐渐过滤出最有可能匹配成功的设备信息。下面这张图能够较好地展现出这个方案在数据处理链路上的核心思想（在此处，用户兴趣与设备匹配具有等效性）：

流程示意图如下

整个方案的设计架构

因此，整个方案的设计架构如下图所示。
我们将其设计成了 T+1 的任务模型。在每日任务中，会获取当天的 H5 匿名设备信息和 APP 匿名设备信息进行匹配。
匹配过程严格遵循了召回、粗排、精排的流程，并将匹配结果入库持久化，以保证数据的可追溯性和可用性。
召回阶段
在召回阶段剔除无关设备时，采用了最弱的约束条件。仅仅要求召回至少一个设备信息字段匹配的设备。这种宽松的约束有助于在初始阶段获取尽可能多的潜在匹配设备。
粗排阶段
粗排阶段使用了一个 DSSM 模型来建模双端设备信息的相关性。该模型的设计灵感来源于 Clip 模型在建模图文相关性任务中的有效性。通过利用 DSSM 模型，能够较好地找出低相关性的设备，从而进一步缩小匹配范围，提高后续精排阶段的效率和准确性。
精排阶段
精排阶段需要严格找出 H5 与 APP 设备信息的 1 对 1 精确匹配关系。为了保证约束有效且匹配准确，我们采用了三个模型进行漏斗式的匹配逻辑。以下覆盖指标均为实验数据：

• 规则匹配：通过全量埋点统计出高可信的规则。这些规则经过了充分的验证和优化，确保规则匹配结果是高度准确的，可以覆盖掉 40%的设备匹配。
• 深度模型匹配：对于剩余 60%的设备匹配，我们通过一个 DSSM 模型进行二分类。该模型能够回收高置信度的匹配结果，可以覆盖掉 26%的设备匹配。
• 随机森林匹配：对于剩余 34%的设备匹配，我们使用了由 100 颗树构建的随机森林模型。通过该模型，能够回收高置信度的匹配结果，可以覆盖掉 4%的设备匹配。
  通过这三个模型的协同工作，我们实现了 H5 与 APP 设备信息的精确匹配。
  

详细设计

可建模的设备信息

由于匿名的跨端设备信息难以有效地关联起来以进行设备信息的洞察，在此，我们选取了自 2023 年 6 月 1 日至 2024 年 6 月 26 日期间已有的神策 H5 和 APP 埋点数据（这已经可以算作历史全量数据）。我们获取了可关联上的每个实名用户的双端手机设备信息（倘若存在一个实名用户下有多条不同的设备信息，则选取最新的一条），其总量为 6945 条。其中，能够应用到后续建模的设备信息包括：

• UA 字符串
• IP
• 屏幕宽高（以及宽高比）
• 浏览器、浏览器版本
• 操作系统、操作系统版本
• 品牌、型号（仅 APP 有上报）
  其中，在这些设备对中，有至少一个设备信息字段可以匹配上的占比为：6832/6945=98.3%，即绝大部分的跨端设备信息至少存在一个字段是可以关联上的。由于这是全量数据统计的结果，可以大胆假设，在那些匿名的跨端设备中也存在该现象（统计学上，类似的数据集总是符合“独立同分布”假设）。

---

埋点信息中还存在国家、省份、城市信息，不进行建模的原因：

• 这些信息通常是从 IP 地址解析出来的，但存在准确性和稳定性方面的问题。例如，部分数据显示国家为中国，而省份和城市却都是广东，这显然与实际情况不符，存在较大偏差。
• 从特征工程的角度来看，此类类别类型的数据一般需要进行独热编码。然而，国家、省份、城市的笛卡尔集数量庞大，进行编码后得到的向量会过于稀疏，这对模型的训练和性能产生不利影响。
• 相比之下，IP 地址可以通过特定的编码方式转化为稠密向量，更有利于后续的建模和分析

召回模块

模块介绍

召回模块在整个匹配系统中扮演着至关重要的角色，其主要职责在于初步地缩小候选设备池子的规模，从而显著地降低计算的复杂度。这么做能够带来诸多好处：

• 降低系统负担：通过避免将全量的设备引入下一轮的精排环节，极大地减少了时间和空间的复杂度。这意味着系统能够更高效地运行，处理更多的请求，同时降低了因计算资源不足而导致的延迟和错误的风险。
• 避免脏数据：那些明显与当前待匹配设备毫无关联的样本，如果进入后续的加工流程，将会对整体匹配的准确性和可靠性产生极大的危害。召回模块能够有效地筛选掉这些脏数据，确保进入后续环节的样本都是与当前匹配任务高度相关的，从而提高整个匹配系统的性能和质量。

实现原理

而该模块作为数据链路的第一道，处理的数据量是最大的，因此过滤的逻辑应该是简单直接且有效的。如上所述，有任何字段可以匹配上的占比：6832/6945=98.3%，即绝大部分的设备信息至少存在一个字段是可以关联上的。召回可以做一个最基本的过滤，候选设备池子中，只要任意字段可以和待匹配设备信息的字段匹配上，池子中的设备信息则进行保留。

粗排模块

模块介绍

粗排模块的职责是在召回过滤下的设备池子中，通过隐式建模设备间的相关度，进一步找出可能存在关联的APP/H5设备信息，为后续精排进一步降低计算复杂度。

实现原理

此时，再拿字段进行关联过滤已无必要。这是由于在大量实名样本对中，发现无关的跨端设备对中，也往往存在至少一个字段相匹配。故而，简单的字段过滤仅在召回阶段使用，需要更“智能”的建模方法来挖掘跨端设备对之间存在的规律，这里便采用了“深度学习”的手段。
建模设备之间关联性是一个旨在判别设备对是否匹配的具有挑战性的任务。在这个任务中，无数的设备都有可能组成各种各样的设备对，进而产生数量庞大的标签（例如设备对 1、设备对 2 等等）。然而，如此众多的标签对于模型的学习来说是极为困难的。由于设备对的组合方式繁多且复杂，模型在对未曾见过的设备对进行推理时，往往会表现出泛化性能不佳的现象。这意味着模型在面对新的、未在训练数据中出现过的设备对时，难以准确地判断它们是否匹配。
为了解决这个问题，对比学习的方法被引入并加以考虑。在对比学习中，我们无需过于关注具体设备对之间是否真正成对，而是着重让模型学习到能够有效区分“是/否匹配”的关键特征和模式。对比学习领域中，Clip模型是目前关于“图片-文本”匹配最先进的模型之一（最早GPT中的文生图，或者看图总结也是基于这个模型的）。Clip本质上做的是图片-文本对的学习，学习”是否匹配“这个特征，这和我们的设备对匹配不谋而合。本方案设计的模型也是用了同样的思路，其中用了Clip的对比损失进行训练，在实验初期，发现了比传统的分类模型有了30%的精度提升。
Clip 的原理如下图所示，此图摘自 Clip 论文所绘制。它通过转置矩阵乘的方式来构建图像-文本的相关性矩阵。在这个矩阵中，对角线元素代表正样本对，而其余元素则代表负样本对。
在训练过程中，其目标是期望模型输出的相关性矩阵的对角线元素尽可能地大，其余元素则尽可能地小。也就是说，通过数值的差异来清晰地体现出是否匹配这一特征。
由于相关性矩阵完全是由正样本对的转置矩阵乘方式构建而成的，所以只要随机采样正样本对，在模型训练时就能够构建出海量的相关性矩阵样本。这一特点无疑对模型的泛化能力具有极大的益处。而且，相关性矩阵中负样本对元素占据多数，这使得模型更加注重去关注，到底什么样的才是真正的无相关的设备对，从而能够更准确地进行判断和区分。

粗排模块的具体做法是：

• 首先，运用训练好的粗排模型，对匹配设备和候选设备池子，计算出它们之间的相关性矩阵。
• 接着，由于模型被明确要求学习判断设备之间是否匹配，所以在经过精心选定的一个特定阈值之下，通过上述所计算出的相关性矩阵，能够精准地排除掉那些关联程度较低的设备对。
• 最后，将经过筛选后规模显著降低的候选设备池子输出给精排模块，以便精排模块能够在这个基础上进行更加精细同时计算更复杂的排序工作，从而提供最符合的设备匹配结果。

特征工程

特征工程旨在将各式各样的文本、数值等信息，通过一系列的处理和转换，编码成模型能够进行学习和训练的格式，也就是浮点数矩阵。好的特征工程对于模型精度的提升起着至关重要的作用。

• UA字符串：Tfidf编码
• IP：

# 按照点号（.）进行分割，得到四个数字，正则化除以255
[ip1, ip2, ip3, ip4]

• 屏幕大小

# 三个值都正则化
[height, width, h/w]

• 浏览器+浏览器版本：独热编码
• 操作系统+操作系统版本：独热编码
• 品牌+型号：独热编码

模型架构设计

嵌入层

• 每类特征都编码成[1, hidden_dim]大小的张量
• 进行Concat，组成序列，输入Transformer的编码器
  特征抽取层
• 使用Transformer的编码器，使用多头自注意力对每个特征之间的相关性进行建模，深度挖掘特征
• 输出编码完的稠密特征
  全连接层
• 对H5和APP的稠密特征计算余弦相似度矩阵（具体实现比较复杂，见Clip论文）
• 输出余弦相似度矩阵

精排模块

模块介绍

在整个推荐系统中，召回和粗排模块发挥了重要的作用。它们通过一系列的筛选和过滤操作，显著地降低了候选设备池子的大小。而精排模块则在此基础上，能够运用最为复杂且精细的算法，对剩余的候选设备进行深度分析和评估，从而准确地找出“最可能匹配”的设备信息。

实现原理

为了实现精准找出“最可能匹配”设备这一目标，精排模块被精心设计为三种算法模块的聚合体，旨在从三个独特的视角对设备匹配进行建模：

• 统计视角：策略匹配模块充分利用高置信度字段组合来学习设备匹配的特征。它通过对大量历史数据的统计分析，识别出那些在设备匹配中具有较高确定性的字段组合模式。
• 深度学习视角：深度模型借助随机梯度下降算法深入学习设备匹配的特征。该模型能够自动从复杂的数据中提取隐藏的模式和关系，从而提高匹配的准确性。
• 机器学习视角：随机森林模型通过熵减原理来学习设备匹配的特征。它构建了多个决策树，并通过集成这些决策树的结果来进行预测，具有较强的泛化能力。
  三个模型的推理过程类似于一个有序的漏斗：
• 首先是策略匹配模块，它依据通过统计得出的高置信度字段组合策略，迅速找出一部分匹配上的设备对。
• 接着，对于策略匹配模块未能处理的剩余设备信息，深度模型发挥作用进行推理，再次找出一部分匹配上的设备对。
• 最后，针对深度模型匹配模块未处理的剩余设备信息，随机森林模型出马，找出最后一部分匹配上的设备对。
  通过这样的协同工作和逐步筛选，精排模块能够更全面、准确地找出最可能匹配的设备，提高整体的匹配效果和效率。

策略匹配模块

前期的实验中，察觉到某些特定的设备字段组合的匹配情况一旦命中，那么这对实名设备对必定是匹配的。根据”独立同分布“这个特性，可以大胆假设一下，匿名设备也存在这个特性。为此，这边统计实名设备对中，可关联的字段组合情况（这边只展示出top10的策略），可统计出的策略共有53条。其中，每条策略的分数是依据该策略在样本中出现的频率占比来计算的。
我们使用待匹配设备信息和池子两两配对，用下述所有的策略进行打分，选用特定阈值，获取出满足打分的设备对作为配对上的设备对。其中，这个特定阈值经过实验严格验证，能够保证有着近乎100%的准确率。

策略（字段组合）	数量	分数（占比）
ip, screen_ratio, os, os_version	1821/6945	0.2665
screen_ratio, os, os_version	1252/6945	0.1833
screen_ratio	566/6945	0.0828
ip, screen_ratio	511/6945	0.0748
ip, screen_height, screen_width, screen_ratio, browser, browser_version, os, os_version	457/6945	0.0669
screen_ratio, os	295/6945	0.0432
ip, screen_ratio, os	275/6945	0.0403
ip, screen_height, screen_width, screen_ratio, browser, os, os_version	246/6945	0.036
ip, screen_height, screen_width, screen_ratio, os, os_version	238/6945	0.0348
os, os_version	164/6945	0.024

深度模型匹配模块

策略匹配漏下来的设备，由深度模型进行处理，它是由粗排的 Clip 模型经过改造而得，因此在特征工程方面和上述所描述的完全相同。然而，需要注意的是，该模型不再属于对比学习的范畴，而是一个明确的二分类任务模型，其会强制模型输出具体的匹配情况。除此之外，在模型架构中存在一个十分显著的区别，那就是在特征抽取完成后得到的稠密向量会进行交叉注意力计算，从而实现特征融合（这种方式已经经过验证，被证明是有效的），最终输出匹配结果。
我们通过将待匹配设备信息与池子中的各项数据进行两两配对。在此过程中，深度模型会精确且明确地输出每一对设备匹配的概率数值。我们会依据这些概率数值，选用具有高概率的匹配设备对，并将其作为最终的输出结果。

随机森林匹配模块

随机森林模型用于处理剩余未处理的设备信息，需注意的是，该模型从本质上来说同样是一个二分类模型。与上述模型一样，随机森林模型也需要对设备字段实施特征工程，其具体的实现方式与上述特征工程保持一致。
我们通过将剩余待匹配设备信息与池子中的各项数据进行两两配对，然后由随机森林模型计算并输出匹配概率，选择具有高概率的设备对作为最终的输出结果。

上线现状

• 实验阶段的验证
  • 建模的数据来源：2024.8.1及其之前历史全量实名设备对、下载来源设备对
  • 验证的数据来源：2024.8.2及其之后的下载来源设备对
  • 验证结果：
    • 覆盖率：70%，准确率98%，误判率2-5%
• 线上试跑的验证
  • 当天就匹配上的设备对数量占比：90-95%
  • 精排兜底的设备对数量占比：10-13%
  • ip不相等的设备对数量占比：10-13%
  • 覆盖率（可匹配设备对数/首次打开埋点的APP设备数）：78-83%
  • 使用目前下载来源漏斗的逻辑进行人数矫正：

日期	第一步：进入APP下载页人数	第二步：点击下载APP人数	第三步：首次打开APP人数	第三步：首次打开APP人数（算法校正后）	漏斗人数占比变化：第三步 / 第二步	漏斗人数占比变化（算法校正后）：第三步 / 第二步	提升的占比
20240810	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240811	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240812	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240813	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240814	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240815	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240816	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240817	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx
20240818	xxx	xxx	xxx	xxx	0.xxx	0.xxx	0.xxx