跳到主要内容

多产品批准

多产品批准允许您在单个同意流程中向父母呈现多个产品以供批准。这减少了可信成人同意流程中的摩擦，使家庭更容易访问您的游戏和服务，同时保持符合隐私法规。

优势​

  • 减少可信成人摩擦：可信成人可以一次批准多个产品，而不是为每个产品经历单独的同意流程
  • 改善儿童体验：儿童同时获得对多个产品的访问权限，减少等待时间和被放弃的同意流程
  • 灵活配置：根据您的平台架构和用户需求选择将哪些产品捆绑在一起
  • 保持合规性：捆绑包中的所有产品都保持其个人权限设置和法规要求

multi-product approval

用例​

多产品批准适用于：

  • 平台 + 游戏：您有一个多个游戏依赖的账户系统或平台
  • 游戏集合：您提供多个相关游戏，家庭通常希望一起访问
  • 分层访问：您有核心服务和可选附加组件，可以同时批准

配置选项​

有三种方法可以实施多产品批准：

1. 产品捆绑（静态配置）​

通过 Compliance Studio 配置哪些产品在同意流程中自动一起出现。

如何配置：

  1. 在 Compliance Studio 中，选择您的产品
  2. 转到配置，在多产品批准部分内单击编辑。
  3. 单击启用多产品批准旁边的切换开关
  4. 选择要与当前产品捆绑的产品
  5. 单击推送到测试

multi-product approval

可信成人体验 - 当父母收到主要产品的同意请求时，他们会自动看到包含的捆绑产品。如果可信成人不想批准它们，可以删除捆绑产品。

最适合经常一起使用但没有硬依赖关系的产品

2. 基本产品（必需依赖项）​

将另一个产品标记为您的产品运行所必需的。这通常在您的产品依赖于平台或账户系统时使用。

如何配置：

  1. 在 Compliance Studio 中，选择您的产品
  2. 转到配置，在多产品批准部分内单击编辑。
  3. 单击启用多产品批准旁边的切换开关
  4. 在基本产品下，选择必须与此产品一起批准的产品
  5. 单击推送到测试

可信成人体验 - 基本产品不能从同意流程中删除。可信成人必须一起批准两个产品，或者完全拒绝同意请求。

重要限制：

  • 一个产品只能有一个基本产品
  • 基本产品本身不能要求另一个基本产品（无链式）
  • 仅用于真正的依赖关系，而不仅仅是便利

最适合无法在没有访问另一个产品的情况下运行的产品（例如，需要平台账户的游戏）

3. 动态捆绑（基于 API）​

在创建同意挑战时，通过 API 以编程方式选择要捆绑的产品。

如何使用：

使用您要包含的特定产品 ID 调用 /challenge/create-bulk API 端点：

{
  "jurisdiction": "US-CA",
  "requestedProductIds": [123, 456, 789],
  "kuid": "12b9fa0e-6d6d-4903-a1fc-f2233027b71d"
}

可信成人体验 - 可信成人看到您为此同意请求定义的特定产品捆绑包。

最适合：

  • 基于用户行为的上下文捆绑
  • A/B 测试不同的产品组合
  • 确定将哪些产品一起提供的复杂逻辑

最佳实践​

选择正确的方法​

  • 使用捆绑当产品经常一起使用但没有技术依赖关系时
  • 使用基本产品仅当一个产品真正无法在没有另一个产品的情况下运行时
  • 使用动态捆绑当您需要运行时灵活性或上下文产品选择时

配置提示​

  1. 从简单开始：仅从基本产品开始，然后根据需要添加捆绑
  2. 考虑可信成人旅程：不要用一个捆绑包中的太多产品压倒父母
  3. 测试您的流程：在上线前使用测试模式验证父母体验
  4. 记录依赖关系：为您的开发团队保留哪些产品依赖于其他产品的清晰记录

权限考虑​

当多个产品捆绑在一起时：

  • 可信成人看到所有产品中所有权限的并集
  • 每个产品保持其自己的权限配置
  • 可信成人可以单独允许或禁止每个产品的权限
  • 来自捆绑产品的所有数据披露一起呈现

常见模式​

模式 1：账户和多个游戏​

配置：

  • 账户系统产品（无基本产品）
  • 游戏 A：账户系统作为基本产品
  • 游戏 B：账户系统作为基本产品
  • 游戏 C：账户系统作为基本产品

结果 - 任何游戏批准自动需要账户系统批准，但父母可以一次批准多个游戏。

账户系统集成 - 当与跨多个游戏的账户系统集成时，通常为每个游戏创建一个 k-ID 产品，然后为账户系统本身创建一个单独的 k-ID 产品。这对于表示对所有游戏或账户本身通用或全局的任何权限和披露很有用。

当产品映射到账户系统时，这意味着对于每个游戏，都会检索两个 Session 对象：一个用于映射到游戏的 k-ID 产品，一个用于映射到账户系统的 k-ID 产品。k-ID API 通过 API 密钥限定到产品。必须使用正确的 API 密钥，具体取决于您是尝试访问映射到账户系统的 k-ID 产品还是游戏。

VPC 的产品上下文 - 如果所有游戏都需要账户才能玩，则可以从账户创建过程触发 VPC。但是，同意请求必须特定于游戏，以便父母知道他们同意什么。k-ID API 根据触发 VPC 时使用的 API 密钥确定在同意过程中应向父母呈现哪个产品。

实际上，将 k-ID 集成到账户系统中必须能够在账户设置时确定哪个游戏触发了账户创建过程，并将其映射到 k-ID API 密钥。

模式 2：带可选附加组件的游戏套件​

配置：

  • 主游戏：无基本产品
  • 扩展包 A：主游戏作为基本产品，与主游戏捆绑
  • 扩展包 B：主游戏作为基本产品，与主游戏捆绑

结果 - 可信成人可以在一个流程中批准主游戏和可选扩展。

模式 3：平台方法​

配置：

  • 平台产品：无基本产品
  • 社交功能：平台作为基本，与平台捆绑
  • 高级内容：平台作为基本，与平台捆绑

结果 - 可信成人批准平台访问，轻松添加附加功能。

技术细节​

Webhook 事件​

有关 webhook 事件结构的详细信息，请参阅 Challenge.StateChange。

当父母批准多产品捆绑包时，您将为每个批准的产品收到单独的 Challenge.StateChange webhook 事件。所有会话共享相同的 kuid（k-ID 用户 ID），允许您将它们与同一个孩子关联。

会话管理​

捆绑包中每个批准的产品都会创建自己的会话，具有自己的 sessionId。您应该：

  • 缓存与玩家的 kuid 关联的所有会话
  • 在检查每个产品的权限时使用适当的会话
  • 使用相关的 sessionId 或 kuid 和产品 API 密钥使用 /session/get 查询会话

使用 kuid 进行跨产品会话访问​

k-ID 为所有已获得可信成人同意的玩家公开一个称为 kuid（k-ID 用户 ID）的全局标识符。kuid 作为 Session 对象的属性返回。当跨多个游戏与账户系统集成时，当 Session 中存在 kuid 时，应将其与账户系统中玩家的身份关联。这允许通过调用 /session/get 仅提供 kuid 作为参数并使用正确产品的适当 API 密钥来检索任何 k-ID 产品的 k-ID 会话（如果存在）。

当可信成人为孩子玩一个或多个产品给予同意时，每个批准产品的注册 webhook 端点都会以 eventType 设置为 Challenge.StateChange 调用。每个 Session 对象对玩家都有相同的 kuid。有关 webhooks 的更多信息，请参阅 Webhooks。

缓存多个产品的会话​

与账户系统集成时，来自多个产品的会话会被缓存。Session 对象都可以通过使用 k-ID 产品 ID 作为键在账户系统中缓存为映射。当玩家尝试玩新游戏时，可以通过产品 ID 查询包含 Session 对象的映射，如果 Session 已经存在，则可以在没有进一步可信成人同意的情况下允许玩家继续。

API 端点​

边缘情况和考虑​

年龄最低要求​

重要

规则 - 孩子必须满足捆绑包中所有产品的年龄要求。

如果基本产品的年龄最低要求高于依赖它的产品，低于该年龄的孩子将被拒绝访问两个产品。

示例：

  • 游戏 A：最低年龄 10，需要账户系统作为基本产品
  • 账户系统：最低年龄 13

结果 - 孩子必须至少 13 岁才能访问游戏 A，即使游戏 A 配置的最低年龄是 10。

最佳实践 - 将依赖产品的年龄最低要求设置为其基本产品的年龄最低要求或更高。

权限处理​

重要

规则 - 可信成人必须批准所有捆绑产品中最严格的权限要求。

当产品捆绑在一起时，k-ID 评估所有产品中的每个权限并应用最严格的设置：

  • 如果权限在任何产品中是必需的，它将成为整个捆绑包的必需
  • 如果权限在一个产品中是可选的，但在另一个产品中是必需的，它将成为必需的
  • 可信成人必须授予所有必需的权限才能完成同意流程

示例：

  • 游戏 A："语音聊天"是可选的（父母可以选择）
  • 账户系统（游戏 A 的基本产品）："语音聊天"是必需的（父母必须批准）

结果 - 可信成人必须批准"语音聊天"才能授予同意，即使游戏 A 单独会使其成为可选的。

最佳实践：

  • 尽可能在依赖产品之间对齐权限要求
  • 审查父母看到的组合权限集
  • 考虑某些权限是否应该在平台级别或游戏级别要求