메인 콘텐츠로 이동

다중 제품 승인

다중 제품 승인을 통해 단일 동의 플로우에서 여러 제품을 부모에게 승인 요청으로 제시할 수 있습니다. 이는 부모 동의 프로세스의 마찰을 줄여 개인정보 보호 규정을 준수하면서도 가족이 게임과 서비스에 더 쉽게 접근할 수 있도록 합니다.

장점​

  • 부모 마찰 감소: 부모는 각 제품에 대해 별도의 동의 플로우를 거치지 않고 여러 제품을 한 번에 승인할 수 있습니다
  • 향상된 사용자 경험: 어린이가 여러 제품에 동시에 접근할 수 있어 대기 시간과 중단된 동의 플로우를 줄입니다
  • 유연한 구성: 플랫폼 아키텍처와 사용자 요구사항에 따라 함께 묶을 제품을 선택할 수 있습니다
  • 규정 준수 유지: 번들에 포함된 모든 제품은 개별 권한 설정과 규제 요구사항을 유지합니다

다중 제품 승인

사용 사례​

다중 제품 승인은 다음에 이상적입니다:

  • 플랫폼 + 게임: 여러 게임이 의존하는 계정 시스템이나 플랫폼이 있는 경우
  • 게임 컬렉션: 가족이 일반적으로 함께 접근하고 싶어하는 여러 관련 게임을 제공하는 경우
  • 계층형 접근: 핵심 서비스와 선택적 애드온을 동시에 승인할 수 있는 경우

예시 시나리오​

귀하의 회사가 중앙 계정 시스템과 여러 개별 게임을 갖춘 게임 플랫폼을 제공한다고 가정해보겠습니다. 어린이가 게임 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를 클릭합니다

다중 제품 승인

부모 경험: 부모가 기본 제품에 대한 동의 요청을 받으면, 번들된 제품이 자동으로 포함된 것을 볼 수 있습니다. 부모는 승인하고 싶지 않은 번들된 제품을 제거할 수 있습니다.

최적 용도: 일반적으로 함께 사용되지만 하드 의존성이 없는 제품

Multi-Product Approval을 위한 제품 구성에 대한 자세한 내용은 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: 플랫폼 접근 방식​

구성:

  • 플랫폼 제품: 필수 제품 없음
  • 소셜 기능: 플랫폼을 필수로, 플랫폼과 번들
  • 프리미엄 콘텐츠: 플랫폼을 필수로, 플랫폼과 번들

결과: 부모는 플랫폼 접근을 승인하고, 추가 기능을 위한 쉬운 애드온을 제공합니다.

기술적 세부사항​

웹훅 이벤트​

부모가 다중 제품 번들을 승인하면, 승인된 각 제품에 대해 별도의 Challenge.StateChange 웹훅 이벤트를 받게 됩니다. 모든 세션은 동일한 kuid (k-ID 사용자 ID)를 공유하므로 동일한 어린이와 연결할 수 있습니다.

세션 관리​

번들의 각 승인된 제품은 자체 sessionId로 자체 세션을 생성합니다. 다음을 수행해야 합니다:

  • 플레이어의 kuid와 연결된 모든 세션을 캐시하세요
  • 각 제품에 대한 권한을 확인할 때 적절한 세션을 사용하세요
  • 관련 sessionId 또는 kuid와 제품 API 키를 사용하여 /session/get으로 세션을 쿼리하세요

API 엔드포인트​

엣지 케이스 및 고려사항​

다중 제품 승인을 구성할 때, 필수 제품이 연령 요구사항과 권한에 어떤 영향을 미치는지 알아야 합니다:

연령 최소 요구사항​

규칙: 어린이는 번들의 모든 제품에 대한 연령 요구사항을 충족해야 합니다.

필수 제품이 의존하는 제품보다 높은 연령 최소값을 가지면, 해당 연령 미만의 어린이는 두 제품 모두에 대한 접근이 거부됩니다.

예시:

  • 게임 A: 최소 연령 10세, 계정 시스템을 필수 제품으로 요구
  • 계정 시스템: 최소 연령 13세

결과: 게임 A의 구성된 최소값이 10세임에도 불구하고, 어린이는 게임 A에 접근하려면 최소 13세여야 합니다.

모범 사례: 의존 제품의 연령 최소값을 필수 제품의 연령 최소값과 같거나 높게 설정하세요.

권한 처리​

규칙: 부모는 번들된 모든 제품에서 가장 제한적인 권한 요구사항을 승인해야 합니다.

제품이 함께 번들될 때, k-ID는 모든 제품에서 각 권한을 평가하고 가장 제한적인 설정을 적용합니다:

  • 권한이 어떤 제품에서 필수이면, 전체 번들에 대해 필수가 됩니다
  • 권한이 한 제품에서는 선택사항이지만 다른 제품에서는 필수이면, 필수가 됩니다
  • 부모는 동의 플로우를 완료하기 위해 모든 필수 권한을 부여해야 합니다

예시:

  • 게임 A: "음성 채팅"이 선택사항 (부모가 선택 가능)
  • 계정 시스템 (게임 A에 필수): "음성 채팅"이 필수 (부모가 승인해야 함)

결과: 게임 A만으로는 선택사항이었을 것이지만, 부모는 동의를 부여하기 위해 "음성 채팅"을 승인해야 합니다.

모범 사례:

  • 가능한 경우 의존 제품 간의 권한 요구사항을 정렬하세요
  • 부모가 볼 결합된 권한 세트를 검토하세요
  • 특정 권한이 플랫폼 레벨에서 필요한지 게임 레벨에서 필요한지 고려하세요

구성 테스트​

라이브로 전환하기 전에:

  1. 제품 아키텍처 검토: 어떤 제품이 의존성을 가지고 있고 어떤 제품이 일반적으로 함께 사용되는지 식별하세요
  2. 테스트 모드에서 구성: 테스트 환경에서 다중 제품 승인 구성을 설정하세요
  3. 부모 경험 테스트: 부모로서 동의 플로우를 진행하여 경험을 확인하세요
  4. 웹훅 통합 검토: 백엔드가 여러 세션 이벤트를 적절히 처리하는지 확인하세요
  5. 라이브로 푸시: 준비가 되면 구성을 라이브 환경에 게시하세요