iOS 中的延迟深度链接

Question

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

考虑这个例子：

因此，用户 A 在他们想要的任何网络上共享他们的链接“ourappURL.com/refer?id=userA”。 用户 B 单击该链接，这会将他们带到 Safari，然后将他们退回到用户 B 下载应用程序的 App Store 页面。

当用户 B 打开应用程序时，应用程序会检查他们进入的推荐 ID（如果有）。 在此示例中，推荐 ID 将是“userA”，因为这是推荐链接中的 ID。 然后应用程序将其发送到我们的服务器，我们会向 UserA 授予推荐积分。

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

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

Answer 1

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

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

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

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

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

以下是步骤的摘要：

1. 用户 1 通过向用户 2 发送以下链接来邀请用户 2：example.com?inviter=1
2. 用户 2 访问网页 P
3. P 构建并发送以下键值对到您的服务器 S iOS|55.55.55.55|750×1334 -> inviter_id=1
4. 用户 2 前往应用商店并下载您的应用 A
5. 用户 2 首先启动 A，A 使用相同的密钥联系 S（假设 IP 没有改变）。
6. S 通过使用传入的此密钥找到值 inviter_id=1，假设用户 1 因邀请用户 2 而奖励 5 分。

希望这有帮助！

编辑 04/24：

既然戴里克在评论中提到了，我想我会借此机会在这里结束我们的故事。

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

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

我们停止使用我们的内部系统已经有大约 6 个月了，我们并不后悔做出这样的决定。

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

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

Answer 2

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

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

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

Answer 3

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

基本工作流程：

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

Answer 4

我的回答来自这里

Apple 不再支持 Deep Links。 它现在被称为通用链接，工作方式略有不同。

来源

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

来自： 这里

这里是另一篇关于通用链接和它们是什么的文章。