TCF 동의 문자열 읽는 법: 개발자를 위한 실전 가이드
TC string이 실제로 무엇인가
IAB Transparency & Consent Framework는 하나의 간결한 토큰 — TC string — 을 생성하며, 이는 모든 광고 요청과 함께 이동하면서 사용자가 무엇에 동의했고 동의하지 않았는지를 벤더에게 정확히 알려줍니다. Base64-URL로 인코딩되고 비트 수준으로 패킹되어 있어 횡설수설처럼 보이지만(CPxy...AAA) 정확하고 감사 가능한 기록을 인코딩합니다.
세그먼트
완전한 TC string은 점으로 구분된 여러 세그먼트입니다. 첫 번째는 코어 문자열(core string)이며, 나머지는 선택 사항입니다:
- Core — CMP ID, CMP 버전, 동의 타임스탬프, 정책 버전, 그리고 결정적으로 목적 동의 및 벤더 동의 비트필드.
- Disclosed vendors — 어떤 벤더가 사용자에게 표시되었는지.
- Publisher TC — 퍼블리셔인 귀하에게 특정한 동의.
비트필드가 핵심입니다: 비트 N이 1로 설정되면 목적 N 또는 벤더 N에 대한 동의를 의미합니다. 목적 1은 “기기에 정보 저장/접근”이고, 목적 3과 4는 개인화 광고를 다루는 식입니다.
실전에서 디코딩하기
비트를 손으로 디코딩하는 경우는 거의 없습니다. IAB에서 제공하는 라이브러리나 공개 디코더를 사용하십시오:
.로 분할하고 코어 세그먼트를 Base64-URL 디코딩합니다.- 고정 너비 헤더 필드(version, created, lastUpdated, cmpId, cmpVersion)를 읽습니다.
- 목적 및 벤더 비트필드를 순회하여 정확히 어떤 것이 부여되었는지 확인합니다.
JavaScript에서 __tcfapi('getTCData', 2, cb) 호출은 이미 파싱된 객체를 반환합니다 — tcData.purpose.consents와 tcData.vendor.consents는 id → 불리언의 맵입니다. 이것이 런타임에서의 진실입니다.
수익을 죽이는 오류들
개인화 수요가 조용히 사라질 때, 대개 TC string이 원인입니다:
- 문자열 누락 — 광고 요청이
gdprApplies/TC string을 전달하지 않아, 규정을 준수하는 SSP가 비개인화로 떨어집니다. - 벤더 미동의 — 수요 파트너의 벤더 ID 비트가 0이어서 개인화로 입찰할 수 없습니다.
- 만료되거나 오래된 문자열 — 오래된 타임스탬프는 다운스트림 플랫폼이 이를 불신하게 만듭니다.
- 잘못된 CMP ID — 등록되지 않았거나 테스트용 CMP ID는 전체 문자열을 무효화합니다.
디버깅 워크플로
사용자의 동의를 재현하고, __tcfapi 또는 광고 요청에서 실시간 TC string을 가져와 검증기를 통과시킨 뒤, 디코딩된 목적/벤더를 파트너가 요구하는 것과 비교하십시오. 열 번 중 아홉 번은 격차가 단일 벤더 비트 하나 또는 누락된 목적 1입니다.
FlexyConsent의 역할
FlexyConsent는 인증된 CMP ID 317로 TC 문자열을 생성하고 __tcfapi를 통해 제공하므로 현재 문자열을 디코딩할 수 있습니다. 보고서는 결정을 출처와 지역별로 보여 줍니다.
핵심 요약
- TC string은 모든 동의 선택에 대한 비트 패킹되고 감사 가능한 기록입니다.
- 목적 및 벤더 비트필드가 파트너의 개인화 광고 게재 가능 여부를 결정합니다.
- 대부분의 수익 하락은 문자열 누락, 미동의 벤더, 또는 오래되거나 유효하지 않은 CMP ID로 추적됩니다.
- 디버깅 시
__tcfapi로 실시간 문자열을 디코딩하고 파트너 요구 사항에 대해 검증하십시오.