首页 文章

在iOS中推迟深层链接

提问于
浏览 次
37

我们正在尝试在我们的某个iOS应用程序中实施延迟深层链接，以鼓励用户邀请他们的朋友使用该应用程序，并根据他们的推介链接发生的安装数量来奖励用户 . 基本上类似于TapStream's product .

考虑这个例子：

因此，UserA在他们想要的任何网络上分享他们的链接“ourappURL.com/refer?id=userA” . UserB单击该链接，将其带到Safari，然后将它们退回到UserB下载应用程序的App Store页面 . 当UserB打开应用程序时，应用程序会检查它们所引用的引荐ID（如果有） . 在此示例中，引荐ID将是“userA”，因为它是引用链接中的ID . 该应用程序然后将此发送到我们的服务器，我们授予UserA一个推荐信用 .

我试图将这个问题分解为其核心部分 . 我相信第一部分是获取用户引荐链接的网页，以将引荐ID保存到应用可以访问它的某个地方的设备 . 但由于iOS的沙盒特性，我不确定这是否可行 .

我知道这基本上是可行的，因为许多广告提供商都能够跟踪广告系列的安装情况（例如，请参阅移动应用跟踪） .

ios deep-linking

4 回答

  • -4

    我们也试图自己这样做，我会尝试分解这里的不同步骤 .

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

    我们的解决方案是将此设备存储到一个环境中的数据键值对，该环境既可以由浏览器访问，也可以由您的应用程序（即后端服务器）访问 .

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

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

    以下是步骤摘要：

    • 用户1通过向2发送以下链接来邀请用户2：example.com?inviter=1

    • 用户2访问网页P.

    • P构造并将以下键值对发送到您的服务器S iOS | 55.55.55.55 | 750×1334 - > inviter_id = 1

    • 用户2进入应用程序商店并下载您的应用程序A.

    • 首次启动A时，A与具有相同密钥的S联系（假设IP未更改） .

    • S通过使用传入的密钥找到值inviter_id = 1，并且假设用户1奖励邀请2的5分 .

    希望这有帮助！

    编辑04/24：

    由于德里克在评论中提到它，我想我会借此机会在这里完成我们的故事 .

    回到我的答案的开头，我提到我们自己试图这样做 . 我们有一个基于我们当前系统架构的工作原型（无论如何不优化，或者意味着优化，用于存储和分析这样的深层链接数据），我们最终决定不将任何额外的工程资源分配到该项目中 .

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

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

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

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

    回复于
  • 2

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

    基本工作流程

    • 用户在Web上选择域链接 .

    • 链接将引用ID设置为cookie .

    • 用户重定向到应用商店 .

    • 在应用启动时，在SFSafariViewController中加载引用页面 .

    • 推荐页面检查cookie，如果存在则调用带有推荐ID的应用程序的深层链接 .

    回复于
  • 40

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

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

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

    回复于
  • 8

    我的答案来自HERE

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

    Source

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

    来自：HERE

    HERE是关于Universal Links的另一篇文章及其内容 .

    回复于

相关问题