유럽 규정 개요 및 안내

Google의 추가 동의 기술 사양

TCF를 구현하지 않은 광고 기술 제공업체(ATP)와 협력하려는 게시자는 동의 관리 플랫폼(CMP)과 직접 협력해야 합니다.

이 문서에서는 IAB 유럽의 글로벌 공급업체 목록(GVL)에 아직 등록되지 않은 공급업체에 투명성 및/또는 동의 신호를 전달하기 위해 IAB 유럽의 투명성 및 동의 프레임워크(TCF) v2와 함께 사용할 수 있는 기술 사양('추가 동의'라고 함)을 정의합니다. 이 사양을 통해 게시자, 동의 관리 플랫폼(CMP) , 파트너는 IAB 유럽의 글로벌 공급업체 목록에는 아직 등록되어 있지 않지만 Google의 광고 기술 제공업체(ATP) 목록에는 있는 회사에 대해 TCF를 구현하면서 추가 동의를 얻고 전달할 수 있습니다.

추가 동의 v2 변경사항

Google에서는 2023년 12월부터 추가 동의 사양 v2를 지원했습니다. 주요 변경사항은 다음과 같습니다.

CMP에 공개된 공급업체를 지원하기 위해 추가 동의(AC) 문자열이 업데이트됩니다.
TCF와 광고주 동의 모드를 모두 지원하는 CMP의 상호 운용성을 허용하도록 CMP API가 업데이트됩니다.

v1 사양을 기반으로 생성된 AC 문자열은 계속 지원됩니다.

추가 동의의 구성요소

'추가 동의'에서는 다음 두 가지를 지원합니다.

IAB TCF v2.2 사양에 정의된 투명성 및 동의 문자열(TC 문자열). IAB의 글로벌 공급업체 목록(GVL)에 있는 공급업체에 대해 설정된 투명성과 동의를 포함합니다. 그리고
간단한 addtl_consent 문자열(AC 문자열). IAB에 등록되어 있지는 않으나 동의를 받고/받았거나 공개된 Google 광고 기술 제공업체(ATP)의 목록을 포함합니다.

이 사양은 다음을 정의합니다.

AC 문자열 형식
AC 문자열을 지원하기 위한 TCF v2.2 CMP API로의 확장 및 TCF와 광고주 동의 모드가 모두 제공되는 경우의 컨트롤
AC 문자열을 저장하는 방법
디지털 광고 체인을 통해 AC 문자열을 전달하는 방법

'추가 동의'(AC) 문자열 형식

AC 문자열에는 어떤 정보가 저장되나요?

AC 문자열에는 다음 구성요소가 포함됩니다.

파트 1: '2'와 같은 사양 버전 번호
파트 2: 구분자 기호 '~'
파트 3: 사용자가 동의한 Google 광고 기술 제공업체(ATP)의 ID를 점으로 구분한 목록 예: '1.35.41.101'
파트 4: 구분자 기호 '~'
파트 5: 'dv.'로 시작하며 공개된 Google 광고 기술 제공업체(ATP)의 ID를 점으로 구분한 목록 예: 'dv.9.21.81'

문자열 길이를 줄이기 위해, 파트 3에 포함된 공급업체를 파트 5에 포함하지 마세요.

AC 문자열 예시

AC 문자열 2~1.35.41.101~dv.9.21.81은 사용자가 ID가 1, 35, 41, 101인 ATP에 동의했으며, ID가 9, 21, 81인 ATP가 사용자에게 공개되었고, v2 사양에 정의된 형식을 사용하여 문자열이 생성되었음을 의미합니다.

AC 문자열은 누가 만들어야 하나요?

AC 문자열은 IAB 유럽 TCF에 등록된 CMP만이 할당된 CMP ID 번호를 사용하여 IAB 정책에 따라 생성할 수 있습니다. 공급업체 또는 기타 타사 서비스 제공업체는 자체적으로 AC 문자열을 생성해서는 안 됩니다.

Google ATP는 어디에 게시되나요?

Google은 IAB에 등록되지 않은 광고 기술 제공업체 및 해당 ID를 다음 위치에 게시합니다.

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

AC 문자열은 언제 만들어야 하나요?

언제나 AC 문자열은 게시자가 Google의 EU 사용자 동의 정책을 준수하는 경우에만 생성될 수 있습니다.

사용자가 다음 사항에 대해 법적으로 유효한 동의를 제공한 경우에만 동의한 공급업체를 포함해야 합니다.

쿠키 또는 기타 로컬 저장소의 사용(법적으로 필요한 경우)
광고 개인 최적화를 위한 광고 기술 제공업체(ATP)의 개인 정보 수집, 공유, 사용. 또한 게시자 또는 CMP가 Google의 EU 사용자 동의 정책에 포함된 기타 모든 약관을 준수하는 경우에 동의를 받은 공급업체를 포함해야 합니다.

공개된 공급업체 중

쿠키 또는 기타 로컬 저장소의 사용(법적으로 필요한 경우)
광고 개인 최적화를 위한 개인 정보의 수집, 공유, 사용에 대해 동의를 얻지 못한 공급업체는 사용자에게 각 ATP의 ID에 대한 적절한 투명성이 제공된 경우에만 포함해야 합니다(Google의 ATP 목록에서와 같이 ATP의 개인정보처리방침에 대한 링크를 제공하는 것 포함).

AC 문자열은 TC 문자열을 대체하는 것이 아닌 TC 문자열에 대한 보충 문자열로만 만들어야 합니다. 요청에 TC 문자열이 제공되지 않는 경우 Google은 요청을 처리하지 않으며 Google에서 수신한 해당 요청에서 AC 문자열을 삭제합니다.

이 사양을 구현하는 CMP는 생성한 AC 문자열이 게시된 Google ATP 파일(GVL에 없는 공급업체)의 ID만 포함하고 있는지 확인해야 합니다. Google은 TC 문자열을 수신하면 TC 문자열에 표시된 GVL의 버전을 확인합니다. 해당 버전의 GVL에 공급업체가 등록되어 있는 경우 공급업체에 대한 TC 문자열 컨트롤과 모든 AC 문자열 항목은 무시됩니다. 이러한 상황에서 Google은 AC 문자열에서 '중복' 항목을 제거하고 TC 문자열과 함께 수정된 AC 문자열을 전달할 권리를 보유합니다. Google 이외의 공급업체는 AC 문자열을 수정할 수 없습니다.

CMP API로의 확장

기존 TCF v2.2 CMP JavaScript API를 확장하여 AC 문자열을 반환하도록 허용하는 것이 좋습니다. 보다 구체적으로 말해, 이 데이터를 반환하도록 TCData 및 InAppTCData JSON 객체를 확장할 것을 권장합니다.

TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

AC 문자열을 저장하는 방법

웹

저장 메커니즘은 CMP의 선택에 달려 있습니다.

인앱

CMP SDK가 AC 문자열을 저장하는 데 NSUserDefaults(iOS) 또는 SharedPreferences(Android)가 사용됩니다. 이를 통해 다음이 가능합니다.

공급업체가 AC 문자열에 손쉽게 액세스 가능
앱 세션 간에 AC 문자열 유지 가능
게시자가 CMP SDK를 다른 것으로 교환할 수 있는 유연성을 제공하기 위해 CMP 간에 AC 문자열 이동 가능

앱에서 CMP SDK를 삭제하려는 게시자는 포함된 AC 문자열을 공급업체가 계속 사용하지 않도록 사용자에 대한 AddtlConsent 값을 지울 책임이 있습니다.

NSUserDefaults 및 SharedPreferences의 저장소 및 조회 키	값
`IABTCF_AddtlConsent`	문자열: AC string with spec version and consented Ad Technology Provider IDs

디지털 광고 체인을 통해 AC 문자열을 전달하는 방법

입찰 요청

ConsentedProvidersSettings를 재사용하여 GVL에 해당하지 않는 공급업체를 다운스트림으로 전파합니다.

OpenRTB 확장 proto
레거시 Protobuf 버전

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

URL 기반 서비스

광고 소재가 렌더링 될 때 <img> 태그에 여러 픽셀이 포함될 수 있습니다. 예를 들어 <img src="http://vendor-a.com/key1=val1&key2=val2">는 브라우저에서 공급업체의 도메인으로 HTTP GET 요청을 보냅니다.

픽셀이 JavaScript를 실행할 수 없는 상태로 <img> 태그에 있기 때문에 CMP API를 사용하여 TC 문자열을 가져올 수 없습니다. TC 문자열에 대한 지원과 유사하게 Google은 AC 문자열을 삽입해야 하는 픽셀 URL에 표준 URL 매개변수와 매크로를 제공합니다.

URL 매개변수	해당 매크로	URL 표현
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

예 1

공급업체 A가 AC 문자열을 수신하려면 이미지 URL에 URL 매개변수 및 매크로 &addtl_consent=${ADDTL_CONSENT}와 함께 키-값 쌍이 포함되어야 합니다. 결과적으로 URL은 다음과 같습니다.

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

예 2

주어진 요청에서 AC 문자열은 1~1.35.41.101입니다.

광고 소재의 호출자 또는 렌더러는 매크로를 포함하는 원래 배치된 픽셀이 지정된 서버를 호출할 때 다음과 같이 수정되도록 URL의 매크로를 실제 AC 문자열로 대체합니다.

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

도움이 되었나요?

어떻게 하면 개선할 수 있을까요?