全面解读 iOS 14 ATT和SKAdNetwork

Vency 2023-07-25 08:41:51

在2020年的WWDC20上，Apple发布了iOS14，并且特别强调iOS14将支持AppTrackingTransparency（简称ATT）和SKAdNetwork，看似微小的更新，对互联网广告行业的影响则是7.0地震级的。

ATT的更新使开发者获取用户的IDFA需要弹窗并经过用户的同意，提高了用户隐私透明度。而根据历史经验，至少40%的用户不会同意，更不用说权限申请弹窗上还要提示为了向用户提供更精准的广告推荐。当然，某些APP会让用户必须同意授权IDFA，否则不提供服务，这种容易被Apple以用户歧视的理由下架，更不可取。目前，iOS上的广告生态中从定向到归因都是基于IDFA之上，影响面可想而知。

SKAdNetwork2.0是由1.0升级而来，以解决上文中提出的IDFA带来的安装和转化归因问题。简单来说，广告平台需要注册成为Apple的一个广告网络并提供一个回调地址，当用户通过此广告网络的广告下载并打开了广告主的APP之后，Apple会把安装等信息传到回调地址。整个流程中有很多细节问题，具体看下文。

ATT和SKAdNetwork2.0的更新，不仅代表着Apple更注重用户隐私透明度，也代表着Apple开始插手广告归因，想作为应用商店在广告归因中分一杯羹，并为未来更大的广告业务做准备。

先说影响面：

此次更新，主要影响的是通过设备号跟外部进行交互的事物上，包括以下：

安装和转化归因，在获取不到IDFA时要有新的方案，例如SKAdNetwork2.0；广告主要更注意归因
延迟深度链接，广告主基于IDFA广告点击的延迟深度链接方案不可行，要有其他方案
APP拉新时，已安装用户的判断在获取不到IDFA时要有新的方案，用Apple提供的方法去查询是否安装某个APP
APP拉活、老客唤醒时，基于IDFA的用户定位方案也不再是主流，在获取不到IDFA时要有新的方案

再说ATT和SKAdNetwork2.0结论：

通过读取签名中的广告展示ID，广告平台仍然可将安装和转化归到某一次广告展示中
安装和转化回传的实时性大大降低，会延迟1天到64天之间，且最多传64种转化，转化价值无法回传
Apple未说明具体归因逻辑、时长和周期，且给广告主的信息几乎为零，未说明如何杜绝广告平台作弊
未提供除了IDFA以外其他定向方案
依赖于点击监测和IDFA的延迟深度链接不可实现
用户禁止APP访问IDFA的概率较高

最后提出几种解决方案：

通用id方案
Id Mapping 方案
IDFA+IDFV加密方案

01 ATT

ATT全名是AppTrackingTransparency，是Apple为提高用户隐私透明度提供的解决方案，获取IDFA也要符合ATT的要求。目前IDFA需要申请的场景，包括但不限于精准广告推荐、与数据第三方共享设备位置、与广告网络共享ID来定位或者lookalike、应用中放置一个第三方SDK用于第三方广告网络定向。很明显，Apple不希望IDFA未经用户允许就用于任何的广告定向。

此外，Apple还说有两种情况下，可以跟踪用户且不需要获取用户许可：

当您的应用程序中的员工或设备数据仅连接到用户设备上的第三方数据，并且不会以可识别用户或设备的方式从设备发送出去
与您共享数据的数据代理仅将数据用于欺诈检测，预防欺诈或安全目的，并且仅代表您使用。例如，仅使用数据代理来防止信用卡欺诈。

这两种情况Apple单独说出来蛮奇怪的，Apple如何能够保证开发者是按照所述要求进行的，而非serve to serve来实现Apple不允许的。如果单从这两种特殊情况来说，对Apple的ATT执行力度是存疑的。

02 SKAdNetwork2.0

SKAdNetwork2.0的整体流程比ATT复杂一些，涉及到的角色也较多，它其实是Apple针对非IDFA的安装和转化归因的整体方案，是要广告平台、广告主、媒体共同参与才能够实现的。此外，SKAdNetwork2.0是由1.0迭代而来的，1.0用的人很少，2.0增加了一些参数和接口。

SKAdNetwork2.0的主要流程

上图毕竟只是个流程，看不出来一些细节问题，例如能否把安装归因到某一次曝光？具体各个角色都要做什么工作？广告网络能否知道转化的产生时间？接下来我们对流程中的每个节点用到的方法、参数等进行详细梳理，才能解决上述问题。

SKAdNetwork2.0的交互流程

1. 广告平台去Apple中注册成为一个广告网络，拥有一个广告网络id。除了id以外，有公钥和私钥一对，用以解密Apple在用户安装后回传的信息，公钥要发送给Apple，私钥自行保存。还要提供一个URL，用以接收SKAdNetwork安装验签回发请求。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/registering_an_ad_network

2. 广告平台向媒体提供带签名的广告。签名是整个SKAdNetwork2.0关键点。

如何生成签名？

首先，广告平台要根据所使用的SKAdNetwork版本来选择参数，若是2.0，则拥有以下参数可供选择，版本是指支持的版本：

SKStoreProductParameterAdNetworkVersion版本2.0。使用API版本值“ 2.0”。
SKStoreProductParameterAdNetworkIdentifier版本1.0和2.0。在Apple上注册的广告网络id。
SKStoreProductParameterAdNetworkCampaignIdentifier版本1.0和2.0。广告系列编号。
SKStoreProductParameterITunesItemIdentifier版本1.0和2.0。广告主APP的App Store ID，即itunes-item-id。
SKStoreProductParameterAdNetworkNonce版本1.0和2.0。是种UUID，是代表每次广告展示的唯一值。签名中使用的该随机数的字符串表示形式必须为小写。
SKStoreProductParameterAdNetworkSourceAppStoreIdentifier版本2.0。媒体APP的应用商店ID。如图source-app-id中的清单3。
SKStoreProductParameterAdNetworkTimestamp版本1.0和2.0。代表广告展示时间

其次，广告平台对参数和值按照Apple要求进行合并，合并成一条字符串。

然后，广告平台用密钥和Apple提供的算法对合并的字符串加密签名。

最后，将拥有应用调用和启动验签所需的所有必需的“ 广告网络安装验签签名”值。把签名放入广告中，并把广告推给媒体，因此广告网络提供给媒体的API或者SDK都要改动。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/generating_the_signature_to_validate_an_installation

3. 媒体在应用中配置广告网络id。媒体要在一个文件中把需要支持的广告网络id填入，此文件支持多个广告网络id，若某广告网络id不在此文件中，则不会对此广告网络id启动安装验签。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/configuring_the_participating_apps

4. 媒体APP显示广告平台提供的带签名的广告。当用户在媒体APP上点击广告时，媒体APP调用App Store视图并代入广告网络提供的签名和验签信息，这样Apple才能知道调起App Store的签名，并把签名带到下一个流程中去。

具体请见：https://developer.apple.com/documentation/storekit/skadnetwork/ad_network_install_validation_keys

5. 用户下载安装广告主APP。

6. 用户打开广告主APP时，广告主APP要调用应用安装验签信息方法。方法是registerAppForAdNetworkAttribution()，调用或者首次启动时使用，无需填入其他任何参数，相当于广告主告诉Apple说这人打开了我的APP了。Apple会等待广告主APP24小时，若24小时内广告主APP未进入到下个流程，Apple会在之后的24小时之中的随机时间点向广告平台发起回调，随机时间点也是为了用户隐私吧。PS：其实不需要广告主调用，Apple应该也知道这一次的打开，可能有技术上的难题。

7. 用户在广告主APP上产生转化，广告主APP要调用更新转化值方法。方法是updateConversionValue(_:)，在产生转化时使用，需要传一个int值，6-bit，相当于0-63中的某个值，调用此方法后Apple回调的时间会推迟24小时。此方法可多次调用，但是距离上一次调用安装（registerAppForAdNetworkAttribution）或转化（updateConversionValue(_:)）不能超过24小时，因为超过24小时的话Apple就会发起回调了。多次调用时，后一次的Value要比前一次的大，否则相当于不生效。因此最多会导致64次调用后才会回传给广告平台信息。

我认为ConversionValue更像是转化id而非转化价值，广告主可以基于自身漏斗设计最多64个转化，目前在SKAdNetwork2.0中并不存在转化价值这个参数。

8. Apple把安装和转化信息发送给广告平台注册时填写的URL上。此时就涉及到如何归因，可惜这方面Apple在文档中没有说得很清楚，例如用户看了两个广告网络广告后，在点击后一个广告去安装广告主APP，此时安装信息的发送逻辑，类似问题还有很多。

9. 广告平台验签收到的安装和转化信息。此时广告平台要支持两种版本的安装和转化信息验签，且只能通过收到的信息中的参数与解密后的签名相验签。生成签名时，用私钥去加密；收到签名后，用公钥去验签和解密。具体参数如下：

version版本2.0。与匹配的广告网络验签API的版本。
SKStoreProductParameterAdNetworkVersionad-network-id版本1.0和2.0。广告网络id
SKStoreProductParameterAdNetworkIdentifiertransaction-id版本1.0和2.0。此验签的唯一值；用于对安装验签消息进行重复数据删除。
campaign-id版本1.0和2.0。展示广告时提供的与匹配的广告系列ID 。
SKStoreProductParameterAdNetworkCampaignIdentifierapp-id版本1.0和2.0。广告主的APP
id
attribution-signature版本1.0和2.0。要验签的Apple的署名签名。
redownload版本2.0。一个布尔值，指示值为1时用户重新下载并重新安装了该应用程序。
source-app-id版本2.0。媒体的APPid。注意：仅当提供的参数满足Apple的隐私阈值时，才会显示。SKStoreProductParameterAdNetworkSourceAppStoreIdentifiersource-appid
conversion-value版本2.0。转化id，已安装的应用程序通过调用提供的无符号6位值。注意：仅当已安装的应用程序提供该参数并且提供的参数满足Apple的隐私规则时，才会显示。updateConversionValue(_:)conversio

上述参数中，核心是attribution-signature签名，若签名被篡改或者非此广告平台的，就会验签失败。通过公钥对签名进行验签和解密后，就可以得到广告平台带入的签名加密前的字符串，而字符串中包含了广告展示ID，即可将安装转化与广告展示ID关联起来。（此处很关键，建议实际验证或者找Apple确认）此外，还可用非签名的参数跟签名内的字符串的参数核对，若有冲突即可舍弃此次回传。

文档请见：https://developer.apple.com/documentation/storekit/skadnetwork/verifying_an_install_validation_postback

03 疑问点

1. 归因相关

Apple是否涉及到归因？归因运算逻辑？归因时间周期？点击广告后没有下载，在中途没有点击其他任何广告，用户自行去APP STORE 下载，归因怎么算？先看A广告点击跳转到AppStore，再看B广告并点击跳转到AppStore，传的是A还是B？

2. 参数相关

redownload 1和0的具体判断逻辑是什么？广告主APP版本跟redownload有啥关系？conversion-value 转化价值的建议用法是什么？说要满足的隐私规则是什么？

3. 签名相关

在正常情况下，广告网络在生成签名时候的签名，跟安装回传中的签名是否一致？若是，则广告网络是否要根据解密后的签名和其他参数作对比？若是，则可以通过广告展示的uuid把安装和曝光关联起来？若是，则有了广告展示的UUID，campaignid还有什么用？

4. 反作弊相关

通过什么渠道向广告主提供了哪些信息？整套机制是否能有效防止媒体或者广告平台作弊？若是，则整套机制为什么能防止？

04 解决方案

1. 通用id方案

这种方案本质上是寻找IDFA的替代品，要根据媒体、广告平台、广告主都能拿到的设备或用户数据，根据这些数据和制定规则去生成一个IDFA的替代品”某某ID”。难点有两个，唯一性和多方认可。要有普遍的唯一性，是作为一个ID的必备能力。而且此方案要受到多方认可，才能够真正对外使用，否则只是另一个IDFV。

2. Id Mapping方案

这种方案本质上类似PC WEB的cookie mapping，通过广告平台的ID和广告主的ID Mapping，来解决IDFA的问题。难点也有两个，如何mapping和如何提高mapping浓度。我有个方案是在A APP调起/唤醒B APP时进行mapping，但是mapping是要涵盖拉新、拉活等多种场景的，我这种方案只能解决拉活，而且mapping浓度也无法保证。

3. IDFA+IDFV加密方案

这种方案是adjust提出来的，本质上就是看Apple能不能睁一眼闭一眼。首先，在广告主端的对广告主的IDFA和IDFV组成一个hash。然后，把这个hash和广告主的IDFV传到媒体APP客户端上。其次，在媒体本地上用媒体的IDFA和广告主的IDFV组成一个hash。最后，在媒体本地比较这两个hash是否一致。此方案就是用到了上文ATT标蓝的内容，认为这种方案不会以可识别的方式把IDFA发出去。Apple是否认为这种方案就是符合隐私要求的，这是要打个问号的。

总之，Apple的小改动对于整个iOS不算什么，但是在互联网广告中掀起了狂风骇浪，到目前也没有业内达成共识的解决方案。ATT和SKAdNetwork2.0的推出，确实对用户隐私是利好，但是也会助长以头部综合广告平台为代表的围墙花园态势。经此一役，大家又回到同一个起跑线上，有风险就有机遇，希望同行同业能够一起面对。