Google의 추가 동의 모드 사양

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

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

추가 동의 v2 변경사항

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

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

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

추가 동의의 구성요소

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

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

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

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만이 IAB 정책에 따라 할당된 CMP ID 번호를 사용하여 생성할 수 있습니다. 공급업체 또는 기타 타사 서비스 제공업체는 자체적으로 AC 문자열을 생성해서는 안 됩니다.

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

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

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

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

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

동의한 공급업체는 사용자가 1) 쿠키 또는 기타 로컬 저장소를 사용(법적으로 요구될 경우)하는 것과 2) ATP에서 광고 개인 최적화를 위해 개인 정보를 수집, 공유, 사용하는 것에 대해 법적으로 유효한 동의를 제공했으며, 해당 공급업체가 Google의 EU 사용자 동의 정책에 포함된 기타 모든 약관을 준수한 경우에만 포함되어야 합니다.

1) 쿠키 또는 기타 로컬 저장소를 사용(법적으로 요구될 경우)하는 것과 2) 광고 개인 최적화를 위해 개인 정보를 수집, 공유, 사용하는 것에 대해 동의를 얻지 못한 비공개 공급업체는 사용자가 각 ATP를 식별할 수 있도록 적절한 투명성이 제공되어야 포함될 수 있습니다(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로의 확장

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

TCData = {
tcString: '세그먼트가 있고 base64url이 인코딩된 TC 문자열',
...
addtlConsent: ‘사양 버전 및 동의한 광고 기술 제공업체 ID가 포함된 AC 문자열’,
enableAdvertiserConsentMode: ‘TCF 및 광고주 동의 모드가 모두 활성화되어 있을 때 TCF 통합을 사용 설정할지 지정하는 불리언.’
}

InAppTCData = {
tcString: '세그먼트가 있고 base64url이 인코딩된 TC 문자열',
...
addtlConsent: ‘사양 버전 및 동의한 광고 기술 제공업체 ID가 포함된 AC 문자열’,
enableAdvertiserConsentMode: ‘TCF 및 광고주 동의 모드가 모두 활성화되어 있을 때 TCF 통합을 사용 설정할지 지정하는 불리언.’
}

AC 스트링은 어떻게 저장되나요?

웹

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

인앱

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

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

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

NSUserDefaults 및 SharedPreferences의 저장소 및 조회 키	값
`IABTCF_AddtlConsent`	문자열: 사양 버전 및 동의한 광고 기술 제공업체 ID가 포함된 AC 문자열

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

입찰 요청

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

OpenRTB 확장 프로그램 Proto
레거시 Protobuf 버전

message ConsentedProvidersSettings { // Google의 EU 사용자 동의 정책에 따라 ATP가 1) 쿠키 또는 기타 로컬 저장소를 // 사용(법적으로 요구될 경우)하는 것과 2) 개인 맞춤 광고를 게재하기 위해 개인 정보를 // 수집, 공유, 사용하는 것에 대해 EEA 사용자가 법적으로 유효한 동의를 제공했다는 사실을 // 게시자가 Google에 전달한 상황에서 이에 해당하는 제공업체의 ID 모음입니다. // 제공업체 ID와 제공업체 이름의 매핑은 providers.csv에 게시됩니다. repeated int64 consented_providers = 2 [packed = true]; }

// Google의 EU 사용자 동의 정책에 따라 개인 맞춤 광고를 게재하기 위해 // 개인 정보를 수집, 공유, 사용하는 것에 대해 EEA 사용자가 법적으로 유효한 동의를 // 제공했다는 사실을 게시자가 Google에 전달한 상황에서 이에 해당하는 제공업체의 정보입니다. // 이 필드는 regs_gdpr이 true인 경우에만 채워집니다. optional ConsentedProvidersSettings consented_providers_settings = 42;

URL 기반 서비스

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

픽셀이 자바스크립트를 실행할 수 없는 상태로 <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

도움이 되었나요?

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