Reklamy natywne na Androida

Format reklam natywnych umożliwia wydawcom dostosowywanie reklam wyświetlanych użytkownikom. Po pobraniu reklamy z pakietu SDK wydawcy mogą zmienić jej układ i wygląd, aby lepiej pasowały do interfejsu aplikacji: można dodać filtr kolorów, zmienić typografię i dodać niestandardowe nakładki. Aby zoptymalizować skuteczność reklam natywnych lub wygodę użytkowników, wydawcy często ustalają limity wyświetlania lub przenoszą odtwarzanie filmów do pakietu SDK. Na koniec wydawcy mogą dostosować detektory kliknięć reklamy tak, by monitorowały dodatkowe zdarzenia, takie jak przesunięcie palcem w górę.

Format reklam natywnych wymaga od wydawcy większego zaufania niż wyświetlanie innych formatów reklam. Pakiety SDK zazwyczaj wykrywają naruszenia zasad i chcą sprawdzić, czy treść reklamy przekazywana wydawcy wyświetliła się użytkownikowi.

Obsługa banerów reklamowych w środowisku wykonawczym SDK umożliwia interfejs API SurfaceControlViewHost. Dzięki temu pakiet SDK może wyświetlać elementy interfejsu z procesu środowiska wykonawczego SDK bez wprowadzania zmian przez aplikację kliencką. Użyj SurfaceView Z w trybie powyżej lub Z poniżej, aby określić, czy powierzchnia, na której renderowany jest interfejs pakietu SDK, znajduje się powyżej czy poniżej okna aplikacji klienckiej. Gdy reklama jest renderowana w trybie Z powyżej, pakiet SDK otrzymuje MotionEvents z interakcji użytkownika, ale wyświetlenia aplikacji klienckiej nie są widoczne nad reklamą. Gdy reklama jest renderowana w trybie Z poniżej, aplikacja pokazuje nad reklamą własne wyświetlenia, ale MotionEvents po interakcji użytkownika z reklamą trafia do aplikacji, a nie do pakietu SDK.

Pakiet SDK i wydawca mogą użyć bibliotek Jetpack privacysandbox.ui do utworzenia i utrzymania sesji UI.

Kontener reklamy należący do aplikacji

W ramach prototypu przekazaliśmy pakietowi SDK wszystkie widoki zawierające reklamę natywną (łącznie z nakładkami aplikacji) i stwierdziliśmy, że choć jest to możliwe, wprowadzenie tych ograniczeń w interfejsie oraz zwiększenie złożoności integracji z pakietem SDK. Bardziej pragmatyczne podejście polega na tym, że aplikacja ma największą liczbę wyświetleń. Pakiet SDK może nadal wyświetlać niektóre elementy interfejsu, np. widok reklamy, za pomocą parametru SandboxedSdkView z privacysandbox.ui. To podejście zapewnia największą elastyczność w obsłudze dotychczasowych i przyszłych przypadków użycia tego formatu reklamy: deweloper aplikacji może przenosić komponenty reklamy i dostosowywać je do potrzeb, podczas gdy pakiet SDK zachowuje prawo własności do odtwarzacza wideo (jeśli jest to wymagane) i zapewnia dostęp do elementów sterujących multimediami.

Proponowany proces kontroli ustawień reklam natywnych.

Powiadomienia o stanie reklamy

Różne pakiety SDK analizują różne właściwości wyświetleń reklam pod kątem wykrywania oszustw i naruszenia zasad. Chcemy to obsługiwać bez określania właściwości, których należy użyć, i uniemożliwiania tego pakietu SDK jako wąskiego gardła przed zmianą zestawu właściwości, których dotyczy zapytanie. Proponujemy utworzenie reprezentacji kontenera reklamy i jego widoków podrzędnych za pomocą elementu NativeAdContainerInfo. Będzie to obiekt typu parceling z różnymi obiektami pobierającymi, ujawniającymi informacje ograniczone do kontenera reklamy i jego zawartości, gdzie informacje takie zapewniają ochronę prywatności, a ich obliczenie nie jest kosztowne. Pakiet SDK będzie mógł akceptować kategorie sygnałów uwzględnionych w NativeAdContainerInfo. Pakiet SDK będzie otrzymywać ten obiekt za każdym razem, gdy stan reklamy zmieni się w sposób odpowiedni dla pakietu SDK, np. w przypadku zdarzeń podlegających rozliczeniu, np. wyświetlenia reklamy i kliknięcia użytkownika.

Dodatkowo wydawca będzie mógł dodawać tagi związane z widokiem (ciągi) do każdego elementu podrzędnego dodanego do NativeAdContainer, dzięki którym pakiet SDK będzie wiedzieć, z którymi zasobami reklamy odpowiadają poszczególne elementy podrzędne.

Gdy użytkownik kliknie widoki należące do pakietu SDK, biblioteka interfejsu przekaże do SDK element MotionEvent z właściwościami przetłumaczonymi do przestrzeni współrzędnych pakietu SDK razem z pierwotnym zdarzeniem MotionEvent. W przyszłych wersjach Androida pracujemy nad dodaniem sposobów, w jakie aplikacje klienckie będą mogły przenosić aktywność dotykową wszystkich gestów użytkownika w częściach tej reklamy natywnej, które będą obsługiwane przez pakiet SDK.

Potwierdzenie

Pakiet SDK będzie mieć dostęp do tych świadectw dotyczących prezentacji reklam:

1. Atest integralności urządzenia: do określania integralności urządzenia używaj interfejsów API platformy, takich jak atestacja klucza.
2. Tożsamość APK: do weryfikacji tożsamości plików APK użyj interfejsów API SdkSandbox, takich jak SdkSandboxController.getClientPackageName i PackageManager API, takich jak requestChecksum.
3. VerifiedMotionEvents: w przyszłych wersjach Androida badamy, jak umożliwić aplikacji klienckiej przeniesienie aktywności polegającej na dotyku w przypadku wszystkich gestów użytkownika dotyczących części tej reklamy natywnej, które należą do pakietu SDK. MotionEvents można przekonwertować na VerifiedMotionEvents przy użyciu systemowych interfejsów API. W odpowiedzi na interakcję użytkownika pakiet SDK może wyświetlać własny interfejs.

Pytania otwarte

Zachęcamy do opinii o tych kwestiach:

1. Czy pakiet SDK powinien samodzielnie generować VerifiedMotionEvents czy też biblioteka interfejsu dostawcy na potrzeby pakietu SDK?
2. Czy pakiet SDK powinien dawać wydawcy możliwość własności wyświetleń zawierających filmy czy samodzielne ich własność?
3. Jakie właściwości powinny być uwzględnione w obiekcie AppOwnedAdContainerInfo?
4. Ile reklam lub komponentów reklam należących do pakietu SDK planujesz wyświetlać jednocześnie na ekranie?