Propozycja projektu widoczności środowiska wykonawczego SDK

Pakiety SDK do reklam w środowisku wykonawczym SDK nie mają dostępu do hierarchii widoków wydawcy. Zamiast tego pakiety SDK w środowisku wykonawczym mają własne widoki. Pakiet SDK nie może używać tych samych interfejsów View API, których używa poza środowiskiem wykonawczym pakietu SDK, aby określić, czy reklama jest widoczna dla użytkownika, ponieważ widok reklamy nie jest dołączony do okna aplikacji. Dotyczy to interfejsów View API na Androidzie, takich jak getLocationOnScreen, getLocationInWindow czy getVisibility, które nie zwracają oczekiwanych wartości.

Obsługa pomiaru widoczności reklam jest podstawowym wymaganiem środowiska wykonawczego pakietu SDK. Ta propozycja ma na celu zapewnienie obsługi Open Measurement i podobnych usług pomiarowych. Rozwiązania omówione w tym artykule mogą mieć zastosowanie również w przypadku interfejsów Attribution Reporting API.

Uprawnienia

Ten projekt ma na celu umożliwienie pakietom SDK do reklam lub partnerom pomiarowym obliczania tych danych o widoczności (nazwy są tymczasowe i mogą ulec zmianie):

• viewport [Rect]: reprezentuje geometrię ekranu urządzenia lub okna aplikacji w zależności od możliwości platformy.
• uiContainerGeometry [Rect]: geometria SandboxedSdkView, która jest renderowana.
• alpha [float]: przezroczystość renderowanego elementu SandboxedSdkView.
• onScreenGeometry [Rect]: podzbiór uiContainerGeometry, który nie jest przycinany przez widoki nadrzędne (aż do viewport włącznie).
• occludedGeometry [Rect]: części onScreenGeometry, które są zasłonięte przez widoki w hierarchii aplikacji. Zawiera Rect dla każdego zasłonięcia, co odpowiada zeru, jednemu lub większej liczbie widoków aplikacji, które przecinają się z SandboxedSdkView onScreenGeometry.

Wymagania

• Wartości uiContainerGeometry, onScreenGeometry i occludedGeometry są wyrażone w przestrzeni współrzędnych viewport.
• Raportowanie zmian widoczności odbywa się z minimalnym opóźnieniem.
• Widoczność można mierzyć przez cały cykl życia wyświetlenia reklamy, od pierwszego do ostatniego pojawienia się.

Propozycja projektu

Ta propozycja opiera się na sposobie działania prezentacji interfejsu przy użyciu bibliotek interfejsu klienta i dostawcy. Rozszerzymy biblioteki interfejsu, aby umożliwić pakietowi SDK rejestrowanie co najmniej jednego obserwatora sesji interfejsu. Obserwator będzie otrzymywać informacje o widoczności za każdym razem, gdy zostaną wykryte odpowiednie zdarzenia modyfikujące typy danych w sekcji możliwości. Pakiety SDK do pomiarów w środowisku wykonawczym pakietu SDK (implementacje OMID i MRAID) mogą dołączać tego obserwatora do sesji interfejsu, aby informacje te były wysyłane bezpośrednio do nich. Partnerzy pomiarowi mogą łączyć informacje uzyskane z bibliotek interfejsu z danymi o treściach, które są już dostępne (np. podczas używania skryptów pomiarowych wstrzykiwanych w kreację reklamy), aby generować zdarzenia widoczności w JavaScript.

Biblioteka klienta nasłuchuje zmian w interfejsie reklamy za pomocą detektorów zdarzeń, takich jak ViewTreeObserver. Gdy biblioteka klienta stwierdzi, że interfejs reklamy zmienił się w sposób, który może wpłynąć na pomiar widoczności, sprawdza, kiedy ostatnie powiadomienie zostało wysłane do obserwatora. Jeśli ostatnia aktualizacja jest większa niż dopuszczalne opóźnienie (konfigurowane przez pakiet SDK, minimalnie 200 ms na urządzeniach mobilnych), tworzony jest nowy obiekt AdContainerInfo i do obserwatora wysyłane jest powiadomienie. Ten model oparty na zdarzeniach jest lepszy dla kondycji systemu niż odpytywanie wykonywane obecnie przez większość implementacji OMID na Androidzie.

Interfejs API

Do biblioteki privacysandbox.ui.core zostaną dodane te elementy:

• SessionObserver: zwykle implementowany przez pakiet SDK do pomiarów, dołączany do sesji zwracanej przez pakiet SDK za pomocą interfejsu privacysandbox.ui. Ten interfejs umożliwi też pakietowi SDK do pomiarów włączenie określonych kategorii sygnałów widoczności. Dzięki temu biblioteka klienta interfejsu może zbierać tylko sygnały, które interesują obserwatora, co jest korzystniejsze dla ogólnej kondycji systemu.
• registerObserver(): dodana do klasy Session ta metoda umożliwia każdej osobie z dostępem do sesji zarejestrowanie obserwatora. Jeśli obserwator zarejestruje się po otwarciu sesji interfejsu, od razu otrzyma zapisane w pamięci podręcznej zdarzenie AdContainerInfo. Jeśli zarejestrują się przed otwarciem sesji, AdContainerInfo zostanie wysłany, gdy sesja zostanie otwarta.
• AdContainerInfo: klasa z metodami pobierającymi, która umożliwia obserwatorowi uzyskanie informacji o kontenerze reklamy tylko do odczytu w przypadku typów danych wymienionych w sekcji możliwości powyżej. Wartości zwracane przez te metody pobierające będą w miarę możliwości odpowiadać wartościom zwracanym przez istniejące metody pobierające w klasie View i jej podklasach. Jeśli kontener reklamy został utworzony za pomocą Jetpack Compose, udostępnia to właściwości semantyczne kontenera. Tej klasy można używać do obliczania zdarzeń MRAID i OMID związanych z widocznością.
• SessionObserverotifyAdContainerChanged(): służy do powiadamiania obserwatora o każdej zmianie widoczności. Przekazuje obiekt AdContainerInfo. Jest ona wywoływana, gdy wykryte zostaną zdarzenia wpływające na typy danych wymienione w sekcji Możliwości. Uwaga: ta metoda może być wywoływana oprócz metod w obiekcie Session. Na przykład wywoływana jest funkcja Session.notifyResized(), aby poprosić pakiet SDK o zmianę rozmiaru reklamy, a gdy to nastąpi, wywoływana jest też funkcja SessionObserver.notifyAdContainerChanged().
• SessionObserverotifySessionClosed(): powiadamia obserwatora o zamknięciu sesji.

Ulepszenia w przyszłości

Każdy kod działający w procesie aplikacji, w tym kod z biblioteki privacysandbox.ui.client, może zostać zmodyfikowany, jeśli aplikacja zostanie naruszona. Dlatego każda logika zbierania sygnałów, która jest uruchamiana w procesie aplikacji, jest podatna na manipulacje ze strony kodu aplikacji. Dotyczy to również kodu pakietu SDK wdrożonego przed udostępnieniem Piaskownicy prywatności, który działa w procesie aplikacji. W związku z tym zbieranie sygnałów przez bibliotekę interfejsu nie pogarsza sytuacji w zakresie bezpieczeństwa.

Dodatkowo kod w środowisku wykonawczym SDK może używać interfejsu API platformy o nazwie setTrustedPresentationCallback, który może zapewnić mu większe gwarancje ze strony platformy dotyczące wyświetlania interfejsu reklamy. setTrustedPresentationCallback działa na poziomie Surface i może pomagać w określaniu warunków dotyczących Surface zawierającego interfejs reklamy przez podanie minimalnych progów wyświetlania, takich jak odsetek widocznych pikseli, czas wyświetlania na ekranie lub skala. Te dane można porównać z danymi o widoczności dostarczanymi przez bibliotekę klienta interfejsu, co zostało wyjaśnione powyżej. Dane dostarczane przez platformę są bardziej wiarygodne, więc wszystkie zdarzenia z biblioteki interfejsu, których dane nie są zgodne z danymi z platformy, można odrzucić. Jeśli na przykład wywołanie funkcji słuchacza przekazanego do interfejsu setTrustedPresentationCallback nastąpi z powiadomieniem, że na ekranie nie są wyświetlane żadne piksele interfejsu reklamy, a biblioteka interfejsu klienta pokazuje niezerową liczbę pikseli na ekranie, dane z tej biblioteki można odrzucić.

Pytania otwarte

1. Jakie sygnały widoczności Cię interesują, a nie zostały wymienione w tym artykule?
2. Obecna propozycja zakłada aktualizowanie widoczności nie rzadziej niż co 200 milisekund, pod warunkiem że w interfejsie nastąpi odpowiednia zmiana. Czy ta częstotliwość jest dla Ciebie akceptowalna? Jeśli nie, jak często wolisz otrzymywać takie informacje?
3. Czy wolisz analizować informacje samodzielnie, czy chcesz, aby biblioteka interfejsu dostawcy odrzucała dane z biblioteki interfejsu klienta, gdy nie pasują one do danych setTrustedPresentationCallback?setTrustedPresentationCallback
4. Jak korzystasz z sygnałów o widoczności? Pomóż nam poznać Twoje przypadki użycia, przesyłając opinię, w której odpowiesz na te pytania.