マルチ製品承認
マルチ製品承認により、単一の同意フローで複数の製品を親に提示して承認を求めることができます。これにより、信頼できる大人の同意プロセスの摩擦が減り、プライバシー規制へのコンプライアンスを維持しながら、家族がゲームやサービスにアクセスしやすくなります。
メリット
- 信頼できる大人の摩擦の削減: 信頼できる大人は、各製品に対して個別の同意フローを経るのではなく、一度に複数の製品を承認できます
- 子供のエクスペリエンスの改善: 子供は複数の製品に同時にアクセスでき、待機時間と放棄された同意フローが減ります
- 柔軟な設定: プラットフォームアーキテクチャとユーザーのニーズに基づいて、どの製品をバンドルするかを選択できます
- コンプライアンスの維持: バンドル内のすべての製品が、個別の権限設定と規制要件を維持します
ユースケース
マルチ製品承認は、以下に最適です：
- プラットフォーム + ゲーム: 複数のゲームが依存するアカウントシステムまたはプラットフォームがある場合
- ゲームコレクション: 家族が通常一緒にアクセスしたい複数の関連ゲームを提供する場合
- 階層的アクセス: 同時に承認できるコアサービスとオプションのアドオンがある場合
設定オプション
マルチ製品承認を実装するには、3つの方法があります：
1. 製品バンドリング（静的設定）
Compliance Studioを通じて、同意フローで自動的に一緒に表示される製品を設定します。
設定方法：
- Compliance Studioで製品を選択します
- 設定に移動し、マルチ製品承認セクション内で編集をクリックします
- マルチ製品承認を有効にするの横のトグルをクリックします
- 現在の製品とバンドルする製品を選択します
- Push to Testをクリックします
信頼できる大人のエクスペリエンス - 親が主要製品の同意リクエストを受信すると、バンドルされた製品が自動的に含まれているのが表示されます。信頼できる大人は、承認したくない場合はバンドルされた製品を削除できます。
最適な用途: 通常一緒に使用されるが、厳密な依存関係がない製品
2. 必須製品（必要な依存関係）
製品が機能するために別の製品を必須としてマークします。これは、製品がプラットフォームまたはアカウントシステムに依存している場合に通常使用されます。
設定方法：
- Compliance Studioで製品を選択します
- 設定に移動し、マルチ製品承認セクション内で編集をクリックします
- マルチ製品承認を有効にするの横のトグルをクリックします
- 必須製品の下で、この製品と一緒に承認する必要がある製品を選択します
- Push to Testをクリックします
信頼できる大人のエクスペリエンス - 必須製品は同意フローから削除できません。信頼できる大人は、両方の製品を一緒に承認するか、同意リクエストを完全に拒否する必要があります。
重要な制限：
- 製品は1つの必須製品のみを持つことができます
- 必須製品自体が別の必須製品を要求することはできません（チェーンなし）
- 利便性のためではなく、真の依存関係の場合にのみ使用してください
最適な用途: 別の製品へのアクセスなしでは機能できない製品（たとえば、プラットフォームアカウントが必要なゲーム）
3. 動的バンドリング（APIベース）
APIを使用して同意チャレンジを作成する際に、プログラムでバンドルする製品を選択します。
使用方法：
/challenge/create-bulk APIエンドポイントを、含めたい特定の製品IDで呼び出します：
{
"jurisdiction": "US-CA",
"requestedProductIds": [123, 456, 789],
"kuid": "12b9fa0e-6d6d-4903-a1fc-f2233027b71d"
}
信頼できる大人のエクスペリエンス - 信頼できる大人は、この同意リクエスト用に定義した特定の製品バンドルを確認できます。
最適な用途：
- ユーザーの行動に基づくコンテキストバンドリング
- 異なる製品組み合わせのA/Bテスト
- どの製品を一緒に提供するかを決定する複雑なロジック
ベストプラクティス
適切なアプローチの選択
- バンドリングを使用: 製品が通常一緒に使用されるが、技術的な依存関係がない場合
- 必須製品を使用: 1つの製品が別の製品なしでは真に機能できない場合にのみ使用
- 動的バンドリングを使用: ランタイムの柔軟性またはコンテキスト製品選択が必要な場合
設定のヒント
- シンプルに始める: 必須製品のみから始め、必要に応じてバンドリングを追加します
- 信頼できる大人のジャーニーを考慮: 1つのバンドルにあまり多くの製品を含めて親を圧倒しないようにします
- フローをテスト: 公開前にテストモードを使用して親エクスペリエンスを確認します
- 依存関係を文書化: 開発チームのために、どの製品が他の製品に依存しているかの明確な記録を保持します
権限に関する考慮事項
複数の製品がバンドルされている場合：
- 信頼できる大人は、すべての製品からのすべての権限の和集合を確認します
- 各製品は独自の権限設定を維持します
- 信頼できる大人は、各製品の権限を個別に許可または不許可にできます
- バンドルされた製品からのすべてのデータ開示が一緒に提示されます
一般的なパターン
パターン1: アカウントと複数のゲーム
設定：
- アカウントシステム製品（必須製品なし）
- ゲームA: アカウントシステムを必須製品として
- ゲームB: アカウントシステムを必須製品として
- ゲームC: アカウントシステムを必須製品として
結果 - 任意のゲームの承認が自動的にアカウントシステムの承認を必要としますが、親は一度に複数のゲームを承認できます。
アカウントシステム統合 - 複数のゲームにまたがるアカウントシステムと統合する場合、通常、各ゲーム用に1つのk-ID製品を作成し、アカウントシステム自体用に別のk-ID製品を作成します。これは、すべてのゲームまたはアカウント自体に共通またはグローバルな権限と開示を表すのに役立ちます。
製品がアカウントシステムにマッピングされている場合、これは各ゲームに対して2つのSessionオブジェクトが取得されることを意味します：1つはゲームにマッピングされたk-ID製品用、もう1つはアカウントシステムにマッピングされたk-ID製品用です。k-ID APIは、APIキーによって製品にスコープされます。アカウントシステムにマッピングされたk-ID製品にアクセスしようとしているのか、ゲームにアクセスしようとしているのかに応じて、正しいAPIキーを使用する必要があります。
VPCの製品コンテキスト - ゲームがすべてプレイにアカウントを必要とする場合、VPCはアカウント作成プロセスからトリガーできます。ただし、同意のリクエストはゲーム固有である必要があるため、親は何に同意しているかを知ることができます。k-ID APIは、VPCをトリガーする際に使用されるAPIキーに基づいて、同意プロセス中に親に提示される製品を決定します。
実際には、アカウントシステムへのk-IDの統合は、アカウント設定時にアカウント作成プロセスをトリガーしたゲームを決定し、それをk-ID APIキーにマッピングできる必要があります。
パターン2: オプションのアドオン付きゲームスイート
設定：
- メインゲーム: 必須製品なし
- 拡張パックA: メインゲームを必須製品として、メインゲームとバンドル
- 拡張パックB: メインゲームを必須製品として、メインゲームとバンドル
結果 - 信頼できる大人は、1つのフローでオプションの拡張パック付きのメインゲームを承認できます。
パターン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オブジェクトのプロパティとして返されます。複数のゲームにまたがるアカウントシステムと統合する場合、kuidはSessionに存在する場合、アカウントシステムのプレイヤーのアイデンティティに関連付ける必要があります。これにより、正しい製品の適切なAPIキーを使用してkuidのみをパラメータとして提供することで、任意のk-ID製品のk-IDセッション（存在する場合）を取得できます。
信頼できる大人が子供に1つ以上の製品をプレイするための同意を与えると、承認された各製品の登録済みwebhookエンドポイントが、eventTypeがChallenge.StateChangeに設定されて呼び出されます。各Sessionオブジェクトは、プレイヤーに対して同じkuidを持ちます。webhooksの詳細については、Webhooksを参照してください。
複数製品のセッションのキャッシュ
アカウントシステムと統合する場合、複数の製品からのセッションがキャッシュされます。Sessionオブジェクトは、k-ID製品IDをキーとして使用して、アカウントシステムのマップとしてすべてキャッシュできます。プレイヤーが新しいゲームをプレイしようとすると、製品IDでSessionオブジェクトを含むマップをクエリでき、Sessionが既に存在する場合、プレイヤーは追加の信頼できる大人の同意なしで続行できます。
APIエンドポイント
- 静的設定: Compliance Studio UI
- 動的バンドリング:
/challenge/create-bulk - セッション取得:
/session/get?kuid={kuid}（APIキーに関連付けられた製品のセッションを返す）
エッジケースと考慮事項
年齢最小要件
ルール - 子供はバンドル内のすべての製品の年齢要件を満たす必要があります。
必須製品が依存する製品よりも高い年齢最小値を持つ場合、その年齢未満の子供は両方の製品へのアクセスを拒否されます。
例：
- ゲームA: 最小年齢10、アカウントシステムを必須製品として必要
- アカウントシステム: 最小年齢13
結果 - ゲームAの設定された最小値が10であっても、子供はゲームAにアクセスするために少なくとも13歳である必要があります。
ベストプラクティス - 依存製品の年齢最小値を、必須製品の年齢最小値以上に設定します。
権限処理
ルール - 信頼できる大人は、すべてのバンドル製品全体で最も制限的な権限要件を承認する必要があります。
製品が一緒にバンドルされている場合、k-IDはすべての製品全体で各権限を評価し、最も制限的な設定を適用します：
- 権限が任意の製品で必須の場合、バンドル全体で必須になります
- 権限が1つの製品でオプションだが、別の製品で必須の場合、必須になります
- 信頼できる大人は、同意フローを完了するためにすべての必須権限を付与する必要があります
例：
- ゲームA: 「ボイスチャット」はオプション（親が選択可能）
- アカウントシステム（ゲームAに必須）: 「ボイスチャット」は必須（親が承認する必要がある）
結果 - ゲームAだけではオプションになっていたとしても、信頼できる大人は同意を付与するために「ボイスチャット」を承認する必要があります。
ベストプラクティス：
- 可能な場合は、依存製品間で権限要件を調整します
- 親が確認する組み合わせ権限セットを確認します
- 特定の権限をプラットフォームレベルまたはゲームレベルで必須にする必要があるかどうかを検討します