在iOS中推迟深层链接 [英] Deferred Deep Linking in iOS

问题描述

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

We're trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many installs occur from their referral link. Basically similar to TapStream's product.

考虑这个例如：

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

So, UserA shares their link, "ourappURL.com/refer?id=userA", on any network they want. UserB clicks that link, which will take them to Safari and then bounce them to the App Store page where UserB downloads the app.

当UserB打开应用程序时，应用程序会检查他们来自哪个推荐ID
in（如果有）。在此示例中，引荐ID将为userA，即
，即引用链接中的ID。该应用程序然后将此发送到
我们的服务器，我们向UserA授予推荐信用。

When UserB opens the app, the app checks which referral ID they came in on (if any). In this example, the referral ID would be "userA" as that’s the ID that was in the referral link. The app then send this to our servers and we award UserA with a referral credit.

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

I'm trying to break this issue down into its core parts. I believe the first part is getting the web page for the user's referral link to save the referral ID to the device somewhere that the app can access it. But I'm not sure this is possible because of the sandboxed nature of iOS.

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

I know this is fundamentally possible because many ad providers offer the ability to track installs from an ad campaign (see Mobile App Tracking for example).

推荐答案

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

We have also attempted to do this ourselves and I will try to break down the different steps here.

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

Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).

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

Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.

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

The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.

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

The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.

以下是步骤摘要：

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. 首次启动A时A，A使用相同的密钥联系S（假设IP未更改）。


6. S找到值inviter_id = 1通过使用此密钥传入，并且，比方说，奖励用户1邀请2的5分。

1. User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
2. User 2 visit Web Page P
3. P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
4. User 2 goes to the app store and downloads your App A
5. Upon 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
6. S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.

希望这有帮助！

编辑04/24：

因为Derrick在评论中提到它，我想我是谁我们借此机会在这里完成我们的故事。

Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.

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

Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.

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

Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.

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

It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.

在此过程中，我们与众多供应商，Appsflyer，Adjust，TapStream合作，最终我们最终获得了分支指标 https：// branch .io 。

During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.

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

Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.

这篇关于在iOS中推迟深层链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！