iOS 中的延迟深度链接

Posted 2023-02-19

【中文标题】iOS 中的延迟深度链接

【英文标题】：Deferred Deep Linking in iOS

【发布时间】：2014-11-09 10:14:20

【问题描述】：

我们正在尝试在我们的一款 ios 应用程序中实施延迟深度链接，以鼓励用户邀请他们的朋友使用该应用程序，并根据用户推荐链接的安装次数来奖励用户。基本类似于TapStream's product。

考虑这个例子：

因此，UserA 在任何网站上分享了他们的链接“ourappURL.com/refer?id=userA” 他们想要的网络。 UserB 单击该链接，这将把他们带到 Safari 然后将它们反弹到 UserB 所在的 App Store 页面 下载应用程序。

当用户 B 打开应用时，应用会检查他们来的推荐 ID 在（如果有的话）。在此示例中，推荐 ID 将是“userA”，如 那是推荐链接中的 ID。然后应用程序将其发送到 我们的服务器，我们向 UserA 奖励推荐信用。

我正在尝试将这个问题分解为其核心部分。我相信第一部分是获取用户推荐链接的网页，以将推荐 ID 保存到应用程序可以访问的设备上。但由于 iOS 的沙盒特性，我不确定这是否可行。

我知道这从根本上是可能的，因为许多广告提供商都提供了跟踪广告活动安装的功能（例如，请参阅移动应用跟踪）。

【问题讨论】：

通过设备上的广告跟踪安装是不同的，因为它们可以关联 IDFA。我不相信你想做的事是可能的

我们也在寻找方法来做到这一点。您是否看过 TapStream 的这篇博文“我们如何构建延迟深度链接”blog.tapstream.com/post/74394304157/…

@Ender2050 是的，我在原帖中提到了 Tapstream。我看到了他们的博客文章，但它似乎只是使用他们服务的广告。我主要感兴趣的是如何自己实现这样的功能，而不是依赖第三方。

基兰，谢谢。我希望我们能够为此找到一些更好的选择。

【参考方案1】：

我们自己也尝试过这样做，我将尝试在此处分解不同的步骤。

回到您的示例，您对“记住”设备标识和所有相关数据“id=userA”是正确的。您对“iOS的沙盒性质”也是正确的，我认为这意味着网页不允许在浏览器应用程序（Safari）之外存储信息，并且应用程序（您的应用程序）无法访问其他应用程序存储的信息（野生动物园）。

我们对此的解决方案是将此设备存储在浏览器和您的应用（即您的后端服务器）都可以访问的环境中的数据键值对。

下一个挑战，仍然是最大的挑战，是如何从浏览器收集的信息中唯一地识别这个设备？与原生应用程序不同，浏览器中的 javascript 无法访问可用于唯一标识 iOS 设备的 IDFA。为了克服这个问题，可以想象使用浏览器应用程序和本机应用程序都可用的公共信息组合，即操作系统类型、公共 IP、屏幕大小等。请注意，复合键来自这些数据字段不保证唯一性（想象两个 iPhone 6 通过同一路由器访问此网页）。因此，您的后端服务器（假设您正在使用它来存储此键值对）将希望制定有关如何处理键冲突的策略，即第二个键删除第一个键，或者您允许冲突存在单个键的值队列。这实际上取决于您实际计划如何使用这项技术。

最后一步是使用您之前在浏览器中使用的完全相同的字段在您的应用上形成此复合键，以在您的后端服务器上执行“查找”以检索先前存储的值。

以下是步骤摘要：

用户 1 通过向用户 2 发送以下链接来邀请用户 2：example.com?inviter=1 用户 2 访问网页 P P 构造并发送以下键值对到您的服务器 S iOS|55.55.55.55|750×1334 ->inviteer_id=1 用户 2 进入应用商店并下载您的应用 A 用户 2 首先启动 A，A 使用相同的密钥联系 S（假设 IP 未更改）。 S 使用传入的这个键找到值invitationer_id=1，假设邀请用户 2 奖励用户 1 5 分。

希望对您有所帮助！

编辑 04/24：

既然Derrick在cmets中提到过，我想我会借此机会在这里完成我们的故事。

回到我回答的开头，我提到我们已经尝试自己这样做。我们有一个基于我们当前系统架构的工作原型（无论如何都没有优化，也没有打算优化，用于存储和分析这样的深度链接数据），我们最终决定不为这个项目分配任何额外的工程资源。

由于此匹配过程的启发式性质，我们发现该项目需要不断调试、调整和优化，以降低投资回报率。更重要的是，我们找到了比我们更专业、做得更好的其他公司。

自从我们停止使用我们的内部系统以来可能已经 6 个月了，我们没有后悔做出这样的决定。

在此过程中，我们与多家供应商合作，包括 Appsflyer、Adjust、TapStream，最终我们获得了 Branch Metrics https://branch.io。

您是否应该 DIY 或再次与另一家公司合作取决于您的具体目标。我们最终决定继续使用 Branch，不仅因为其他供应商每月收取 500 美元到数千美元的费用，而 Branch 完全免费，而且他们提供的支持水平简直无与伦比。

【讨论】：

Ethan，听起来你在描述我们在 Branch Metrics 所做的事情:)

谢谢！正是我需要理解这一点。发生冲突的可能性有多大？就像如果 2 部确切的 iphone 点击来自同一个 wifi 连接的链接（如会议）会发生什么。是否有设备更独特的信息？

Ethan，你为什么选择 branch.io 而不是adjust（除了免费和支持）？

既然苹果和安卓一直在竭尽全力杀死可以唯一标识用户/设备的延迟深度链接方法，那么为什么不让应用商店接受一个入站参数 - 然后传递该参数在应用程序启动时。太令人沮丧了。

【参考方案2】：

我们已经成功地使用剪贴板 (NSPasteboard) 实现了这一点：处理重定向到应用商店的网页在让用户下载应用之前将粘贴到移动设备的剪贴板。安装应用程序后，它会在首次启动时使用 NSPasteboard 来检查适当编码的字符串。该字符串可以包含感兴趣的文本，或者更安全地包含用于从后端获取有趣数据的令牌。在目标 C 中：

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;

应用完成后可以清除剪贴板，以避免重复相同的操作。

【讨论】：

根据这篇文章***.com/questions/34045777/…，他们已经禁用了通过 javascript 以编程方式粘贴到 iOS 上的剪贴板，因此这将不再有效。

@DougVoss 只要您使用正确的方法（请参阅顶部链接的问题）并在点击处理程序中进行，程序化粘贴就可以在 iOS 12 中工作。当用户通过点击我们的移动网页登录页面上的按钮首次安装应用程序时，这种方法非常适合我们维护上下文

可以确认，我已经在 iOS 13 上进行了测试，带有一个简单的 react 网站和 iOS 应用程序。效果很好。

等等，这种方法有效吗？苹果不会拒绝你的应用程序或任何东西？我还需要披露我们进行归因吗？ （不使用 IDFA）

iOS 14 让这变得更加困难，Safari 不允许您在没有实际用户触发“点击”或“触摸”事件的情况下复制内容，即使您将数据写入手机的剪贴板，当您尝试阅读它（一旦用户安装应用程序），iOS 14 将向用户显示您阅读了他们的剪贴板。这不是一个好的体验。可能最好使用诸如 branch.io 之类的解决方案，如另一个答案中所述。

【参考方案3】：

这里有一个很好的解决方案：http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/

基本工作流程：

用户在网络上选择域链接。 链接将推荐 ID 设置为 cookie。 用户重定向到应用商店。 在应用启动时，在 SFSafariViewController 中加载推荐页面。 推荐页面检查 cookie，如果存在，则使用推荐 ID 调用应用的深层链接。

【讨论】：

是的 - 除了 SFSafariViewController 中有一个明确的部分，它可能只用于向用户显示信息，因此以这种方式使用它基本上直接违反了该规则。有问题。

看起来从 iOS 11 开始，来自 Safari 应用的 cookie 和 SFSafariViewController 没有共享，所以它不再起作用了

2019年今天有没有办法从WKWebView或SFSafariViewController获取cookie？

Apple 扼杀了这种方法。它不再起作用了。

【参考方案4】：

我的回答来自HERE

Apple 不再支持深层链接。它现在被称为通用链接，并且工作方式有所不同。

来源

现在 Apple 不再支持用于深度链接的 URI 方案，开发人员必须实现通用链接才能在 iOS 上正确地进行深度链接。如果您已经在使用 URI 方案，请查看我们关于过渡到通用链接的博客。

发件人：HERE

HERE 是另一篇关于通用链接及其是什么的文章。

【讨论】：

问题是关于延迟深度链接，通用链接无法解决。

OP 明确指出需要在用户点击链接的那一刻（例如 facebook 活动）和安装应用程序之后保留参数，以便用户可以被带到应用程序的某些部分例如。