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로 사양에 맞는 TC string을 생성하고, 신선하게 유지하며, 디버깅을 위해 디코딩된 상태를 노출하고, 귀하의 트래픽 전반에서 실제로 어떤 목적과 벤더가 부여되고 있는지 보고합니다 — 따라서 동의(그리고 수익)가 어디서 새고 있는지 추측이 아니라 직접 볼 수 있습니다.

핵심 요약

• TC string은 모든 동의 선택에 대한 비트 패킹되고 감사 가능한 기록입니다.
• 목적 및 벤더 비트필드가 파트너의 개인화 광고 게재 가능 여부를 결정합니다.
• 대부분의 수익 하락은 문자열 누락, 미동의 벤더, 또는 오래되거나 유효하지 않은 CMP ID로 추적됩니다.
• 디버깅 시 __tcfapi로 실시간 문자열을 디코딩하고 파트너 요구 사항에 대해 검증하십시오.