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ść reklam natywnych lub wrażenia użytkowników związane z tymi reklamami, wydawcy często ustawiają limity wyświetlania lub przekazują odtwarzanie wideo do pakietu SDK. Wydawcy mogą też dostosowywać czujniki kliknięć reklam, aby monitorować dodatkowe zdarzenia, np. przesunięcia w górę.

Format reklam natywnych wymaga od wydawcy większego zaufania niż wyświetlanie innych formatów reklam. Pakiety SDK zwykle mają wykrywać naruszenia zasad i sprawdzać, czy treść reklamy przekazana wydawcy została wyświetlona użytkownikowi.

Obsługa banerów reklamowych w środowisku wykonawczym pakietu SDK jest realizowana za pomocą interfejsu API SurfaceControlViewHost. Umożliwia to pakietowi SDK wyświetlanie elementów interfejsu użytkownika z procesu środowiska wykonawczego SDK bez możliwości modyfikacji przez aplikację klienta. 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, pakiet SDK otrzymuje MotionEvents z interakcji użytkownika, ale widoki aplikacji klienckiej 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 miała większość wyświetleń. Pakiet SDK może nadal wyświetlać niektóre elementy interfejsu użytkownika, np. widok reklamy, za pomocą elementu SandboxedSdkViewprivacysandbox.ui. Takie podejście zapewnia największą elastyczność w obsługiwaniu obecnych i przyszłych przypadków użycia tego formatu reklamy. Dzięki niemu deweloper aplikacji może przenosić komponenty reklamy i nadawać im styl w razie potrzeby, a pakiet SDK zachowuje prawo własności nad odtwarzaczem wideo (jeśli jest to preferowane) i dostęp do elementów sterujących multimediami.

Diagram pokazujący przepływ danych między wydawcą a pakietem SDK.
Proponowana kontrola przepływu reklam natywnych.

Powiadomienia o stanie reklamy

Różne pakiety SDK sprawdzają różne właściwości wyświetleń reklam pod kątem wykrywania oszustw i naruszania 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 obiekt z możliwością dzielenia, który za pomocą różnych metod gettera udostępnia informacje ograniczone do kontenera reklamy i jego zawartości. Informacje te są chronione i niedrogie w wykonywaniu. 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 specyficzne dla wyświetlenia (łańcuchy znaków) do każdego elementu podrzędnego dodanego do NativeAdContainer. Można ich używać do informowania pakietu SDK, któremu zasobowi reklamy odpowiada dany element podrzędny.

Gdy użytkownik kliknie widoki należące do pakietu SDK, biblioteka UI przekaże do pakietu MotionEvent z właściwościami przetłumaczonymi na przestrzeń współrzędnych pakietu SDK, a także oryginalne zdarzenie MotionEvent. W przyszłych wersjach Androida rozważamy dodanie sposobów, które pozwolą aplikacji klienta na przeniesienie fokusa dotykowego na wszystkie gesty użytkownika w częściach tej reklamy natywnej, które należą do pakietu SDK, aby mógł on je obsługiwać.

Potwierdzenie

Aby zapewnić większą pewność wyświetlania reklam, pakiet SDK będzie mógł korzystać z tych atrybutów:

  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

  1. Czy wolisz, aby pakiet SDK samodzielnie generował VerifiedMotionEvents, czy też chcesz, aby biblioteka interfejsu użytkownika dostawcy robiła to za niego?
  2. Czy w przypadku pakietu SDK lepiej jest, aby wyświetlenia zawierające film należały do wydawcy, czy do samego pakietu?
  3. Jakie właściwości chcesz uwzględnić w obiekcie AppOwnedAdContainerInfo?
  4. Ile reklam lub komponentów reklamowych należących do pakietu SDK chcesz wyświetlać jednocześnie na ekranie?