使用 StoreKit 2 和 App Store 服务器 API 为客户提供支持

David Wendland：大家好 我是 David Wendland 是 App Store 商业技术宣传员 今天很高兴通过 网络与大家见面 分享我们整个团队开展的工作 在开始之前 先请来自 Cupertino 的 同事们做个自我介绍 Manjeet Chawla：大家好 我叫 Manjeet Chawla 是 App Store 技术项目经理 Joe Mani：嗨，我是 Joe 担任 App Store 项目经理 David：我们三个人今天 将给大家做一个 由三个部分组成的序列讲座 “通过 StoreKit 2 和 App Store 服务器 API 为顾客提供支持” 我们将着重介绍 StoreKit 2 框架和 App Store 服务器 API 功能 如何改进 app 内购买项目 客户支持和退款处理 希望这三个部分能够给您带来一些 见解、方法和益处 供您在规划 app 和顾客体验改进时考虑 在 app 内购买项目部分 我先简要介绍 我们在秋季的发布 以及客户端、服务器 和沙盒中的新功能 接着来讨论一些 可以考虑的实施方法 帮助您在试图整合这些更新时 为您的计划制定战略 和确定优先级 首先从新功能开始 在 iOS 15 中 我们回到了起点 创建了一个全新改进的框架 来简化 StoreKit 2 的客户端实施 这带来了更多设备端功能 改进了状态信息 现在的交易 使用 JWS 格式来增强安全性 此外 我们推出了三个独立功能 在您的 app 中直接向顾客 提供更多的服务 在服务器端 我们通过发布版本 2 对现有的 App Store 服务器通知 进行了重大更新 这大大增加了受支持购买事件的数量 另外也采用了新的 JWS 格式 最后 我们随 App Store 服务器 API 发布了一套功能 它具有一系列端点 来支持不同的能力 包括检索顾客的购买历史记录 为订阅者提供当前订阅状态等 其他功能囊括了各种各样的 客户管理场景 我的同事 Manjeet 和 Joe 稍后会进行介绍 今年的详细更新列表说明 我们仍在继续投入力量到 使用 StoreKit 的 app 内购买项目 总体上这些更新改进了安全性 降低了复杂性 简化了在沙盒和 Xcode 中 测试 app 内购买项目的流程 在我们的平台上 借助触控 ID 和 面容 ID 等功能 我们利用安全的生物特征 和流畅的身份验证技术 让顾客通过超过 15 亿台设备 安全、便利地进行购买 App Store 每周访客数量 目前达到了 6 亿人次 涵盖 175 个店面 和 40 多种语言 您可以根据地区调整价格等级 未来一年我们也会将 支持的价格等级数量 扩大到 500 以上 为您提供更多的定价选项 针对每一货币和市场 提供定制的价格点 我们支持 45 种货币 和 195 种付款方式 竭力为顾客提供更大便利 让他们可以使用首选的付款方式 还可进行组合 在我们继续关注 这些平台改进的同时 现在来仔细探究一下 StoreKit 2 重点介绍相较于 初代 StoreKit 的优势和关键增强 供大家参考 StoreKit 2 有一项重要功能 可以在顾客的所有设备之间 自动同步新的 app 内购买项目交易 这有助于您在 app 中 提供一致且可靠的体验 此框架支持设备端购买验证 与旧版框架相比有所简化 因此您不必完全依赖于 服务器端购买验证 所有交易都将 使用 JWS 进行签名 使您能够验证 每一笔交易的真实性 框架也在设备端提供授权状态信息 不仅降低了复杂性 也让您能够确保授权访问的恰当性 iOS 15 中还引入了一个 新的 appAccountToken 您可以通过它设置 发起购买的 app 内帐户 并让它随完成的交易一起返回 另外还有一些独特的独立 StoreKit 2 功能可以跟 初代 StoreKit 框架 一同工作 如果您的 app 目前通过 iOS 15 使用初代 StoreKit 则也可添加这些 独立的 StoreKit 2 功能 以提供通常在您 app 之外 进行的 app 内购买体验 第一个是 showManageSubscriptions 这个功能可让订阅者 无需离开您的 app 就能管理他们的订阅 接下来是 beginRefundRequest 可用来向顾客显示交易 以便他们在您的 app 中 发起退款请求 您也可用它在沙盒中 测试和模拟从待定到 批准或拒绝状态的退款 我们还引入了一项功能 让您可以更轻松地检查 顾客的推介促销优惠资格 这很重要 因为在推销免费试用等优惠时 您需要确保 顾客在完成购买时 确实能够享受到优惠 有了 StoreKit 2 这项检查可以通过使用 isEligibleForIntroOffer 方法 并传入订阅组 ID 来轻松完成 它将检查顾客是否消费了 针对该订阅组中任何订阅的 任何一种推介促销优惠 此外 您也应当仅在 StoreKit 返回的情况下 推销推介促销优惠 这将来自于 Product.SubscriptionOffer 其中会返回可用的 推介促销优惠 详细信息 如果不可用 则 StoreKit 不会返回它 因而就能避免您推销 不可用的优惠 所以一定不要采用硬编码 而应让您的 app 利用 StoreKit 它将使用 App Store Connect 中配置的开始和结束日期 现在把话题转到服务器端 我们来探讨 App Store 服务器 API 的特性 它支持服务器对服务器请求 不需要任何顾客互动 我们来说订阅状态 这提供了与您 app 相关的顾客订阅的状态 如果您有多个订阅产品 则可以获得各个订阅的 授权状态 各自用一个 唯一原始交易 ID 表示 订阅状态有一个优点 它仅返回每个订阅的 当前 JWS 签名交易 因此不需要服务器端逻辑 去解析顾客的交易历史记录 就能确定他们当前的交易 或者要授权的产品 如果您是多平台服务提供商 可以随时以服务器对服务器形式 使用此服务来获取当前状态 不需要您的 app 处于运行状态 只需顾客的原始交易 ID 不再需要 app 收据 我们建议采用 这里的一些最佳做法 务必在每次购买或恢复交易后 将唯一的原始交易 ID 存储在您的数据库中 这个值代表每一个订阅产品 对跟踪订阅的生命周期非常重要 从初次购买到续订 再到账单问题和恢复 或者升级和降级 此 ID 可用于 顾客端和服务器 API 以及服务器通知 最后 作为一种 安全防护最佳做法 应当仅以服务器对服务器形式 使用订阅状态 如果需要直接 从 app 检查状态 StoreKit 2 框架 提供了解决方案 与服务器 API 相关 的下一功能是 app 内购买项目历史记录 您可以通过服务器对服务器方式 检索完整且最新的 顾客交易历史记录 历史记录将包含 所有非消耗型项目 非续期订阅 自动续期订阅 和任何未结束的 消耗型购买项目 全部都将是安全的 JWS 签名交易 现在 拥有交易历史记录 和所有原始交易 ID 将 有助于您实施 beginRefundRequest API 因为您需要显示交易 以供顾客选取 从而能发起退款请求 对于使用初代 StoreKit 的 app 内的非订阅型 app 内购买项目 您可以告别 verifyReceipt 并使用此 API 来验证成功购买 或检查更新以防服务中断 至于最佳做法 一些顾客可能有许多购买项目 而回复中一次最多 包含 20 笔交易 如果有更多交易 请务必使用 hasMore 字段 如果其为 true 则在该回复和 后续请求中使用 revision 标记 来获取下一页的交易 如此重复直至 hasMore 字段 返回 false 并存储该 revision 标记 以备日后使用 这可帮助您使用 记录的 revision 标记 快速检索顾客的最新交易 那样您就不必再次分页了 另一个重要的最佳做法是 在交付了产品或服务后 使用 finishTransaction 未完成的交易将保留在队列中 帮助您的 app 跟踪需要 交付给顾客的购买项目 以免发生任何设备端中断 这一点非常重要 最后一条建议与退款或 撤销的交易相关 如果您要尽可能快速、高效地 接收与这些交易相关的更新 可考虑使用 版本 2 服务器通知 其效率远高于轮询任何 API 现在来看看 我们的服务器通知 它们针对重要购买事件 和状态更新 以近实时方式 直接发送至您的服务器 今年推出的版本 2 大大优化了此功能 变得更有效、更易用 提供了更多粒度 我们将支持的事件数量翻了一倍 总共达到了 28 种 不同的事件 使用版本 2 时 每一事件仅发送一个通知 让您可以在收到通知后 采取特定的措施 这些通知也同样适用于 通过“家人共享”访问 app 内购买项目的 家庭成员 一旦发生通知递送失败 我们会在七天内重试最多五次 以考虑任何的服务中断 当然 版本 2 可在沙盒中使用 方便您安心地 在测试环境中进行开发 最佳做法是 在接收这些通知时 务必要在成功接收后 使用 HTTP 200 响应代码来回复 这可告知我们您已收到通知 并且不需要我们再次发送 如果您的服务返回错误 或不做回复 App Store 会重新发送 相同的通知有效负载 每个通知中 均包含 signedDate 您可知道原始通知的 确切发送时间 您也可以使用 JWS 签名交易信息 验证所收到通知的真实性 从而确信它们已得到 App Store 的签名 请务必利用新功能 为沙盒和生产环境的事件提供 唯一的服务器 URL 最后一个最佳做法 是要立即应用通知更新 一些事件具有高度时限性 例如升级或退款 因此 以近实时的方式 来处理这些事件 可能会大有裨益 我们要介绍的 最后一个新消息是 App Store Connect 中的更新 可以帮助您在沙盒中 测试 app 内购买项目 在“用户和访问”标签页中的 沙盒测试员下方 您可以找到这些功能 大家可能已经知道 为了支持测试 目前在沙盒中 可以加快订阅续订 现在我们添加了一项功能 可以按各个沙盒 Apple ID 减慢或加快续订速度 正如您在 Xcode 中进行 StoreKit 测试时一样 当您需要更多时间 完成续订之间的操作时 这应当有所帮助 为帮助对不同店面进行测试 您现在可以随时更改 沙盒 Apple ID 的店面 为进一步拓展单个沙盒 Apple ID 的用途 您现在可以清除自动续期订阅 和非消耗型项目的 购买历史记录 方便您重复购买内容 或兑换推介促销优惠等等 我们已探讨了 StoreKit 2 和 服务器 API 的 一些优势和最佳做法 现在来介绍 在准备将这些特性和 功能集成到 您的 app 或服务器时 可考虑的一些方法 想到 app 内购买项目 我们考虑的主要是 为顾客提供 购买项目授权 以及处理状态更改 为此 您必须要做出选择 要么采用设备端方法 一切都在本地进行 不使用任何服务器后端 要么是利用 服务器对服务器 API 以服务器作为您的事实来源 我们首先看设备端 StoreKit 2 框架 提供了一个功能 让您的 app 可以 完全在设备端 管理 app 内购买项目 和状态更改 不需要服务器的介入 对于小型业务和缺乏现有 服务器后端的企业而言 这是非常有帮助的 为此 您可以首先 利用 StoreKit 2 的 这三个核心函数 来支持购买流程 您的 app 将使用 Products 来检索您供应的产品 及其详细信息 以推动您 app 内的推销 这可确保信息始终准确 并与 App Store 保持同步 StoreKit 2 发布后 您可以将 VerificationResult 和 PurchaseResult 组合起来用于 在成功购买或恢复交易后 验证交易的真实性 StoreKit 2 框架的 另一个关键优势是能够 让 app 掌握 所有交易的最新信息 顾客可能拥有多台设备 借助 Transaction.updates 不管交易源自于哪一台设备 您的 app 都可以保持同步 利用 currentEntitlement 方法 您的 app 可以快速获得 顾客购买记录的即时状态 以便将这些产品 立即授权给顾客 而不需要他们登录 或执行“恢复购买项目” 因为您已掌握了 最新的交易详情 最后 我们理解在设备端获得 自动续期订阅信息的重要性 不仅是产品本身的信息 也包括当前订阅者的状态 以及他们的下一个续订期间 Product.SubscriptionInfo 可用于此用途 借助刚才介绍的 这六个核心函数 您可在 iOS 15 上 充分利用 StoreKit 2 减少或消除对服务器的依赖 为顾客提供出色的体验 现在考虑一下 服务器对服务器架构 这对多平台或多 app 服务 至关重要 因为顾客希望能够 可靠地访问服务 您的系统必须要随时做到 实时更新其购买项目的 最新状态 通常在这种设置中 您会让自己的服务器 充当事实来源 全天候保持在线 以随时接收 并检查与 App Store 相关的更新 现在从 app 的角度 观察这个流程 我们这里有顾客的设备 假设您的 app 正在运行 使用初代 StoreKit 框架 发起购买 并使用 App Store verifyReceipt 服务器 来验证购买 这意味着您的 app 将在购买或恢复事件后 向您的服务器发送 Base64 编码的 app 收据 然后再发送到 verifyReceipt 服务器 App Store 将在回复中 提供顾客的交易 这时您的服务器需要 解析这些交易 以评估并确定其状态 以及需要在服务器端 或您的 app 内 采取什么措施 您或许问过自己这个问题 好在答案是否定的 App Store 服务器 API 不依赖于您的 app 采用整个 StoreKit 2 框架 也就是说 您可以马上利用 App Store 服务器 API 中提供的新功能 同时您的 app 可以继续 使用初代 StoreKit 我们来详细讲讲 您可以如何做到这一点 因为采用相同的设计 您需要进行两个主要更改 首先我们会更新您的 app 以检索原始交易 ID 其次我们会更新 您的服务器以使用 App Store 服务器 API 这两个更改允许您的 app 使用初代 StoreKit 或 StoreKit 2 以便于在任何 iOS 版本上 支持最新的 app 版本 要进行第一个更改 并开始使用 original_transaction_ID 您将替换用于检索 Base64 app 收据的逻辑 为进行这项工作 您可能已在 使用 app 收据 URL 方法 对于自动续期订阅 请直接将它替换为这个属性 对于其他 app 内购买项目类型 则应使用这个类似的属性 现在我们将服务器更新为 使用 App Store 服务器 API 您要从 /verifyReceipt 更改为 /History 或 /SubscriptionStatus URL 后续请求会使用 JWT 进行授权 您也将使用原始的交易 ID 完成了这些更改后 您不再在服务器上维护授权逻辑 而是可以使用安全的 JWS 签名交易 并且无需存储 app 收据 如果您的 app 支持 旧版 iOS 这为您提供了一个利用 App Store 服务器 API 功能的途径 我们在前面讲到了 StoreKit 2 和服务器 API 如何负责为您确定订阅状态 现在作为一项最佳做法 您的 app 应当始终 在 app 启动时 确定订阅者状态 确定了状态后 它可以存储在本地 并在需要时更新 我想简要讨论一下我们 返回的这个五个状态 以及您针对每个状态 分别需要采取的措施 还有一些可考虑的机会 需要注意的是 新顾客不会有任何这些状态 这也是您的 app 要管理的状态 首先是“活跃”状态 这意味着 应当向顾客提供服务 直到其到期日期为止 如果您提供多个级别的服务 一个机会可能是 利用促销优惠来 提供 app 内升级优惠 注意这类优惠应当根据顾客 以往的订阅记录为他们定制 当订阅完全流失后 您将具有“已过期”状态 您不需要提供任何服务 也可以推销当前的订阅产品 您可以选择利用促销优惠 或订阅优惠代码 提供赢回优惠 如果顾客在到期日期后 60 天内再次订阅 他们现有的累积付费服务天数 将重新算入您 85% 的收益率中 下一个状态是计费重试期 我们都会不时遇到账单问题 信用卡可能会到期 商店余额可能会消费完 这些订阅本该自动续期 但由于付款方式问题 进入了所谓的计费重试期 尽管订阅已经到期 并且不需提供任何服务 顾客也不需要重新订阅 他们只需解决账单问题便可 我们会在最长 60 天里 通过各种顾客通信来 自动重试并恢复订阅 不需开发者的介入 但如果能借助 app 内信息传送 您就可以直接提醒顾客 留意他们的账单问题 并提供有效的行动号召 通过深层链接指引顾客 前往付款信息页面解决问题 接下来是账单宽限期 这与计费重试相关 但只有当您 在 App Store Connect 中 选择了启用 App Store 账单宽限期 它才能应用于您的订阅者 对于这个状态 您需要继续提供服务 一直到宽限期到期为止 如果我们在宽限期里 恢复了订阅 订阅者将保留原先的账单周期 因此他们的服务不会有中断 提供商也可避免损失任何计费天数 与计费重试一样 您也可以提供同样的 app 内信息传送来 提醒顾客留意账单问题 最后是“已撤销”状态 这适用于可在家人之间共享的订阅 这些家庭成员不再有权使用 相关的服务或内容 因此可以撤销其访问权限 此状态下 您也可以通过推销优惠 来重新获得这些顾客 在最后一个部分 我想深入介绍 使用 App Store 服务器通知时 您可考虑采用的一些实施方法 查看所有这些受支持的事件时 您可以发现其中有不少 不一定适用于您的业务 许多事件属于订阅生命周期 另一些则适用于所有 app 内购买项目类型 如果您不提供订阅 实施方法就比较简单 因为订阅为更加复杂 而且您也可以避免使用 其中许多根本不适用的事件 但我们来看看这些 可供您考虑的不同实施阶段 我们划分成三个阶段 也就是入门 支持生命周期和 基于见解采取行动 在采用版本 2 时 这个入门阶段适用于所有人 不论业务模式是什么 也不管有没有采用 版本 1 通知 第一步是 在 App Store Connect 中 启用版本 2 您可以在“App 信息”下 找到这个功能 其标题为“App Store 服务器通知” 在秋季更新发布后 您现在可以选择 沙盒和生产专用 URL 您可以添加 URL 并选取要接收的版本 如果您已在接收版本 1 建议您仅在沙盒中启用版本 2 以支持开发 而后再在生产中启用版本 2 现在我们已经启用了版本 2 一起来看看优先级设定 根据您的业务模式和使用情况 评估首先要支持哪些通知 一种有用的做法是 您应当关注 与您的业务和路线图 最契合的大量关键事件 适用于所有 app 内 购买项目类型的 一种事件是退款 对于每一笔已退款给顾客的交易 您会收到一个 REFUND 通知 如何处理这些事件 将取决于您的政策 和业务模式 对于基于订阅的业务 这四种通知现在适用于 订阅旅程中的主要事件 从初次购买或重新订阅 到续订成功或失败 一直到订阅到期 通过对这五种通知类型 优先采取行动 您可为收到的大部分事件 获得相应的支持 第一个阶段奠定了牢固的基础 可让您将回报最大化 现在可以进入下一个阶段 完成您对所有通知类型的支持 基于订阅的通知 只剩下几个而已 其他的通知则与功能采用相关 我们来看一看 这两种类型适用于 所有基于订阅的 app DID_CHANGE_RENEWAL_STATUS 和 DID_CHANGE_RENEWAL_PREF 它们对于确定顾客取消服务 或更改服务级别至关重要 在考虑这些剩余的类型时 要根据您的具体使用情况来定 如果您在 App Store Connect 中 启用了账单宽限期 则适用 GRACE_PERIOD_EXPIRED 如果您通过 App Store 服务器 API 延长了订阅者的续订 则会发送 RENEWAL_EXTENDED 如果针对 app 内购买项目 为产品启用了家人共享 则适用 REVOKE OFFER REDEEMED 适用于 使用订阅优惠代码或促销优惠时 而当订阅自动续期价格调高时 则会发送 PRICE_INCREASE 然后还有 REFUND_DECLINED 和 CONSUMPTION_REQUEST Joe 会在讨论退款处理时 详细阐述这些类型 最后 让我们谈谈 基于见解采取行动阶段 到了这一刻 您要接收与您业务相关的 所有事件并相应地采取行动 这可确保您的服务清楚 所有顾客订阅的当前状态 或对已购买的消耗型项目 非消耗型项目或非续期 订阅的任何访问权限更改 对于订阅 以下通知 可标识处于具体状态的顾客 以便您的业务能主动采取特定措施 从而能够辨别并且明智地 吸引、留住和赢回订阅者 这里提供了一些示例通知类型 您可以识别关键事件 抓住与顾客互动的机会窗口 主动提供 app 内信息传送 或展示定制的订阅优惠 我们来看一个示例 顾客取消订阅 在这个情景中 假设订阅者 在 11 月 25 日 购买了月付订阅 而后在 12 月 5 日 订阅者选择取消订阅 并且当前期间还剩 20 天 这是我们的挽留期 从订阅者取消之时开始 到订阅到期并且 顾客自愿流失为止 目前发生该取消操作时 自动续期状态 被设为 false 立即触发 App Store 发送 DID_CHANGE_RENEWAL_STATUS 通知 其子类型为 AUTO_RENEW_DISABLED 实时提醒您挽留期开始 这个机会窗口允许您的服务 展示定制的 app 内信息传送 或在到期之前推销挽留优惠 务必要对这类优惠进行量身定制 并为各类顾客设定资格标准 我的部分到这里为止 现在请我的同事 Manjeet 继续 Manjeet：谢谢 Dave！ 我叫 Manjeet Chawla 是 App Store 的技术项目经理 Dave 探讨了如何 使用 StoreKit 2 和 App Store 服务器 API 来改进 app 内购买项目 现在让我们从顾客支持的角度 谈谈同样的这些 API 我将讨论顾客如今在 app 内购买项目方面 遇到的一些常见支持情景 以及针对这些情景利用 上述 API 的最佳做法 在探讨客户支持前 我们先了解支持服务对您的 总体客户管理有怎样的影响 您可能会依赖各种各样的 CRM 工具和系统 如采购、分析、客户支持 和不同的营销通信渠道 提供支持可让您的顾客 心情愉悦、保持粘度 并改善您的总体客户关系 和满意度 我们知道顾客会 主动联系您寻求帮助 App Store 也开发了 各种工具以方便您高效地 提供支持并解决问题 今天我要谈五个新的客户支持工具 它们可以协助您处理来自 所有支持渠道的查询 首先是查找订单 ID 如今 顾客进行 app 内购买时 会通过其 Apple ID 收到一张收据 他们也可随时通过 在“帐户设置”下 查看购买记录 来访问此收据 如果有顾客联系您 您的支持团队现在 可以请顾客提供 此收据上的订单 ID 然后通过调用新的 App Store 服务器 API 使用订单 ID 来 查找与该收据对应的 顾客 app 内购买项目 您也可以使用此 API 验证收据的真实性 并将相应收据上的交易 关联到相应顾客 另外 也可使用此 API 识别购买项目中的任何问题 例如 如果交易中含有 已经退款或已被 App Store 撤销的购买项目 您可以查看回复中的 evocationDate 和 revocationReason 来获取关于退款的更多详细信息 实施了这个 API 后 您就能够在顾客联系您寻求支持时 查找与订单 ID 对应的 历史购买项目 最佳做法是 所有 app 内购买项目的 original_transaction_id 都应存储在顾客帐户数据中 当顾客联系您寻求支持时 您就可以轻松使用此 API 查找 并关联帐户数据库的 顾客购买项目 甚至还可以将这个 API 与现有客户支持渠道相集成 如电话、电子邮件或网页 为您的顾客提供一致的支持体验 接下来谈谈退款查找 在 WWDC20 上 App Store 推出了退款通知 每当有顾客成功完成了 app 购买项目的退款时 系统会通知您的服务器 退款查找是一个 全新的 App Store 服务器 API 可供您用于查找顾客的 所有已退款交易 有了这个 API 您可以通过随时 快速、轻松地查找退款 来处理服务器停机 或安排维护 另外 您也可以识别涵盖顾客 所有 app 内购买项目类型 的完整退款记录 还可以使用此 API 监控 退款或可疑活动激增趋势 并且响应可能造成退款的 内容交付问题 至于最佳做法 如果您将各个 app 内购买项目的 original_transaction_id 存储在顾客帐户数据库中 您可以使用其任何 original_transaction_id 来查找他们的以往退款 还可使用退款查找 API 对可能导致顾客退款的内容交付问题 进行故障诊断 现在我们将话题重点转移到 自动续期订阅上 举个例子 假如发生了服务中断 或有活动被取消 这样的情景可能更常见于 基于流媒体的 app 如体育比赛、直播电视或视频等 对于这类服务中断 或取消的事件 您如何才能安抚顾客？ 现在可以使用全新的 续订延期服务器 API 来延后有效付费订阅的续订日期 针对额外时间给予顾客免费服务 此 API 可用来处理暂时中断 也可用于提供安抚措施 例如客户遭遇不佳的服务体验时 请注意 在一年内只能将 顾客订阅续订日期延期两次 每次最长 90 天 不论实际订阅时限多长 另外还要注意 这个延长期限不算在 获得 85% 收益率所需的 一年付费服务期内 最佳做法是 存储 original_transaction_id 来标识您要为其延后 续订日期的订阅 确定最适合您的业务模式 的延长期限 并在延长顾客的订阅时 显示 app 内信息传送 由于每位顾客在一年中 只能延期两次 您可能需要为 符合延期条件的顾客 维护一个资格标准 务必与业务和营销团队协调沟通 以便在所有通信渠道中 提供一致的信息传送 现在我们来讨论另一个情景 为了补偿顾客 您可能想要为顾客的订阅 提供一次性折扣 在 iOS 14 中 App Store 推出了 订阅优惠代码以帮助您 通过限时以折扣价 或免费提供订阅来 获得、留住和赢回订阅者 您可以通过线上或线下渠道 分发这些一次性的唯一代码 对于客户服务问题 您可以提供这些一次性代码 作为服务问题的补偿 也可将它当做一个机会 来推荐备选的订阅选项 例如期限更长且 性价比更高的方案 使用 iOS 14 和 iPadOS 14 以及更高版本的顾客 可以通过一次性兑换代码 URL 在 App Store 中兑换优惠代码 如果您实施了 StoreKit 中的 presentCodeRedemptionSheet API 则顾客也可在 app 中兑换代码 最佳做法是在 app 内提供 便于顾客兑换代码的兑换流程 以及自定 app 内信息传送 和优惠代码描述 以帮助顾客做出明智的决定 同时也将此用于您的 现有客户支持渠道 如电话、电子邮件和网页 甚至是您的 app 内 例如当顾客 在实时聊天会话中 与您的支持团队对话时 如果您通过电子邮件等 数字营销渠道 分发了这些代码 每个代码将关联一个 预填充了代码的兑换 URL 您可以使用唯一 URL 提供深层链接 将顾客从您的电子邮件 无缝引导至 App Store 上 进行的兑换流程 此 URL 由两个值构成 一个是代表 app 的 ID 这对每个 app 来说是静态的 另一个值是代码 将使用订阅者唯一字母数字值 来动态填充 URL 如果此 URL 嵌入在电子邮件中 轻点它就会将用户引导至 App Store 以完成交易 需要注意几点 订阅者在此处的流程中 绝不会看到具体代码 而且在完成后 您的 app 还需要完成 另外一个外部交易 这会在顾客再次 启动 app 时进行 接下来我们来看看一个情景 顾客想要管理他们的订阅 StoreKit 2 中发布了 一个新的管理订阅 API 它允许您直接在 app 内 显示要管理的现有订阅 通过在 app 内支持订阅管理 顾客无需离开您的 app 就能升级、降级或取消订阅 这自然为您提供了 一种途径来协助 解决常见的订阅用户问题 并提供备选的优惠 供顾客考虑 您也可以利用这个机会 在顾客看到管理订阅页面前 展示个性化的挽留优惠 例如当他们的互动不足时 您甚至还可以 在顾客取消订阅时 展示退出调查问卷 以提供更多取消详情 至于最佳做法 通过使用 StoreKit API 您可以提供一致的体验 让顾客无需离开您的 app 就能管理或取消他们的订阅 不妨打造品牌化的关联体验 来补充系统提供的管理 UI 例如 您可以提供 热门的高端等级 根据顾客的偏好 或使用情况 提供个性化建议或替代方案 同时评估您的总体 订阅管理体验 因为它关乎到您所有渠道上的 客户支持旅程 我们现在来看看 app 中的 “管理订阅”UI 示例 在“帐户设置”下可添加一个选项 供用户用来管理订阅 顾客轻点这个按钮后 App Store 就会显示 现有的“订阅管理”页面 列出当前有效的订阅 以及续订选项 这是顾客熟悉的视图 当他们在 App Store 中 访问“帐户设置”下的 “管理订阅”时 会看到同样的视图 他们可在那里 查看、升级、降级 或取消自己的订阅 如果顾客选择取消订阅 他们会看到一个确认屏幕 其中显示取消详情和服务到期日期 顾客在这个页面中执行任何操作后 您会收到 App Store 服务器通知 如果您实施了 StoreKit 2 框架 则 app 中也会收到通知 了解了我今天介绍的 这些新客户支持工具后 我们来讨论使用这些 API 来提供支持有哪些好处 现在您可直接在 app 中 为 app 内购买项目 提供顺畅的关联支持 以改进您的总体顾客体验 这将提高总体留存率 和顾客满意度 从而带来更高的参与度 最终让 app 获得更多好评 现在请我的同事 Joe 来谈谈退款处理 Joe：感谢 Manjeet 针对已经发布的新客户支持工具 介绍了最佳做法和用例 大家好 我叫 Joe Mani 是 App Store 的 一名技术项目经理 退款是一个敏感的话题 App Store 开发了各种工具 协助您了解退款 对您的 app 的影响 以及如何利用这些工具 改进您的顾客体验 我将重点介绍 使用这些工具的好处 也会全面说明如何处理退款 过去一年发布的新工具中 有两个会影响到退款 首先要讨论的是 beginRefundRequest API App Store 提供 “报告问题”功能 Apple 支持也建立了 可供顾客请求退款的途径 随着 iOS 15 的发布 App Store 在 StoreKit 2 框架中 引入了一个新的 beginRefundRequest API 供顾客用于为 app 内 购买项目请求退款 通过实施 beginRefundRequest API 您可以获得多重好处 在今天讲座的听众当中 许多人应该遇到过顾客要求 为 app 内购买项目 办理退款 借助新 beginRefundRequest API 您无需重定向顾客 即可提供同样的功能 还能在 app 中提供协助 如果您知道自己的 app 内 购买项目可能存在问题 您可以使用此 API 协助顾客 对问题进行故障诊断 更快获得解决方案 在 iOS 15 中 App Store 创建了两个额外的专用通知 以便您可以知道退款 已获得批准还是遭到拒绝 如果退款获得批准 您的 app 会收到通知 同时您的服务器也会 从 App Store 接收 REFUND 通知 如果退款遭到拒绝 您的服务器会收到新的 REFUND_DECLINED 通知 注意顾客必须运行 iOS 15 或更高版本才能使用此功能 我们来讨论最佳做法 存储原始交易 ID 还要注意 退款请求最常发生于 购买后的 30 天以内 您可以提供自定 app 内信息传送 打造定制化的顾客体验 即使您可能遇到了 顾客因不满而请求退款的情况 您可以灵活地向顾客显示 与以往购买相关联的信息 顾客选择了要退款的交易后 您可以调用相关 API 来显示退款请求表单 供顾客从原因代码列表中进行选择 这与他们在 Apple 的 “报告问题”中看到的画面一致 对于自动续期订阅 您可以确定留存策略 以继续在您的 app 中 与顾客保持互动 因为退款成功会取消订阅 研究完 beginRefundRequest 现在我们来谈谈 之后会发生什么 以及您可以如何更多地介入 App Store 推出了 一个新服务器 API 让您有机会通过 向 Apple 发送 与顾客消耗型 app 内购买项目相关的 消费信息来帮助改进 退款流程并提供信息参考 例如他们在请求退款前 是否消费了某个项目 总的来说 每个退款请求 都会经过我们的退款决策系统 以做出决定 退款决策系统包含 有关发生问题的交易 和其他因素的信息 例如顾客的购买和退款历史记录 在 Apple 做出决定前 App Store 会 向您的服务器发送 CONSUMPTION_REQUEST 通知 您的服务器会在回复此通知时 将消费信息数据 发回给 App Store 而这可能会影响退款决定 消费信息有效负载 由几个字段构成 我来谈谈其中三个关键的字段 通过 Consumption 您可以轻松地 告诉我们 app 内购买项目 是已经全部消费、部分消费 还是完全未消费 例如 如果您的 app 提供物物交换的交易平台 或者 app 内 购买项目已从一个帐户 转移到另一个帐户 这被视为已经消费 对于内容交付 您可能会遇到服务中断 或无法交付 app 内购买项目 并且希望向顾客退款 您现在可以单纯地 提供未交付的项目 随着 appAccountToken 在 StoreKit 2 中推出 我们现在使用 与您为 app 创建的 用户帐户关联的 标准 UUID 格式 此帐户用于发起购买和 消费购买的内容 可以帮助识别经销商 至于最佳做法 大部分退款 请求是在 30 天内发生的 因此请相应存储 交易的消费信息数据 存储每个消耗型 app 内购买项目的 original_transaction_ID 以方便查找 Apple 请求相关数据的交易 要确保 Apple 将您的 数据纳入到决策过程中 请在收到消费信息请求 通知后的 12 小时内回复 如果初次请求后情况有变 请在这个 12 小时期限内 发送更新的有效负载 确保在向 App Store 发送 所请求消费信息数据之前 先征得顾客同意 最后 在消费信息有效负载内 并非所有字段都必填 请查阅 Apple 文档 了解哪些字段可标记为未申报 作为今天讲座的总结 我想提供一个关键行动检查清单 对于采用和实施 这些功能的后续步骤 您可以首先配置和启用服务器 以接收 App Store 服务器通知 方法是 在 App Store Connect 中 输入 URL 并在沙盒中启用版本 2 对于您的客户支持工具 请集成到现有的支持渠道 如电话、电子邮件、 网页或 app 内支持 对于您的 app 请确定 iOS 15 中 与 StoreKit 2 相关 的所需客户端更改 以支持新的 beginRefundRequest isEligibleforIntroOffer 和 showManageSubcriptions API 最后 请务必利用 沙盒测试更新来充分发挥 沙盒 Apple ID 的作用 如店面更改、清除购买记录 测试退款以及调整订阅续期速度 本次讲座到此结束 非常感谢大家与我们一同 深入探索如何利用 StoreKit 2 和 App Store 服务器 API 为顾客提供支持