브라우저 콘솔에서 IAB GPP 문자열 디버깅하기: 단계별 튜토리얼
GPP 문제를 발견하기 어려운 이유
미국 방문자가 데이터의 판매 또는 공유를 옵트아웃하면, 그 선택은 페이지의 모든 광고 파트너에게 도달해야 합니다. IAB Global Privacy Platform(GPP)에서는 그 선택이 압축된 문자열과 섹션 ID 목록으로 전달됩니다. 둘 중 하나라도 잘못되면(누락되었거나, 오래되었거나, 잘못된 섹션을 담고 있거나) 눈에 보이는 고장은 전혀 없습니다. 광고는 계속 로드되고 배너도 멀쩡해 보이며, 문제는 나중에 파트너가 옵트아웃을 무시하거나 인벤토리에 대한 입찰이 줄어드는 형태로 드러납니다.
다행히 거의 모든 것을 브라우저 콘솔에서 검사할 수 있습니다. 이 튜토리얼은 실제 페이지에서 실행하는 순서대로 점검 과정을 안내합니다.
1단계: API가 존재하고 준비되었는지 확인하기
GPP 호환 CMP는 전역 __gpp 함수를 노출합니다. 페이지에서 DevTools를 열고 ping 명령을 실행하십시오.
__gpp('ping', function (data) { console.log(data); });
반환된 객체는 한눈에 많은 것을 알려줍니다.
- gppVersion — 현재 구현에서는 1.1이어야 합니다.
- cmpStatus — CMP가 로드되었는지 오류가 발생했는지.
- cmpDisplayStatus — 이 방문자에게 배너가 표시됨, 숨김, 비활성화 중 어느 상태인지.
- signalStatus — CMP가 동의 상태를 확정하면 “ready”, 아직 결정 중이면 “not ready”.
- supportedAPIs — CMP가 생성할 수 있는 섹션.
- applicableSections — 지금 이 방문자에게 적용되는 섹션 ID.
- gppString — 인코딩된 문자열 자체.
__gpp가 정의되지 않았다면 CMP stub이 없거나 너무 늦게 로드되는 것입니다. stub은 이를 기대하는 어떤 광고 스크립트보다 먼저 자리를 잡고 있어야 하며, 그렇지 않으면 해당 스크립트는 CMP를 보지 못하고 기다리거나 신호 없이 진행합니다.
2단계: 적용 섹션 확인하기
GPP의 각 프라이버시 프레임워크에는 숫자 섹션 ID가 있습니다. 퍼블리셔가 가장 자주 접하는 것은 2(EU TCF v2), 5(캐나다 TCF), 7(US National, “usnat”), 그리고 캘리포니아, 버지니아, 콜로라도, 유타, 코네티컷 같은 개별 주 섹션을 위한 8 이상입니다. 미국 주 방문자는 일반적으로 applicableSections에서 EU 섹션이 아니라 국가 섹션 또는 해당 주 섹션을 보아야 합니다.
여러 위치에서 테스트하십시오. 흔한 버그는 CMP가 배너를 위해서는 지역을 올바르게 감지하면서도 문자열에는 상관없이 기본 섹션을 기록하는 경우, 혹은 그 반대입니다. VPN이나 CMP의 미리보기 도구를 사용해 배너가 보여주는 내용과 applicableSections가 보고하는 내용을 비교하십시오.
3단계: 섹션 데이터 읽기
문자열을 직접 디코딩하는 대신 CMP에 파싱된 섹션을 요청하십시오.
__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');
US National 섹션에서 옵트아웃 필드는 간단한 규칙을 사용합니다. 0은 해당 없음, 1은 사용자가 옵트아웃함, 2는 사용자가 옵트아웃하지 않음을 의미합니다. 먼저 다음 필드에 집중하십시오.
- SaleOptOut과 SharingOptOut
- TargetedAdvertisingOptOut
- 방문자에게 각 관행에 대한 고지가 제공되었는지 기록하는 해당 notice 필드
이제 페이지에서 옵트아웃을 수행하고(“Do Not Sell or Share” 링크를 클릭하거나 환경설정 센터에서 설정을 토글) getSection을 다시 실행하십시오. 옵트아웃 필드가 2에서 1로 바뀌어야 합니다. 그렇지 않다면 UI와 신호가 동기화되지 않은 것입니다.
4단계: Global Privacy Control 경로 테스트하기
여러 주 법은 기업이 Global Privacy Control 신호를 옵트아웃으로 취급하도록 요구합니다. GPC를 지원하는 브라우저나 확장 프로그램에서 GPC를 활성화하고, 콘솔에서 navigator.globalPrivacyControl이 true를 반환하는지 확인한 다음, 새 세션에서 페이지를 로드하십시오. 방문자가 배너를 건드리지 않아도 관련 옵트아웃 필드가 이미 1로 읽혀야 합니다. 일부 섹션에는 해당 선택이 GPC 신호에서 비롯되었음을 나타내는 필드도 포함됩니다.
5단계: 스냅샷만이 아니라 이벤트를 지켜보기
광고 스크립트는 페이지 로드 시 문자열을 한 번 읽고 잊어버려서는 안 됩니다. 파트너가 보는 것을 확인하려면 리스너를 등록하십시오.
__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });
listenerRegistered, signalStatus, sectionChange 같은 이벤트가 관찰되어야 합니다. 방문자가 선택을 바꾸면 업데이트된 문자열과 함께 sectionChange 이벤트가 뒤따라야 합니다. 헤더 비딩 wrapper나 광고 서버 통합이 signalStatus가 “ready”가 되기 전에만 문자열을 읽는다면 빈 값이나 오래된 값을 보낼 수 있습니다.
6단계: 문자열을 광고 요청까지 추적하기
마지막으로 Network 탭을 열고 광고 요청을 필터링하십시오. 많은 광고 엔드포인트는 gpp와 gpp_sid 매개변수(문자열과 적용 섹션 ID)를 받습니다. 다음을 확인하십시오.
- 미국 방문자의 요청에 두 매개변수가 모두 있는지.
- 문자열이 요청 시점에 ping이 반환한 문자열과 일치하는지.
- 옵트아웃 이후의 요청이 캐시된 문자열이 아니라 새 문자열을 담고 있는지.
Prebid.js를 사용한다면 consent management 모듈이 GPP용으로 구성되었는지 확인하고, wrapper에서 나가는 입찰 요청과 최종 광고 서버 호출을 모두 검사하십시오.
흔한 실패 패턴
- stub이 광고 태그보다 늦게 로드됨 — 파트너가 CMP를 전혀 보지 못합니다.
- 지역에 맞지 않는 섹션 — 미국 트래픽에 EU 섹션이 전송되거나, 섹션이 아예 없습니다.
- UI와 신호의 불일치 — 토글은 바뀌는데 문자열은 바뀌지 않습니다.
- GPC 무시 — 브라우저 신호가 옵트아웃이 되지 않습니다.
- 요청 속 오래된 문자열 — wrapper가 처음 본 값을 캐시합니다.
핵심 요약
- ping으로 시작하십시오. 버전, 상태, 적용 섹션, 문자열이 이야기의 대부분을 알려줍니다.
- getSection으로 옵트아웃 필드를 읽으십시오. 1은 옵트아웃함, 2는 옵트아웃하지 않음입니다.
- 옵트아웃 링크와 GPC를 따로 테스트하고 둘 다 신호를 바꾸는지 확인하십시오.
- 이벤트를 수신하고, 광고 요청이 문자열을 읽기 전에 “ready” 신호를 기다리십시오.
- 옵트아웃 전후로 실제 네트워크 요청에서 gpp와 gpp_sid를 확인하십시오.