订阅优惠最佳做法

下午好 欢迎各位 参加今天的“订阅优惠的最佳实践”会议 我是 Ross LaBeau 我是 App Store 团队的一名工程师 今天我们将深入地了解 App Store 中 App 内购买项目的最新特性

订阅提供者 可通过订阅优惠 这一全新的方式 为用户提供 特定时长的折扣价格

我们知道 用户流失是订阅 App 利润下降的主要原因之一 这是一个强大的新工具 通过留住用户 或赢回已经流失的用户 来帮助减少用户流失 订阅优惠 最酷的地方在于 你可以选择何时 向用户提供优惠 以及向他们展示哪些优惠 例如 如果你刚刚收到一条 服务器对服务器的自动续订通知 一位用户已经取消了自动续订 你想在即刻采取行动 并给予他优惠 例如为期三个月的半价订阅 从而让用户继续使用你的 App 并保持订阅

与试用优惠不同的是 用户可以在你的允许下 多次兑换订阅优惠 他们甚至可以 多次兑换同一优惠 App Store 提出的唯一条件是 用户必须 正在自动续订 或者订阅过你的 App

今天我们将介绍 在 App Store Connect 中 创建这些优惠的具体设置

我们将讨论如何生成 在每次交易中 你都需要发送的密码签名

我们也将谈到新的 StoreKit API 以及如何使用它们 向 App Store 发送一个交易 并进行一次购买

我们将从 App Store 的角度 以及如何创建你的 自定义业务规则的角度 来讨论用户的资格审查

我们将提供一些提示和技巧 帮助你给你的用户 分配和营销这些优惠 最后 我们将讨论 更多关于如何 减少用户流失的商业策略

首先 就像试用优惠一样 你需要在 App Store Connect 中 设置订阅优惠 进入“功能”选项卡下的 “App 内购买” 之后选择任一自动续订的订阅选项

然后点按“订阅价格” 旁边的加号按钮 选择“创建促销优惠”

在这里 你可以输入 易于理解的优惠名称 以及产品代码 这个产品代码 也就是标识符 从这开始 你将使用这个特定的标识符 来指代这个优惠

之后就和试用优惠的设置 非常相似了 你需要选择类型 时长以及价格 除了设置这些优惠之外 你还需要设置一个私钥 以便生成之前提及的签名 我们之后再进一步讨论这个签名 创建你的私钥 你需要进入 App Store Connect 的“用户与访问” 选择“密钥” 并确保选择左侧的“订阅” 点按加号按钮

输入易于理解的密钥的名字 并点按“生成”

之后你就可以 在上方的“活跃”密钥列表中 发现这个新建的密钥

你也会发现 App Store Connect 已经为它生成了 一个密钥 ID 这也是一个 特定的标识符 用来在 StoreKit 中引用这个密钥

现在你可以 下载你的私钥 只需点按“下载密钥” 但是重要的一点需要注意 你仅可以下载一次这个密钥 没有错 只有一次 一旦你下载了它 App Store Connect 将会 永久地从 Apple 服务器中删除它 这么处理的原因是 这些密钥是非常敏感的加密信息 这个私钥就像是你的身份 它被用来证明授权用户 兑换这笔交易的是你本人

如果你在你的所有 App 中 以及为这些 App 设置的优惠中 都使用了同一个密钥 那么这些密钥将在 你的整个开发者帐户中生效

但是你也可以按照喜好 使用多个密钥 如果你使用 一个开发者帐户来服务 多个 App 或不同的业务组分 那么你可以创建多个密钥 来将它们分割开 就像我所提到的 每笔交易都需要一个加密签名 你需要把它发送到 App Store 来兑换优惠

现在 为了确保只有授权用户才能兑换优惠 我们需要做出如下的设置 使用有效载荷生成一个签名 你同样需要将这个有效载荷 发送到 App Store

这个签名运用了一个叫“非对称加密”的东西 非对称加密 是一个十分常见的技术 它使用两个密钥来生成 并验证签名 而不仅仅是我们刚才讨论的私钥 我们使用私钥作为你身份的证明 来签署你的有效载荷 第二个密钥 叫做公钥

就像它的字面意思 这个公钥实际上 可以显示给其他人 你不能用它 生成任何签名 使用公钥所能做的一切 就是证明该签名 是用你的私钥生成的 并与你用来签署的 有效负载匹配

由于生成签名 需要使用你的私钥 所以你应该始终在 安全服务器上进行 而不是从设备本身进行 因为你一定不想 将这段加密信息 放在其他人的硬件上

我们现在看一看 我们利用 NodeJS 和 Express 构建的服务器 这实际上是可以 在网上下载到的示例代码

如果你不使用 JavaScript 也不用担心 这里展示的一切成果 都可以以其他语言完成 比如 Python PHP Java Swift 等等 选择哪个都可以

第一步 当你的 App 准备好向用户展示优惠时 你需要将这个请求 发送到服务器 然后生成一个签名

在本例中 App 已经知道我们想要签署的 几个有效载荷 因此我们仅需 在请求中的主题部分获取它们

我们将获得 App 的 套装标识符 订阅的产品标识符

以及优惠标识符 对应的是你将展示给 用户的优惠 最后我们会得到一个哈希 App 用户名 这是一个单向排序的安全哈希值 包含一些关于用户的标识信息 也许是他们在你的 App 中的用户名 或者他们的邮箱

但很重要的一点是 你要对它进行哈希 处理 并且永远不要把纯文本标识信息 发送到 App Store 你需要在自己的数据库中 保持这种安全性

下一个有效载荷 叫做“nonce”（唯一性参数）

这只是一个随机的数据片段 以确保没有两个交易是相同的 我们使用它来防止重放攻击 和其他绕过它的方法 如此用户将不能重新发送相同的请求 在没有你的批准下 获得多次的免费订阅 App Store 使用 版本为 4 的 UUID 这就是我们要创建的

然后我们会得到一个时间戳 这是自 Unix Epoch 格式以来的 以毫秒为单位的时间戳

这是一个十分常用的格式 你可以看到 在 JavaScript 中生成它十分容易

这个时间戳 也被用来帮助阻止攻击

重要的是你所做的每一笔交易 将只在该时间戳之后的 24 小时内被接受 所以你不应该 提前一周产生这些签名

有效载荷的最后一部分 是密钥 ID 这个是 App Store Connect 之前生成的密钥 ID

我在这里植入了一个 名为 getKeyID() 的函数

我们要做的就是 返回我们存储在 环境变量中的密钥 ID 我们这样做 而不是将它提交到代码 并将其放入存储库中 是因为这样更安全

暴露更少的弱点

如果你只返回了 一个密钥 ID 但如果你使用多个密钥 这实际上是实现逻辑的 理想位置

或者 如果你确定 你的一个密钥被泄露了 有人未经授权访问了它 你可以在 App Store Connect 中禁用它 你可以生成一个新密钥 只需要切换这里的逻辑 就可以使用这里的新密钥 来签署它们 你甚至不需要推送 App 更新 这样你可以把停运时间降到最低

现在我们已经有了所有 要签署的有效载荷 我们想把它们合并成 一个数据块来生成签名 现在你可以看到 我们的方法是 把它们按这个顺序组合成一个字符串

我们使用字符 将它们连接起来 每个字符之间的代码点为“\u2063” 好吧 我明白你们的疑惑 为什么我们不使用空格呢 十分重要的一点是 当你生成 或验证加密签名时 你要非常精确地知道 你使用的是哪个字符 正如你们中的一些人可能知道的 单词空格可以指 多种不同类型的空白字符 所以我们使用这个

现在我们有了有效载荷 下一步是得到密钥本身 我们使用 getKeyStringForID(keyID)

我们要做的就是检查 确保密钥 ID 和我们的期望匹配 然后我们将从另一个环境变量 返回密钥 这里我使用的是 字符串中的密钥 它以 PEM 格式记录

这是一个十分常见的格式 App Store Connect 会把它发送给你 几乎任何第三方 或第一方的库 都能处理它

我们有了密钥有效载荷 我们准备好签署了

我们在这里做的是 创建一个椭圆曲线 数字签名算法对象 这听起来很神奇 但很容易做到 正如你所看到的 这里只有一行使用了 NodeJS 中的 JavaScript 语言的 ECKey 库代码

其他语言的库 也使它变得非常简单

我们传入密钥字符串 并告诉它 它是 PEM 格式 我们将把这个 cryptoSign 对象作为 NodeJS 的加密库的一部分 我们要告诉它 使用 SHA256 哈希算法

这是你一直应该使用的算法 无论你使用什么库 你都应该确保指定它

接下来 我们把有效负载 添加到这个 cryptoSign 对象 它只是告诉我们 这是我们用来生成签名的东西

最终 生成签名 这里的加密库 在默认情况下 以 DER 格式生成签名

大多数情况都是这样的 但如果你的库默认情况下 不使用这个格式 请确保在这里指定 DER

它不会返回 一大堆原始的加密字节 我们要求它发送一个 Base64 编码的字符串 这使得将数据 从服务器传输到设备 非常容易 这也是 StoreKit 使用的格式

现在我们有了我们的签名

下一步是做一些验证 你不必每次 都进行这种验证 但是当你在自己的服务器上 编写签名生成代码时 这样做确实很有帮助 只是为了确保没有错误 或者什么奇怪的事情发生

它的作用是 基于你的私钥 生成一个公钥 然后像 App Store 一样 验证你的签名和有效载荷

最后 剩下的就是将签名 连同我们在这里生成的 这些有效负载片段 包括 密钥 ID nonce 和时间戳 一起发送回设备

现在你已经设置好服务器 来生成这些签名 下一步就是设置 App 发出请求并发送交易

首先要做的是 获取优惠细节 这些你当然都可在 App Store Connect 中 通过 SKProducts 请求进行设置

我们将添加一些代码 来发送签名请求到服务器 并运行我们刚刚讲过的代码

具体执行时 一个好的策略是 在用户准备购买时 发送签名请求 我们建议你 在展示你的故事线 或向用户展示这个优惠之前 发送签名请求

这样做不仅是因为 24 小时的 时间戳限制 还因为这样你就可以 从自己的服务器中获得最新的业务逻辑 你可能已经换了密钥 或者你有了关于你的用户的 新的资格信息 从而使你决定 是否向其发送优惠信息 你希望所有这些 都是最新的

最后 我们将处理 来自服务器的响应 然后将交易发送到 App Store

当你发出 SKProducts 请求时 你将注意到在每个 SKProduct 上 都有一个用于订阅优惠的新属性 它就是 discounts

这是一个 SKProductDiscount 对象数组

你可能会认出 SKProductDiscount 因为它与我们用于 试用优惠的模型相同 因为它们非常相似 你可以看到 它有价格 订阅时长等信息

但我们还为订阅优惠 添加了两个新属性

其中一个是 identifier 这是你在 App Store Connect 中 添加的产品代码

它是可选的 因为试用优惠并没有标识符 所以它在那里为 nil 但是对于每一个订阅优惠而言 它是存在的 我们添加了一个类型 这是一个数组 它会告诉你 这是一个订阅优惠 还是一个试用优惠

然而 你永远不会在 discounts 数组中 获得试用优惠 那些将只会存在于 SKProduct 的试用价格属性中

这样你已经准备好向用户 展示你的优惠了 第一步是向服务器 发送一个请求 来获取优惠细节

在本例中 我们将传入 App 用户名的哈希版本 订阅的产品标识符

以及优惠标识符 这里 我们的服务器 已经知道我们使用的是什么 App 套装 ID 它会运行所有我们提及的代码 然后返回一个 nonce 一个时间戳 一个密钥标识符 当然还有 在 Base64 格式字符串中的签名本身

我们不会详细讨论如何发出 安全的 HTTPS 请求和响应 有许多关于这点的资源可供参考 我们将继续 把目光放在 completion() 代码块中

你需要对所有这些信息进行处理 创建这个名为 SKPaymentDiscount 的新类

注意这里是 SKPaymentDiscount 而不是 SKProductDiscount

SKProductDiscount 是我们刚刚提到的 它提供了你在 App Store Connect 中 设置的优惠的详细信息

这个 SKPaymentDiscount 实际上 包含了有效负载 和签名的所有细节 你需要使用它附加到支付上 并发送到 StoreKit

我们在这里创建一个 把这些细节 传递到初始化器 然后返回到 completion() 代码块中 这样我们便准备好显示优惠

当顾客轻点购买时 我们将调用这里的 buyProduct 函数 你需要确保订阅本身 具有 SKProduct 用于生成签名的 相同的哈希 App 用户名 以及我们刚刚创建的 SKPaymentDiscount

从这里开始设置就非常简单了 使用该产品 创建一个新的 SKMutablePayment

我们将设置 applicationUsername

然后用 SKPaymentDiscount 设置这个新的 paymentDiscount 属性

就是这样

只需将支付 添加到支付队列中 就像其他 App 内购买项目的设置

除此之外 我们还专门为订阅优惠 新添了 SKErrorCodes

第一个是 invalidOfferIdentifier 正如它的字面意思 如果你试图使用的 优惠标识符丢失 或者你在 App Store Connect 中禁用了它 就会返回这个代码

下一个是 invalidOfferPrice App Store 实际上 会对现收现付的订阅优惠 进行价格验证 我们想要确保 优惠的价格 比订阅本身的基础价格更低 因为可能会发生这种情况 你设定了一个优惠 然后你又降低了 基础订阅的价格 我们要确保 这确实是一个折扣

然而 App Store 不为 预付费订阅优惠 进行价格验证 原因是我们希望 你能够创建套装 例如 如果你开始运营 一个全新的 基于订阅的游戏 你可能想给一些用户一个优惠 比如三个月的订阅访问 附赠一个额外的传奇装备 或者经验包之类的赠品 相比于仅仅三个月的订阅 提供更多的价值

下一个错误代码是 invalidSignature

如果你发送的签名 不能与你之前告诉我们 你所使用的私钥 或者与你发送的有效载荷 进行验证匹配 这意味着在这两者之间 有什么被更换了 我们将发回这段代码

最后一个是 missingOfferParams 如果你忘记发送 或者你发送一个 空字符串版本的有效载荷 你会收到这段代码

最常见的例子是 忘记在 SKMutablePayment 上 设置 App 用户名

我们刚才看到的这些代码 都可以在网上找到

就像我说的 你现在就可以下载 NodeJS 服务器 并在本地运行 这是一个随时可以运行的 App

我们看到的 Swift 代码 可以在这些文档页面上找到 而且有更多关于它的详细文档 另外 如果你有任何问题 请在 3 点后 到我们实验室来

现在我们已经讨论了 如何生成签名 以及如何将交易 发送到 StoreKit 你可能会想 “很好 但是我应该将这些优惠发送给谁呢”

正如我所说 App Store 只执行一条规则 每个想要兑换优惠的用户 必须在该 App 中订阅过 自动续订的订阅服务 这包括了 任何自动续订的订阅 它不一定是 你想要给出优惠的 那个订阅类别

它可以来自任何订阅组 重复一下 并不需要匹配

这既包括当前的订阅用户 也包括那些 已经退出并流失的订阅用户 因此你可以使用优惠 来留住用户 或者重新召回用户

用户从第一个订阅期起 便具有资格

包括他们正处于 一个免费或付费的试用优惠订阅中

记住这一点 用来检查以确保用户 确实符合条件的方法 当然是查看收据

其实很简单 你只需要查看 in_app 数组 或者 latest_receipt_info 数组 如果它可用 并且浏览那里的所有对象 你需要查看每个产品 ID 如果你发现一个产品 ID 是自动更新订阅 那么你就知道 他们已经订阅了 因此他们有资格 兑换该 App 中 任何自动续订订阅的 任何优惠 但这只是 App Store 提出的资格条件 十分简单 我们将更多的决定权交给你

你一定希望 实现自己的业务规则 以确定向哪些客户展示优惠 以及向他们展示哪些优惠

为了给你们一些实用的 关于这个内容的建议和见解 我想请我的同事 Michael 上台

谢谢 Ross

下午好 我是 Michael Gargas 我是 App Store 商业团队的 一名技术支持 今天我很高兴 能和大家一起 使用我们超棒的新功能 订阅优惠 并讨论用户的资格 分配 和自发流失

作为开发者 你可能会问自己一些 关于 App 中 用户订阅活动的问题 比如 我的大多数用户什么时候会流失 是否已经有用户流失了

或者 为什么用户 可能取消了他们的订阅

正如 Ross 提到的 你可以通过 App 收据 确定订阅优惠的基本资格 在 in_app 数组 和 latest_receipt_info 中 你将获知该订阅用户 或普通用户之前的订阅活动

此外 我们将通过更新的 服务器到服务器通知 提供此信息

但这只是关于 用户所订阅的产品 在 App 收据的内部 我们提供了许多额外的 有价值的用户订阅信息

比如订阅状态 我的用户会在 订阅到期后续订吗 或者我的用户是否处于 付款失败状态 我们还提供了独特标识符 比如原始的交易 ID 和 WEB 订单行项目 ID 以便你为服务器上的 特定的用户 确定特定的订阅 我们提供 该用户的订阅日期 例如当前期间的订阅开始日期 和到期日期 以及之前的所有续订日期 我们提供订阅意图 让你知道 是否有人取消了订阅 以及他们为什么 要取消订阅 如果他们要求退款 是你的 App 出了问题 还是其他的什么原因

在去年的“Engineering Subscription”会议中 我们讨论了 从 App 收据中 存储额外用户数据的概念 这里我们有一个 查看用户的 订阅到期日期的示例 将其存储在服务器上 并确定该用户不再符合 订阅服务的资格 我们也在此基础上 并讨论了 从 /verifyReceipt 存储 额外的订阅用户状态栏 然后从响应中 解析出特定的栏 比如 autoRenewStatus

此外 我们建议你现在保存 来自服务器到服务器通知的状态更改 因为我们也正在 将统一的 App 收据 包含在这些服务器到服务器通知中

这是 Apple 提供给你的 关于你的 App 中 订阅用户和普通用户的数据

作为一名开发者 你的 App 中有许多 Apple 没有的 关于用户订阅活动的 附加信息

通过获取这些信息 并将其与 我们在购买或续订行为之后 提供的 JSOJN 数据结合起来 你就可以开始为用户群体 策划特定的优惠

随着时间的推移 你可以使用关键的订阅指标 如转化率 参与度 保留率和客户流失率 来监视这些用户群体 如何对优惠做出响应 为了更直观地了解这一点 让我们看一下服务器上的 一个用户表的示例

这里我们看到 按 userId 和 originalTransactionId 排序的用户 originalTransactionId 是特定用户的 任何订阅购买的 父特定标识符 正如我们所说 你可以开始在 App 收据中 添加额外的用户信息 比如用户的 自动续订状态 和账单重试状态 但你不应该止步于此 你可以将其与 App 中 有关用户活动的信息相结合 这里我们有一个 contentConsumed 的例子 contentConsumed 可以是观看视频 阅读文章 保存故事等等

通过查看这些信息 我们能够确定 哪些用户 有资格获得订阅优惠 哪些没有

更进一步 我们可以开始存储额外的信息 比如续订 用户所经历的 账单错误的数量 以及他们是否有资格 获得特定类型的优惠

正如 Ross 所提到的 每个订阅队列 最多可以有 10 个订阅优惠 这将允许你最多创建 10 个不同的 用户群体来标识 和分配订阅优惠 如果我们看一下 服务器上的三个示例用户 你将看到 根据他们的订阅活动 当用户在免费试用期间 禁用了自动续订功能 且订阅到期后并未续订时 我们已经能够 使他们有资格获得 诸如回归奖励之类的优惠 或者一个保留优惠 指的是当前已订阅 但已禁用自动续订功能的用户 你希望向他们展示保留优惠 以便让他们 继续订阅你的服务 还可以提供升级优惠 找到那些在较低订阅级别上 如按月订阅 有连续续订的用户 然后向他们 提供订阅优惠 激励他们升级到 比如年度订阅的高级订阅级别 这将通过 更多的信息 确定用户资格 而不仅仅是查看用户 之前是否在我的 App 中 订阅了我的订阅产品

在你构建了 这个详细的用户资格之后 下一步就是 分配你的订阅优惠

让我们来看看订阅优惠 可能采取的方式

首先 正如我们所讨论的 你需要确定哪些用户 或用户群体 有资格获得订阅优惠 然后你可以和这些用户互动 从 App Store 中 获取信息 并呈现给你的用户

此时 用户将有希望 进行购买 并兑换订阅优惠 如果我们回到我们的标识 你可以看到我们标记了 三个不同的用户 他们有资格获得三种 不同类型的订阅优惠

那么你在哪里 展示这些信息呢 如果用户仍在 使用你的 App 但处于未订阅状态 你可以通过 App 内发送信息 或本地通知 将订阅优惠 直接展示给用户

重要的是要理解 你的 App 应该 能为所有消费提供相应的价值 当你鼓励用户 消费某个优惠时 你要仔细考虑这种推销 并确保你 清楚地陈述了 这个订阅优惠的价值定位 以及拟定 用户认可的条款

和往常一样 你需要确保 你遵守了最新的 关于订阅的 App 审查指南

这是基于用户 仍然在使用你的 App 的情况

如果用户不再启动 App 又该如何呢 这对于订阅优惠而言 又有什么不同呢

这里我们可以 看到标识阶段 但是我们还需要了解 在你的 App 之外 推广订阅优惠的能力 你需要 在 App Store 或者说 在 App 之外 展示这些订阅优惠 从而吸引这些老用户

现在 让我们来谈谈 在你的 App 之外展示优惠

你可以使用 现有的外部通道 来分发对订阅优惠操作的调用

比如 你已经采用了 付费广告或电子邮件营销

然后使用通用链接 将用户从这些外部通道引导回 App 并识别 他们可能接收到 哪些订阅优惠

有关通用链接的 更多信息 我强烈建议你查看 “What's New in Universal Links” 的会议 你可在今年的 WWDC App 中获得会议内容

我们现在已经讨论了 确定用户资格 以及在 App 内部 或者通过现有的外部渠道 向那些符合资格的用户 推广订阅优惠

接下来让我们谈谈一些 可以利用在订阅优惠上的策略 帮助我们减少用户流失

在去年的“Engineering Subscription”中 我们谈到了 用户自主流失 即用户在订阅期间 主动取消订阅的行为

自主流失指的是 用户选择 离开你的订阅产品 这与非自主流失有所不同 后者指的是用户没有做出任何选择 只是账单问题导致的流失

去年 我们给了你一些策略 比如向那些自主流失的用户 提供其他可选的订阅产品 但这不是赢回客户的好方法 今年 我们将给出如下的建议

我们希望你 使用来自 App 收据的数据 以及你所拥有的 关于订阅用户 如何在 App 中消费内容的信息 来分析你的用户订阅行为 我们想让你 使用这些信息 并确定特定的用户群体 然后把你的订阅优惠 最好是匹配的订阅优惠 分配给 不同的用户群体

在谈到订阅优惠时 我们通常只考虑 赢回未订阅的用户

但我们想 在此基础上再扩展一下 讨论另外五种 为你的订阅用户 展示订阅优惠的方式 你可以利用订阅优惠 来进行用户保留营销 当你看到 用户在订阅到期后 选择不再续订时 你可以尝试通过订阅优惠 来留住该客户

如果你掌握的信息 使你相信在某个时间点 这个用户可能会流失 那么你可以为他们提供一个挽留优惠 实质上是预测 用户可能会 从 App 中流失 你可以在 App 收据中 查看用户的订阅活动 和他们当前 订阅的产品 你可以提供订阅优惠 从而在订阅组中 升级或降级该用户 此外 你还可以使用订阅优惠 来安抚可能在 App 中 体验不佳的用户

你也可以使用订阅优惠 来奖励你最忠实的订阅用户 让我们来逐个探讨 并展示如何 在 App 中 向用户展示这些订阅优惠

首先 让我们看一个 赢回用户的例子 这里我们有一位 在 26 日购买订阅的用户

但是在订阅期间中 该用户选择取消 他们致电 Apple Care 并阐述对服务不满意 想要取消订阅并退款 正如我们在今天早些时候 与你谈论到的 我们通过 带有取消日期等栏的收据 让你知道这一信息 以便你立即知道 退款 取消发生的时间 以及取消原因 这样你就能知道 是因为 App 本身还是其他原因 我们还通过更新的 服务器到服务器通知 发送这些信息 以便你能够实时了解 订阅用户 和普通用户的动态 让他们知道 他们有其他的 订阅优惠选项 我们进一步考虑这个问题 我们希望从收据 或者服务器到服务器的通知中 获取信息 比如自动续订状态 过期意图 等等 我们想把它存储在服务器上

标记那些 可享受回归优惠的用户 这是向你的用户 展示订阅优惠的信号

例如 在这里你可以看到一个 “再一次与我们同行”的标语 展示给一个可能已经流失的用户 作为开发者的你现在 正试图重新赢得这个用户

我们还有一个 来自《iTranslate》App 的开发者的示例 他利用订阅优惠为用户提供了 免费续订一个月的优惠

这些都是订阅优惠 这项全新特性的优秀应用实例

现在让我们讨论一下保留用户 保留当前 仍在订阅你的 App 的 订阅用户的行为

这里我们看到一个用户 已经购买了他们的订阅

然而在订阅期间 他们选择来到 Apple 的“管理订阅”界面 并取消了订阅

我们更新了 服务器到服务器的通知 你可以通过 与 Apple 重新验证收据 并确认“auto_renew_status”的值 已从 1 更改为 0 来找到此信息 这是你的用户 将不会在订阅到期后 继续订阅的信号 但如果你发布了订阅优惠 我们将发送一个状态 或服务器到服务器的通知 让你知道 该用户将不再续订 当用户禁用续订状态 和启用续订状态时 我们都会 发送此消息

这将告诉你 应该让他们知道 他们还不应该离开 并期待接下来你的订阅产品 会提供什么新功能 如果我们回顾数据库中的 用户的例子 你可以看到 我们已经更新了 用于保留优惠的栏 当这个用户 返回到 App 无论是被你的营销激励 还是仅仅出于使用的目的 都可以向他们展示订阅优惠 并让他们知道 现在是订阅的好时候

“请再一次与我们同行 我们注意到你下个月 将会离开我们了” 这是一个很棒的标语 能够赢回和保留用户 继续订阅你的 App

我们还有一个 来自《Ultimate Guitar》的例子 提供一个月的免费订阅和 50% 的折扣 让用户知道 这个优惠仅限今日

那么这就是用户保留

让我们看一个升级示例 在这里 我们看到一个订阅用户 选择在 4 月 1 日降级他们的订阅 你已经知道 我们将在收据中显示即将更新的产品

你可以选择从响应中 解析它并将其存储在服务器中

我们还向你发送 服务器到服务器的通知 为了让你知道 该用户已选择 降级他的订阅

如果用户 选择了另一种产品 你知道他们一直在消费 更高级别的服务 无论是 享有更高折扣 和更长订阅时间的 年度订阅 还是高级订阅服务 其能够访问 低级订阅无权访问的 这名用户查看过的特定内容 在本例中 当你看到用户降级订阅时 你可以将他们标记为 有资格获得升级优惠 当这名用户 返回到你的 App 时 利用一个明确且简洁的标语 展示一个订阅优惠 说明优惠的内容 以及他们将 在这项优惠中获得什么 我们还有一个 很棒的《Dashlane》开发者的例子 他们试图让用户 再次升级到 他们的高级服务

那么这就是升级的例子 让我们来讨论一下用户服务

我们都在尽我们最大的努力 制作完美的软件 但是很明显 有些时候用户可能会 在你的订阅产品中 遇到问题 故障 某种类型的错误或者停机

这个用户可能决定 通过你的支持渠道 与你联系 并让你知道他们的使用体验并不理想 如果我们在你的服务器上 回顾用户表 如果你的用户服务代理 有能力查找那些特定的用户 并将他们标识为 有资格享受优惠 你的代理就可以指示 那个用户重新启动 App 因为他们现在有资格享受优惠

你可能希望 在设置界面上 显示订阅优惠 在这里 我们看到了一个 免费续订一个月的优惠 并为用户可能经历的 任何服务中断道歉

当用户使用 App 时 他将看到一个订阅优惠 和一个明确且简洁的标语

这是让你的用户 满意的好方法 并且可以安抚任何在你的 App 中 有过糟糕使用体验的用户

你还可以使用订阅优惠 来奖励你最忠实的订阅用户 在这里 我们看到一个用户 即将连续地第 11 次续订 对于开发者来说 他显然是一个很棒的的订阅用户 我们希望给予他们一些奖励 如果我们查看 服务器上的用户表 你将看到我们一直在捕捉续订周期 这是通过存储在 App 收据中的信息找到的

如果我们回顾 用户的时间线 我们现在可以将该用户 标记为有资格享受忠诚用户优惠 因为他们已经越过了一个阈值 所以我们认为这些用户值得奖励

在下一次 使用 App 时 你可以通过 比如一个月的免费订阅 来奖励他们的服务和忠诚度

在这里 我们看到一个 《Luminary》开发者的例子 他们奖励早期的高级用户 如果现在激活 用户就能享受额外的两个月的服务

最后让我们谈谈挽留优惠

挽留优惠 和保留优惠十分相似

作为一名开发者 你可能掌握一些信息 使你相信这个用户可能会流失 这指的是 在用户可能采取行动 进入“管理订阅”界面 并取消订阅之前

如果你发现 其中一个有流失倾向的用户 进入到 你在 App 内部的设置界面中 安置的的一个深链接 使得他跳转到 Apple 的“管理订阅”界面 你可以在这名用户 跳转到 Apple 的 “管理订阅”界面之前 向他展示一个订阅优惠

以上是六个不同的例子 向你展示了 如何使用订阅优惠 来最小化 App 的用户自主流失 但这仅仅是一个开始 我非常兴奋地看到 作为开发者 你能够提出一些 非常棒的想法 为你的 App 中的订阅用户 提供良好的用户体验

在订阅优惠 被分配给用户之后 下一步是 分析订阅优惠的性能 今天 我很高兴地宣布 我们推出了两个全新的报告仪表盘 能够帮助你 分析订阅活动 订阅状态仪表盘 和订阅事件仪表盘 让我们看一看 App Store Connect

如果你导航到 销售和趋势模块 你将看到 我们推出的订阅状态指示板 这个仪表盘允许你 随着时间的推移 了解你的订阅用户基础 例如 你将能够在标准价格 与试用优惠 或订阅优惠之间比较 精确地查看有多少订阅用户

这是一个很好的工具 帮助你查看和分析 你的订阅用户在不同时间 和地区的增长情况

此外 你还可以使用此仪表盘 查看 App 中的用户 正在选择哪些优惠

我们还启用了 全新的订阅事件仪表盘 它允许你 随时查看 用户订阅活动

你可以使用它 来查看用户如何转换到 订阅的标准价格 或者你甚至可以 使用它来了解 新订阅用户 与回归的订阅用户的比率

通过应用正确的过滤器 你还可以使用它 来具体查看 特定的订阅优惠 如何赢回以前未订阅的用户 然后你可以 使用这些信息 通知和优化你的订阅优惠 并决定在何时分配优惠

总而言之 如果你从今天的会议中 学习到了什么 我们希望是实现订阅优惠 但是你必须在 App 内 和服务器上实现它们 我们强烈建议你 执行详细的 用户资格规则 通过使用 来自收据的信息 我们更新了服务器到服务器的通知 以便你能够实时了解 用户活动 并获得只有开发者能够拥有 且 Apple 不会拥有的数据

我们鼓励你向用户提供 内容定向的订阅优惠 我们希望你这样做 以便在 App 中 提供最佳的用户体验 最后 在订阅优惠被分发到用户之后 建议你使用我们的两个 全新的报告仪表盘 来监视这些 订阅优惠的性能 获取更多信息 欢迎大家 在演讲之后的下午 3 点 来到我们的实验室 感谢今天所有参加 “订阅优惠”会议的各位 我真的很期待 能够看到你们在你们的 App 中 做出怎样的创新 为我们共同的用户 提供优异的使用体验 谢谢大家 [掌声]