Chrome은 서드 파티 쿠키와 관련하여 사용자 선택권을 위한 새로운 환경을 제안하고 있습니다. 서드 파티 쿠키 없이 탐색하는 사용자를 위해 사이트를 준비해야 합니다.
이 페이지에는 예정된 변경사항의 영향을 받을 수 있는 항목에 관한 정보가 포함되어 있습니다.
일반적인 사용자 경험
많은 결제 및 쇼핑 워크플로는 서드 파티 쿠키를 사용합니다. 다음 표에는 서드 파티 쿠키가 사용 중지되면 영향을 받을 수 있는 일부 사용자 여정이 나와 있으며, 개발자가 중단을 방지하는 데 사용할 수 있는 대체 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은 Storage Access 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
에 로그인하기 위해 사용자에게 사용자 인증 정보를 입력하라는 메시지가 표시될 수 있습니다. 스토리지는 opener 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는 기본 사이트 1개와 연결된 사이트 5개 등 최대 6개의 사이트를 세트로 지원하기 때문입니다.
확장된 대시보드 배포
다음과 같은 경우에는 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
는 사용자가shop.example
계정과 연결된 선호 결제 수단을 확인, 수정 또는 선택할 수 있도록payments.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
에 로그인하면 스토리지가 opener에 의해 파티션되고 payments.example
삽입이 팝인 내에 설정된 스토리지 값에 액세스할 수 있습니다. 그러나 이 접근 방식을 사용하려면 사용자가 모든 사이트에서 결제 제공업체에 로그인할 때 사용자 인증 정보를 입력해야 합니다.
사기 행위 감지
위험 분석 시스템은 쿠키에 저장된 데이터를 분석하여 표준에서 벗어난 패턴을 식별할 수 있습니다. 예를 들어 사용자가 갑자기 배송지 주소를 변경하고 새 기기를 사용하여 대규모 구매를 여러 번 하는 경우 잠재적 사기 점수가 높아질 수 있습니다. 사기 감지 쿠키는 일반적으로 결제 서비스 제공업체 또는 사기 방지 서비스 위젯이 판매자 사이트에 설정하는 서드 파티 쿠키입니다.
서드 파티 쿠키 제한으로 인해 사기 감지 시스템이 중단되지는 않지만 사용자에게 추가적인 불편을 줄 수 있습니다. 차단된 쿠키로 인해 시스템에서 사용자가 적법한지 확실하게 확인할 수 없는 경우 본인 인증 완료와 같은 추가 확인이 필요할 수 있습니다.
서드 파티 쿠키가 차단된 경우 사기 감지를 지원하려면 비공개 상태 토큰 (PST) API를 사기 감지 솔루션에 통합하는 것이 좋습니다. PST를 사용하면 결제 제공업체가 토큰 발급자로 등록하고 서드 파티 쿠키를 사용하지 않는 토큰을 사용자에게 부여할 수 있습니다. 그런 다음 이러한 토큰을 판매자 사이트에서 사용해 사용자가 신뢰할 수 있는지 확인할 수 있습니다. 구현 세부정보는 PST 개발자 문서를 참고하세요.
개인 정보 보호 샌드박스에서는 다른 사기 방지 API를 실험하고 있습니다.
맞춤 결제 버튼
판매자 사이트에 삽입된 결제 버튼 (예: <선호 결제 수단>으로 결제)은 종종 결제 제공업체가 설정한 교차 사이트 정보를 사용합니다. 이렇게 하면 맞춤설정이 가능해지고 사용자는 선호하는 결제 수단으로 원활하게 결제할 수 있습니다. 사용자의 브라우저에서 서드 파티 쿠키가 차단되면 맞춤설정된 결제 버튼 렌더링에 영향을 줄 수 있습니다.
SAA를 사용하면 저장소 액세스가 가능하지만 필요한 메시지로 인해 이상적인 사용자 환경을 제공하지 못할 수 있습니다.
Google에서는 파티션되지 않은 로컬 데이터 액세스가 있는 펜싱된 프레임이라는 사용 사례를 구체적으로 타겟팅하는 잠재적 솔루션을 모색하고 있습니다. 이 API는 현재 개발 중이며 개발자 여러분이 미래를 만들어갈 수 있습니다. 직접 사용해 보고 의견을 제공해 주세요.
도움말 보기
발생한 중단 현상은 goo.gle/report-3pc-broken에 신고하세요. 의견 양식을 제출하거나 GitHub의 개인 정보 보호 샌드박스 개발자 지원 저장소에서 문제를 제출할 수도 있습니다.