订阅服务架构

（你好 WWDC 2020） （大家好 欢迎参加 WWDC）

大家好 感谢观看《订阅服务搭建》视频 我是 Michael Gargas 来自 App Store 商务团队的技术顾问 非常开心为大家介绍有关 如何在 Apple 平台上构建 和维护订阅服务的一些新概念 （订阅服务搭建 受众） 我们不仅希望 能为业务和架构搭建带来帮助 也希望服务端团队和数据分析师从中受益 无论你的 app 已经提供订阅服务多年 还是刚刚开始 本视频都能提供有价值的信息 帮助你搭建系统权限架构 你可以从中了解 服务端系统搭建或重建的多种方式 以便充分利用 Apple 不断推出的新功能 要构建成功的订阅平台 有必要掌握订阅者旅程 在此基础上我们可以定义订阅权限 构建自定义逻辑 利用权限引擎将其付诸实践 为订阅者打造量身定制的体验

下面我们来详细了解订阅者旅程 以及不同的订阅者操作 所产生的各种复杂状态 （掌握订阅者旅程） 以前可能只根据 一两个收据字段就能授权访问 比如产品 ID 和到期日并确定 是用户还是订阅者 是否活跃 （订阅者状态 活跃 不活跃） 我们推出了新功能 比如“账单重试”和“宽限期” 这些收据字段的组合变得越来越复杂 因此需要对 app 收据 本身足够了解才能掌握它们 （掌握订阅者旅程 订阅示例） 下面我们来看日历视图的订阅示例 这里是为期一个月的产品 5 月 1 日购买的 接下来我们详细研究下 看一下不同的订阅者操作 对订阅者状态的影响 （基本订阅） 有关 5 月 1 日购买的基本订阅项目 Apple 会给开发者 发送服务器对服务器通知 说明发生了初次购买 若订阅者没有采取后续操作 我们会在下一个 1 日进行续订 不过比如说订阅者选择取消订阅 （自愿流失） 这里我们看到 依旧是 1 日购买的订阅项目 不过订阅者 打开了 App Store “管理订阅”设置 选择了取消订阅 这时 Apple 会给开发者发送 服务器到服务器通知 告知你订阅者禁用了自动续订状态 如果没有后续操作 该用户将自发流失 不再使用你的订阅产品 这会通过 收据响应中的 expires_date 和 expiration_intent 字段表示

（账单重试） 在这个例子中 如果 Apple 没有成功从用户卡中为续订扣款怎么办？ 还是相同的例子 1 日的初次购买通知 这次 Apple 没能在下个计费周期 成功从用户卡中扣款 而用户打开了 App Store 中的“付款信息”设置 更新了资料中的付款方式 这时 Apple 会给开发者发送 服务器到服务器通知 说明订阅者进行了续订 我们会继续在下个 15 日为用户进行续订 （宽限期） 如果作为开发者的你 启用了宽限期怎么办？ 这个例子中 还是 1 日购买的订阅产品 在下一个续订日期我们未能更新卡片 然而 启用宽限期之后 16 日以内恢复订阅 就可以保持账单日期的连续性 因此 可以看到 Apple 会在下一个 1 日 继续为订阅者续订 每个订阅者旅程都是独一无二的 理解这一点很重要 正是因为这样 我们需要掌握所有的收据字段 Apple 因用户操作而发送的信号 以及具体用户操作带来的 不同状态 （额外的注意事项） 这些例子说明了订阅状态如何 快速超越活跃和非活跃的状态 基本操作比如升级或降级甚至是跨级 以及复杂的账单状态 比如“账单重试”和“宽限期” 也会带来通知或操作的机会 有助于打造更好的用户体验 减少用户流失 使转化率最大化 （使用 App 内购买项目） 在以往视频中 我们重点介绍了一系列工具和功能 帮助改善订阅服务 无论是帮助处理付款的 StoreKit 框架 服务器到服务器通知或者改进的收据数据 它们都为在 Apple 平台上 构建有吸引力的订阅服务 奠定了基础 （App 内购买项目新动态） （App 内购买项目 及服务器到服务器通知的使用） 我强烈建议你观看这些视频 确保掌握现有的以及全新的功能 之后会在你的 app 中集成 为准确回应用户操作 （购买过程） 我们需要仔细探讨订阅者状态 （确定群体 参与 获取 提交 购买） 可以看到 确定订阅者状态 是购买过程的关键环节之一 这有助于作为开发者的你 充分了解想要为终端用户打造的体验 无论是提供订阅服务 还是因为退款取消服务 理解订阅状态是关键 （订阅者状态）

当考虑订阅状态时 我们需要了解订阅者之前的状态 当前的状态以及将来可能会发生的事件

对 app 收据中数据的深入了解 是理解订阅状态的关键 （每一个续订事件都是一个静态输入） 收据中的每一个续订事件 都是一个静态输入 及时显示订阅者当时的状态 （AppReceipt JSON 字段组合创建状态） 可以通过查看 不同收据字段值的组合来推断状态 （订阅状态带来量身定制的体验） 你可以使用这些状态 为特定订阅者打造独一无二的体验 并在 app 体验中采取任何相关操作

仔细研究后发现 显而易见有多种不同的状态 订阅者可以是任何状态 这些状态是不同收据值的组合 比如到期日值设为将来 自动续订状态设为一 代表活跃和开启自动续订

对于每一个状态 我们也定义了相关的子状态 用于说明用户在使用怎样的服务 比如免费试用或者订阅服务

现在我们更好地了解了 订阅者状态和子状态背后的复杂性 下面我们来看下实际情况是怎样的 以及作为开发者的你要采取 哪种操作或通知 接下来我们详细探讨 五种不同复杂状态的示例 以及需要因此而采取的操作 （复杂的订阅状态 留存） 如果想要确定订阅者的状态 我们必须查看最新的收据数据 （收据数据 活跃） 表面上如果我们只关注到期日的话 可能就只看到“活跃” 在查看并尝试确定订阅者状态时 作为开发者的你应该查看最新的收据数据 表面上 如果只使用到期日 那么看到的就只是“活跃” （活跃（自动续订关闭）订阅优惠） 但是如果我们再仔细研究一下 就会发现我们可以 基于用户的自动续订状态和当前订阅产品 提供留存订阅优惠 这里 订阅者已经使用了订阅优惠 作为开发者 你可能想要使用后续优惠留存他们

（账单重试到期 标准订阅） 如果我们使用同样的逻辑继续研究 可以看到该用户订阅已过期 但状态却是“账单重试” 表明 Apple 仍在尝试收取续订费用 在这个例子中 作为开发者 你可能想展示一个把订阅者 深度链接到 App Store 账户的 固定横幅 以便更新他们的付款信息 （宽限期到期 订阅优惠） 在宽限期的例子中 我们还可以 通过这些具体的收据字段 来确定用户处于宽限期 优惠可以通过天数倒计时的方式来展示 这也可以深度链接到 订阅者在 App Store 中的付款信息 便于用户更新并恢复订阅 （赢回 账单过期 标准订阅） 另一种提供量身定制体验的方式是 赢回订阅已到期的用户 在这个例子中 我们可以看到用户订阅到期的方式 他们最初订阅的是什么产品 提供推送通知 推广现有的市场优惠 赢回用户

需要注意的是这个推送通知 仍然需要把用户深度链接到 app 中适当的付款屏幕 （升级 活跃（自动续订开启） 标准订阅） 最后 作为开发者 你或许想通过推广潜在的升级方案 为订阅者打造更好的体验 在这个例子中 你可能注意到 用户购买了一个月的产品 通过多个连续的阶段来续订 你可以推荐升级至年度订阅 提供折扣并奖励最忠实的订阅者 （复杂的订阅状态） （状态 标准订阅 免费试用 首次优惠 订阅优惠） 我们了解了五种状态和子状态 不过可以看到 并不只有活跃和不活跃这一种状态 根据不同的订阅者操作 会有更多的潜在结果 这一点是定义订阅权限的关键因素 下面有请我的同事 Garrett 详细介绍有关权限的内容 大家好 我是 Garrett Cox App Store 解决方案工程师 （定义订阅权限） Michael 描述了订阅者旅程 正如我们看到的 订阅者可能有多种潜在的状态 权限过程需要解释这些潜在状态 首先我们来定义订阅权限的组成部分 （定义订阅权限 确定过程） 尽管内容访问是订阅权限的根本依据 但访问的范围注定很广泛 除解锁内容外 访问权限可能因地域可用性 账单状态和独特的服务级别而不同 在把产品展示给用户之前 我们必须确定他们符合资格 这也适用于 我们可能展示的升级和降级选项 产品展示的方式和时间 根据用户是否有资格享受折扣价而变化 比如免费试用或优惠

App Store 决定某些资格标准 比如免费试用 但是你可以根据业务需要 管理订阅优惠的资格

最后 你向用户传达的信息可以更有意义 而不仅仅是告知到期日期 量身定制的体验意味着及时沟通 优惠信息或关键账单问题 这在订阅者旅程中是变化的 鉴于订阅权限的这一定义 你需要构建服务端逻辑 分析涵盖订阅者旅程的所有订阅数据 我们暂且称它为权限引擎 这一分析数据 之后用于评估用户的服务权限 引擎需要支持订阅优惠的更改 以及用户可能呈现的账单状态变化

具体来讲 我们的引擎使用 收据数据和任何其他 app insights 来评估并使用正确的权限信息响应 （数据库 权限引擎 响应） （构建权限引擎） 在详细讲解我们订阅开发者 如何为权限引擎编码前 我想告诉大家 在和本次视频一起的文章中 我们会在 Node.js 中提供范例代码 展示这一过程的部分构建 帮助你入门权限引擎的构建 现在 我来演示这些环节 就像我们一起构建权限引擎一样 （权限过程 安全 API 网关） 这里更详细地总结了 使用我们的引擎所构建的权限过程 订阅数据包括收据和服务端通知 已放入引擎中 输出是一个简化的 JSON 负载 你可以使用它授权服务并更新用户数据库 （安全 API 网关 准备数据） app 收据是信息源 用于审查交易数据 （验证收据） 为此 我们的第一个环节是 验证所有收据的真实性 （确保准确性） 如果开始的收据过期了 这一环节应包含从 App Store verifyReceipt 端点 获取最新的收据信息 我们需要确保 使用最新的、没有过期的信息 来确定权限 （添加额外的 Insight） 我们还可以从系统中获取其他相关数据 或者收据中没有的 订阅者独有的上下文细节

如果你在多个 app 或者平台提供订阅 这一环节应包括传递 app 收据之外的 订阅者状态 确保他们不会被排斥在外 或通过另外一个订阅服务来购买 接下来我们将合成收集的相关数据 （合成） （分析交易数据） 这一环节相当于引擎的发电站 因为我们要把现有的信息压缩并转化为 可以操作的 insight

信息散布在 app 内收据中的多个 数组和字段 比如 latest_receipt_info 数组 和 pending_renewal_info 数组 我们想要这一过程彻底检查 形成权限的所有相关字段 （构建响应） 我们想要逻辑在数据上迭代 构建放在最终响应中的数据对象 （解决关键细节） 我们的重心是生成并绑定任何 有助于确定 用户订阅者旅程节点的关键细节 （响应对象 权限代码） 例如 我们想按订阅产品来组织响应 并包含所有必要信息 这一关键数据对于所有订阅服务都很宝贵 比如产品 ID、试消费或者到期日 我们现在更改权限代码 （观看小时数 活动预告） 此外 我们可以在收据之外添加 insight 这仍可能会影响权限过程 比如订阅者可能感兴趣的 观看小时数或者活动预告 现在我们把数据压缩成了有意义的细节 用于区分不同的订阅者群体 （群体 支持群体） 最初定义群体时 应包含所有一般的订阅账单状态 （定位订阅者） 根据订阅者状态划分的群体 我们可以基于订阅者在旅程中的位置 打造独一无二的体验 （订阅状态 状态） 鉴于我们把订阅者旅程分成了不同的状态 我们需要通过 Michael 列举的状态来区分订阅者 （状态 值） 这个例子中 我直接 为每一个状态分配了独一无二的值 你可以根据订阅需要修改或完善这些值 （订阅子状态 变体） 我也为子状态赋值 通过分配十进制数值 为具体的订阅产品创建独一性 （变体 值） （订阅状态和子状态） 这样 两者可以结合 代表一系列群体 简单来讲 正值代表我们会解锁访问的案例 而负值代表不会向 某个产品 ID 提供服务的订阅状态

即便我们使用正值和负值来定义通用访问 我们可以改进权限过程来关注独特的群体 （权限代码） 通过结合这些值 现在我们的权限代码可以代表产品的状态 我们可以把这个值 发送给客户端或者在服务端保存 既然是正值 该代码可以作为 解锁服务的简单信号 或者在这个例子中 既然该值的独特 insight 代表了 在免费试用期间禁用自动续订的活跃用户 那么它可以作为自定义操作处理

（授权 使用群体和 insight） 我们确定了订阅者的群体 接下来我们用它来 确定想要包含的权限信息 （应用权限） 在这一环节 我们主要是生成并绑定适合 订阅者独特群体的附加数据 （应用业务操作） 这一环节也可以 包含采取适用于每一独特群体的 特定业务操作 这里介绍了方法 （响应对象） 我们构建响应对象时 包含了权限需要的 必要密钥 并加入了与订阅权限有关的值 我们可以使用该陈述以及几个语句 定制权限用以包含复杂的状态 比如 Michael 提到的状态 （留存） 在订阅者禁用自动续订的留存示例中

包含权限代码 4.0 和具体产品的 if 语句 可以用来绑定留存信息甚至是优惠 （宽限期） Michael 提到的宽限期微妙状态 必须在宽限期用于解锁服务 但是既然我们已经定义了唯一的代码 我们可以用这个状态添加逻辑 覆盖更小众的操作 鼓励用户更新他们的账单信息 从而防止不必要的服务损失 （账单重试） 宽限期与账单重试区别不大 因此在提供有限访问时 我们可以设立类似的 账单信息更新目标 （赢回） 在这个例子中 我们可以使用权限信息 为选择取消服务的用户展示自定义优惠 （升级） 即便对于忠实的订阅者 我们也可以使用该权限代码 续订数和订阅组 ID 来建议升级至年度产品订阅 （响应） 我们终于到了最后一个环节 并生成了所有的必要权限信息 （响应/更新 同步数据库） 我们发送该数据 更新我们的数据库 确保准确同步并代表用户状态 （安全响应） 如果是用户设备请求该权限数据 我们应该将计算好的数据安全发送回设备 建议添加类似 JSON Web Signature 的东西 证明数据来自你的服务器 （使用权限引擎） 刚刚我们详细探讨了权限引擎逻辑的构建 接下来我们梳理下 了解如何在我们的系统架构中使用引擎

有几点需要注意 （权限架构要点 高可用性） 有一个高度可用的权限引擎 在发生更改时 我们可以使用最新的权限内容 来进行计算和响应 这样的可用性和所有的订阅状态一起 确保我们准确地授权订阅者 打造适当的体验 （准确性） 尽管准确响应是我们的使命 我们想要该过程在意外情况下也万无一失 （万无一失） 最后 我们构建的引擎 有足够的空间支持未来的功能 或者应对以后订阅业务发生的变化 （灵活性） （架构） 我们介绍了如何构建引擎来确认、验证 并适当授权服务 打造订阅体验 这里总结了在服务器架构中 最大程度发挥引擎作用的方式 （App Store 服务器 开发者后台 订阅者） 这一方法真的很强大 即便还只是处于订阅的入门阶段 （基本执行） 只是通过基本执行 不使用通知或存储 我们也能支持 Apple 提供的多种订阅功能 比如订阅优惠 此外 引擎在服务端运行 意味着权限逻辑的错误或者更新 可以使用收据或模拟收据数据解决及测试 然后快速部署 那样 新的入站请求 可以通过适当授权的访问回应 而不用依赖于客户端更新 需要注意的一点是我们需要设备发送收据 用于在所有请求中处理 如果不存储收据数据 我们也没有办法支持 web 或者其他平台 但是该方法是个不错的开始 甚至在我们遇到储存问题 或者是出于某些原因 未能处理 App Store 通知时 可以作为合理的应急方案 （添加存储） 但是这里迭代很容易 添加永久存储后 就变成把产生的权限信息 和收据数据发送到永久存储的问题了 过了这一关后 我们可以 通过 web 和非平台方式授权访问 （全覆盖） 但是这里我们应该添加一个端点 来接受和处理 App Store 服务器通知 在更新状态发生变化时 服务器会收到通知 而不是状态来选取 verifyReceipt 端点

这种情况下 我们也有多种方式应对故障 如果错过或没有处理通知 则使用永久存储的收据数据维持准确性 即便存储数据不准确 我们也可以更新权限逻辑 那样的话我们可以 直接把数据发送给权限引擎 并授权服务 直到我们使用存储把问题解决 如果你从本视频中学到任何东西的话 那就是通过构建反应灵敏的权限过程 你可以根据订阅者体验的复杂性量身定制

在此基础上你可以进行迭代 以更好地支持订阅者旅程

谢谢观看本次视频 希望你喜欢 WWDC 的其他部分