在 Adapty 中，您将在客户使用应用的整个旅程中收到各种订阅事件。这些订阅流程描述了常见场景，帮助您了解用户订阅、取消或重新激活订阅时 Adapty 生成的事件。

请注意，Apple 会在实际开始/续订时间前数小时处理订阅付款。在以下流程图中，为保持示意图清晰，我们将订阅开始/续订与扣费显示为同时发生。

此外，与同一操作相关的事件会同时发生，可能以任意顺序出现在您的 Event Feed 中，顺序可能与我们示意图中显示的不同。

订阅生命周期

初次购买流程

当客户首次购买订阅（不含试用期）时，将触发以下事件：

• Subscription started
• Access level updated（授予用户访问权限）

当订阅续订日期到来时，订阅将自动续订，并触发以下事件：

• Subscription renewal（开始新一个订阅周期）
• Access level updated（更新订阅到期日期，将访问权限延长一个周期）

付款失败或用户取消续订的情况，分别在账单问题结果流程和订阅取消流程中说明。

订阅取消流程

当用户取消订阅时，将触发以下事件：

• Subscription renewal canceled（表示订阅在当前周期结束前仍然有效，之后用户将失去访问权限）
• Access level updated（为该访问等级禁用自动续订）

订阅结束后，将触发 Subscription expired (churned) 事件，标志订阅终止。

如果退款获批，以下事件将替代 Subscription expired (churned)：

• Subscription refunded（结束订阅并提供退款详情）

对于 Stripe，订阅可以立即取消，跳过剩余周期。在这种情况下，以下事件同时触发：

• Subscription renewal cancelled
• Subscription expired (churned)
• Access Level updated（移除用户的访问权限）

如果退款获批，退款批准时还会触发 Subscription refunded 事件。

订阅重新激活流程

如果用户取消订阅后到期，之后又重新购买同一订阅，将触发 Subscription renewed 事件。即使访问权限存在间隔，Adapty 也会通过 vendor_original_transaction_id 将这些交易视为同一交易链，因此重新购买被视为续订。

Access level updated 事件将被触发两次：

• 订阅结束时，撤销用户的访问权限
• 用户重新购买时，授予访问权限

订阅暂停流程（仅 Android）

此流程适用于用户在 Android 上暂停订阅后再恢复的情况。

暂停订阅有延迟效果。如果用户在订阅即将续订前暂停，订阅将保持活跃状态，用户在当前计费周期的剩余时间内仍可使用付费内容。

1. 用户暂停订阅时，触发 Subscription paused (Android only) 事件。

2. 订阅周期结束时，Adapty 触发 Access level updated 事件，撤销用户的访问权限。

3. 用户恢复订阅时，触发以下事件：

   • Subscription renewed
   • Access level updated（恢复用户的访问权限）

这些订阅将属于同一交易链，通过相同的 vendor_original_transaction_id 关联。

试用流程

如果您在应用中使用试用期，您将收到额外的试用相关事件。

成功转化的试用流程

最常见的流程是：用户开始试用、提供信用卡信息，并在试用期结束时成功转化为标准订阅。在试用开始时，将触发以下事件：

• Trial started（标记试用开始）
• Access level updated（授予访问权限）

标准订阅开始时，触发 Trial converted 事件。

未成功转化的试用流程

如果用户在试用转化为订阅前取消，将在取消时触发以下事件：

• Trial renewal cancelled（禁止试用自动转化为订阅）
• Access level updated（禁用访问续订）

用户将保留访问权限直到试用期结束，届时触发 Trial expired 事件，标记试用结束。

试用期到期后的订阅重新激活流程

如果试用期到期（因账单问题或取消）且用户之后购买了订阅，将触发以下事件：

• Access level updated（授予用户访问权限）
• Trial converted

即使试用和订阅之间存在间隔，Adapty 也会通过 vendor_original_transaction_id 将两者关联。此次转化被视为连续交易链的一部分（从零价格试用开始），因此触发 Trial converted 事件而非 Subscription started。

产品变更

本节涵盖对有效订阅所做的各类调整，例如升级、降级或购买其他组的产品。

立即生效的产品变更流程

用户更改产品后，可能会在订阅结束前立即在系统中生效（主要发生在升级或替换产品的情况下）。在这种情况下，产品变更时：

• 访问等级随之变更，同时触发两个 Access level updated 事件：
  1. 移除第一个产品的访问权限。
  2. 授予第二个产品的访问权限。
• 旧订阅结束并支付退款（触发 Subscription refunded 事件，cancellation_reason = upgraded）。请注意，不会触发 Subscription expired (churned) 事件；Subscription refunded 事件将替代它。
• 新订阅开始（为新产品触发 Subscription started 事件）。

如果用户降级订阅，第一个订阅将持续到付费周期结束，届时被新的低级别订阅替代。在这种情况下，立即触发的仅有 Access level updated 事件（禁用访问自动续订）。其他所有事件将在订阅实际切换时触发：

• 另一个 Access level updated 事件（授予第二个产品的访问权限）。
• Subscription expired (churned) 事件（结束第一个产品的订阅）。
• Subscription started 事件（为新产品开始新订阅）。

延迟生效的产品变更流程

还有一种情况是用户在订阅续订时更改产品。此情况与前一种非常相似：立即触发一个 Access level updated 事件，禁用旧产品的访问自动续订。其他所有事件将在用户更改订阅且系统完成切换时触发：

• 另一个 Access level updated 事件（授予第二个产品的访问权限）。
• Subscription expired (churned) 事件（结束第一个产品的订阅）。
• Subscription started 事件（为新产品开始新订阅）。

账单问题结果流程

如果因账单问题导致试用转化或订阅续订失败，后续处理取决于是否启用了宽限期。

启用宽限期时，若付款成功，试用将转化或订阅将续订；若付款失败，应用商店将继续尝试向用户收费，若仍然失败，应用商店将自行终止试用或订阅。

因此，在发生账单问题时，Adapty 将触发以下事件：

• Billing issue detected
• Entered grace period（如果启用了宽限期）
• Access level updated（提供至宽限期结束的访问权限）

如果之后付款成功，Adapty 会记录 Trial converted 或 Subscription renewed 事件，用户不会失去访问权限。

如果付款最终失败且应用商店取消订阅，Adapty 将触发以下事件：

• Trial expired 或 Subscription expired (churned)（cancellation_reason: billing_error）
• Access level updated（撤销用户的访问权限）

未启用宽限期时，账单重试期（应用商店持续尝试向用户收费的时间段）将立即开始。

如果在宽限期结束前付款始终未成功，流程相同：当应用商店自动终止订阅时，触发以下相同事件：

• Trial expired 或 Subscription expired (churned) 事件（cancellation_reason 为 billing_error）

• Access level updated（撤销用户的访问权限）

跨用户账户共享购买的流程

当一个 Customer User ID iOS、Android、React Native、Flutter 和 Unity 尝试恢复或延长已绑定到不同 Customer User ID iOS、Android、React Native、Flutter 和 Unity 的订阅时，Adapty 的 Sharing paid access between user accounts 设置将控制访问权限的管理方式。具体流程将因所选选项而异。

将访问权限转移给新用户的流程

推荐选项是将访问等级转移给新用户。这可保留原用户的交易历史，确保分析数据的一致性。仅触发 2 个 Access level updated 事件：

1. 移除第一个用户的访问权限
2. 授予第二个用户访问权限

以下是此场景中生成的事件中与访问等级分配和转移相关字段的详细说明：

• 用户 A：Access level updated（在用户 A 于应用内购买订阅时发送）

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

• 用户 A：Access level updated（在应用重新安装且用户 B 登录、撤销用户 A 访问权限时发送）

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": false,
    },
    "profiles_sharing_access_level": null
  }

• 用户 B：Access level updated（在用户 B 登录并获得访问权限时发送）

  {
    "profile_id": "00000000-0000-0000-0000-000000000001",
    "customer_user_id": UserB,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

用户间共享访问权限的流程

此选项允许多个用户在其设备使用同一 Apple/Google ID 登录时共享同一访问等级。当用户重新安装应用并使用不同邮箱登录时，他们仍可访问之前的购买内容，非常实用。启用此选项后，多个已识别的用户可以共享同一访问等级。在共享访问期间，所有交易均记录在原始 Customer User ID iOS、Android、React Native、Flutter 和 Unity 下，以保持完整的交易历史和分析数据。

因此，仅触发 1 个事件：Access level updated（授予第二个用户访问权限）。

以下是此场景中生成的事件中与访问等级分配和共享相关字段的详细说明：

用户 B：Access level updated（在用户 B 登录并获得访问权限时发送）

{
  "profile_id": "00000000-0000-0000-0000-000000000000",
  "customer_user_id": UserA,
  "event_properties": {
    "profile_has_access_level": true,
  },
  "profiles_sharing_access_level": [
    {
      "profile_id": "00000000-0000-0000-0000-000000000001,
      "customer_user_id": UserB
    }
  ]
}

用户间不共享访问权限的流程

启用此选项后，第一个获得访问等级的用户画像将永久保留该权限。如果需要将购买内容绑定到单一 Customer User ID iOS、Android、React Native、Flutter 和 Unity ，此选项非常理想。