多产品批准
多产品批准允许您在单个同意流程中向家长展示多个产品以供批准。这减少了家长同意流程中的摩擦,使家庭更容易访问您的游戏和服务,同时保持对隐私法规的合规性。
优势
- 减少家长摩擦: 家长可以一次性批准多个产品,而不需要为每个产品经历单独的同意流程
- 改善用户体验: 儿童可以同时访问多个产品,减少等待时间和被放弃的同意流程
- 灵活配置: 根据您的平台架构和用户需求选择要捆绑在一起的产品
- 保持合规: 捆绑中的所有产品都保持其个人权限 设置和监管要求

使用场景
多产品批准适用于:
- 平台 + 游戏: 您有一个多个游戏依赖的账户系统或平台
- 游戏集合: 您提供多个相关游戏,家庭通常希望一起访问
- 分层访问: 您有核心服务和可选附加组件,可以同时批准
示例场景
您的公司提供一个游戏平台,具有中央账户系统和几个独立游戏。当儿童尝试玩游戏A时:
- 同意流程自动包括账户系统和游戏A
- 家长一次性审查和批准两个产品的权限
- 儿童立即获得对两个产品的访问权限
- 如果儿童后来想玩游戏B,家长可以单独批准或与其他游戏一起批准
配置选项
有三种方式实现多产品批准:
1. 产品捆绑(静态配置)
通过 Compliance Studio 配置哪些产品在同意流程中自动一起出现。
配置方法:
- 在 Compliance Studio 中选择您的产品
- 转到 Configuration,在 Multi-Product Approval 部分内点击 Edit
- 点击 Enable Multi-Product Approval 旁边的切换开关
- 选择要与当前产品捆绑的产品
- 点击 Push to Test

家长体验: 当家长收到主要产品的同意请求时,他们将自动看到包含的捆绑产品。家长可以移除他们不想批准的捆绑产品。
最适合: 经常一起使用但没有硬依赖关系的产品
有关如何为多产品批准配置产品的更多详细信息,请参阅Compliance Studio指南 Multi-Product Approval。
2. 必需产品(必需依赖)
将另一个产品标记为您的产品功能所必需的。这通常用于您的产品依赖于平台或账户系统时。
配置方法:
- 在 Compliance Studio 中选择您的产品
- 转到 Configuration,在 Multi-Product Approval 部分内点击 Edit
- 点击 Enable Multi-Product Approval 旁边的切换开关
- 在 Essential Product 下,选择必须与此产品一起批准的产品
- 点击 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: 账户 + 多个游戏
配置:
- 账户系统产品(无必需产品)
- 游戏A: 账户系统作为必需产品
- 游戏B: 账户系统作为必需产品
- 游戏C: 账户系统作为必需产品
结果: 任何游戏批准自动要求账户系统批准,但家长可以一次性批准多个游戏。
模式2: 带可选附加组件的游戏套件
配置:
- 主游戏: 无必需产品
- 扩展包A: 主游戏作为必需产品,与主游戏捆绑
- 扩展包B: 主游戏作为必需产品,与主游戏捆绑
结果: 家长可以在一个流程中批准带有可选扩展的主游戏。
模式3: 平台方法
配置:
- 平台产品: 无必需产品
- 社交功能: 平台作为必需,与平台捆绑
- 高级内容: 平台作为必需,与平台捆绑
结果: 家长批准平台访问,为附加功能提供简单的附加组件。
技术细节
Webhook事件
当家长批准多产品捆绑时,您将收到每个批准产品的单独 Challenge.StateChange webhook事件。所有会话将共享相同的 kuid(k-ID用户ID),允许您将它们与同一个儿童关联。