Native Ads ‒ Custom Rendering

Diese Funktion ist derzeit nur im Rahmen eines eingeschränkten Betaprogramms verfügbar. Wenden Sie sich an Ihren Account Manager, wenn Sie daran teilnehmen möchten. Die Funktion wird nach Abschluss der Betaphase allen Publishern zur Verfügung gestellt.

In unserem Codelab finden Sie eine vollständige Anleitung zum Implementieren des benutzerdefinierten Renderings von nativen Anzeigen.

In diesem Leitfaden zeigen wir Ihnen, wie Sie das Google Mobile Ads SDK zum Implementieren nativer DFP-Anzeigen in einer Android-App verwenden. Ergänzend finden Sie noch wichtige Punkte, die Sie in diesem Zusammenhang berücksichtigen sollten.

Voraussetzungen

In diesem Leitfaden wird vorausgesetzt, dass Sie bereits praktische Erfahrungen mit dem Google Mobile Ads SDK gesammelt haben. Falls noch nicht geschehen, sollten Sie unseren Startleitfaden durcharbeiten.

Was ist eine native Anzeige?

Native Anzeigen sind Anzeigen, die Nutzern über Komponenten der Benutzeroberfläche präsentiert werden, die plattformspezifisch sind. Sie werden unter Verwendung der gleichen Ansichtstypen dargestellt, mit denen Sie bereits Ihre Layouts erstellen. Außerdem können sie so formatiert werden, dass sie mit dem visuellen Design der Benutzeroberfläche übereinstimmen, in denen sie auftreten. Für die Programmierung bedeutet dies, dass beim Laden einer nativen Anzeige Ihre App ein NativeAd-Objekt empfängt, das seine Assets enthält. Die App und nicht das SDK ist dann für die Darstellung zuständig.

Systemdefinierte native Anzeigenformate

Es gibt zwei systemdefinierte Formate für native Anzeigen: App-Installationsanzeigen und Contentanzeigen. App-Installationsanzeigen sind durch NativeAppInstallAd repräsentiert, Contentanzeigen durch NativeContentAd. Diese Objekte enthalten die Assets für die native Anzeige.

Benutzerdefinierte native Anzeigenformate

Zusätzlich zu den systemdefinierten nativen Formaten haben DFP-Publisher die Möglichkeit, eigene native Anzeigenformate zu erstellen, indem sie benutzerdefinierte Listen mit Assets definieren. Diese werden als benutzerdefinierte native Anzeigenformate bezeichnet und lassen sich mit reservierten Anzeigen verwenden. Publisher können damit ihren Apps beliebig strukturierte Daten übergeben. Solche Anzeigen sind durch das Objekt NativeCustomTemplateAd repräsentiert.

Systemdefinierte Anzeigenformate laden

Native Anzeigen werden über die Klasse AdLoader geladen. Diese enthält ihre eigene Builder-Klasse, damit sie bei der Erstellung angepasst werden kann. Indem Sie AdLoader beim Erstellen Listener hinzufügen, wird von einer App festgelegt, welche Typen von nativen Anzeigen sie empfangen kann. Von AdLoader werden dann nur genau diese Typen angefragt.

AdLoader erstellen

Der folgende Code zeigt, wie Sie einen AdLoader erstellen. Damit kann entweder eine App-Installationsanzeige oder eine Contentanzeige in einer einzelnen Anfrage geladen werden:

AdLoader adLoader = new AdLoader.Builder(context, "/6499/example/native")
    .forAppInstallAd(new OnAppInstallAdLoadedListener() {
        @Override
        public void onAppInstallAdLoaded(NativeAppInstallAd appInstallAd) {
            // Show the app install ad.
        }
    })
    .forContentAd(new OnContentAdLoadedListener() {
        @Override
        public void onContentAdLoaded(NativeContentAd contentAd) {
            // Show the content ad.
        }
    })
    .withAdListener(new AdListener() {
        @Override
        public void onAdFailedToLoad(int errorCode) {
            // Handle the failure by logging, altering the UI, etc.
        }
    })
    .withNativeAdOptions(new NativeAdOptions.Builder()
            // Methods in the NativeAdOptions.Builder class can be
            // used here to specify individual options settings.
            .build())
    .build();

Vorbereitung für die einzelnen Formate

Die ersten Methoden im Beispiel oben sind zur Vorbereitung von AdLoader für einen bestimmten Typ nativer Anzeigen zuständig:

forAppInstallAd: Durch Aufruf dieser Methode wird AdLoader so konfiguriert, dass App-Installationsanzeigen angefragt werden. Nachdem eine solche Anzeige geladen wurde, wird die onAppInstallAdLoaded-Methode des Listener-Objekts aufgerufen.

forContentAd: Diese Methode funktioniert wie forAppInstallAd, gilt jedoch für Contentanzeigen. Nachdem eine solche Anzeige geladen wurde, wird die onContentAdLoaded-Methode des Listener-Objekts aufgerufen.

Selbst wenn AdLoader Handler für mehrere native Anzeigenformate enthält, sendet das SDK nur eine einzige Anzeigenanfrage. Google wählt die Anzeige aus und gibt die zurück, die den maximalen Ertrag für den Publisher ermöglicht.

AdListener mit AdLoader verwenden

Beim Erstellen von AdLoader von oben kann auch die Funktion withAdListener zum Festlegen eines AdListener verwendet werden. Dieser Schritt ist optional. Die Methode übernimmt einen AdListener als alleinigen Parameter. Dieser dient für Rückrufe von AdLoader, wenn Anzeigenlebenszyklusereignisse stattfinden:

.withAdListener(new AdListener() {
  // AdListener callbacks like OnAdFailedToLoad, OnAdOpened, and so on,
  // can be overridden here.
})

Die Funktionsweise von AdListeners unterscheidet sich in einem Punkt erheblich zwischen nativen Anzeigen bzw. Banner- und Interstitial-Anzeigen. Da AdLoader eigene formatspezifische Listener (OnAppInstallAdLoadedListener usw.) hat, die nach dem Laden einer Anzeige verwendet werden, wird die onAdLoaded-Methode von AdListener nicht aufgerufen, wenn eine native Anzeige erfolgreich geladen wurde.

NativeAdOptions

Die letzte im Code zur Erstellung von AdLoader oben enthaltene Funktion ist eine weitere optionale Methode: withNativeAdOptions.

.withNativeAdOptions(new NativeAdOptions.Builder()
        // Methods in the NativeAdOptions.Builder class can be
        // used here to specify individual options settings.
        .build()
)

Mit dem Objekt NativeAdOptions lassen sich von Apps spezifische Optionen für Anfragen festlegen. Seine Builder-Klasse enthält die folgenden Methoden, die beim Erstellen einer Instanz verwendet werden:

setReturnUrlsForImageAssets: Bildassets für native Anzeigen werden über Instanzen von NativeAd.Image zurückgegeben. Darin sind die Felder Drawable und Uri enthalten. Ist diese Option auf "false" gesetzt (Standardeinstellung), werden vom SDK Bildassets automatisch abgerufen und die Felder Drawable und Uri befüllt. Ist die Option hingegen auf "true" gesetzt, wird vom SDK lediglich das Feld Uri gefüllt. So können Sie die eigentlichen Bilder nach Belieben herunterladen.

setImageOrientation: Creatives können mehrere Bilder enthalten, die für unterschiedliche Geräteausrichtungen bestimmt sind. Wenn Sie diese Methode mit einer der NativeAdOptions-Ausrichtungskonstanten (ORIENTATION_PORTRAIT, ORIENTATION_LANDSCAPE oder ORIENTATION_ANY) aufrufen, werden Bilder für die jeweilige Ausrichtung abgerufen. Wird die Methode nicht aufgerufen, wird der Standardwert ORIENTATION_ANY verwendet.

Wenn Sie setImageOrientation zur Angabe einer Präferenz für die Bildausrichtung im Quer- oder Hochformat angeben, werden vom SDK zuerst Bilder, die mit dieser Ausrichtung übereinstimmen, in Bildasset-Arrays gespeichert. Nicht damit übereinstimmende Bilder werden im Anschluss gespeichert. Da für einige Anzeigen nur eine Ausrichtung verfügbar ist, müssen Publisher ihre Apps so programmieren, dass sowohl Bilder im Quer- als auch im Hochformat gehandhabt werden können.

setRequestMultipleImages: Bildassets können mehrere Bilder enthalten. Wenn von Ihrer App dieser Wert auf "true" gesetzt wird, können alle Bilder aus allen Assets, in denen mehr als ein Bild enthalten ist, angezeigt werden. Ist dieser Wert "false" (Standardeinstellung), wird das SDK von Ihrer App angewiesen, nur das erste Bild aus Assets, in denen mehrere Bilder enthalten sind, anzuzeigen.

Falls withNativeAdOptions beim Erstellen von AdLoader überhaupt nicht aufgerufen wird, wird der Standardwert für jede Option verwendet.

setAdChoicesPlacement()

Das Datenschutzinfo-Overlay wird standardmäßig rechts oben angezeigt. Von Apps kann die Rendering-Position dieses Overlays geändert werden, indem diese Property auf einen der folgenden Werte festgelegt wird:

  • ADCHOICES_TOP_LEFT
  • ADCHOICES_TOP_RIGHT
  • ADCHOICES_BOTTOM_RIGHT
  • ADCHOICES_BOTTOM_LEFT

Native Anzeige laden

Nachdem Sie AdLoader erstellt haben, rufen Sie seine loadAd-Methode auf, um eine Anzeige anzufragen:

adLoader.loadAd(new PublisherAdRequest.Builder().build());

AdLoaders verwendet dieselbe PublisherAdRequest-Klasse wie Banner- und Interstitial-Anzeigen. Sie können die Methoden dieser Klasse verwenden, um Ausrichtungsinformationen wie bei anderen Anzeigentypen hinzuzufügen.

Ein einzelnes AdLoader-Objekt kann mehrere Anfragen senden, allerdings immer nur jeweils eine. Wird ein AdLoader erneut verwendet, muss gewartet werden, bis eine Anfrage abgeschlossen ist, bevor loadAd erneut aufgerufen wird, um die nächste Anfrage zu senden. Falls Sie mehrere Anzeigen gleichzeitig anfragen müssen, können Sie mehrere AdLoader-Objekte verwenden.

Zeitpunkt der Anzeigenanfrage

Apps, von denen native Anzeigen ausgeliefert werden, können diese vor der eigentlichen Auslieferung anfragen. In vielen Fällen ist dies die empfohlene Praxis. Von einer App, die eine Liste von Elementen darstellt, in die native Anzeigen eingestreut sind, können beispielsweise native Anzeigen für die gesamte Liste geladen werden, obwohl einige davon entweder überhaupt nicht oder erst ausgeliefert werden, wenn der Nutzer scrollt.

Anzeigen vorab zu laden ist eine programmiertechnisch clevere Lösung. Allerdings sollten Publisher alte Anzeigen nicht immer mitschleppen, ohne sie nochmals auszuliefern. Alle nativen Anzeigenobjekte, die noch nach mehr als einer Stunde ohne Auslieferung vorhanden sind, sollten verworfen und durch neue Anzeigen aus einer neuen Anfrage ersetzt werden.

Systemdefinierte Anzeigenformate ausliefern

Beim Laden einer nativen Anzeige ruft das SDK den Listener für das entsprechende Anzeigenformat auf. Anschließend ist Ihre App für die Auslieferung der Anzeige zuständig. Dies ist allerdings nicht sofort nötig. Um die Auslieferung systemdefinierter Anzeigenformate zu erleichtern, enthält das SDK einige nützliche Ressourcen.

Anzeigenansichtsklassen

Für jedes systemdefinierte Format gibt es eine entsprechende Anzeigenansichtsklasse: NativeAppInstallAdView für App-Installationsanzeigen und NativeContentAdView für Contentanzeigen. Diese Anzeigenansichtsklassen sind ViewGroups, die Publisher als Root für native Anzeigen des entsprechenden Formats verwenden müssen. Eine einzelne NativeContentAdView entspricht beispielsweise einer einzelnen Contentanzeige. Jede Ansicht, die zur Auslieferung der Assets dieser Anzeige verwendet wird (z. B. die ImageView zur Darstellung des Screenshotassets) muss ein untergeordnetes Objekt des Objekts NativeContentAdView sein.

Die Ansichtshierarchie für eine Contentanzeige, die ein RelativeLayout zur Darstellung ihrer Assetansichten verwendet, könnte wie folgt aussehen:

Die Anzeigenansichtsklassen enthalten auch Methoden, die zum Registrieren der für jedes einzelne Asset verwendeten Ansicht und zum Registrieren des NativeAd-Objekts selbst dienen. Wenn die Ansichten so registriert werden, können vom SDK unter anderem die folgenden Aufgaben automatisch gehandhabt werden:

  • Klicks erfassen
  • Impressionen erfassen (wenn das erste Pixel auf dem Bildschirm sichtbar ist)
  • Datenschutzinfo-Overlay für native Backfill-Creatives präsentieren

Datenschutzinfo-Overlay

Einem Datenschutzinfo-Overlay wird vom SDK eine Anzeigenansicht hinzugefügt, wenn eine Backfill-Anzeige zurückgegeben wird. Sollten von Ihrer App native Backfill-Anzeigen verwendet werden, lassen Sie bitte in der bevorzugten Ecke Ihrer nativen Anzeigenansicht Platz für das automatisch eingefügte Datenschutzinfo-Logo. Das Datenschutzinfo-Overlay muss außerdem gut zu erkennen sein. Wählen Sie daher entsprechende Hintergrundfarben und -bilder aus. Weitere Informationen zu Darstellung und Funktion des Overlays finden Sie in den Richtlinien für programmatische native Anzeigen mit nativen Designs.

Codebeispiel

Dies sind die Schritte zum Ausliefern eines systemdefinierten nativen Anzeigenformats:

  1. Erstellen Sie eine Instanz der erforderlichen Anzeigenansichtsklasse.
  2. Für jedes auszuliefernde Anzeigenasset:
    1. Befüllen Sie die Assetansicht mit dem Asset im Objekt der nativen Anzeige.
    2. Registrieren Sie die Assetansicht mit der Klasse ViewGroup.
  3. Registrieren Sie das native Anzeigenobjekt mit der Klasse ViewGroup.

Dies ist das Beispiel einer Funktion, die eine NativeContentAd ausliefert:

private void displayContentAd(ViewGroup parent, NativeContentAd contentAd) {
    // Inflate a layout and add it to the parent ViewGroup.
    LayoutInflater inflater = (LayoutInflater) parent.getContext()
            .getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    NativeContentAdView adView = (NativeContentAdView) inflater
            .inflate(R.layout.my_content_ad, parent);

    // Locate the view that will hold the headline, set its text, and call the
    // NativeContentAdView's setHeadlineView method to register it.
    TextView headlineView = (TextView) adView.findViewById(R.id.contentad_headline);
    headlineView.setText(contentAd.getHeadline());
    adView.setHeadlineView(headlineView);

    ...
    // Repeat the above process for the other assets in the NativeContentAd
    // using additional view objects (Buttons, ImageViews, etc).
    ...

    // Call the NativeContentAdView's setNativeAd method to register the
    // NativeAdObject.
    adView.setNativeAd(contentAd);

    // Place the AdView into the parent.
    parent.addView(adView);
}

Sehen wir uns die einzelnen Aufgaben einmal an:

Layout erweitern

LayoutInflater inflater = (LayoutInflater) parent.getContext()
        .getSystemService(Context.LAYOUT_INFLATER_SERVICE);
NativeContentAdView adView = (NativeContentAdView) inflater
        .inflate(R.layout.my_content_ad, parent);

In diesem Beispiel wird ein XML-Layout erweitert, das Ansichten zur Auslieferung einer Contentanzeige enthält. Anschließend wird ein Verweis auf die NativeContentAdView ermittelt, die ihr Rootelement ist. Dies ist ein guter Einstieg. Sie könnten allerdings auch eine vorhandene NativeContentAdView verwenden, falls es eine solche in Ihrem Fragment oder in Ihrer Aktivität gibt, oder sogar eine Instanz dynamisch erstellen, ohne eine Layoutdatei zu verwenden.

Assetansichten befüllen und registrieren

TextView headlineView = (TextView) adView.findViewById(R.id.contentad_headline);
headlineView.setText(contentAd.getHeadline());
adView.setHeadlineView(headlineView);

Hier wird die Ansicht ermittelt, die zum Ausliefern des Anzeigentitels verwendet wird. Dessen Text wird mit dem in contentAd enthaltenen Stringasset festgelegt. Anschließend wird die Ansicht mit dem NativeContentAdView-Objekt registriert. Diese Sequenz zum Ermitteln der Ansicht, Festlegen ihres Werts und Registrieren mit der Anzeigenansichtsklasse muss für jedes vom nativen Anzeigenobjekt bereitgestellte Asset wiederholt werden.

Natives Anzeigenobjekt registrieren

adView.setNativeAd(contentAd);

Im diesem letzten Schritt wird das native Anzeigenobjekt mit der Ansicht registriert, die für seine Auslieferung zuständig ist.

Benutzerdefinierte native Anzeigenformate laden

AdLoader erstellen

Genau wie ihre systemdefinierten Pendants werden benutzerdefinierte native Anzeigenformate mithilfe der Klasse AdLoader geladen:

AdLoader adLoader = new AdLoader.Builder(context, "/6499/example/native")
    .forCustomTemplateAd("10063170",
      new NativeCustomTemplateAd.OnCustomTemplateAdLoadedListener() {
          @Override
          public void onCustomTemplateAdLoaded(NativeCustomTemplateAd ad) {
              // Show the custom template and record an impression.
          }
      },
      new NativeCustomTemplateAd.OnCustomClickListener() {
          @Override
          public void onCustomClick(NativeCustomTemplateAd ad, String s) {
              // Handle the click action
          }
      })
    .withAdListener( ... )
    .withNativeAdOptions( ... )
    .build();

Ähnlich wie AdLoader mit der Methode forAppInstallAd konfiguriert wird, um eine App-Installationsanzeige anzufragen, wird AdLoader mit der Methode forCustomTemplateAd so konfiguriert, dass benutzerdefinierte Anzeigenvorlagen gehandhabt werden. Der Methode werden drei Parameter übergeben:

  • Die Vorlagen-ID der benutzerdefinierten Vorlage, die von AdLoader angefordert werden soll. Jedem benutzerdefinierten nativen Anzeigenformat ist eine Vorlagen-ID zugeordnet. Dieser Parameter gibt an, welche Vorlage von Ihrer App mit AdLoader angefragt werden soll.
  • Ein OnCustomTemplateAdLoadedListener. Er wird aufgerufen, wenn eine Anzeige geladen wurde.
  • Ein optionaler OnCustomClickListener. Er wird aufgerufen, wenn der Nutzer auf die Anzeige tippt oder klickt. Weitere Informationen zu diesem Listener finden Sie im Abschnitt "Klicks und Impressionen bei benutzerdefinierten nativen Anzeigenformaten verarbeiten" weiter unten.

Da ein einzelner Anzeigenblock so konfiguriert werden kann, dass er mehrere Creative-Vorlagen ausliefert, kann forCustomTemplateAd mehrmals mit unterschiedlichen Vorlagen-IDs aufgerufen werden. So kann AdLoader für mehr als ein benutzerdefiniertes natives Anzeigenformat vorbereitet werden.

Vorlagen-IDs

Die zur eindeutigen Bezugnahme auf native benutzerdefinierte Anzeigenformate verwendeten Vorlagen-IDs finden Sie in der DFP-Benutzeroberfläche auf dem Tab Auslieferung im Bereich Creatives > Native Anzeigenformate:

Die Vorlagen-ID jedes benutzerdefinierten nativen Anzeigenformats steht unterhalb seines Namens. Ein Klick auf einen Namen bringt Sie auf einen Bildschirm mit Informationen zu den Feldern der Vorlage:

Hier können einzelne Felder hinzugefügt, bearbeitet oder entfernt werden. Rechts sehen Sie die Spalte Variablen-ID. Diese IDs werden für den Zugriff auf die einzelnen Assets verwendet. Im nächsten Abschnitt finden Sie dazu nähere Informationen.

Benutzerdefinierte native Anzeigeformate ausliefern

Benutzerdefinierte native Anzeigenformate unterscheiden sich von systemdefinierten darin, dass Publisher die Möglichkeit haben, ihre eigenen "Vorlagen" oder Listen mit Assets zu definieren, die eine Anzeige ausmachen. Die Vorgehensweise zur Auslieferung eines solchen Formats unterscheidet sich also von systemdefinierten Formaten in einigen Punkten:

  1. Da die Klasse NativeCustomTemplateAd dazu gedacht ist, beliebige, in DFP benutzerdefinierte native Anzeigenformate zu verarbeiten, hat sie keine benannten Abrufmethoden (Getter) für Assets. Sie enthält stattdessen Methoden wie getText und getImage, die die Variablen-ID eines Vorlagenfelds als Parameter übernehmen.
  2. Es gibt keine dedizierte Anzeigenansichtsklasse wie NativeContentAdView zur Verwendung mit NativeCustomTemplateAd. Sie können ein FrameLayout, ein RelativeLayout oder jedes andere Layout verwenden, das für eine gute Nutzererfahrung sinnvoll ist.
  3. Da es keine dedizierte Klasse ViewGroup gibt, müssen Sie keine der zur Auslieferung der Anzeigenassets verwendeten Ansichten registrieren. Dies erspart Ihnen einige Zeilen Code zur Auslieferung der Anzeige. Allerdings bedeutet es auch ein wenig mehr Aufwand, um später Klicks zu verarbeiten.

Hier sehen Sie eine Beispielfunktion, von der eine NativeCustomTemplateAd ausgeliefert wird:

public void displayCustomTemplateAd (ViewGroup parent,
                                     NativeCustomTemplateAd customTemplateAd) {
    // Inflate a layout and add it to the parent ViewGroup.
    LayoutInflater inflater = (LayoutInflater) parent.getContext()
            .getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    View adView = inflater.inflate(R.layout.custom_template_ad, parent);

    // Locate the TextView that will hold the value for "Headline" and
    // set its text.
    TextView myHeadlineView = (TextView) adView.findViewById(R.id.headline);
    myHeadlineView.setText(customTemplateAd.getText("Headline"));

    // Locate the ImageView that will hold the value for "MainImage" and
    // set its drawable.
    Button myMainImageView = (ImageView) adView.findViewById(R.id.main_image);
    myMainImageView.setImageDrawable(
            nativeCustomTemplateAd.getImage("MainImage").getDrawable());

    ...
    // Continue locating views and displaying assets until finished.
    ...
}

Klicks und Impressionen bei benutzerdefinierten nativen Anzeigenformaten verarbeiten

Bei benutzerdefinierten nativen Anzeigenformaten ist Ihre App für das Erfassen von Impressionen und das Melden von Klickereignissen an das SDK zuständig.

Impressionen erfassen

Rufen Sie zum Erfassen einer Impression bei einer benutzerdefinierten Vorlagenanzeige die Methode recordImpression für die entsprechende NativeCustomTemplateAd auf:

myCustomTemplateAd.recordImpression();

Das SDK verhindert automatisch, dass für eine einzelne Anfrage eine Impression doppelt gezählt wird, falls Ihre App versehentlich die Methode für dieselbe Anzeige zweimal aufruft.

Klicks melden

Um dem SDK zu melden, dass bei einer Assetansicht ein Klick aufgetreten ist, rufen Sie die Methode performClick für die entsprechende NativeCustomTemplateAd auf und übergeben Sie ihr den Namen des Assets, auf das geklickt wurde. Wenn beispielsweise in Ihrer benutzerdefinierten Vorlage ein Asset namens "MainImage" enthalten ist und Sie einen Klick auf die ImageView melden möchten, die diesem Asset entspricht, sieht der Code wie folgt aus:

myCustomTemplateAd.performClick("MainImage");

Sie müssen diese Methode nicht für jede Ansicht aufrufen, die Ihrer Anzeige zugeordnet ist. Wenn Sie ein Feld "Bildunterschrift" verwenden, das zwar zu sehen sein soll, Nutzer jedoch nicht darauf klicken oder tippen, muss Ihre App performClick für die Ansicht dieses Assets nicht aufrufen.

Auf Klickaktionen bei benutzerdefinierten Vorlagenanzeigen reagieren

Wenn auf eine benutzerdefinierte Vorlagenanzeige geklickt wird, gibt es drei mögliche Reaktionen vom SDK. Sie werden in dieser Reihenfolge versucht:

  1. OnCustomClickListener von AdLoader aufrufen (falls angegeben)
  2. Für jede Deep-Link-URL der Anzeige versuchen, einen Content-Resolver zu ermitteln und den ersten erfolgversprechenden zu starten
  3. Einen Browser öffnen und zur normalen Ziel-URL der Anzeige wechseln

Die Methode forCustomTemplateAd akzeptiert einen OnCustomClickListener. Wenn Sie ein Listener-Objekt übergeben, ruft das SDK stattdessen seine Methode onCustomClick auf und unternimmt keine weiteren Schritte. Wenn Sie als Listener einen Null-Wert übergeben, verwendet das SDK jedoch wieder den Deep-Link und/oder die Ziel-URLs, die mit der Anzeige registriert sind.

Mit benutzerdefinierten Klick-Listenern kann Ihre App die beste Aktion als Reaktion auf einen Klick auswählen. Das kann beispielsweise die Aktualisierung der Benutzeroberfläche, der Start einer neuen Aktivität oder einfach nur die Protokollierung des Klicks sein. In diesem Beispiel wird lediglich protokolliert, dass ein Klick erfolgte:

AdLoader adLoader = new AdLoader.Builder(context, "/6499/example/native")
    .forCustomTemplateAd("10063170",
      new NativeCustomTemplateAd.OnCustomTemplateAdLoadedListener() {
        // Display the ad.
      },
      new NativeCustomTemplateAd.OnCustomClickListener() {
          @Override
          public void onCustomClick(NativeCustomTemplateAd ad, String assetName) {
            Log.i("MyApp", "A custom click just happened for " + assetName + "!");
          }
      }).build();

Auf den ersten Blick mag es seltsam erscheinen, dass es überhaupt benutzerdefinierte Klick-Listener gibt. Schließlich hat Ihre App dem SDK gerade mitgeteilt, dass ein Klick aufgetreten ist. Warum also sollte das SDK wiederum dieses Ereignis der App melden?

Es gibt einige Gründe für diesen Informationsaustausch. Der wichtigste ist jedoch, dass damit das SDK weiterhin die Kontrolle über die Reaktion auf den Klick hat. Es kann beispielsweise automatisch Drittanbieter-Tracking-URLs pingen, die für das Creative festgelegt worden sind, und ohne zusätzlichen Code andere Aufgaben im Hintergrund erledigen.

Nativen Anzeigencode testen

Direkt verkaufte Anzeigen

Wenn Sie gerne einmal testen möchten, wie sich direkt verkaufte native Anzeigen verhalten, können Sie diese DFP-Anzeigenblock-ID verwenden:

/6499/example/native

Dieser Anzeigenblock ist so konfiguriert, dass App-Installationsanzeigen und Contentanzeigen sowie ein benutzerdefiniertes natives Anzeigenformat mit den folgenden Assets ausgeliefert werden:

  • Anzeigentitel (Text)
  • MainImage (Bild)
  • Bildunterschrift (Text)

Die Vorlagen-ID für das benutzerdefinierte native Anzeigenformat lautet 10063170.

Native Backfill-Anzeigen

Wenn Sie gerne einmal testen möchten, wie sich native Backfill-Anzeigen verhalten, können Sie diesen DFP-Anzeigenblock verwenden:

/6499/example/native-backfill

In diesem Anzeigenblock werden App-Installationsanzeigen und Contentanzeigen ausgeliefert, in denen das Datenschutzinfo-Overlay enthalten ist.

Bevor Sie die Anzeige live schalten, müssen Sie Ihren Code so ändern, dass er auf die tatsächlichen Anzeigenblock- und Vorlagen-IDs verweist.

Feedback geben zu...

SDK for DFP Users on Android