App 内购买和使用服务器对服务器通知

（App内购买项目 及使用服务器到服务器通知） 早上好！

欢迎参加App内购买项目 及使用服务器到服务器通知演讲 我是Dana DuBois 我是App Store技术部经理

我们今天要谈很多内容 首先从StoreKit的新功能 开始谈起 自去年的演讲起 我们又进行了哪些变更呢？

然后我要把舞台交给 我的同事Tori 她将跟大家具体介绍 服务器到服务器通知 以及如何确保你在后台 拥有订阅客户的最新信息？

接着Manjeet会上台介绍 一些不一样的内容 即订阅周期中的计费事件

最后 他会跟大家介绍 如何减少无意识流失 并把订阅客户留在你的服务中

那么首先

StoreKit中有哪些新功能？

嗯 今年春季我们引入了订阅优惠

订阅优惠是我们引入的一个新功能

为你提供了一个工具 让你保留现有订阅者 以及重获曾使用过此服务的订阅者

你可以通过给每个订阅 设置最多十个不同的激活的优惠实现 那将会打折或免费获得服务 你可以提供给你的客户们

你的app要决定 要呈现什么以及给谁呈现 完全由你做主 这是一个很棒的功能 也是一个很大的功能 实际上今天稍后会有一场 专门的演讲 就在这里 下午两点 如果你的服务中有订阅功能 我强烈建议你们参加那场演讲

（SKStoreFront） StoreKit中还有哪些 新功能？嗯… 今年夏季我们要宣布 引入了SKStorefront SKStorefront是我们 展示给你们开发人员的一个商店 用户会在这里设置 他们的App Store

从而向客户呈现正确的内容 你想向全世界的客户们推销什么？ 你可以用SKStorefront 针对某个客户 在他们的设备上获取特定的范围

这与App Store内容的 呈现方式一样 并且这个API为你提供的是当前 设定了App Store的商店

有一件事你要记住 就是这个API会为那个商店 返回一个特定设备的缓存值 并且它可以随时间发生变更 因此你需要思考一些东西 当你与 SKStorefront连接时 那么让我们打开代码 看看这些是如何运作的

如果你现正在连接StoreKit SKPaymentQueue上 已经有委托了 我们给那个增加了一个功能 即给商店获取一个 返回当前缓存值的参数 即.storefront 它将为你提供那个值 因为它会发生变更 也因为它是特定设备上的 它可以是空值 虽然不太可能 那么你需要在你的app中检查一下 并确保没问题

一旦你拥有那个商店 就在API上 是一个国家代码 它是三个字母的代码 ISO标准值 适用于全世界的地区及国家 并且那将准确地告诉你 那台设备上的App Store 被设定为哪里 这是真的 然后那将允许你获取国家代码 并向客户们推销正确的内容 但正如我所说过的 它可以随时间发生变更 那么让我们再深入查看代码 了解你还需要思考什么东西

在这里我们有一段示例代码 在这里你会获取 从后台取出的产品标识符 把它传进来 然后尝试决定是否应该取出元数据 执行一个SKProduct请求 以决定是否应该显示那个内容 那么… 开发人员所要做的就是 从后台取出那个元数据 并执行一个调用 嘿 这个商店对那个代码有效吗？ 然后你可以在这里看到 在你取出产品信息之前 你要调用shouldShow 如果它返回真 把那个标识符添加到 你即将做出SKProduct 请求的项的列表上 你应该在执行SKProduct 请求之前做这一步 因为如果你不推销那个产品 那么不提取产品元数据会更有效率

但正如我刚说过的那样 它会随时间发生变更 实际上用户可以切换账户 或甚至可能会在同一个账户内 进入App Store 并浏览不同的商店 开发人员们总是会这样做 因为他们真的想了解世界不同地区中 他们的app分别是什么样子 了解它看起来是什么样子 了解它用起来怎么样 在App Store中 有一种方法可以实现 因此我们向确保你在运行的app中 拥有最新的信息 因此在SKPayment 交易观察器上我们添加了一个 新的paymentQueueDidChange事件 你可以直接在你的app内监测 它会传入付款队列 当你得到它之后 进入 queue.storefront 并获得一个新值 关于那是哪个商店 然后再一次… 它是一个新商店 那么你想重新加载 特定于那个新商店的全部内容 实际上你可能拥有不同的内容 你想根据用户所在的位置进行推销

那么再一次调用 shouldShow 决定你是否应该为它提取产品信息

那么当你正在执行购买时 会发生什么呢？ 你推销了一些内容 用户即将购买它 然后通常一切都很顺利 但是如果用户实际上在一个 与他们的设备所设定的地区 不一样的商店中 付款队列可能会改变商店 在交易中间 那么我们为你提供了一个 paymentQueue委托 它可以让你监测 paymentQueue: shouldContinue: in newStorefront 这是你进行复查的机会 我是否应该允许这次购买 在这个新商店中发生？ 再一次使用那个 同样的shouldShow功能 在那里你监测了全部产品标识符 并且你明白那些产品 在哪些地区内可用 如果它返回真 就允许付款继续 为了确保实现最佳用户体验 我们希望它的返回速度要快 因此你不应该执行服务器端调用 在paymentQueue: shouldContinue: newStorefront中间 你应该把这个信息缓存到你的设备上 地区内可用的产品 当付款发生时可以随时获取 那样你可以很快地返回 用户就可以继续他们的购买了 或者如果你返回否 实际上你可以通知用户 为什么在新商店中购买无效

那么正如我所说过的 也许产品在新地区内不可用

那么你该怎么做呢？ 嗯 如果发生这种情况 在你的paymentQueue: updatedTransactions委托调用中 我们将返回一个 SKStoreProductNotAvailable报错 它会通知你说你刚刚告诉我们 你不应该允许此交易 发生在那个新商店中 并且在这里你有机会呈现一个对话框 或者… 推销一些其它 可能与新商店中的内容相等值的内容 显示一个警告 更新UI 做一些此时此刻你需要做的操作

那么这就是 SKStorefront （App预定） 我们还引入了什么新功能？ 嗯…

在iOS 11/11.2以及tvOS 11.2 和macOS 10.13.2中 我们引入了app预定

这是一个所有开发人员都会使用的 很棒的功能 你知道的 世界各地 以便在app在商店内上线之前 吸引用户对他们的app的兴趣 我们要很激动地宣布 今年我们引入了 watchOS 6.0 因此你可以直接在Watch中 销售你的app 并提前引起用户们的兴趣 比如可以让他们进行预订 但我们今年还做了另一件事 即将发布 我们将在app收据内暗示 app是否是作为预订所进行的购买 因此你会了解哪些客户预订了app 并且你可以用于…

给他们发送很棒的信息 比如感谢他们预订我的app 或者如果你想解锁一些附加内容 作为对某些最佳客户的回馈 你也可以使用收据中的那个信息 还有一件关于收据的信息 即它将 可以返回到iOS 11/12 时光倒流 收据中都可以使用此功能

那么这些是自去年演讲以来 关于StoreKit和 App内购买项目相关的信息 接下来我要把舞台 交给我的同事Tori 她将为大家谈谈 服务器到服务器通知的相关内容 Tori？ （服务器到服务器通知）

大家好 我叫Tori 今天能来到这里 我感到万分激动 我要跟大家分享服务器到服务器通知

我们有一些新功能 我们想引入服务器到服务器通知中 并且我想做一次深入的沟通 关于你要如何使用这些 来有效地监控你的订阅事件 但在此之前 首先让我们来看看 什么是服务器到服务器通知 以及如何设置服务器来接收这些通知

（什么是服务器到服务器通知？） 那么服务器到服务器通知 是我们通过JSON串从服务器 发送的HTTP POST请求 你可以通过它们的曾用名识别它们 statusUpdateNotifications 服务器到服务器通知对于 在你的订阅事件上 获取当前更新来说非常有用 用于重获客户 比如订阅优惠 一旦你决定了你想在那个终端 接收服务器到服务器通知 你所要做的就是从那个终端 返回一个200响应 表明已成功接收信息 然而如果你不返回200响应 我们将最多重试三次 重新给你发送通知

一旦你已经确定了这个终端 你首先要在App Store 连接中把它设置好 你可以在你app的app信息页上 找到这个地方 在订阅状态URL部分 （设置你的终端）

除了在App Store 连接中设置终端 当然还有连接必须遵从的安全性要求 便于你成功地接收这些通知 基本上 总的来说就是 连接必须遵守app传输安全条款 或ATS 它意味着很多事 首先必须由一个受信任的认证机构 颁发证书 （设置服务器） Transport Layer Securit版本 或TLS版本必须是TLS 1.2 你必须使用 所提供的对称密码算法中的一种 并且证书必须通过 SHA-256及以上的算法 来签署和颁发

我希望通过全部这些信息 你会更好地理解 什么是服务器到服务器通知 以及如何设置它们 如果要了解更多信息 请在developer.apple.com上 查询statusUpdateNotifications 相关的文档

现在我们已经了解了 什么是服务器到服务器通知 以及如何接收它们 现在我要很激动地分享一些 我们引入到服务器到服务器通知中的 新功能和新通知类型 那么当我们考虑 要添加到通知中的一些新功能时 我们查看了一下 当前通知中的收据字段 最新收据和最新收据信息 我们注意到这些收据 虽然有用 但仅提供了app内最新购买的信息 因此我们就思考如何让它变的更有用 如果我们可以提供完整的订阅历史 当我们给你发送 服务器到服务器通知时 为此 我们对服务器到服务器通知 引入了统一收据

（统一收据） 那么回顾一下 统一收据包含 从订阅服务中进行订阅购买的历史 以前 这个非常有价值的信息 只能通过点击 verifyReceipt获取 目前通知中的两个收据字段 最新收据和最新收据信息 提供一个加密和解密交易型收据 关于app内的最新购买 从秋季开始 你将会在服务器到服务器通知中 看到一个新字段 我们决定把它叫做统一收据 它将包含几乎全部 你期待从统一收据中获取的一切信息

通过在服务器到服务器通知中 添加统一收据 在大多数情况下 这将使最新收据和最新收据信息 变得不再需要

然而有一个重要警告 我们必须在这里声明 我们为你生成的这个收据 并没有绑定设备上安装的特定app 就和你平时 购买之后收到的收据一样 为此 收据应该要一直保存在 你的服务器上 永远不要保存在本地设备上 （未绑定app的特定安装 应该一直保存在服务器上）

那么 把它放在一边 让我们看看你可以从 服务器到服务器通知中的统一收据中 获得哪些信息？ 你从这个JSON对象中 发现的第一个字段是最新收据 这是一个加密统一收据 是我们刚刚为你生成的 稍后你可以用它点击验证收据 如果你需要的话 你还将发现最新收据信息 它包含针对你的订阅服务 所做出的订阅购买的数组 其中含有与之相关的元数据 用于帮助你追踪你的订阅者身上 发生了什么 （统一收据） 你还将发现待决续订信息 它包含 针对你的订阅的即将到来的续订信息 比如客户是否处于价格上涨的流程中 或者他们是否进入了计费重试周期 我们还将包含收据状态 以及收据所生成的环境 要么是沙盒 要么是生成 我们选择以此方式命名字段 因为这反映了你可以从验证收据中 接收哪些信息 希望你可以在那里 重新使用你的解析逻辑 从而让交易变得更简单

然而… 最新收据信息将仅限于 最新的100个App内购买项目 那么如果你需要更多信息 你可以通过所提供的加密收据 点击验证收据

让我们看看当前有哪些通知类型 目前有四种现有的通知类型 初次购买 交互式续订 变更续订偏好以及取消 我们又增加了四个 变更续订状态 续订失败 追回 以及涨价同意

现在让我们快速看看 每一个新通知类型 以便我们了解为什么要发送它们

首先让我们看看变更续订状态 当用户变更是否自动续订时发送 实际上你应该立即收到这个通知 从而确保你正在查找它 如果你目前正在使用我们的 服务器到服务器通知的话 （新通知类型） 我们即将添加一个 叫做续订失败的通知类型 当用户在订阅周期中 首次尝试续订而自动续订失败时发送 你将在秋季看到这个通知

和续订失败一起添加的还有追回 当我们在账单重新发送周期中 追回订阅计费时 发送追回通知 这也将在秋季上线 如果你收到了追回通知 你最近一定收到过续订失败通知 并且你可以了解订阅计费 已被成功追回 如果你当前使用了我们的 服务器到服务器通知 你可能注意到我们将发送追回通知 当我们当前发送续订通知类型时

我们计划让追回通知最终取代 续订通知 因为它的命名更恰当 但在过渡阶段 当我们发送追回通知时 我们会同时发送追回和续订通知 给你一点适应时间

最后 我们添加了第四个通知类型 涨价同意 当我们检测到你的某个订阅者 已经进入涨价流程时 给你发送涨价同意 那需要他们的同意 以便他们能继续续订 针对这个通知 我们在JSON payload中添加了一个新字段 涨价有效日期 这是客户必须同意涨价的日期 以便他们可以继续续订 你也会在秋季看到这个通知

那么现在我们已经了解了 服务器到服务器通知中的新功能 我要很激动地跟大家分享 如何处理全部八个通知类型 从而最大限度地利用每一种通知 当你收到它时 （处理通知） 那么首先 让我们快速回顾一下 我们现有的通知类型 初次购买 交互式续订 （现有通知类型概览） 变更续订偏好以及取消 我们要花点儿时间 深入了解每一种通知类型 但在此之前 我想让你注意一下 这个图表上的一个趋势 你会注意到 在JSON payload中 我们要求你针对每一种通知类型 查找原始交易id 这是因为原始交易id 被看作是订阅的唯一标识符 并且持续追踪这个信息 会帮助你把随后事件链接回 订阅的初始购买

现在让我们想象一下 如果你有一个潜在订阅者 让我们叫他John 并且他有兴趣购买你的订阅服务 让我们具体操作一下 John关于订阅所做出的决定 以及在此过程中你会收到哪些通知

（当前通知类型概览） （首次购买订阅） 那么你期待收到的第一个通知类型 是首次购买 当John首次购买订阅服务时 我们会给你发送初次购买通知 收到这个通知之后 你可以在你的服务器上 把客户状态更新为 比如“活跃”或“已订阅” 并为新购买的订阅提供服务 在这个通知类型中 让你在JSON payload中 查找四个字段 第一个是购买日期 它可以精确到毫秒 它会告诉你 客户购买订阅服务的具体日期和时间 接下来你应该查找原始交易id 正如我所提到的那样 这是订阅服务的唯一标识符 持续追踪它 会让你把随后的通知 链接回这个初次购买

你还应该查找网络订单行排列项id 这是每个订阅周期的唯一标识符 并且如果你在收到这个通知后 点击验证收据 它将把这个通知链接到 verifyReceipt数组中的某个条目

最后你应该查找产品id 产品id会准确地告诉你 你的新客户订阅了哪个产品

因此在John使用订阅服务 一段时间之后 他决定把服务升级到一个更高的等级 我们提前考虑到了这种续订 因此我们会给你发送一个 交互式续订通知类型 （潜在的续订） 因为升级… 会立即为客户提供更高等级的权限 我们还将针对 已取消的较低等级的订阅 给你发送一个取消通知类型 然而 如果客户在流失了一段时间后 又重新订阅 你只会收到交互式续订通知类型

在这个通知中 你该在JSON payload中 查找另外四个字段

第一个是购买日期 这会告诉你 客户重新订购这个订阅服务 或升级服务的具体日期和时间 你应该再一次查找原始交易id 从而把它链接回原始订阅

以及网络订单行排列项id 这对于每个订阅周期来说 是唯一标识符 它会帮助你把这个通知链接到 verifyReceipt 数组中的某个条目

最后查找产品id 这会告诉你 客户重新订购的具体产品 或升级到了哪个等级的产品

不久之后 John决定把订阅的等级 降低到更基础的等级 在这种情况下 我们会给你发送 变更续订偏好通知类型 收到这个通知之后 你可以在你的服务器上 把客户的订阅状态 更新为一个更基础的等级 在这个通知类型中 我希望你查找两个字段 （订阅降级） 第一个是自动续订产品id 因为续订降级不会发生 除非订阅周期结束 这会准确地告诉你续订时 客户将自动续订哪个产品

你应该再次查找原始交易id 以便把这个通知链接回原始订阅

（客户服务部执行退款） 现在很遗憾 不久之后 John拨打了客服电话 并决定取消订阅 在这种情况下 我们会给你发送一个 取消通知类型 正如我之前所提到的那样 当客户升级订阅时 你将收到一个取消 外加交互式续订通知 而取消意味着 取消较低等级的订阅

在这个通知类型中 首先你应该查找取消日期 这会告诉你 客户决定取消订阅的具体日期和时间 你仍然要查找原始交易id 从而把它链接回原始交易购买

以及产品id 从而精确地了解 客户取消了哪个产品的订阅

那么现在我们已经了解了 全部现有的通知类型 让我们同样地来了解一下 我刚才介绍的四种新通知类型 它们分别是…

变更续订状态 续订失败 追回 以及涨价同意 （新通知类型概览） 在这些通知类型中 你仍然想在 每个JSON payload中 查找原始交易id 正如我刚才所提到的那样 这是因为它是订阅的唯一标识符 它会帮助你把所有的通知 都链接到一起

现在让我们再次访问John （自动续订状态变更） 有一天他正在滚动浏览 他的订阅管理页面 并决定再次自动续订 在这种情况下 我们会给你发送 一个变更续订状态通知类型 你还将在客户决定 关闭自动续订时收到这个通知 收到这个通知后 你可以在你那端更新客户的订阅状态 从而响应此次变更

或者你还可以部署保留政策 从而留住客户 如果你看到他们已经关闭 自动续订的话

在这个通知类型中 你应该查找并记下另外四个字段 第一个是自动续订状态变更日期 它会告诉你客户自动续订状态 发生变更的具体日期和时间

你应该查找自动续订状态 它会告诉你是否开启自动续订 如果你知道自动续订状态 有一个值为真 你就可以了解 客户已经开启了自动续订 并打算继续购买你的订阅服务

你应该再次查找原始交易id 从而把它链接回原始订阅购买 以及产品id 从而了解客户针对哪个产品 开启或关闭了自动续订

当我们在自动续订阶段 尝试对John的订阅计费时 我们很遗憾地遇到了计费报错 在这种情况下 我们将在 那个订阅周期中的首次续订尝试时 给你发送续订失败通知 收到这个通知后 你可以选择推迟对客户的服务 你还可以把客户的订阅状态更新为 比如“活跃”或“计费重试” 取决于JSON payload中 所看到的字段值 那么现在 让我们具体看一下 在这里你要查找的第一个字段 在计费重试周期中 它的值为0或1 它会告诉你 我们是否正在积极尝试 追回订阅计费 如果你看到这个字段的值为1 你就会了解我们正在尝试 追回订阅计费 在计费重试周期中

你仍然要查找原始交易id 从而把它链接回原始订阅 以及截止日期 这会表明我们尝试自动续订的 具体日期和时间 并且它已经失败了 （计费重试中的订阅追回） 很幸运的是在计费重试阶段 John的订阅计费问题已经解决了 并且我们可以追回 对他的订阅的计费了 在这种情况下 我们会给你发送一个追回通知类型

提醒一下 追回通知 正在取代我们目前 正在发送的续订通知类型

收到这个通知类型后 你可以追回要追回的订阅 并把客户状态更新为 比如“活跃”或“已订阅” 或任何表明是活跃的订阅者的表述 在这种通知类型中 我还希望你在payload中 查找其它几个字段

首先你应该查找购买日期 这会告诉你具体何时 我们会追回对这个订阅的计费

你应该再次查找原始交易id 因为它会告诉你 我们到底追回了对哪个订阅的计费 因为它是订阅的唯一标识符

最后查找到期日期 它会告诉你 新订阅周期的到期日期和时间 你可以期待我们再次尝试自动续订

（客户进入涨价流程） 现在让我们假设你们开发人员 决定增加订阅服务的价格 我们何时检查某个订阅服务是否涨价 在周订阅续订之前七天 在月订阅续订之前十天 在年订阅续订之前30天 我们发现你希望涨价 我们将给你发送一个 涨价同意通知 收到这个通知后 你可以在你那端 把用户状态更新为“涨价” 或者你可以部署app内消息 提醒你的客户同意涨价 请注意我们还会给客户发送邮件 及推送通知 提醒他们同意涨价

在这个通知类型内 我还希望你查找其它字段 首先你应该查找价格同意状态 它将告诉你 客户是否已经同意涨价 然而因为我们会给你发送这个通知 几乎是一检测到涨价就发送通知 在绝大部分情况下 你应该期待这个值为零 否则就是客户尚未同意

你应该再次查找原始交易id 从而把这个通知链接回原始订阅 最后我希望你查找截止日期 这会告诉你这个订阅周期 到期的日期和时间 到那时候 你的客户将不得不同意涨价

（订阅周期） 那么现在我们已经了解了 服务器到服务器通知相关的新功能 以及你要如何处理这些通知 当你收到它们之后 我要邀请 Manjeet Chawla上台 为大家谈谈订阅周期 以及减少流失

早上好 我是Manjeet Chawla 是App Store商务部的员工 今天能与大家一起分享 我感到万分激动 关于如何使用服务器到服务器通知 中的新功能以及改进的功能 来识别订阅周期中的计费事件 那可能会影响你客户的订阅状态

那么订阅周期是什么样的呢？

现在你可能通过提供免费试用 来获得新客户 或通过推广价吸引他们关注你的服务 并允许用户在支付全款之前 试用你的服务

接下来你要保持用户 黏附在你的服务中 通过为他们提供持续更新的内容

最后你尝试通过最小化流失 把他们保留成为活跃的订阅者

现在我们都知道在这个周期中 对于绝大多数订阅者来说 会出现各种各样的计费事件

你现在很可能是通过调用 verifyReceipt终端 来让订阅者获取这些计费事件变更

现在我们知道这样效率不高 并且代价也很大 随着订阅业务的增长

但是我们之前对服务器到服务器 通知所做出的改进 你不再需要依赖于收据 来反映这些计费事件变更了 因此让我们更多地谈谈 如何使用新服务器到服务器通知 来检测这些计费事件 并为你的客户创建最佳订阅体验

让我们从初次购买订阅服务开始 现在我们都知道这个初次购买 是客户可以在某段时间内浏览内容

当客户在你的app中 购买了订阅服务 你将通过设备上的StoreKit 收到一个交易通知 以及与那个交易相关的收据

与此同时 你将收到 关于新购买的一个新通知 叫做初次购买 使用这个通知 你可以识别新购买的订阅者 之前从未购买过你的订阅服务

现在你抓住那个 初次购买通知JSON 与此同时你会从设备上发送一张收据 到你的服务器上 通过安全连接 发送到verifyReceipt 终端以验证收据的内容

在App Store返回的响应中 你要检查JSON的内容 并更新用户数据库 通过查找 用户所做出的最后一次购买

最后你之前保存的那个通知 你可以通过这个 verifyReceipt 把来自App Store的 响应链接到 初次购买通知 通过使用原始交易id 以及网络订单行排列项id

现在当订阅服务已经准备好 可以续订之后 App Store会在后台 自动为你续订 当用户下一次在设备上打开app时 你将收到一个新交易通知 以及一个与该交易相关的收据

你再次以base64加密那个收据 并安全地发送到你的服务器上

假如你的用户正在一个不同的平台上 使用他们的服务 并且你不希望依赖于 用户打开app来检测续订 你还可以使用你之前 从初次购买中存储的收据数据 并将其发送到你的服务器上

接下来你要把它发送到 verifyReceipt终端 并在JSON响应中检查续订交易 （续订） 在响应中 你可以验证该用户的最新续订 并根据那个续订更新最新到期日期

最后你要保持对客户的服务 因为订阅已成功续订

请注意对于这个事件来说 没有服务器到服务器通知 因此你必须根据 从初次购买中获得的信息 来调用verifyReceipt 从而检查续订交易

现在假如客户一直喜欢你的服务 并且他们觉得基础订阅很不错 并且他们决定升级到高级产品 也许是高等级的服务 （升级） 现在对于这个升级 你将在你的服务器上收到取消通知 来自于App Store

并且JSON内容中 将包含一个取消日期 通知你App Store 已经为用户 取消之前的订阅

取消通知之后 你还将在你的服务器上收到 一个交互式续订通知

这个通知用于更新用户的数据库

更新升级日期 那么现在你知道这个用户已经把订阅 升级成了一个高等级的服务 或者是高级产品

最后你要在app中 为用户解锁高级内容

（取消） 现在… 在某种情况下 客户觉得这个内容并不适合他 并且他想取消订阅 他们可以通过 在设备上的管理订阅设置中 关闭自动续订来实现

现在… 你可能想依赖于收据 来反映最新续订状态 你甚至可能调用全部客户的 verifyReceipt 仅仅是为了获取 他们最新的订阅的续订状态

我们刚刚讲过了 Tori刚刚提到了新通知 通过使用新通知 你就不需要再依赖于 verifyReceipt 来获取续订状态变更了

现在每当用户 从管理订阅设置中 关闭自动续订状态时 你就会获得变更续订状态通知

你使用这个事件把续订状态 更新为假 因为在这个情况下 用户关闭了自动续订

并且你还要更新他们的订阅状态

现在假如你没有收到 关于这个用户的其它通知 直到订阅周期结束

你就可以假设 在当前订阅周期结束后 流失了这些客户

因此你可以把用户的订阅状态 更新为“不活跃”或“已流失”

随着时间流逝 因为你的订阅者会流失 你一定希望试着把他们重新拉回来 通过提供一个很有吸引力的优惠 要么是折扣价格 要么也许甚至是免费试用

我们最近发布了一个新功能 叫做订阅优惠 它允许你提供折扣价格或免费试用 从而保留现有订阅者 或重获之前流失的订阅者 （重获） 今天稍后有一场关于 订阅优惠的演讲 我的同事们将分享一些最佳范例 关于实施订阅优惠 以及关于如何使用订阅优惠 来增加客户保留数量的不同的用例

现在让我们看一个 稍微有点不一样的情况 用户没有取消订阅的意图 但App Store不能代表用户 追回或续订 （计费错误） 也许是用户的信用卡过期了 或也许是他们的账户中资金不足

对于这个事件 App Store现在会给你发送 续订失败通知 使用这个通知 你会了解用户的订阅 由于计费问题续订失败了 并且你可以把客户的订阅状态 更新为“不活跃”或“已流失”

你可以使用这个通知 在app内给他们显示一条消息 让他们知道他们的订阅已经到期

（计费重试） 现在对于计费相关的问题 App Store 会自动做几次尝试 尝试续订 如果某次尝试成功 并且如果你允许客户订阅该服务 你将收到一个恢复通知 那么使用这个通知 你可以把那个客户的用户数据库 更新为“已订阅” 并且你会注意到那个新续订 有一个新的到期日期

然后你就可以为该客户重新启动服务

（减少无意识流失） 那么现在我们在上一个例子中看到 App Store会在一段时间内 数次尝试续订 现在这是自动发生的了

但你作为开发人员要如何 响应这些尝试 以及要采取什么措施来减少 无意识流失呢？

去年 关于订阅的实施 我们谈到了我们扩展的计费重试逻辑 那会在一段时间内尝试续订

当由于计费问题导致续订失败时 会部署这个逻辑

自发布之后 我们一直在持续地更新 并使它与优化追回策略相协调 我们还查看了先进的机器学习模型 用于改进在整个平台内 追回订阅的方式

我们查看了一下它自发布之后的性能 你可以看到我们可以追回 由于计费问题 导致订阅失败的77%的订阅 （计费重试性能） 通过追回这些订阅 我们能把整个平台无意识流失率 降低为不到2%

通过我们对计费重试策略 所做出的更新和改进

我们可以追回4600万次订阅

（追回4600万次订阅） 否则这些订阅就会流失 但是用户却没有要取消服务的意图 用户会续订并享受他们的服务 并且他们不想取消订阅 并且我们看到在整个平台上 一半以上的这种订阅仍然是活跃的

现在因为我们了解了 我们如何追回这些订阅 在一个为期60天的时间段内 （追回率） 你可以看到 我们在为期60天的时间段内 追回了由于计费问题 导致续订失败的77%以上的订阅

其中80%以上的追回 发生在前16天

当我们追回这些订阅时会发生什么？

首先你要再允许服务 正如Tori刚才所提到的那样 通过新通知 你可以对该客户重新启动服务 当他们下一次尝试获取服务时

我们就为那个订阅开始了一个 新的计费周期 自执行追回操作之日起

并且客户朝着 更高的收入分成的目标85/15 所累积的付费服务的天数将从 开始执行追回之日起开始恢复计算

那么… 如果你在此期间为客户提供服务 从他们开始计费重试到追回之日 你很可能会漏掉这些天的收益

我们该如何改进呢？

那么今年秋季 我要非常激动地宣布 我们即将发布一个新功能 那会允许你提供一个计费宽限期 给客户们一些额外时间 当他们享受他们的服务时 他们拥有对那些付费内容的权限 并且它允许开发人员获得额外的收益 针对你在这些天内所提供的所有服务 （计费宽限期概览）

这为你的所有客户创建了一个 更好的体验 他们在一段时间内自然而然地被追回 因为他们从未表达过取消服务的意图

这还会追回 也许账户中有临时信用卡的客户

现在让我们看看要如何实施这个功能 嗯 非常简单 实施计费宽限期需要三个简单的步骤

首先通过App Store连接 选择提供宽限期 以便提供宽限期的预配置持续时间

根据我们之前看到过的追回数据 我们要针对周订阅 开始为期六天的宽限期 而其它是16天的宽限期

接着在verifyReceipt 响应中查找一个新字段 或在通知中 这将允许你了解 服务的最新到期日期 （账单宽限期的实施） 并且你在这段时间内 要保持对客户的服务

现在你可能会想

作为开发人员 为什么要选择提供计费宽限期？

嗯 有许多好处 首先… 客户从未有过取消订阅的意图 因此他们喜欢一直获得你的服务 而不想中断

这就允许你 或你的客户维持现有的计费周期 当我们在这个计费宽限期内 追回他们的订阅时

并且它可以让你 作为开发人员 可以…

赚取额外的收益 对于你在计费宽限期内所提供的服务 （计费宽限期的好处） 并且正如我们之前所看到的那样 它允许客户以更快的比率累积 成为那些较高的85/15 收益分成的付费天数

我非常鼓励你们 了解订阅的宽限期 当我们稍后在今年秋季发布后

现在… 除了提供宽限期 你还可以做哪些操作 减少整体无意识流失和增加追回？

在这里让我们看一个例子 在app内 通过给计费重试状态的客户 显示情境消息 你可以让他们了解他们的订阅 失败了 因为计费问题 （计费重试客户消息）

并且如果你提供宽限期 你可以让消息侧重于 你为客户提供的宽限期服务 你可以在设计这条消息方面 发挥你的创造力 它要发生在宽限期结束之前 也许你正在提供高级内容 并且他们会在宽限期结束后 失去对那部分内容的权限 那么 突出这一点…

宽限期结束后 他们会失去对高级内容的权限 这将帮助你追回那些订阅

在这里让我们看一个app Foodvisor 给计费重试阶段的用户 显示了一条消息 并为他们显示 能浏览高级内容的剩余时间

在这条消息中 你还可以嵌入一个 付款详情页面的深链接 然后客户就会去解决计费问题

正如你所看到的 我们最近已经更新了 这个付款详情页面 允许客户 在账户中拥有最多十种 不同的付款方式

除了为客户提供 更简单的付款管理选项 这还帮助App Store 减少整体的无意识流失率 通过用存档的可替换的付款方式收费

我们在这场演讲中涵盖了许多话题 但总结一下

我们谈到了订阅优惠 我们最近发布的新功能 帮助你减少自发流失率 通过为客户提供折扣价格 或免费试用 从而保留他们的订阅 Dona给我们详细介绍了实施 新API SKStorefront代码 用于给世界各地的客户 显示正确内容 （总结）

我们谈了即将发布的一些收据变更 允许你回馈 预订app的忠实客户 也许是给他们提供游戏的初始余额 并且如果你还没有这样做 请查看 服务器到服务器通知 并在App Store连接中 添加那个URL 以便获得来自App Store 的计费事件的通知

我们讲了宽限期 以及如何提供宽限期 以便增加由于计费问题 导致续订失败的客户的追回率

并且我们讲了情境消息 你可以在app内显示 用于追回更多的订阅

要获取关于本演讲的更多信息 以及本演讲的视频 请查看演讲302 并且今天下午 我的同事们将分享 关于订阅优惠的最佳范例 他们将告诉你如何实施订阅优惠 以及使用订阅优惠 减少自发流失率的不同用例

并且我们会在讨论会中 解答关于这些功能的任何疑问

谢谢大家 祝大家下午愉快