SDK 런타임 조회가능성 설계 제안서

SDK 런타임의 광고 SDK는 게시자의 뷰 계층 구조에 액세스할 수 없습니다. 대신 런타임의 SDK에는 자체 뷰가 있습니다. SDK는 광고가 사용자에게 표시되는지 확인하기 위해 SDK 런타임 외부에서 사용하는 것과 동일한 View API를 사용할 수 없습니다. 광고 뷰가 애플리케이션의 창에 연결되어 있지 않기 때문입니다. 여기에는 예상 값을 반환하지 않는 getLocationOnScreen이나 getLocationInWindow, getVisibility와 같은 Android View API가 포함됩니다.

광고 조회가능성 측정 지원은 핵심 SDK 런타임 요구사항입니다. 이 설계 제안서의 목표는 Open Measurement 및 유사한 측정 서비스를 지원하는 것입니다. 여기에서 설명하는 솔루션은 Attribution Reporting API에도 적용될 수 있습니다. 이 제안서에 관한 의견을 보내주시기 바랍니다.

기능

이 설계의 목표는 광고 SDK 또는 측정 파트너가 다음 조회가능성 데이터를 계산할 수 있도록 지원하는 것입니다(이름은 잠정적이며 변경될 수 있음).

SDK 런타임 조회가능성 구성요소가 상호 운용되는 방식을 보여주는 그림
그림 1. SDK 런타임 조회가능성 개요
  • viewport [Rect]: 플랫폼의 기능에 따라 기기 화면 또는 앱 창 도형을 나타냅니다.
  • uiContainerGeometry [Rect]: 렌더링되는 SandboxedSdkView의 도형입니다.
  • alpha [float]: 렌더링되는 SandboxedSdkView의 불투명도입니다.
  • onScreenGeometry [Rect]: 상위 뷰로 잘리지 않는 uiContainerGeometry의 하위 집합입니다(viewport까지 포함).
  • occludedGeometry [Rect]: 애플리케이션 계층 구조의 모든 뷰에 의해 가려지는 onScreenGeometry 부분입니다. SandboxedSdkView onScreenGeometry와 교차하는 0개 또는 1개 이상의 앱 뷰에 상응하는 각 오클루전의 Rect를 포함합니다.

요구사항

  • uiContainerGeometry, onScreenGeometry, occludedGeometry 값은 viewport의 좌표 공간으로 표현됩니다.
  • 가시성 변경 보고는 최소한의 지연 시간으로 이루어집니다.
  • 가시성은 처음 표시부터 마지막 표시까지 광고 뷰의 전체 수명 주기 동안 측정할 수 있습니다.

설계 제안

이 제안서는 클라이언트 및 제공자 UI 라이브러리를 사용하여 UI 프레젠테이션이 작동하는 방식을 기반으로 합니다. SDK가 UI 세션의 관찰자를 하나 이상 등록할 수 있도록 UI 라이브러리가 확장됩니다. 관찰자는 기능 섹션의 데이터 유형을 수정하는 관련 이벤트가 감지될 때마다 조회가능성 정보를 수신합니다. SDK 런타임의 측정 SDK(OMIDMRAID 구현)는 이 관찰자를 UI 세션에 연결하여 이 정보가 UI 세션에 직접 전송될 수 있도록 할 수 있습니다. 측정 파트너는 UI 라이브러리에서 가져온 정보를 이미 사용할 수 있는 콘텐츠에 관한 데이터(예: 광고 소재에 삽입된 측정 스크립트를 사용할 때)와 결합하여 JavaScript 조회가능성 이벤트를 생성할 수 있습니다.

조회가능성 제어 흐름
그림 2. 조회가능성 제어 흐름

클라이언트 라이브러리는 ViewTreeObserver와 같은 이벤트 리스너를 통해 광고 UI의 변경사항을 수신 대기합니다. 조회가능성 측정에 영향을 미칠 수 있는 방식으로 광고 UI가 변경되었다고 판단할 때마다 클라이언트 라이브러리는 마지막 알림이 관찰자에게 전송된 시기를 확인합니다. 마지막 업데이트가 허용 지연 시간(SDK에서 구성 가능, 모바일에서 최소 200ms까지)보다 길면 새로운 AdContainerInfo 객체가 생성되고 알림이 관찰자에게 전달됩니다. 이 이벤트 기반 모델은 오늘날 Android에서 대부분의 OMID 구현으로 실행되는 폴링보다 시스템 상태에 더 적합합니다.

API

다음 항목이 privacysandbox.ui.core 라이브러리에 추가됩니다.

  • SessionObserver: 일반적으로 측정 SDK에 의해 구현되며 privacysandbox.ui를 통해 SDK에서 반환한 세션에 연결됩니다. 또한 이 인터페이스를 사용하면 측정 SDK가 특정 카테고리의 조회가능성 신호를 선택할 수 있습니다. 이렇게 하면 UI 클라이언트 라이브러리가 관찰자가 관심을 두는 신호만 수집할 수 있어 전반적인 시스템 상태에 더 좋습니다.
  • registerObserver(): Session 클래스에 추가되었으며 이 메서드를 사용하면 세션에 액세스할 수 있는 누구나 관찰자를 등록할 수 있습니다. UI 세션이 열린 후 관찰자가 등록되면 캐시된 AdContainerInfo가 즉시 전송됩니다. 세션이 열리기 전에 등록된 경우 세션이 열릴 때 AdContainerInfo가 전송됩니다.
  • AdContainerInfo: 관찰자가 위의 기능 섹션에 나열된 데이터 유형의 읽기 전용 광고 컨테이너 정보를 가져올 수 있는 getter가 포함된 클래스입니다. 이러한 getter의 반환 값은 가능한 경우 View 및 서브클래스에 있는 기존 getter의 parcelable 반환 값에 상응합니다. 광고 컨테이너가 Jetpack Compose를 사용하여 만들어진 경우 컨테이너의 시맨틱 속성이 노출됩니다. 이 클래스는 조회가능성과 관련된 MRAID 및 OMID 이벤트를 계산하는 데 사용할 수 있습니다.
  • SessionObserverotifyAdContainerChanged(): 조회가능성이 변경될 때마다 관찰자에게 알리는 데 사용됩니다. AdContainerInfo 객체를 전달합니다. 이 메서드는 기능 섹션에 나열된 데이터 유형에 영향을 미치는 이벤트가 감지될 때마다 호출됩니다. 참고: 이 메서드는 세션의 메서드에 추가로 호출할 수도 있습니다. 예를 들어 Session.notifyResized()는 SDK에 광고 크기를 조절하도록 요청하기 위해 호출되는데 이때 SessionObserver.notifyAdContainerChanged()도 호출됩니다.
  • SessionObserverotifySessionClosed(): 관찰자에게 세션이 닫혔음을 알립니다.

향후 개선사항

privacysandbox.ui.client 라이브러리의 코드를 포함하여 애플리케이션 프로세스에서 실행되는 모든 코드는 애플리케이션이 손상되면 수정할 수 있습니다. 따라서 애플리케이션 프로세스에서 실행되는 신호 수집 로직은 애플리케이션 코드로 조작될 가능성이 높습니다. 이는 애플리케이션 프로세스에서 실행되는 개인 정보 보호 샌드박스가 제공되기 전에 배포된 SDK 코드에도 적용됩니다. 따라서 UI 라이브러리에 의한 신호 수집은 보안 상황을 악화시키지 않습니다.

또한 SDK 런타임의 코드는 setTrustedPresentationCallback이라는 플랫폼 API를 사용할 수 있습니다. 이 API는 광고 UI 프레젠테이션에 관해 프레임워크의 강력한 보장을 제공할 수 있습니다. setTrustedPresentationCallback은 노출 영역 수준에서 작동하며, 프레젠테이션의 최소 기준점(예: 표시되는 픽셀 비율이나 화면에 표시되는 시간, 크기 조정)을 지정하여 광고 UI가 포함된 노출 영역에 관해 어설션을 만드는 데 도움이 될 수 있습니다. 이 데이터는 위에서 설명한 UI 클라이언트 라이브러리에서 제공하는 조회가능성 데이터와 비교하여 확인할 수 있습니다. 프레임워크에서 제공하는 데이터가 더 안정적이므로 데이터가 프레임워크의 데이터와 일치하지 않는 UI 라이브러리의 모든 이벤트는 삭제할 수 있습니다. 예를 들어 setTrustedPresentationCallback에 제공된 리스너가 광고 UI의 픽셀이 화면에 표시되지 않는다는 알림과 함께 호출되었는데 클라이언트 UI 라이브러리는 0이 아닌 수의 픽셀을 화면에 표시하면 후자의 데이터는 삭제될 수 있습니다.

미응답 질문

다음 사항에 관한 의견을 보내주시기 바랍니다.

  1. 이 설명에서 언급되지 않았지만 관심이 있는 조회가능성 신호는 무엇인가요?
  2. 현재 제안은 UI에 관련 변경사항이 있는 경우 조회가능성을 200밀리초마다 업데이트하는 것입니다. 이 실행 빈도가 적절한가요? 적절하지 않다면 어떤 빈도를 선택하고 싶으신가요?
  3. setTrustedPresentationCallback의 정보를 직접 분석하고 싶나요? 아니면 setTrustedPresentationCallback 데이터와 일치하지 않을 때 제공자 UI 라이브러리가 클라이언트 UI 라이브러리의 데이터를 삭제하는 방식을 선호하나요?
  4. 조회가능성 신호는 어떻게 사용하나요? 질문에 답하는 의견을 제출해 주시면 사용 사례를 이해하는 데 도움이 됩니다.