이중 배너 문제

많은 앱은 일부는 네이티브이고 일부는 웹입니다. 게임이 스토어, 뉴스, 도움말 페이지를 WebView로 보여 주거나, 유틸리티 앱이 자사 웹사이트의 기사를 렌더링하거나, 하이브리드 앱이 인터페이스 대부분을 웹 콘텐츠로 감싸기도 합니다. 각 쪽에는 고유한 동의 메커니즘이 있습니다. 네이티브 앱은 인앱 CMP 또는 SDK를 사용하고, 웹 페이지는 웹 CMP를 로드합니다. 둘이 연결되어 있지 않으면 사용자는 두 번 질문을 받고, 한쪽에서 한 선택은 다른 쪽에서 무시되며, WebView 안에서 나가는 광고 요청은 잘못된 신호를 담게 됩니다.

이 가이드에서는 네이티브와 웹의 동의를 일치시키는 방법을 다룹니다. 사용자가 한 번만 답하면 모든 광고 요청이 같은 결정을 담도록 하기 위해서입니다.

각 쪽이 동의를 저장하는 위치

네이티브

IAB TCF는 인앱 CMP가 동의를 저장하는 방법을 규정합니다. iOS에서는 NSUserDefaults, Android에서는 SharedPreferences에 IABTCF_TCString, IABTCF_gdprApplies, IABTCF_PurposeConsents 같은 표준 키를 사용해 저장합니다. 광고 SDK는 이 키를 직접 읽습니다. IAB GPP도 IABGPP_ 접두사를 가진 유사한 키(예: IABGPP_HDR_GppString)를 정의합니다.

웹

웹 CMP는 일반적으로 사이트 도메인의 퍼스트파티 쿠키나 로컬 스토리지에 결정을 저장하고, __tcfapi와 __gpp JavaScript 함수를 통해 이를 노출합니다. 페이지의 광고 태그는 네이티브 저장소가 아니라 이 함수들을 호출합니다.

간극

WebView는 기기 브라우저와도, 앱의 네이티브 환경설정과도 별개인 자체 쿠키 및 저장 공간을 가지고 있습니다. iOS에서 비영구 데이터 저장소를 사용하는 WKWebView는 닫힐 때 모든 것을 잊어버립니다. 직접 구축하지 않는 한 양쪽 사이에는 아무것도 흐르지 않습니다.

단일 신뢰 출처를 정하십시오

첫 번째 결정은 어느 쪽이 동의를 소유하느냐입니다. 대부분의 앱에서 답은 네이티브 CMP입니다. 그 이유는 다음과 같습니다.

• 어떤 WebView가 열리기 전에 가장 먼저 실행됩니다.
• 보통 수익의 대부분을 차지하는 네이티브 광고 SDK가 네이티브 저장소를 읽습니다.
• iOS에서는 App Tracking Transparency 프롬프트와 함께 조율할 수 있습니다.

인터페이스 전체가 웹 콘텐츠인 하이브리드 앱에서는 웹 우선이 합리적일 수 있지만, 그 경우 네이티브 SDK를 위해 결정을 네이티브 저장소에 다시 기록해야 합니다.

네이티브 동의를 WebView에 전달하기

네이티브를 신뢰 출처로 삼으면 WebView도 동일한 결정을 볼 수 있어야 합니다. 일반적인 패턴은 다음과 같습니다.

1. __tcfapi 구현을 주입합니다. 페이지의 스크립트가 실행되기 전에 __tcfapi(필요하면 __gpp도)를 정의하고, 네이티브 저장소에서 읽은 TC string과 값으로 호출에 응답하는 작은 스크립트를 주입합니다. 그러면 페이지의 광고 태그가 표준 API를 통해 네이티브 결정을 얻습니다.
2. 웹 배너를 억제합니다. 페이지가 앱 안에서 로드될 때 웹 CMP가 숨겨진 채로 있도록, 예를 들어 쿼리 매개변수나 직접 관리하는 사용자 지정 사용자 에이전트 토큰을 기준으로 구성합니다. 그렇지 않으면 사용자에게 두 번째 배너가 보입니다.
3. 로드 시 문자열을 전달합니다. 일부 웹 CMP는 초기화 시 기존 동의 문자열을 받아 채택할 수 있습니다. 지원되는 방법은 사용 중인 웹 CMP의 문서를 확인하십시오.

어떤 패턴을 사용하든, 사용자가 네이티브 설정 화면에서 선택을 바꿀 때 주입된 값이 업데이트되도록 하십시오. 다음 앱 실행 때만 업데이트되어서는 안 됩니다.

웹 동의를 네이티브로 되돌리기

사용자가 WebView 안에서, 예를 들어 개인정보 설정 페이지를 통해 동의를 변경할 수 있다면 앱이 이를 알아야 합니다. JavaScript 브리지를 사용하십시오. iOS에서는 메시지 핸들러, Android에서는 JavaScript 인터페이스입니다. 웹 쪽이 __tcfapi('addEventListener', ...)로 리스닝하다가 새 문자열을 네이티브 코드로 보내면, 네이티브 코드가 표준 키에 기록합니다. 기록하기 전에 WebView에서 온 입력을 검증하고, 자체 콘텐츠에서 온 메시지만 수락하십시오.

WebView 안의 광고

WebView에 렌더링되는 광고는 웹 광고입니다. 광고 SDK가 둘을 연결하는 방법을 제공하지 않는 한, 이들은 네이티브 저장소가 아니라 페이지에서 동의를 읽습니다. 예를 들어 Google의 Mobile Ads SDK는 WebView를 등록하여 그 안의 광고가 앱의 신호를 사용할 수 있게 하는 API를 제공합니다. 사용 중인 SDK의 최신 문서를 확인하십시오. 어떤 경우든, WebView에서 나가는 광고 요청이 네이티브 광고 요청과 동일한 TC 또는 GPP 문자열을 담고 있는지 테스트로 확인하십시오.

테스트 체크리스트

• 새로 설치: 동의 프롬프트가 두 번이 아니라 한 번 나타난다.
• 네이티브 CMP에서 모두 거부하고 WebView를 열어 광고 요청을 확인한다: 문자열에 거부가 반영되어 있어야 한다.
• 네이티브 설정에서 동의를 변경하고 열려 있는 WebView로 돌아간다: 페이지가 새 결정을 인식해야 한다.
• 웹 설정이 있다면 그곳에서 동의를 변경하고 네이티브 키가 업데이트되는지 확인한다.
• 앱을 강제 종료한 뒤 다시 실행한다: 양쪽 모두에서 결정이 유지된다.
• WebView 저장소는 플랫폼마다 동작이 다르므로 iOS와 Android 모두에서 테스트한다.

핵심 요약

• 네이티브와 WebView 동의는 별도의 저장소에 있으며 기본적으로 동기화되지 않습니다.
• 단일 신뢰 출처를 선택하십시오. 대부분의 앱에서는 네이티브 CMP입니다.
• 주입된 __tcfapi 또는 __gpp를 통해 네이티브 동의를 웹 콘텐츠에 노출하고 웹 배너는 숨기십시오.
• JavaScript 브리지를 사용해 웹에서의 변경을 네이티브 저장소로 되돌리십시오.
• WebView에서 나가는 광고 요청이 네이티브 요청과 동일한 동의 문자열을 담고 있는지 확인하십시오.