在iOS中推迟深层链接

Kir*_*sar 44 deep-linking ios

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

考虑这个例子:

因此,UserA在他们想要的任何网络上分享他们的链接"ourappURL.com/refer?id=userA".UserB单击该链接,将其带到Safari,然后将它们退回到UserB下载应用程序的App Store页面.

当UserB打开应用程序时,应用程序会检查它们所引用的引荐ID(如果有).在此示例中,引荐ID将是"userA",因为它是引用链接中的ID.该应用程序然后将此发送到我们的服务器,我们授予UserA一个推荐信用.

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

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

eth*_*gui 48

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

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

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

下一个挑战仍然是最大的挑战,那就是如何从浏览器收集的信息中唯一地识别这个设备?与本机应用程序不同,浏览器中的Javascripts无法访问可用于唯一标识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进入应用商店并下载您的App A.
  5. 在2首次启动A时,A用相同的密钥联系S(假设IP没有改变).
  6. S通过使用传入的密钥找到值inviter_id = 1,并且假设用户1奖励邀请2的五个点.

希望这有帮助!

编辑04/24:

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

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

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

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

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

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

  • Ethan,听起来你在描述我们在Branch Metrics所做的事情:) (9认同)
  • 由于苹果和安卓不断地不遗余力地杀死可以唯一标识用户/设备的延迟深度链接方法,那么为什么不只允许应用程序商店接受入站参数,然后在启动时将该参数传递给应用程序。太令人沮丧了。 (6认同)

PPi*_*son 8

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

基本工作流程

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

  • 看起来从Safari应用程序和"SFSafariViewController"的iOS 11 cookie开始不共享,因此它将不再起作用 (7认同)
  • 苹果终止了这种方法。它不再起作用了。 (2认同)

Ant*_*ott 5

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

UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
Run Code Online (Sandbox Code Playgroud)

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