iOS16下不依赖clipboard的deferred deep-linking替代方案咨询

原来靠剪贴板透传参数的路子在iOS16之后基本走不通：只要App主动读通用剪贴板，系统就会弹显眼的提示告知用户，绝大多数用户看到都会直接拒绝，方案成功率跌到20%~30%是常态。下面是可以完全自主研发落地、不需要依赖第三方SaaS服务的替代方案，按落地难度从低到高排序：

• 方案1：苹果官方SKAdNetwork + 自有短链映射（合规性最高，落地最快）
  这是苹果官方原生支持的归因路径，完全不碰隐私敏感权限：

  1. 把你自己的业务域名配置成App的Associated Domains关联域名，所有分享、投放的链接都用这个域名下的短链
  2. 用户点击短链时，服务端生成唯一click_id，把click_id和对应的深链路径、自定义参数绑定存在自有数据库，同时把click_id拼到SKAdNetwork的签名参数里按苹果要求上报
  3. 用户首次安装打开App时，系统会自动把带click_id的SKAdNetwork归因回传抛给App，App拿click_id请求自有服务端，换取对应深链参数完成路由跳转即可
     小提示：SKAdNetwork的回传存在一定延迟，可以配合下面的设备特征匹配做即时兜底，避免用户第一次打开的时候等不到参数跳不了。

• 方案2：无权限设备特征模糊匹配（准确率90%+，适配全场景）
  这是目前国内互联网厂商自研延迟深链的主流方案，全程只采集系统公开的、不需要申请任何权限的参数，完全合规：

  1. 用户点击短链进入落地页时，页面前端在合规范围内采集公开设备特征：公网IP地址、系统版本、机型、屏幕分辨率、运营商、系统语言、点击时间戳，把这些特征和对应深链参数一起上报服务端存储，特征有效期设为2小时即可
  2. 用户安装完首次打开App时，App端采集和上面完全一致的公开设备特征，上报到服务端
  3. 服务端做加权匹配：IP匹配权重最高（同C段IP即可判定为高优先级匹配），其次是点击时间和App首次启动的时间差（间隔越短权重越高），再匹配机型、分辨率、系统版本等静态特征，匹配度超过预设阈值就返回对应深链参数
     实测公网环境下这个方案的准确率能到92%以上，家庭/办公WiFi环境下准确率接近98%，唯一会出问题的场景是同一个公网IP下短时间内有大量同机型用户点击链接，这种场景可以配合其他方案兜底。

• 方案3：SFSafariViewController静默Cookie透传（准确率99%，适配自有域名场景）
  如果你的所有分享、投放落地页都部署在自有域名下，这个是目前自研方案里准确率最高的，完全没有匹配误差：

  1. 用户点击短链跳转到Safari打开的自有域名落地页时，给域名种下第一方Cookie，存唯一的trace_id和对应的深链参数
  2. 用户安装完首次打开App时，在App底层放一个1x1像素大小、透明的SFSafariViewController，加载自有域名下的一个空白静默页，用户完全感知不到这个组件的存在
  3. 静默页加载时会自动携带Safari下存的第一方Cookie，页面拿到trace_id之后通过JSBridge传给App，App拿trace_id去服务端换取深链参数，拿到之后直接销毁底层的SFSafariViewController即可完成跳转
     避坑：不要用自定义WKWebView做这件事，WKWebView的存储和系统Safari不互通，拿不到之前种下的Cookie；这个方案不需要申请任何权限，只要页面是你自己域名的，苹果审核完全不会卡。

自研落地避坑提醒

• 不要尝试调用私有API获取设备唯一标识，100%会被审核打回
• 所有特征采集必须在用户同意隐私协议的前提下进行，不要超范围采集隐私数据
• 实际落地的时候可以把三个方案组合使用：优先走SFSafariViewController透传拿参数，拿不到就走设备特征模糊匹配，最后用SKAdNetwork的回传做兜底，整体准确率能到98%以上，效果和第三方服务商基本没有差距。

内容的提问来源于stack exchange，提问作者Mark Kjorlien