Reklamy natywne na Androida

Format reklam natywnych umożliwia wydawcy dostosowanie reklamy wyświetlanej użytkownikowi. Po pobraniu reklamy z pakietu 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ść lub wygodę użytkowników w przypadku reklam natywnych, wydawcy często ustawiają limity wyświetleń lub przekazują odtwarzanie wideo do pakietu SDK. Wydawcy mogą też dostosowywać detektory kliknięć reklam, aby śledzić dodatkowe zdarzenia, takie jak przesunięcia w górę.

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

Obsługa banerów reklamowych w środowisku wykonawczym SDK jest realizowana za pomocą interfejsu API SurfaceControlViewHost. Dzięki temu pakiet SDK może wyświetlać elementy interfejsu użytkownika z procesu środowiska wykonawczego SDK bez ingerencji aplikacji klienckiej. Użyj trybów SurfaceView Z 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 klienta. Gdy reklama jest renderowana w trybie Z powyżej, 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 własne widoki nad reklamą, ale MotionEvents z interakcji użytkownika z reklamą są przekazywane do aplikacji, a nie do pakietu SDK.

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

Kontener reklamy należący do aplikacji

Stworzyliśmy prototyp, w którym pakiet SDK zarządza wszystkimi widokami składającymi się na reklamę natywną (w tym nakładkami aplikacji). Okazało się, że jest to możliwe, ale nakłada pewne ograniczenia na interfejs użytkownika i zwiększa złożoność integracji z pakietem SDK. Bardziej pragmatyczne podejście polega na tym, aby większość widoków należała do aplikacji. Pakiet SDK może nadal wyświetlać niektóre elementy interfejsu, np. widok reklamy, za pomocą SandboxedSdkView z privacysandbox.ui. To podejście zapewnia największą elastyczność w obsłudze obecnych i przyszłych przypadków użycia tego formatu reklamy: dzięki temu deweloper aplikacji może przenosić komponenty reklamy i dostosowywać ich styl w miarę potrzeb, a pakiet SDK zachowuje własność odtwarzacza wideo (jeśli jest to preferowane) i dostęp do elementów sterujących multimediami.

Powiadomienia o stanie reklamy

Różne pakiety SDK sprawdzają różne właściwości wyświetleń reklam pod kątem wykrywania oszustw i naruszeń zasad. Chcemy to obsługiwać bez określania, których właściwości należy używać, ani bez ograniczania możliwości zmiany zestawu właściwości, o które wysyłane są zapytania, przez pakiet SDK. Proponujemy utworzenie reprezentacji kontenera reklamy i jego widoków podrzędnych za pomocą NativeAdContainerInfo. Będzie to obiekt z możliwością przekazywania między procesami, który zawiera różne metody pobierania informacji ograniczonych do kontenera reklamy i jego zawartości, przy czym informacje te chronią prywatność i nie są kosztowne w obliczeniu. Pakiet SDK będzie mógł wyrazić zgodę na kategorie sygnałów uwzględnione w NativeAdContainerInfo. Pakiet SDK będzie otrzymywać ten obiekt za każdym razem, gdy stan reklamy zmieni się w sposób istotny dla pakietu SDK, np. w przypadku zdarzeń podlegających rozliczeniu, takich jak wyświetlenie reklamy i kliknięcia użytkownika.

Wydawca będzie też mógł dodawać do każdego elementu podrzędnego dodanego do NativeAdContainer tagi specyficzne dla widoku (ciągi znaków), które mogą służyć do informowania pakietu SDK, z którym zasobem reklamy jest powiązany dany element podrzędny.

Gdy użytkownik kliknie widoki należące do pakietu SDK, biblioteka interfejsu prześle do pakietu SDK zdarzenie MotionEvent z właściwościami przetłumaczonymi na przestrzeń współrzędnych pakietu SDK wraz z oryginalnym zdarzeniem MotionEvent. W przypadku przyszłych wersji Androida rozważamy dodanie sposobów umożliwiających aplikacji klienckiej przekazywanie fokusu dotykowego w przypadku wszystkich gestów użytkownika w częściach reklamy natywnej należących do pakietu SDK, aby były one obsługiwane przez ten pakiet.

Potwierdzenie

Pakiet SDK będzie mieć dostęp do tych atestów, aby uzyskać większą pewność co do sposobu wyświetlania reklam:

1. Atestowanie integralności urządzenia: używaj interfejsów platformy, takich jak Key Attestation, aby określać integralność urządzenia.
2. Tożsamość APK: używaj interfejsów SdkSandbox API, takich jak SdkSandboxController.getClientPackageName, oraz interfejsów PackageManager API, takich jak requestChecksum, aby weryfikować tożsamość APK.
3. VerifiedMotionEvents: W przypadku przyszłych wersji Androida rozważamy umożliwienie aplikacji klienckiej przekazywania fokusu dotykowego w przypadku wszystkich gestów użytkownika w częściach reklamy natywnej należących do pakietu SDK, aby były one obsługiwane przez ten pakiet. MotionEvents można przekonwertować na VerifiedMotionEvents za pomocą interfejsów API systemu. Pakiet SDK może wyświetlać własny interfejs w odpowiedzi na interakcję użytkownika, jeśli zdecyduje się na to.

Pytania otwarte

1. Czy lepiej, aby pakiet SDK sam generował VerifiedMotionEvents, czy żeby robiła to biblioteka interfejsu dostawcy?
2. Czy lepiej, aby pakiet SDK pozwalał wydawcy na posiadanie widoków zawierających film, czy też sam pakiet SDK powinien być właścicielem tych widoków?
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?