マルチプロダクト承認
マルチプロダクト承認により、単一の同意フローで複数のプロダクトを親に提示して承認を求めることができます。これにより、信頼できる大人の同意プロセスの摩擦が減り、プライバシー規制へのコンプライアンスを維持しながら、家族がゲームやサービスにアクセスしやすくなります。
メリット
- 信頼できる大人の摩擦の削減: 信頼できる大人は、各プロダクトに対して個別の同意フローを経るのではなく、一度に複数のプロダクトを承認できます
- 子供のエクスペリエンスの改善: 子供は複数のプロダクトに同時にアクセスでき、待機時間と放棄された同意フローが減ります
- 柔軟な設定: プラットフォームアーキテクチャとユーザーのニーズに基づいて、どのプロダクトをバンドルするかを選択できます
- コンプライアンスの維持: バンドル内のすべてのプロダクトが、個別の権限設定と規制要件を維持します
ユースケース
マルチプロダクト承認は、以下に最適です：
- プラットフォーム + ゲーム: 複数のゲームが依存するアカウントシステムまたはプラットフォームがある場合
- ゲームコレクション: 家族が通常一緒にアクセスしたい複数の関連ゲームを提供する場合
- 階層的アクセス: 同時に承認できるコアサービスとオプションのアドオンがある場合
設定オプション
マルチプロダクト承認を実装するには、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だけではオプションになっていたとしても、信頼できる大人は同意を付与するために「ボイスチャット」を承認する必要があります。
ベストプラクティス：
- 可能な場合は、依存プロダクト間で権限要件を調整します
- 親が確認する組み合わせ権限セットを確認します
- 特定の権限をプラットフォームレベルまたはゲームレベルで必須にする必要があるかどうかを検討します