我们正在尝试在一款iOS应用中实现延迟深度链接，以鼓励用户邀请好友使用该应用，并根据用户的推荐链接安装次数来奖励用户。与Tapstream的产品基本相似。
请考虑以下示例：
因此，UserA在他们想要的任何网络上共享他们的链接“ourappurl.com/refer?id=UserA”。UserB点击这个链接，这个链接会把他们带到Safari，然后弹出到应用程序商店页面，在那里UserB下载应用程序。
当UserB打开应用程序时，应用程序会检查他们进入的是哪个推荐ID（如果有的话）。在本例中，引用ID将是“usera”，因为它是引用链接中的ID。然后应用程序将此发送到我们的服务器，我们授予UserA一个推荐信用。
我想把这个问题分解成核心部分。我相信第一部分是获得用户的推荐链接的网页，将推荐ID保存到应用程序可以访问的设备的某个地方。但我不确定这是可能的，因为iOS的沙盒性质。
我知道这从根本上是可能的，因为许多广告提供商提供了从广告活动中跟踪安装的能力（例如，参见移动应用程序跟踪）。
我们自己也曾尝试这样做，我将在此尝试详细说明不同的步骤。
回到您的示例，关于“记住”设备标识和所有相关数据“id=usera”，您是正确的。你说的“iOS的沙盒性质”也是对的，我想这意味着网页不允许存储浏览器应用程序（Safari）之外的信息，应用程序（你的应用程序）不能访问其他应用程序（Safari）存储的信息。
我们的解决方案是将此设备存储在一个既可被浏览器访问，也可被应用程序访问的环境中，即后端服务器。
下一个挑战，仍然是最大的挑战，是如何从可从浏览器收集的信息中唯一地识别这个设备？浏览器中的JavaScript与本机应用程序不同，没有访问IDFAs的权限，而IDFAs可以用来唯一标识iOS设备。为了克服这个问题，我们可以设想使用浏览器应用程序和本地应用程序都可用的公共信息的组合，例如操作系统类型、公共IP、屏幕大小等。请注意，来自这些数据字段的组合键并不能保证唯一性（设想两个iPhone 6通过同一路由器访问该网页）。因此，您的后端服务器（假设您正在使用它来存储这个键-值对）将希望有一个策略来处理键上的冲突，即第二个键删除第一个键，或者您通过为单个键设置一个值队列来允许冲突的存在。这真的取决于你实际计划如何使用这项技术。
最后一步是在应用程序上形成这个复合键，使用前面在浏览器中使用的完全相同的字段在后端服务器上执行“查找”以检索先前存储的值。
以下是对步骤的总结：
希望能有所帮助！
编辑04/24：
既然Derrick在评论中提到了它，我想我会借此机会结束我们的故事在这里。
回到我回答的开头，我提到我们自己也试图做到这一点。我们有一个基于我们当前系统架构的工作原型（对于存储和分析这样的深度链接数据，它没有经过任何优化，也没有打算进行优化），我们最终决定不为这个项目分配任何额外的工程资源。
由于这个匹配过程的启发式性质，我们发现这个项目需要不断地调试、调优和优化以减少ROI。更重要的是，我们找到了比自己更专业、做得好得多的其他公司。
自从我们停止使用我们的内部系统以来，大概已经有6个月了，我们并没有后悔做出这样的决定。
在此过程中，我们与许多供应商合作过，Appsflyer、Adjust、TapStream，最终我们得到了分支度量https://Branch.io。
你是否应该DIY或与另一家公司再次工作取决于你的具体目标。我们最终决定与Branch合作，不仅是因为Branch是完全免费的，其他供应商每月收费从500美元到数千美元不等，而且他们提供的支持水平也是无与伦比的。
这里有一个很好的解决方案：http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
基本工作流程：
我们已经成功地使用剪贴板（NSPasteboard）实现了这一点：在允许用户下载应用程序之前，处理重定向到app store的web页面会粘贴到移动设备的剪贴板。安装应用程序后，它会在首次启动时使用NSPasteboard检查是否有适当编码的字符串。这个字符串可以包含感兴趣的文本，或者更安全的是，包含用于从后端获取感兴趣数据的令牌。在目标C中：
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
剪贴板可以在应用程序完成后清除，以避免重复相同的操作。
