Reklamy natywne na Androida

Format reklam natywnych umożliwia wydawcy dostosowanie reklamy wyświetlanej użytkownikowi. Po pobraniu reklamy z SDK wydawcy mogą zmienić jej układ i wygląd, aby lepiej dopasować ją do interfejsu aplikacji: dodać filtr kolorów, zmienić typografię i dodać niestandardowe nakładki. Aby zoptymalizować skuteczności lub wygody użytkowników reklam natywnych, wydawcy często ustawiają reklamy displayowe ogranicza odtwarzanie wideo lub przenosi je do pakietu SDK. Wydawcy mogą też dostosowywać detektory kliknięć reklam, które będą monitorowane pod kątem dodatkowych zdarzeń, takich jak przesunięcia w górę.

Format reklam natywnych wymaga większego zaufania do wydawcy niż potrzebnych do wyświetlania innych formatów reklam. Pakiety SDK zwykle chcą wykryć zasady naruszenia zasad oraz by sprawdzić, czy treść reklamy podana wydawcy została wyświetlona użytkownika.

Obsługę banerów reklamowych w środowisku wykonawczym SDK uzyskuje się za pomocą Interfejs API SurfaceControlViewHost. Dzięki temu pakiet SDK może wyświetlać interfejs użytkownika z procesu środowiska wykonawczego SDK bez modyfikowania go przez i aplikacjami klienckimi. Użyj trybów SurfaceView Z powyżej lub Z poniżej, aby określić, czy powierzchnia, na której renderowane jest UI pakietu SDK, znajduje się nad oknem aplikacji klienta, czy pod nim. Gdy reklama jest renderowana w trybie Z above, platforma SDK otrzymuje MotionEvents z interakcji użytkownika, ale widoki aplikacji klienta nie są widoczne nad reklamą. Gdy reklama jest renderowana w trybie Z below, aplikacja wyświetla swoje widoki na górze reklamy, ale MotionEvents z interakcji użytkownika z reklamą przechodzi do aplikacji, a nie do pakietu SDK.

Biblioteki Jetpacka privacysandbox.ui mogą być używane przez pakiet SDK i wydawcę do tworzenia i utrzymywania sesji interfejsu użytkownika.

Kontenery reklam należące do aplikacji

Prototypowaliśmy rozwiązanie, w którym pakiet SDK ma kontrolę nad wszystkimi widokami zawierającymi reklamę natywną (w tym nakładkami aplikacji) i stwierdziliśmy, że choć jest to możliwe, nakłada pewne ograniczenia na interfejs użytkownika i zwiększa złożoność integracji z pakietem SDK. Bardziej praktyczne podejście polega na tym, aby aplikacja była odpowiedzialna za większość wyświetleń. Pakiet SDK nadal może samodzielnie wyświetlać niektóre elementy interfejsu, np. widok reklamy, za pomocą funkcji SandboxedSdkView z privacysandbox.ui. Takie podejście zapewnia największą swobodę obecne i przyszłe przypadki użycia tego formatu reklamy są obsługiwane: deweloper aplikacji może zmieniać położenie elementów reklamy i nadać im odpowiedni styl wymaganych, ale pakiet SDK zachowuje własność odtwarzacza wideo (jeśli to konieczne) oraz zachowuje dostęp do elementów sterujących multimediami.

Diagram przedstawiający przepływ danych między wydawcą a pakietem SDK.
Proponowany przepływ kontroli nad reklamami natywnymi

Powiadomienia o stanie reklamy

Różne pakiety SDK analizują różne właściwości wyświetleń reklam, aby wykrywać oszustwa, naruszenia zasad. Chcemy to umożliwić, nie narzucając, których właściwości należy używać, ani nie zmuszając pakietu SDK do zmiany zestawu zapytań. Proponujemy utworzenie reprezentacji kontenera reklamy i jego widoków podrzędnych za pomocą funkcji NativeAdContainerInfo. Będzie to pakiet Obiekt z różnymi modułami pobierającymi, ujawniającymi informacje ograniczone do kontenera reklamy gdzie są dostępne, służą one do ochrony prywatności i nie są kosztowne . Pakiet SDK będzie mógł włączyć kategorie sygnałów uwzględnione w sekcji NativeAdContainerInfo. Pakiet SDK otrzyma ten obiekt, gdy stan reklamy zmieni się w sposób istotny dla pakietu SDK, np. w przypadku zdarzeń podlegających rozliczeniu, takich jak wyświetlenia reklam i kliknięcia użytkowników.

Dodatkowo wydawca będzie mógł dodawać tagi (ciągi tekstowe) związane z widokiem danych wszystkie elementy podrzędne dodane do NativeAdContainer, które mogą zostać użyte do powiadomienia pakietu SDK. którym komponentowi reklamy odpowiada każdy z nich.

Gdy użytkownik kliknie widoki należące do pakietu SDK, biblioteka interfejsu przekazuje MotionEvent z właściwościami przetłumaczonymi na przestrzeń współrzędnych pakietu SDK na potrzeby funkcji Pakiet SDK wraz z pierwotnym obiektem MotionEvent. W przyszłych wersjach Androida poznaj sposoby dodawania przez aplikację kliencką fokusu dotykowego dla aplikacji klienckiej wszystkich gestów użytkownika w częściach tej reklamy natywnej należących do pakietu SDK, które mają być obsługiwane przez SDK.

Potwierdzenie

Te atesty będą dostępne dla pakietu SDK na potrzeby wzmocnienia Pewne kwestie dotyczące prezentacji reklam:

  1. Potwierdzenie integralności urządzenia: użyj interfejsów API platformy, takich jak Key Attestation, aby określić integralność urządzenia.
  2. Tożsamość pliku APK: aby zweryfikować tożsamość pliku APK, użyj interfejsów API SdkSandbox, takich jak SdkSandboxController.getClientPackageName, oraz interfejsów PackageManager, takich jak requestChecksum.
  3. VerifiedMotionEvents: w przyszłych wersjach Androida rozważamy możliwość przeniesienia przez aplikację klienta fokusa dotykowego na wszystkie gesty użytkownika w częściach tej reklamy natywnej należących do pakietu SDK, aby mógł on nimi zarządzać. MotionEvents można przekonwertować na VerifiedMotionEvents za pomocą interfejsów API systemu. Pakiet SDK może wyświetlać własny interfejs użytkownika w reakcji na jego interakcje.

Pytania otwarte

Zachęcamy do przesłania opinii na temat tych kwestii:

  1. Czy lepiej, żeby pakiet SDK samodzielnie wygenerował VerifiedMotionEvents, lub biblioteki interfejsu dostawcy?
  2. Czy wolisz, aby pakiet SDK pozwalał wydawcy na wyświetlanie własnych widoków zawierających czy też prawa do tych wyświetleń?
  3. Jakie właściwości powinny według Ciebie zostać uwzględnione w AppOwnedAdContainerInfo obiekt?
  4. Ile reklam lub komponentów reklamowych należących do pakietu SDK chcesz wyświetlać jednocześnie na ekranie?