跳到主要内容

多产品批准

多产品批准允许您在单个同意流程中向家长展示多个产品以供批准。这减少了家长同意流程中的摩擦，使家庭更容易访问您的游戏和服务，同时保持对隐私法规的合规性。

优势​

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

多产品批准

使用场景​

多产品批准适用于：

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

示例场景​

您的公司提供一个游戏平台，具有中央账户系统和几个独立游戏。当儿童尝试玩游戏A时：

  1. 同意流程自动包括账户系统和游戏A
  2. 家长一次性审查和批准两个产品的权限
  3. 儿童立即获得对两个产品的访问权限
  4. 如果儿童后来想玩游戏B，家长可以单独批准或与其他游戏一起批准

配置选项​

有三种方式实现多产品批准：

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

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

配置方法:

  1. 在 Compliance Studio 中选择您的产品
  2. 转到 Configuration，在 Multi-Product Approval 部分内点击 Edit
  3. 点击 Enable Multi-Product Approval 旁边的切换开关
  4. 选择要与当前产品捆绑的产品
  5. 点击 Push to Test

多产品批准

家长体验: 当家长收到主要产品的同意请求时，他们将自动看到包含的捆绑产品。家长可以移除他们不想批准的捆绑产品。

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

有关如何为多产品批准配置产品的更多详细信息，请参阅Compliance Studio指南 Multi-Product Approval。

2. 必需产品（必需依赖）​

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

配置方法:

  1. 在 Compliance Studio 中选择您的产品
  2. 转到 Configuration，在 Multi-Product Approval 部分内点击 Edit
  3. 点击 Enable Multi-Product Approval 旁边的切换开关
  4. 在 Essential Product 下，选择必须与此产品一起批准的产品
  5. 点击 Push to Test

家长体验: 必需产品无法从同意流程中移除。家长必须一起批准两个产品，或者完全拒绝同意请求。

重要限制:

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

最适合: 没有对另一个产品的访问就无法功能的产品（例如，需要平台账户的游戏）

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: 账户系统作为必需产品

结果: 任何游戏批准自动要求账户系统批准，但家长可以一次性批准多个游戏。

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

配置:

  • 主游戏: 无必需产品
  • 扩展包A: 主游戏作为必需产品，与主游戏捆绑
  • 扩展包B: 主游戏作为必需产品，与主游戏捆绑

结果: 家长可以在一个流程中批准带有可选扩展的主游戏。

模式3: 平台方法​

配置:

  • 平台产品: 无必需产品
  • 社交功能: 平台作为必需，与平台捆绑
  • 高级内容: 平台作为必需，与平台捆绑

结果: 家长批准平台访问，为附加功能提供简单的附加组件。

技术细节​

Webhook事件​

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

会话管理​

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

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

API端点​

边缘情况和考虑​

在配置多产品批准时，请注意必需产品如何影响年龄要求和权限：

年龄最小要求​

规则: 儿童必须满足捆绑中所有产品的年龄要求。

如果必需产品的年龄最小值高于依赖它的产品，低于该年龄的儿童将被拒绝访问两个产品。

示例:

  • 游戏A: 最小年龄10岁，要求账户系统作为必需产品
  • 账户系统: 最小年龄13岁

结果: 尽管游戏A的配置最小值为10岁，但儿童必须至少13岁才能访问游戏A。

最佳实践: 将依赖产品的年龄最小值设置为等于或高于其必需产品的年龄最小值。

权限处理​

规则: 家长必须批准捆绑中所有产品的最严格权限要求。

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

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

示例:

  • 游戏A: "语音聊天"是可选的（家长可以选择）
  • 账户系统（游戏A的必需）: "语音聊天"是必需的（家长必须批准）

结果: 尽管游戏A单独会使它成为可选的，但家长必须批准"语音聊天"才能授予同意。

最佳实践:

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

测试您的配置​

在上线之前：

  1. 审查您的产品架构: 识别哪些产品有依赖关系，哪些通常一起使用
  2. 在测试模式中配置: 在测试环境中设置您的多产品批准配置
  3. 测试家长体验: 作为家长通过同意流程验证体验
  4. 审查Webhook集成: 确保您的后端正确处理多个会话事件
  5. 推送到上线: 准备就绪时，将您的配置发布到上线环境