Annunci nativi su Android

Il formato degli annunci nativi consente al publisher di personalizzare un annuncio che viene mostrato a un utente. Dopo aver recuperato un annuncio dall'SDK, i publisher possono modificare il layout e l'aspetto dell'annuncio per adattarlo meglio all'interfaccia utente dell'applicazione: aggiungendo un filtro colorato, modificando la tipologia e aggiungendo overlay personalizzati. Per ottimizzare il rendimento o l'esperienza utente degli annunci nativi, i publisher spesso impostano limiti di visualizzazione o riducono la riproduzione dei video nell'SDK. Infine, i publisher possono personalizzare i listener dei clic sugli annunci per monitorare eventi aggiuntivi come gli scorrimenti verso l'alto.

Il formato degli annunci nativi richiede un livello di attendibilità maggiore nel publisher rispetto a quello necessario per mostrare altri formati di annunci. Gli SDK in genere vogliono rilevare violazioni delle norme e verificare che il contenuto dell'annuncio fornito al publisher sia stato mostrato all'utente.

Il supporto degli annunci banner nel runtime dell'SDK viene ottenuto tramite l'API SurfaceControlViewHost. In questo modo l'SDK può mostrare gli elementi dell'interfaccia utente del processo di SDK Runtime senza che venga manomesso dall'applicazione client. Utilizza le modalità SurfaceView Z sopra o Z sotto per determinare se la superficie in cui viene visualizzata l'interfaccia utente dell'SDK si trova sopra o sotto la finestra dell'applicazione client. Quando un annuncio viene visualizzato utilizzando la modalità Z sopra, l'SDK riceve MotionEvents dall'interazione dell'utente, ma le visualizzazioni dell'applicazione client non sono visibili sopra l'annuncio. Quando un annuncio viene visualizzato in modalità Z sotto, l'applicazione mostra le proprie visualizzazioni nella parte superiore, ma il valore MotionEvents derivante dall'interazione dell'utente sull'annuncio passa all'applicazione, non all'SDK.

Le librerie Jetpack privacysandbox.ui possono essere utilizzate dall'SDK e dal publisher per stabilire e gestire una sessione UI.

Contenitore annunci di proprietà dell'app

Abbiamo creato un prototipo di autorizzazione per consentire all'SDK di possedere tutte le visualizzazioni che comprendono un annuncio nativo (inclusi gli overlay dell'applicazione) e abbiamo scoperto che, per quanto possibile, imponeva alcune restrizioni all'interfaccia utente e aumentava la complessità dell'integrazione con l'SDK. Un approccio più pragmatico consiste nel lasciare che l'applicazione riceva il maggior numero di visualizzazioni. L'SDK può comunque scegliere di mostrare autonomamente alcune UI, ad esempio la visualizzazione dell'annuncio, utilizzando SandboxedSdkView da privacysandbox.ui. Questo approccio offre la massima flessibilità riguardo al modo in cui vengono supportati i casi d'uso esistenti e futuri di questo formato di annunci. Con questo approccio, lo sviluppatore di app può spostare i componenti degli annunci e applicarne lo stile secondo necessità, mentre l'SDK mantiene la proprietà del video player, se preferito, e l'accesso ai controlli multimediali.

Diagramma che mostra il flusso di dati tra il publisher e l'SDK.
Flusso di controllo degli annunci nativi proposto.

Notifiche sullo stato degli annunci

SDK diversi esaminano le diverse proprietà delle visualizzazioni di annunci per rilevare eventuali attività fraudolente e violare le norme. Vorremmo supportarlo senza specificare quali proprietà utilizzare o diventare il collo di bottiglia per l'SDK che modifica l'insieme di proprietà oggetto della query. Proponiamo di creare una rappresentazione del contenitore di annunci e delle relative visualizzazioni secondarie utilizzando NativeAdContainerInfo. Si tratterà di un oggetto parcelable con vari getter che espongono informazioni limitate al contenitore dell'annuncio e ai relativi contenuti, in cui queste informazioni tutelano la privacy e non richiedono costi di calcolo. L'SDK potrà attivare le categorie di indicatori incluse in NativeAdContainerInfo. L'SDK riceve questo oggetto ogni volta che lo stato dell'annuncio cambia in modi pertinenti all'SDK, ad esempio eventi fatturabili come impressioni dell'annuncio e clic dell'utente.

Inoltre, il publisher potrà aggiungere tag specifici per la visualizzazione (stringhe) a ogni elemento secondario aggiunto a NativeAdContainer, che potranno essere utilizzati per comunicare all'SDK a quale asset annuncio corrisponde ciascun asset secondario.

Quando l'utente fa clic sulle viste di proprietà dell'SDK, la libreria dell'interfaccia utente inoltrerà all'SDK MotionEvent con proprietà tradotte nello spazio di coordinate dell'SDK, insieme all'evento MotionEvent originale. Per le versioni future di Android, vedremo altri modi per consentire all'applicazione client di trasferire lo stato attivo al tocco per tutti i gesti dell'utente nelle parti di proprietà dell'SDK di questo annuncio nativo che verranno gestite dall'SDK.

Attestazione

Le seguenti attestazioni saranno disponibili per l'SDK per ottenere garanzie più sicure sulla presentazione dell'annuncio:

  1. Attestazione di integrità del dispositivo: utilizza le API della piattaforma come Attestazione chiave per determinare l'integrità del dispositivo.
  2. Identità APK: utilizza le API SdkSandbox come SdkSandboxController.getClientPackageName e le API PackageManager come requestChecksum per verificare l'identità dell'APK.
  3. VerifiedMotionEvents: nelle versioni future di Android, stiamo valutando di consentire all'applicazione client di trasferire l'attenzione del tocco per tutti i gesti dell'utente sulle parti di questo annuncio nativo di proprietà dell'SDK che dovranno essere gestite dall'SDK. MotionEvents può essere convertito in VerifiedMotionEvents utilizzando le API di sistema. L'SDK può mostrare la propria UI in risposta all'interazione dell'utente, se lo desidera.

Domande aperte

Invitiamo l'utente a ricevere feedback sui seguenti punti:

  1. È preferibile che l'SDK generi VerifiedMotionEvents autonomamente o che la libreria UI del provider lo faccia per l'SDK?
  2. È preferibile che l'SDK lasci che le visualizzazioni contenenti il video siano di proprietà del publisher oppure che le visualizzazioni siano i proprietari?
  3. Quali proprietà vorresti che fossero incluse nell'oggetto AppOwnedAdContainerInfo?
  4. Quanti annunci di proprietà dell'SDK o componenti degli annunci prevedi di mostrare contemporaneamente sullo schermo?