02  撞库

为了实现连接与打通这些消费者数据，数据中的ID至关重要，这个ID必须是广告主和媒体共同利用的ID类型。比如，广告主和媒体双方都用手机号码识别用户，或者都用设备ID（deviceID）识别用户。

现在，另一个至关重要的问题需要解决，那就是我打了双引号并且加粗了的“交给”二字。

广告主是如何将自己的一方数据连同ID一起“交给”媒体的呢？

过去，媒体提供给广告主一个上传数据的操作界面，广告主把自己的一方消费者数据，上传给媒体就可以了。

最开始，这些一方消费者数据的上传，是明文的。

但这么做，广告主风险巨大，媒体也渐渐不想接受这些明文数据。因为媒体若接受了这些数据，它也要承担法律责任，而广告主随意上传明文消费者数据且不说会泄露消费者个人信息，它自己的商业机密也被泄露了。

所以，媒体之后，都要求广告主上传经过加密的消费者数据（MD5或者SHA256加密）。

MD5或者SHA256，都是不可逆的加密。也就是说，不可能通过加密之后的密文还原为原文。加密了之后如果把原文完全毁掉并且忘掉了，想要找回原文是不可能的。当然，不能通过密文还原为原文，不代表不能用别的方法还原为原文——这一点极为重要，也是我们后面隐私计算能够实现的基础之一。

假如，我用SHA256加密了一段文字：“我爱公众号宋星的数字观”，变成了密文

“43d24306cf8a96d5b47f33114bdc66ef0c32cd26b639a4f71f5dfe13c65bce43”。然后我忽然得了失忆症，忘掉了原文是什么，而且我也没有任何记录记下我的原文是什么。现在我手上只有这段完全看不懂什么意思的密文。

按道理讲，我永远也不可能再知道这段密文对应的明文是什么了。

但天无绝人之路。正巧我的朋友，他也曾经加密了很多文字，其中也包括“我爱公众号宋星的数字观”这十一个字。

并且，他没有丢掉他的原文和加密密文的对应记录。

我于是去找他，希望搞清楚我的密文“43d24306cf8a96d5b47f33114bdc66ef0c32cd26b639a4f71f5dfe13c65bce43”背后到底是什么原文。

他把这个密文跟他所有的密文做一个vlookup的匹配，或者干脆来个Ctrl+F，直接就找到了他那边的同样的密文，然后对照着他的原文和密文对照表，他轻松找到了“我爱公众号宋星的数字观”。

我想你一定已经理解了背后的原因，就是这种SHA256等不可逆加密的背后，是不需要密钥的，而且任何人，只要他加密的原文是一样的，那么得到的密文也就一模一样。无论是用户ID，还是一段话，只要是相同的，那么SHA256之后的密文，不会有区别。因此，广告主把自己的消费者的电话号码一一用SHA256加密，然后拿着密文上传给媒体，只要媒体那边也有这些消费者的电话号码，那么就能够同样把这些电话号码用SHA256加密之后，进行匹配。

虽然是用加密的密文进行匹配，但是用原文密文的对照表一对照，也就知道了明文是什么。

这种方法，有一个学名，叫“隐私集合求交”，也被俗称为“安全求交”。但，实际上，“安全”二字很勉强，它本质上就是行业中常说的“撞库”的方法。

你会说，这样加密还有什么意义，只要保留着加密的明文和密文之间的对应关系，那么什么不可逆加密之类的，都照样会被破解。广告主就算把消费者的ID都加密了，上传给媒体，媒体照样还是很有可能把这些密文对应的ID给找回来。

并不是没有意义。上面这些不可逆加密的方法，确实不妨碍媒体还原广告主上传的消费者ID。但数据传输的中间过程中，例如需要由第三方经手的时候，数据万一发生泄露，消费者ID明文被暴漏的风险大大降低了。

比如，我是广告主，我找一个agency帮我上传相关的数据给媒体。在明文操作的情况下，agency可以拿到这些消费者ID，并且agency的员工有可能获得这些ID，这是很不安全的。但是，如果加密了，就算agency拿到了这些密文，也不会有大量的手机号码和对应的密文的对照表，风险也会更小。

讲到这里，跟隐私计算还没有什么关系。下面，隐私计算要出场了。

03 隐私计算为什么是必须的

在上面的场景中，有些广告主介意自己的消费者ID上传给媒体，哪怕是加密了，这些广告主仍然觉得自己的消费者ID会通过撞库被媒体掌握。比如，奥迪说，我可不愿意把我的消费者ID上传给媒体，要是上传给了媒体，媒体就知道这些ID背后，是我的消费人群，媒体就可能转手把我的这些ID用于给其他车厂进行营销所用，比如给宝马或者特斯拉投广告，就直接投放给这些ID。隐私计算可以解决这个问题，即广告主ID保密情况下的ID匹配与数据应用。这种基于各方共有ID并在匹配ID（撞库）之后进行的相关计算，被称为“纵向联邦学习”。

另一些广告主，则有更高的要求，他们说，我的这些消费者，不仅仅只有ID，还有很多ID背后的属性，这些数据，能不能跟媒体或者第三方的数据结合起来，用于更好地洞察消费者？或者结合起来更好地圈选消费者？不过，这些属性不能透露给媒体或者第三方，也就是说，要在不给媒体或者第三方提供数据的情况下实现基于一方、二方（或三方数据）相结合的人群洞察和圈选。

这也是隐私计算可以解决的问题，即在不共享消费者属性数据的情况下，实现对属性数据的应用。

这些应用对于实现一些重要的数字营销场景至关重要，毕竟，数据如果不能够连通起来，数据的价值就大打折扣，数据在数字营销上的作用就得不到充分发挥。可以这么说，今天的数字营销，如果没有隐私计算的帮助，很多高级的玩法都无法实现。

我们先看看“广告主ID保密情况下的ID匹配与数据应用”问题如何通过隐私计算加以解决。

04 在ID保密情况下的ID求交与数据应用

前面说了，ID保密是广告主在意的，他们不希望自己消费者的ID被媒体知道，以免媒体把自己的ID也用于自己竞争对手的推广。但自己的ID总是要跟媒体的ID做匹配的，一旦匹配了，那岂不是自己的这些ID，媒体就完全知道了。

上图：交集ID可以不泄露吗？

因此，必须解决这个问题。

利用差分隐私实现匿踪安全求交

这个问题的解决，要靠加入一些“混淆ID”。所谓“混淆ID”，也叫“随机噪声”，就是广告主在跟媒体匹配的时候，额外随机添加很多其他与广告主消费者不相关的ID。这样，媒体就不知道广告主真正的消费者到底是哪些了。比如，A是广告主，自己的消费者手机号码有5000个，想要跟媒体B进行ID匹配。但为了不把这些ID暴露给媒体，于是又掺杂了45000个其他的手机号码。这样，凑齐了5万个手机号码，跟媒体匹配。

媒体，当然也就不知道这5万个手机号码中到底哪些是广告主的消费者了。广告主的ID就此实现了保密！

这种利用“掺混淆数据”保护秘密（隐私）的方法，被称为“差分隐私”。差分隐私有很多方法，这里讲的只是一种最容易理解的方法。其他各种掺入混淆数据的方法，要基于各种各样的算法，以保证混淆的效果，这里就不多介绍了。

加入了差分隐私的ID匹配，也被称为“匿踪安全求交”。

上图：基于“混淆差分”的安全求交

讲到这里，你肯定会一头雾水了。按照这样的匹配方法，广告主的数据岂不是也被污染了？比如，广告主要找跟自己已有的这5千消费者相近似的人群，结果，媒体按照的却是“掺水”的5万个人群去寻找近似人群。广告主虽然保住了秘密，但是营销效果却南辕北辙了！你的担忧不是多余的，这绝对是非常重大的问题。为了解决这个问题，需要再引入一些新的东西。这个新的东西，是媒体和广告主中间的一个可信第三方。

可信第三方

还是回到前面这个例子，A是广告主，B是媒体，那么这个可信第三方就是C。C的职责很重要。广告主（A）要把自己的5000个手机号码加密发给第三方（C），然后C帮忙再掺入45000个起混淆作用的手机号码。

然后C帮助A，跟媒体（B）进行数据匹配。匹配完成后，B将自己的数据结果（个体级别的用户属性数据），以加密的形式发给C。

C针对B发回的加密属性，把混淆ID的加密属性去掉（剥离），然后计算广告主5000个手机号码中能匹配到的那些人的加密属性，并且归纳出这些人的共性特征。这些共性特征，不再带有个人属性，而是统计级别的数据，所以不再涉及到广告主A的消费者的ID。并且这些共性特征是由媒体B发来的加密属性计算出来的，因此，也是加密状态。

第三方C再把这些共性特征返回给媒体B，媒体把这些加密状态的共性特征解密，之后寻找与这些共性特征相同或者相近的人群，帮助广告主进行广告投放。

上图：加入可信第三方的匿踪安全求交

同态加密

你肯定又有问题了，为什么C计算的是媒体B发来的加密的个体属性。加密之后，还能计算吗？答案是，能。因为隐私计算有另外一个技术，叫“同态加密”。所谓同态加密，就是计算原文（明文）的结果，和计算这些明文加密之后的密文的结果，是完全一样的。如果原文用了某个算法和秘钥进行了加密，那么加密之后，做“加减乘除”以及各种各样的数学计算之后得到的结果，再利用该加密算法和秘钥解密之后，得到的结果，和直接用明文做同样的数学计算得到的结果一样。这样，C在计算媒体B发来的加密个体属性，得到的共同属性特征，虽然也是加密的，但是在B那里做一个解密就可以直接应用于圈选人群了。甚至，今天的技术，连解密都不需要，就可以直接圈选人群了，这样安全性进一步提高。

这样，广告主A没有暴露自己真正的消费者ID；媒体B也没有透露自己这些ID背后的属性；第三方C，帮助A和B完成了数据匹配，也计算出A消费者的共性特征，却也不知道这些特征具体是什么。只要C信守诚信，不泄露A交给他的加密的消费者ID，那么整个过程，就是相当安全的。

这就是隐私计算在数字营销上的一个非常典型且重要的应用。

05 对交集ID进行保密的进一步优化

基于可信硬件技术的安全屋

上面的“匿踪安全求交”需要加入很多“噪声”，同时对第三方的计算能力的要求很高。而且，还要确保第三方是诚实可信的。因此，在实践中，采用这种方法并不多。大部分时候，广告主和媒体都怕麻烦，媒体会直接在自己的服务器内辟出一个所谓的“安全屋”，然后让这个安全屋扮演上面第三方C的角色，发挥安全求交或是逆踪求交的作用。这是目前最常见的实现方式，但谈不上小标题所说的优化，只能算是简化。这种简化，多多少少有点“自欺欺人”的味道。

当然，这种方法也不能说一无是处，媒体会强调，广告主的数据会在“可信硬件技术”之下被隔离保护起来，对广告主数据的操作，也是在这些硬件内进行的，并不会被泄露到这些硬件之外。

可信硬件技术，也在行业中被俗称为“数据安全岛”。

可信硬件技术主要解决下面的问题：

1. 数据独立（data separation）：存储在某个分区中的数据不能被其他的分区读取或篡改。也就是说，广告主用于安全求交的ID，是不会被放到除可信硬件之外的地方的。

2. 时间隔离(temporal separation)：公共资源区域中的数据不会泄露任意分区中的数据信息。计算资源，例如CPU，也有专门隔离的时间切片，来处理可信硬件中的数据。

3. 信息流控制（Control of information flow）：

除非有特殊的授权，否则各个分区之间不能进行通信。

4. 故障隔离（Fault isolation）：一个分区中的安全性漏洞不能传播到其他分区。

如果媒体严格采用可信硬件技术及管理，确实能够确保广告主提供的ID不被挪作他用。当然了，媒体是不是都能严格自律，我们可以看他们获得的执行标准的认证，比如《信息安全技术 可信执行环境服务规范》认证之类。不过认证这东西也不能100%全信，具体哪个媒体合格，哪个媒体不合格，就不在本文讨论的范围了。

全匿名下的安全求交（尚无定论）

上面的方法，对那些“较真”的广告主而言，可能是不可接受的。有些广告主，一定要求自己上传的ID不能被媒体知晓，那怕是加密后，并且媒体保证只用这些ID做撞库也不行。因此，他们迫切需要知道，是否有比“匿踪安全求交”更优化的方法解决这个问题。目前，隐私计算的技术解决方案提供商可能已经找到了解法。这个解法，颇有些“釜底抽薪”的味道。简单讲，任何求交的过程，都必然会导致交集ID被求交的双方共同掌握（安全求交），或是被第三方掌握（匿踪安全求交）。那么，如果能够不做求交，就实现跟求交一样的效果，把广告主ID和媒体ID匹配的用户的属性直接计算出来，就不存在广告主的消费者ID被媒体知晓的情况了。

在2022年的一个新闻稿中，某个数据科技公司提到，他们的技术能够：“无需安全求交、不泄露交集ID、在全匿名数据集下进行联邦学习的技术难题，真正符合《数据安全法》和《个人信息保护法》的要求，进一步加强了用户数据安全和隐私保护。”

真的可以吗？我的客户和我见过的媒体都还没有采用，所以，我暂时还不能给出肯定的回答。但看到这个消息，至少让我觉得这个方向是有可能的。

06 ID求交（撞库）和可信硬件环境下的数字营销应用场景

广告主的消费者ID和媒体的用户的ID打通，本质上就是广告主私域用户的ID，和媒体的公域人群的ID的打通。一旦打通，很多数字营销的应用就变得可能。

应用一：Retargeting

Retargeting：广告主把那些在自己的私域中留下了各种行为和痕迹，但却没有实现最终转化的人的ID收集起来，然后把这些ID跟媒体的ID做安全求交，之后在媒体上给这些人投放定向广告。比如，某次大促，广告主A花了一个亿，引流到自己的私域小程序上，并获得了1000万个OpenID。然后，这1000万个OpenID中，有100万个发生了购买行为，剩下900万个没有购买。于是，广告主A又找腾讯，把这900万OpenID跟腾讯广告做安全求交，随之对这900万人进行定向的朋友圈广告投放。

应用二：Look-alike

跟Retargeting其实本质没有什么区别，只是多了一个步骤，即look-alike的步骤。还是上面那个例子，广告主A觉得对900万个没有购买的投放一次广告，人数有点少。于是就找腾讯广告说，我跟你安全求交后，请你帮我找到跟这100万购买人群类似的更多的人。于是腾讯广告基于这100万购买人群的共性特征，帮助广告主A找到了3000万个跟这100万人类似的人。随之对这3900万（3000万look-alike的人，加上900万retargeting的人）人进行广告投放。

应用三：基于一方、二方数据的联合人群圈选

这个是一个非常有意思的应用，是目前比较高端的应用。媒体可能只对部分大型广告主开放该功能。具体实现如下：广告主将自己的消费者ID，以及每个ID对应的属性标签，在加密后，上传到媒体提供的可信硬件环境中。

媒体与这些ID进行安全求交。

求交之后，能够匹配到的ID，媒体也把这些ID对应的媒体端所拥有的属性数据，上传到该硬件环境中。

此时，这个硬件环境中，也就是数据安全岛中，就集合了交集ID，以及每个ID所对应的广告主的一方属性标签，和媒体的二方属性标签。

媒体基于这些ID和属性标签，以及基于这个可信硬件环境，为广告主提供一个圈选人群的界面。广告主在这个界面中，根据自己的需求，基于一方、二方的属性标签，进行人群圈选。

比如，广告主A，跟媒体通过安全求交，匹配了1000万人。这1000万人，广告主自己的标签是过去一年内的购物数据和私域内的互动行为数据。而媒体端，则是这1000万人的社会属性和兴趣爱好数据。

基于联合人群圈选的解决方案，广告主A可以选择，在过去3个月内购买了某类商品，且兴趣爱好是旅游的一线城市的20-30岁的女生。

圈选之后，媒体基于圈选结果得到的ID，进行广告投放，或是按照广告主A的要求做其他营销触达。

或者，广告主也可以先基于自己的一方数据标签，圈选出人群，然后再看这些人群的二方属性是什么。从而更好地洞察自有消费者。

比如，广告主A基于自己的一方数据，圈选出3个月内购买某类商品的人群，然后再在这个界面上要求媒体对这些做画像。媒体会提供这些人的二方属性的统计报告。

应用四：数据下发

所谓数据下发，是指媒体基于ID求交之后，将个体级别的数据传输给媒体。最典型的，就是“会员通”。广告主将自己的会员ID加密后，上传给电商平台提供的“会员通”服务指定的可信硬件环境中（例如，阿里的聚石塔、京东的云鼎），ID在这里进行求交。求交之后能匹配上的ID的会员相关的数据，会传输给广告主。

应用五：Leads打分或决策判断

指在ID求交之后，第二方或者第三方为广告主提供是否应该为该ID进行某项营销行为的判断决策。比如，汽车广告主，将收集到的线索（leads）ID，通过安全求交的方法与运营商的数据相匹配。匹配后，运营商提供一个线索价值的打分返回给广告主。运营商为什么能做这样的事情，在这篇文章就不介绍了，如果感兴趣，欢迎上我的线下课《数据化增长：数据驱动的新数字营销》（点击查看具体课程介绍）。

07 安全求交之外的隐私计算应用

安全求交并不是隐私计算在数字营销中的唯一应用。我们前面讲过，安全求交本质上是“纵向联邦学习”。同样，“横向联邦学习”在数字营销中也有应用。比如，我们如果有1000万个汽车购买者的私域数据样本，就能计算出，购车人在私域中做出的哪些行为（或行为的组合），就意味着他们要买车了。这个计算的结果，就是“购车预测模型”。

但可惜，每个汽车主机厂最多的样本也只有200万个。于是多个主机厂联合起来，他们不分享任何的ID给彼此（不做安全求交），而是各自基于自己的样本先计算一个“粗糙的”购车预测模型。然后各自把自己计算的模型结果上传到一个第三方，第三方基于这些车厂的模型，整合出一个新的模型。并把这个新的模型下发给各个主机厂，再次做计算，以优化这个模型的“梯度”。

至于什么是梯度，就不解释了，太技术。你可以简单理解为，就是对这个模型里面的参数什么的进行进一步优化。

这样的过程多来几遍，直到这个模型靠谱了，就能够给每个车企使用了。

你看，每个车企没有把自己的任何样本公开出去，却都得到了靠谱的购车预测模型。

所谓横向联邦学习，这里的横向，就是指，参与计算的各方，他们拥有的样本的ID并不相同，但是这些ID的属性类型是相同的，比如购买者都有在私域中的各种同样的行为类型（查看车型、查看购车金融、询问客服之类的，每个车企的私域都有这些相同的交互功能）、同样的社会属性类型等。而纵向联邦学习，则是样本的ID相同，而ID背后的属性不同。

讲到这里，终于把我想讲的基本上讲完了。能读到这里的朋友，应该对隐私计算在数字营销上的原理和应用有了更全面的理解。不过，还有一些问题我没有能在这里进一步阐述，比如，这些应用场景具体起到什么作用，对不同行业的意义是什么，又如，隐私计算在数字营销中的合法合规性问题。这些内容，就不再写在文章中了，否则文字太多了。感兴趣的朋友，欢迎上我的线下课《数据化增长：数据驱动的新数字营销》（点击查看具体课程介绍）进一步了解学习。

以上。