서드 파티 쿠키는 브라우저 제한, 사용자 설정, 개발자 플래그 또는 엔터프라이즈 정책에 의해 차단될 수 있습니다.
서드 파티 쿠키의 사용 가능 여부와 관계없이 사이트 또는 서비스에서 모든 사용자에게 우수한 환경을 제공해야 합니다.
이 페이지에는 서드 파티 쿠키가 차단될 때 영향을 받을 수 있는 일반적인 사용자 여정에 관한 정보가 포함되어 있습니다.
일반적인 사용자 경험
많은 결제 및 쇼핑 워크플로가 서드 파티 쿠키를 사용합니다. 다음 표에는 서드 파티 쿠키가 사용 중지된 경우 영향을 받을 수 있는 사용자 여정이 나열되어 있으며, 개발자가 중단을 방지하기 위해 사용할 수 있는 대체 API가 제안되어 있습니다. 이 목록에는 일부만 나와 있으며 개인 정보 보호 샌드박스 솔루션이 추가로 제공되면 업데이트될 수 있습니다.
결제 관련 사용자 여정 테스트
사용자 흐름이 서드 파티 쿠키 제한의 영향을 받는지 테스트하는 가장 좋은 방법은 서드 파티 쿠키 테스트 플래그를 사용 설정하여 사용자 흐름을 진행하는 것입니다.
웹사이트가 예상대로 작동하는지 확인하려면 서드 파티 쿠키가 제한된 상태에서 다음 흐름을 테스트하세요.
- 크로스 사이트 결제: 서드 파티 결제 제공업체 (예: <example-provider>로 결제)를 사용하는 결제 흐름을 테스트합니다. 다음 사항을 확인하세요.
- 리디렉션이 성공적으로 발생합니다.
- 결제 게이트웨이가 올바르게 로드됩니다.
- 결제 프로세스를 오류 없이 완료할 수 있습니다.
- 사용자가 예상대로 웹사이트로 다시 리디렉션됩니다.
- 결제 대시보드: 거래 대시보드 위젯이 서드 파티 쿠키가 제한된 상태에서 예상대로 작동하는지 테스트합니다. 사용자가 다음 작업을 할 수 있는지 확인합니다.
- 대시보드에 액세스합니다.
- 모든 결제가 예상대로 표시됩니다.
- 대시보드의 여러 섹션 (예: 거래 내역, 결제 세부정보) 간에 오류 없이 이동할 수 있습니다.
- 결제 수단 관리: 결제 수단 관리 위젯이 예상대로 작동하는지 테스트합니다. 서드 파티 쿠키가 차단된 상태에서 다음을 테스트합니다.
- 결제 수단 추가 또는 삭제가 예상대로 작동합니다.
- 이전에 저장한 결제 수단으로 결제하는 것은 영향을 받지 않습니다.
- 사기 감지: 서드 파티 쿠키가 있을 때와 없을 때 사기 감지 솔루션이 어떻게 작동하는지 비교합니다.
- 서드 파티 쿠키를 차단하면 추가 단계가 도입되어 사용자 마찰이 추가로 발생하나요?
- 브라우저에서 서드 파티 쿠키가 차단된 경우에도 의심스러운 패턴을 감지할 수 있나요?
- 맞춤 결제 버튼: 서드 파티 쿠키가 제한된 상태에서 결제 버튼이 올바르게 렌더링되는지 테스트합니다.
- 개인 맞춤 버튼에 사용자가 선호하는 방법이 표시되지 않더라도 사용자가 구매를 완료할 수 있나요?
크로스 사이트 결제
일부 결제 서비스 제공업체는 사용자가 재인증하지 않고도 여러 판매자 사이트에서 계정에 액세스할 수 있도록 서드 파티 쿠키를 사용할 수 있습니다. 서드 파티 쿠키 없이 탐색하는 사용자의 경우 이 사용자 여정이 영향을 받을 수 있습니다.
삽입된 결제 양식
다음 도메인을 고려하세요.
payment-provider.example는 판매자 사이트에 결제 서비스를 제공하고 사용자 결제 및 세션 데이터를 저장합니다.merchant.example은payment-provider.example에서 제공하는 결제 양식을 삽입하는 웹사이트입니다.
사용자가 방금 payment-provider.example에 로그인했습니다 (예: 다른 사이트에서 결제를 완료하는 동안). 사용자가 merchant.example에서 결제 절차를 시작합니다.
서드 파티 쿠키를 사용할 수 있는 경우 merchant.example에 삽입된 payment-provider.example 결제 양식은 최상위 컨텍스트에서 payment-provider.example에 설정된 자체 최상위 세션 쿠키에 액세스할 수 있습니다.
하지만 서드 파티 쿠키가 차단되면 삽입된 콘텐츠는 자체 최상위 쿠키에 액세스할 수 없습니다.
FedCM을 사용한 맞춤설정 가능한 솔루션
payment-provider.example은 ID 공급업체로 작동하도록 FedCM을 구현하는 것이 좋습니다. 이 접근 방식은 다음과 같은 경우에 적합합니다.
payment-provider.example이 관련 없는 서드 파티 사이트에 삽입되어 있습니다.payment-provider.example이 5개 이상의 관련 사이트에 삽입되어 있습니다.
FedCM의 주요 이점은 UI가 사용자에게 선택사항에 관한 더 많은 컨텍스트를 제공할 수 있다는 것입니다. 사용자 권한을 통해 FedCM은 신뢰 당사자 (merchant.example)와 ID 공급자(payment-provider.example) 간에 맞춤 데이터를 공유할 수 있습니다. 신뢰 당사자는 하나 이상의 ID 공급자를 지원하도록 선택할 수 있으며 FedCM UI는 조건부로만 표시됩니다.
필요에 따라 개발자는 사용자가 ID 제공자로 로그인할 때 FedCM 프롬프트가 자동으로 표시되는 수동 모드와 사용자가 결제 버튼을 클릭하는 등의 작업을 한 후 로그인 프로세스가 트리거되는 활성 모드 중에서 선택할 수 있습니다.
FedCM은 스토리지 액세스 API (SAA)의 신뢰 신호 역할도 하므로 사용자가 추가 사용자 메시지 없이 삽입의 제공업체로 로그인하는 데 동의한 후 삽입이 최상위 파티셔닝되지 않은 쿠키에 액세스할 수 있습니다.
스토리지 액세스 중심 솔루션
고려해야 할 또 다른 API는 Storage Access API (SAA)입니다.
SAA를 사용하면 사용자에게 payment-provider.example 삽입이 자체 최상위 쿠키에 액세스하도록 허용하라는 메시지가 표시됩니다. 사용자가 액세스를 승인하면 서드 파티 쿠키를 사용할 수 있을 때와 마찬가지로 양식이 렌더링됩니다.
FedCM과 마찬가지로 사용자는 payment-provider.example가 삽입된 모든 새 사이트에서 요청을 승인해야 합니다. API의 작동 방식을 알아보려면 SAA 데모를 참고하세요.
기본 SAA 프롬프트가 요구사항에 적합하지 않은 경우 FedCM을 구현하여 환경을 더 맞춤설정하는 것이 좋습니다.
소수의 관련 사이트에서 사용자 불편 감소
판매자 사이트와 결제 제공업체가 동일한 회사에 속하는 경우 관련 웹사이트 세트 (RWS) API를 사용하여 도메인 간의 관계를 선언할 수 있습니다. 이렇게 하면 사용자 마찰을 줄일 수 있습니다. 예를 들어 insurance.example와 payment-portal-insurance.example이 동일한 RWS에 있는 경우 payment-portal-insurance.example 삽입 내에서 저장소 액세스가 요청되면 payment-portal-insurance.example이 자체 최상위 쿠키에 자동으로 액세스할 수 있습니다.
기타 실험적 솔루션
이 시나리오에서 유용할 수 있는 또 다른 실험용 API는 파티셔닝된 팝인입니다. API는 현재 활발하게 개발 중입니다.
파티셔닝된 팝인의 경우 사용자에게 merchant.example에서 연 팝인 내에서 payment-provider.example에 로그인하기 위해 사용자 인증 정보를 입력하라는 메시지가 표시될 수 있습니다. 스토리지는 오프너 merchant.example에 의해 파티셔닝됩니다. 이 경우 payment-provider.example 삽입은 팝인 내에 설정된 저장소 값에 액세스할 수 있습니다. 이 솔루션을 사용하면 사용자가 모든 사이트에서 결제 서비스 제공업체에 로그인해야 합니다.
결제 링크 결제
일부 결제 제공업체는 판매자 사이트의 맞춤 결제 페이지를 렌더링하는 결제 링크를 생성하는 서비스를 제공합니다. 결제 링크 서비스와 결제 제공업체용 사용자 포털은 payment-provider.example, payment-link.example과 같이 서로 다른 도메인에 구현되는 경우가 많습니다.
payment-link.example은 payment-provider.example에서 제공하는 결제 양식을 삽입합니다. 이는 삽입된 결제 양식 패턴의 변형입니다.
FedCM, SAA, RWS도 이 경우에 고려해 볼 만한 옵션입니다.
지급 대시보드
일부 애플리케이션은 여러 사이트에서 사용자에게 거래 대시보드를 표시하여 금융 활동을 중앙에서 확인할 수 있도록 합니다. 이렇게 하려면 대시보드에서 여러 도메인에 걸쳐 사용자별 데이터에 액세스해야 합니다.
다음 도메인을 고려하세요.
earnings.example는 다양한 웹 애플리케이션에 삽입할 수 있는 지급 대시보드를 제공합니다. 이 서비스는 사용자 수입 데이터와 세션 정보를 저장합니다.catsitting.example및dogsitting.example은(는)earnings.example대시보드를 모두 삽입하는 별도의 웹사이트입니다.
사용자가 earnings.example 계정에 로그인합니다. catsitting.example 또는 dogsitting.example을 방문하면 수입을 확인할 수 있습니다. 삽입된 earnings.example 대시보드는 최상위 쿠키를 사용하며 사용자의 맞춤 수입 정보를 표시합니다.
다른 예와 마찬가지로 earnings.example 삽입에는 서드 파티 쿠키가 사용 중지된 상태에서 최상위 쿠키에 대한 액세스 권한이 없습니다.
퍼스트 파티 대시보드
세 도메인이 모두 동일한 당사자에 속하는 경우 RWS와 함께 SAA를 사용하는 것이 좋습니다.
SAA를 사용하면 earnings.example가 사용자 권한으로 최상위 쿠키에 액세스할 수 있습니다. 이 당사자가 4개 이하의 도메인에서 earnings.example를 사용하는 경우 RWS를 사용하여 도메인 간의 관계를 선언하면 원활한 사용자 환경을 제공할 수 있습니다.
동일한 당사자가 5개 이상의 도메인에 위젯을 삽입하는 경우 RWS는 세트에서 최대 6개의 사이트(기본 사이트 1개와 연결된 사이트 5개)만 지원하므로 모든 삽입 사이트와 위젯의 도메인 간 관계를 선언할 수 없습니다.
확장된 대시보드 배포
다음과 같은 경우 SAA 및 RWS가 최적의 솔루션이 아닐 수 있습니다.
- 서드 파티 사이트용 대시보드 솔루션을 배포합니다.
- 대시보드 위젯을 삽입한 사이트가 5개를 초과합니다.
이 경우 earnings.example는 ID 공급업체 역할을 하도록 FedCM을 구현하는 것이 좋습니다. 즉, 사용자는 earnings.example에서 관리하는 계정으로 dogsitting.example에 로그인해야 합니다.
FedCM은 공유되는 정보를 사용자에게 명확하게 전달하는 데 도움이 되는 맞춤설정 가능한 UI를 제공합니다. FedCM을 사용하면 dogsitting.example가 earnings.example에 맞춤 권한을 공유하도록 요청할 수 있습니다(예: 거래 데이터에 액세스).
FedCM은 Storage Access API의 신뢰 신호 역할도 하며, earnings.example 삽입은 SAA API 호출 시 추가 사용자 메시지 없이 자체 최상위 쿠키에 대한 스토리지 액세스 권한을 부여받습니다.
사이트별 대시보드 설정
여러 사이트에서 데이터를 공유할 필요가 없는 경우 CHIPS를 사용하여 쿠키를 파티셔닝하는 것이 좋습니다. CHIPS는 대시보드 레이아웃이나 필터와 같은 사이트별 환경설정을 저장하는 데 유용합니다.
결제 수단 관리
또 다른 일반적인 흐름은 사용자가 호스트 사이트를 벗어나지 않고 삽입된 항목 내에서 결제 수단을 보고 수정하는 것입니다.
다음 흐름을 고려해 보세요.
payments.example는 웹사이트에 삽입할 수 있는 결제 관리 도구를 제공합니다. 이 서비스는 사용자 결제 데이터와 세션 정보를 저장합니다.shop.example는 사용자가payments.example도구를 통해shop.example계정과 연결된 선호하는 결제 수단을 확인, 수정 또는 선택할 수 있도록 지원하는 웹사이트입니다.
결제 수단 관리를 구현하는 결제 서비스 제공업체는 FedCM을 사용하는 ID 공급업체가 되는 것도 고려해야 합니다. FedCM을 사용하면 사용자가 ID 공급자 (payments.example)에서 관리하는 계정을 사용하여 신뢰 당사자 (shop.example)에 로그인할 수 있습니다.
FedCM을 사용하면 사용자 권한을 통해 신뢰 당사자와 ID 공급자 간에 맞춤 데이터를 공유할 수 있습니다. FedCM 사용의 주요 이점은 UI가 사용자에게 선택사항에 관한 더 많은 컨텍스트를 제공할 수 있다는 것입니다. 또한 Storage Access API의 신뢰 신호 역할도 하므로 삽입된 콘텐츠가 최상위 쿠키에 액세스할 수 있습니다.
서드 파티 쿠키가 사용 중지되면 payments.example 삽입이 최상위 쿠키에 액세스할 수 없습니다. 이 경우 SAA는 스토리지 액세스를 요청하여 적절한 작동을 보장할 수 있습니다.
삽입 내에 설정된 정보가 다른 삽입 사이트 간에 공유되지 않아도 되는 경우가 있습니다. payments.example는 특정 삽입 사이트별로 서로 다른 사용자 환경설정을 저장하기만 하면 됩니다. 이 경우 CHIPS를 사용하여 쿠키를 파티셔닝하는 것이 좋습니다. CHIPS를 사용하면 shop.example에 삽입된 payments.example 내에서 설정된 쿠키가 another-shop.example에 삽입된 payments.example에 의해 액세스되지 않습니다.
이 사용자 흐름에서 사용할 수 있는 또 다른 실험적 API는 파티셔닝된 팝인입니다.
사용자가 shop.example에 의해 열린 팝인 내에서 payments.example에 로그인하면 스토리지가 오프너에 의해 파티셔닝되고 payments.example 삽입이 팝인 내에서 설정된 스토리지 값에 액세스할 수 있습니다. 하지만 이 방법을 사용하려면 사용자가 모든 사이트에서 결제 서비스에 로그인하기 위해 인증 정보를 입력해야 합니다.
사기 행위 감지
위험 분석 시스템은 쿠키에 저장된 데이터를 분석하여 표준에서 벗어난 패턴을 식별할 수 있습니다. 예를 들어 사용자가 갑자기 배송지 주소를 변경하고 새 기기를 사용하여 여러 건의 대규모 구매를 하는 경우 잠재적 사기 점수가 증가할 수 있습니다. 사기 감지 쿠키는 일반적으로 결제 제공업체 또는 사기 방지 서비스 위젯이 판매자 사이트에 설정하는 서드 파티 쿠키입니다.
서드 파티 쿠키 제한으로 인해 사기 감지 시스템이 중단되지는 않지만 사용자 마찰이 추가로 발생할 수 있습니다. 쿠키가 차단되어 시스템에서 사용자가 합법적인지 확실하게 확인할 수 없는 경우 본인 인증을 완료하는 등 추가 확인이 필요할 수 있습니다.
서드 파티 쿠키가 차단될 때 사기 감지를 지원하려면 비공개 상태 토큰 (PST) API를 사기 감지 솔루션에 통합하는 것이 좋습니다. PST를 사용하면 결제 서비스 제공업체가 토큰 발급자로 등록하고 서드 파티 쿠키를 사용하지 않는 토큰을 사용자에게 부여할 수 있습니다. 그런 다음 이러한 토큰을 판매자 사이트에서 사용하여 사용자가 신뢰할 수 있는지 확인할 수 있습니다. 구현 세부정보는 PST 개발자 문서를 참고하세요.
개인 정보 보호 샌드박스에서는 다른 사기 방지 API를 실험하고 있습니다.
맞춤 결제 버튼
판매자 사이트에 삽입된 결제 버튼 (예: <기본 결제 수단>으로 결제)은 결제 제공업체에서 설정한 크로스 사이트 정보를 사용하는 경우가 많습니다. 이를 통해 맞춤설정이 가능하며 사용자는 원하는 결제 수단으로 원활하게 결제할 수 있습니다. 사용자의 브라우저에서 서드 파티 쿠키가 차단되면 맞춤 결제 버튼 렌더링에 영향을 줄 수 있습니다.
SAA를 통해 저장소 액세스를 허용할 수 있지만 필요한 메시지가 이상적인 사용자 환경으로 이어지지 않을 수 있습니다.
Google에서는 이 사용 사례를 구체적으로 타겟팅하는 잠재적 솔루션인 파티셔닝되지 않은 로컬 데이터 액세스가 있는 Fenced Frame을 살펴보고 있습니다. 이 API는 현재 개발 단계에 있으며 향후 변경될 수 있습니다. 직접 사용해 보고 의견을 제공해 주세요.
고객센터
이 가이드에 설명된 사용자 여정 또는 API에 관해 궁금한 점이나 의견이 있으면 의견을 공유하세요.