Einbau des Google Mobile Ads SDK: Unterschied zwischen den Versionen

(29 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)

Zeile 1:

Diese Dokumentation dient dazu den Einbau des Google Mobile Ads SDK (GMA SDK) und die Werbeintegration der iq digital zu erklären. Sie geht dabei auf notwendige und wichtige Eigenheiten ein und versucht übliche Missverständnisse aufzuklären.

Die Dokumentation beginnt dabei mit dem GMA SDK und allgemeinen Informationen, welche für alle Werbeformen gelten, die in der App laufen sollen. Darauf folgen Werbeform spezifische Erklärungen und zum Abschluss werden werbeform spezifische Events erklärt, welche die App berücksichtigen muss.

==Offizielle Dokumentation zum Google Mobile Ads SDK==

Das Google Mobile Ads SDK (GMA SDK) bringt alles mit, was für eine Werbeausspielung in nativen Apps benötigt wird.

Zeile 5:

Zeile 9:

[https://developers.google.com/ad-manager/mobile-ads-sdk/ios/quick-start GMA SDK iOS Getting Started]

[https://developers.google.com/ad-manager/mobile-ads-sdk/android/quick-start GMA SDK ~~iOS~~ Getting Started]

[https://developers.google.com/ad-manager/mobile-ads-sdk/android/quick-start GMA SDK Android Getting Started]

===Download des Google Mobile Ads SDK===

Zeile 51:

Zeile 55:

====Begriffserklärung====

;netzwerkId:Hier ist immer die Netzwerk ID der iq digital einzugeben: 183

;level1:Dies ist die Bezeichnung der App im Google Ad Manager und wird von der iq digital vorgegeben. Die ~~Bezwichnung~~ besteht aus <appname>_app_<plattform>_<gerätetyp>.

;level1:Dies ist die Bezeichnung der App im Google Ad Manager und wird von der iq digital vorgegeben. Die Bezeichnung besteht aus <appname>_app_<plattform>_<gerätetyp>.

:;appname:Der Name der App

:;plattform:Das Betriebsystem, also ''ios'' oder ''android''

:;gerätetyp:Der Gerätetyp, also '''phone''' oder ''tablet''

;level2:Dies ist die Bezeichnung einer Rubrik der App, z.B. ''politik''

;level2:Dies ist die Bezeichnung einer Rubrik der App oder der Startseite, z.B. ''politik'', ''openingpage''

;level3 (usw.):Dies ist die Bezeichnung für eine Unterrubrik, z.B. im Falle von ''politik'' als level2 wäre ''ausland'' eine Unterrubrik für level3. Level4 und höher sind weitere tiefere Verzweigungen der App, diese werden im Normalfall nicht ~~also~~ Adunits angelegt ~~und solche~~ Seiten würden ~~unter dem~~ level3 ~~angelegt~~ werden.

;level3 (usw.):Dies ist die Bezeichnung für eine Unterrubrik, z.B. im Falle von ''politik'' als level2 wäre ''ausland'' eine Unterrubrik für level3. Level4 und höher sind weitere tiefere Verzweigungen der App, diese werden im Normalfall nicht als Adunits angelegt. Solche Seiten würden dann über das übergeordnete level3 vermarktet werden. Beispiel: Eine Seite ''politik/ausland/usa'' ist zu speziell, um sie einzeln zu vermarkte. In so einem Fall ist es sinnvoll, dass sie nur bis level3, also als ''politik/ausland'', vertaggt wird.

;seitentyp:In Apps mit Banner-Anzeigen (z.B. News Apps) bezeichnet ''seitentyp'' die unterschiedlichen Seitentypen, also ob es sich z.B. um eine Übersichts-, Artikel- oder Bildergalerieseite handelt. Übliche Werte dafür sind ''homepage'', ''index'', ''artikel'', ''bildgal''. In Apps mit Fullscreen-Anzeigen (z.B. epaper oder Zeitungs Apps) werden mit ''seitentyp'' die unterschiedlichen Anzeigeplätze innerhalb der Rubrik gemeint, also ob es sich z.B. erste, zweite oder dritte Swipe Anzeige handelt. Übliche Werte sind ~~''openingpage'',~~ ''swipe_1'', ''swipe_2'', ''swipe_3'' usw.

;seitentyp:In Apps mit Banner-Anzeigen (z.B. News Apps) bezeichnet ''seitentyp'' die unterschiedlichen Seitentypen, also ob es sich z.B. um eine Übersichts-, Artikel- oder Bildergalerieseite handelt. Übliche Werte dafür sind ''homepage'', ''index'', ''artikel'', ''bildgal''. In Apps mit Fullscreen-Anzeigen (z.B. epaper oder Zeitungs Apps) werden mit ''seitentyp'' die unterschiedlichen Anzeigeplätze innerhalb der Rubrik gemeint, also ob es sich z.B. erste, zweite oder dritte Swipe Anzeige handelt. Übliche Werte sind ''swipe_1'', ''swipe_2'', ''swipe_3'' usw.

====Beispiel für die fiktive Rheinischer Kurier News App mit Banner-Anzeigen:====

Zeile 72:

Zeile 76:

*/183/Rheinischer_Kurier_epaper_app_ios_tablet

*/183/Rheinischer_Kurier_epaper_app_ios_tablet/preloading_ad

*/183/Rheinischer_Kurier_epaper_app_ios_tablet/openingpage

*/183/Rheinischer_Kurier_epaper_app_ios_tablet/openingpage/swipe_1

*/183/Rheinischer_Kurier_epaper_app_ios_tablet/politik/swipe_1

*/183/Rheinischer_Kurier_epaper_app_ios_tablet/politik/swipe_2

Zeile 82:

Zeile 86:

===Creative Sizes===

Im Google Ad Manager stehen die Creative Sizes für die Werbemittel-Größen. Dabei ist es möglich dass die tatsächlich ausgespielte Größe eines Werbemittels von der CreativeSize abweicht (in so einem Fall wird von Pseudogröße gesprochen). Die App muss für ein Adrequest der entsprechenden Platzierung alle zugehörigen Creative Sizes abfragen. Die oft lange Liste aus Größen ergibt sich aus den vielen möglichen unterschiedlichen Werbeformen und den ~~unterschieden~~ in direkter und programmatischer Vermarktung.

Im Google Ad Manager stehen die Creative Sizes für die Werbemittel-Größen. Dabei ist es möglich dass die tatsächlich ausgespielte Größe eines Werbemittels von der CreativeSize abweicht (in so einem Fall wird von Pseudogröße gesprochen). Die App muss für ein Adrequest der entsprechenden Platzierung alle zugehörigen Creative Sizes abfragen. Die oft lange Liste aus Größen ergibt sich aus den vielen möglichen unterschiedlichen Werbeformen und den Unterschieden in direkter und programmatischer Vermarktung.

Bei Fullscreen Ad und Preloading Ad Platzierungen werden meist Größen für Portrait- und Landscape-Modus gemeinsam abgefragt.

Zeile 112:

Zeile 116:

;doc:Die Bezeichnung des Seitentyps. Gültige Werte sind homepage, index, artikel, bildgal

;iqadtype:Die Angabe der Plattform. Gültige Werte sind online, mew, app, amp

;appver:Die Bezeichnung der Appversions-Nummer (s.u.)

;appver:Die Bezeichnung der Appversions-Nummer. Beispiel: Version 4.01 sollte dann appver=4_01 sein. Es sollte eine sinnvolle Bezeichnung sein, damit im Problemfall eine bestimmte Appversion von der Vermarktung ausgeschlossen werden kann.

Angaben welche Keywords für welche Platzierung verwendet werden sollen, finden sich in der creative_sizes_and_keywords.xlsc Tabelle, die von der iq digital zu Projektstart zur Verfügung gestellt wird.

Zeile 119:

Zeile 123:

*https://developers.google.com/ad-manager/mobile-ads-sdk/ios/targeting#custom_targeting

*https://developers.google.com/ad-manager/mobile-ads-sdk/android/targeting#custom_targeting

===Content-Url Parameter im Adrequest===

Damit programmatische Partner (z.B. Adexchange, Headerbidding oder Backfill) möglichst hoch um eine Werbeplatzierung bieten, muss dieser App-Werbeplatzierung mitgeteilt werden, zu welcher stationären Webseite sie tatsächlich gehört. Dies geschieht über den content-url Parameter im Adrequest. Hier ist als Wert die URL der Webseite zu übergeben, die möglichst genau zu dem Inhalt in der App passt. Beispiel: Ein App-Artikel sollte im content-url Parameter auf seinen stationären Webartikel verlinken, eine App Startseite auf die Homepage usw.

Das GMA SDK besitzt dazu eine setContentUrl-Funktion.

Dies wird hier genauer beschrieben:

*https://developers.google.com/ad-manager/mobile-ads-sdk/ios/targeting?hl=de#content_url

*https://developers.google.com/ad-manager/mobile-ads-sdk/android/targeting?hl=de#content_url

===Debugging===

[[Datei:Easteregg dialog.png|300px|thumbnail|Beispiel aus einer Android App mit Textfeld für Keywords und Checkbox für USB Debugging]]

Es muss eine "Easter-Egg"-Funktion ~~eingebaut~~ in die App eingebaut werden, damit die iq digital Probleme und neue Werbeformen innerhalb der Live App (Version aus dem App- bzw. Playstore) testen kann. Der Adserver DFP bietet die Möglichkeiten Testschaltungen über ein Keyword in der App auszuspielen.

Es muss eine "Easter-Egg"-Funktion in die App eingebaut werden, damit die iq digital Probleme und neue Werbeformen innerhalb der Live App (Version aus dem App- bzw. Playstore) testen kann. Der Adserver DFP bietet die Möglichkeiten Testschaltungen über ein Keyword in der App auszuspielen.

In einem selten frequentierten Bereich der App, wie z.B. dem Impressum, sollte es daher die Möglichkeit für Eingeweihte geben, einen kleinen Dialog aufzurufen. Durch diesen kann man ein selbst gewähltes Keyword jedem zukünftigen Adrequest anhängen. Gleichzeitig oder durch das Aktivierung einer Checkbox kann der USB-Debug-Modus, um die Werbe Webviews in der Android App auf dem Desktop Chrome zu inspizieren, aktiviert werden.

Zeile 139:

Zeile 150:

Es gibt vielfältige Optionen, wie das Easter-Egg aktiviert werden kann. Mehrfache/unsinnige Taps auf UI-Elemente oder eine ganz spezielle Eingabe ins Suchfeld seien hier beispielhaft genannt. Die iq digital erlaubt sich aber die Vorgabe, dass unter Android und iOS das Debug-Easter-Egg identisch aktiviert wird. Bei der Art der Aktivierung des Debug-Easter-Egg stehen wir gerne beratend zur Seite.

~~===App-Versions-Targeting===~~

~~Es soll die Möglichkeit geben, dass wir ältere App-Versionen, die noch im Spiel sind, aber einen in Hinblick auf die Werbung relevanten Bug aufweisen, von der Werbeausspielung ausschließen können.~~

~~Die addCustomTargeting Methode (siehe oben Punkt "Anhängen von Key-Value-Paaren"), müsste dazu benutzt werden. Nur würde hier nicht als Key "kw" sondern "appver" benutzt werden.~~

~~Damit das Ganze auch praktikabel ist, bedarf es hier ein bisschen Fingerspitzengefühl, was das Value angeht.~~

~~Das Problem ist, dass wir diese Werte lediglich als Zeichenketten im AdServer sehen und daraufhin operieren können. Wir können zwei Strings lediglich abgleichen.~~

~~Was leider nicht geht, ist eine Bedingung wie "Wenn die Appversion kleiner oder gleich 3, dann dort keine Werbe-Ausspielung".~~

~~Es darf also nicht inflationär viele verschiedene Versionsnummern gleichzeitig in der Gesamtheit der Nutzer geben.~~

Sinnvoll wäre also eine Major-Versionsnummer und ein oder zwei "Nachkommastellen", getrennt mit einem Unterstrich. Also z.B. "1_12". Gewünscht ist nicht eine extra Versionsnummer nur für die Werbung, sondern ein sinnvoller Substring der internen Versionierung.

~~Entscheidend ist aber, dass dieser Wert zumindest dann inkrementiert wird, wenn sich irgendwie Auswirkungen auf die Werbeintegration ergeben könnten.~~

~~Mit Fingerspitzengefühl meine ich konkret, dass man sich die Frage stellt...~~

~~• Wird das Google Ads SDK in einer neuen Version benutzt? -> immer inkrementieren~~

~~• Wurde etwas an den Aufrufen der Methoden des Google Ads SDK verändert, z.B. Timings? -> immer inkrementieren~~

~~• Wurde etwas an der Swipe-View-Struktur verändert? -> besser inkrementieren~~

~~• Wurde etwas am Layout verändert? -> vielleicht inkrementieren~~

~~Bei den beiden erst genannten Punkten gehen wir davon aus, dass das nicht ohne Rücksprache mit uns erfolgt.~~

===Wichtige Hinweise zu dieser Anleitung===

Zeile 202:

Zeile 197:

*im Falle einer Buchung:

**erzeugt das Interstitial mit Hilfe des GMA SDKs

**~~vergößert~~ den Werbecontainers auf Display-Größe

**vergrößert den Werbecontainers auf Display-Größe

*bei Orientationchange- oder Resize-Event: passt die Werbeseite und den Werbecontainer an die neuen Display-Maße an

*bereitet im Hintergrund weiter den Content vor

Zeile 287:

Zeile 282:

*erstellt den Werbecontainer mit Größe, welche in der Antwort vom Andserver auf das Adrequest mitgeliefert wird

*lauscht mit dem EventListener auf mögliche setsize- oder noad-Events und verändert den Werbecontainer entsprechend.

*im Falle einer Ausbuchung: empfängt sie ein noad-Event, muss sie die Werbeplatzierung und die zugehörige Anzeigenkennzeichnung komplett entfernen bzw. ausblenden

*im Falle einer Ausbuchung:

**empfängt sie ein setsize-Event muss sie die Werbeplatzierung und den Werbecontainer an die neue Größe anpassen, sofern sich diese von der aktuellen Größe unterscheidet

**empfängt sie ein noad-Event, muss sie die Werbeplatzierung und die zugehörige Anzeigenkennzeichnung komplett entfernen bzw. ausblenden

|workflowad=

#App sendet Adrequest an Adserver

#Adserver antwortet mit Werbebuchung

#App erzeugt ~~dynamisch~~ die ~~Werbeseite~~

#App erzeugt Werbecontainer mit der Größe, die in der Response des Adservers enthalten ist

#Werbecontainer ~~wird~~ auf ~~die Display~~-~~Abmaße aufgezogen~~

#eventuell muss der Werbecontainer auf Grund eines setsize-Events angepasst werden

~~#Werbetemplate skaliert Werbemittel in dem Container~~

|workflownoad=

#App sendet Adrequest an Adserver

#Adserver antwortet~~, dass er keine~~ Werbebuchung ~~hat~~

#Adserver antwortet mit Ausbuchung als Werbebuchung

#App ~~erzeugt '''keine''' Werbeseite bzw. entfernt~~ eine ~~zuvor erzeugte Werbeseite~~ aus ~~dem Seitenfluss~~

#App empfängt eine Response mit der Größe 99x1 und erhält kurze Zeit später ein noad-Event

#App blendet Werbeplatzierung und Anzeigenkennzeichnung bis zum nächsten Pagerequest aus

|creativesizes=

320x50, 320x53, 320x80, 320x106, 320x160, 320x320, 320x416, 320x460, 300x50, 300x75, 300x100, 300x150, 300x200, 300x250, 300x600

Zeile 310:

Zeile 307:

}}

==~~=Beschreibung=~~==

==Dokumentation der iq digital App Events==

Die ~~Werbeplatzierungen sind Banner-Platzierungen innerhalb~~ der ~~Content-Seite, die üblicherweise 320px Breite und eine bestimmte Höhe einnehmen. Sollte keine Werbung gebucht sein, wird die Platzierung ausgeblendet, es sollte kein Weißraum entstehen.~~

Die Werbetemplates der iq digital senden in bestimmten Situationen Events an die App. Die App muss auf diese Events reagieren und gemäß der folgenden Spezifikation den Werbecontainer verändern. Die App Events bestehen dabei immer aus dem Namen und einem "data"-String.

Die Adrequests für diese Platzierungen sollten initial beim Pagerequest erfolgen. Bei sehr langen Seiten, ist es auch möglich weiter unten liegende Banner Platzierungen erst zu laden, wenn der untere Content generiert wird. Jedoch sollte dabei immer berücksichtigt werden, dass das Ad genug Zeit hat, rechtzeitig angezeigt zu werden.

~~Für Banner-Platzierungen benutzen wir Pseudo-größen (z.B. 310x1, 310x4, 310x8 usw.). Damit das Banner in der korrekten Größe dargestellt wird, rufen die~~ iq digital ~~Templates ein bestimmtes Event auf. Dazu stellt die iq digital ein EventHandler-Klasse für Android zur Verfügung, die~~ in die App ~~integriert werden muss. Für iOS muss diese Klasse von den Appentwicklern portiert werden. Die EventHandler-Klasse benutzt eine spezielle Syntax für ein resize-Event~~. Die App muss ~~bei Erhalt des~~ Events ~~dann entsprechend~~ der ~~Logik die Größe des Ad entsprechend ändern~~.

Die App Events~~, die von der EventHandler~~-~~Klasse behandelt werden müssen, sind im Anhang A dokumentiert. Für Android gibt es mit der PublisherAdAppEventListener.java eine Vorlage, die nur noch um appspezifischen Code erweitert werden muss~~.

==Dokumentation ~~der iq digital App Events~~==

===Wichtige Links in der GMA SDK Dokumentation===

~~Die~~ App Events ~~bestehen aus dem Namen und einem "data"~~-~~String~~

*[https://developers.google.com/ad-manager/mobile-ads-sdk/ios/banner#app_events GMA SDK iOS App Events]

*[https://developers.google.com/ad-manager/mobile-ads-sdk/android/banner#app_events GMA SDK Android App Events]

===setsize – Event===

Zeile 327:

Zeile 322:

;width:Die neue Breite des Adviews in Pixel (Device-Independent-Pixel) als ganze Zahl.

;height:Die neue Höhe des Adviews in Pixel (Device-Independent-Pixel) als ganze Zahl.

{{Warnung|text=Ausnahme: Für eine Anpassung auf die maximal verfügbare Breite oder Höhe wird der Wert '''max''' verwendet.}}

{{Warnung|text=Ausnahme: Für eine Anpassung auf die maximal verfügbare Breite oder Höhe wird der Wert '''max''' verwendet. Mit maximaler verfügbare Breite bzw. Höhe ist im Normalfall die Displaybreite bzw. -Höhe gemeint. Sollte eine App hier zwingende Abweichungen haben, wie einen notwendigen Rand, muss dies unbedingt '''frühzeitig mit iq digital''' besprochen werden.}}

Beispielaufrufe:

Zeile 338:

Zeile 334:

Das noad-Event wird von den Werbetemplates der iq digital aufgerufen, um der App zu signalisieren, dass für die Platzierung keine Buchung vorliegt und die App die Werbeplatzierung '''und die zugehörige Anzeigenkennzeichnung''' entfernen soll.

Der "data"-String hat für dieses Event keine Bedeutung und kann ignoriert werden.

Der "data"-String hat für dieses Event keine Bedeutung und kann ignoriert werden. Da das AppEventListener Interface von Google eine @NonNull Annotation für data hat, wird beim noad-Event einfach der Wert "noad" für data übergeben, da der leere String von Google als null umgewandelt wird.

[[Kategorie:Ad Technology]][[Kategorie:APP]]

[[en:Integration of the Google Mobile Ads SDK]]

@@ Zeile 1: / Zeile 1: @@
+Diese Dokumentation dient dazu den Einbau des Google Mobile Ads SDK (GMA SDK) und die Werbeintegration der iq digital zu erklären. Sie geht dabei auf notwendige und wichtige Eigenheiten ein und versucht übliche Missverständnisse aufzuklären.
+Die Dokumentation beginnt dabei mit dem GMA SDK und allgemeinen Informationen, welche für alle Werbeformen gelten, die in der App laufen sollen. Darauf folgen Werbeform spezifische Erklärungen und zum Abschluss werden werbeform spezifische Events erklärt, welche die App berücksichtigen muss.
 ==Offizielle Dokumentation zum Google Mobile Ads SDK==
 Das Google Mobile Ads SDK (GMA SDK) bringt alles mit, was für eine Werbeausspielung in nativen Apps benötigt wird.
@@ Zeile 5: / Zeile 9: @@
 [https://developers.google.com/ad-manager/mobile-ads-sdk/ios/quick-start GMA SDK iOS Getting Started]
-[https://developers.google.com/ad-manager/mobile-ads-sdk/android/quick-start GMA SDK iOS Getting Started]
+[https://developers.google.com/ad-manager/mobile-ads-sdk/android/quick-start GMA SDK Android Getting Started]
 ===Download des Google Mobile Ads SDK===
@@ Zeile 51: / Zeile 55: @@
 ====Begriffserklärung====
 ;netzwerkId:Hier ist immer die Netzwerk ID der iq digital einzugeben: 183
-;level1:Dies ist die Bezeichnung der App im Google Ad Manager und wird von der iq digital vorgegeben. Die Bezwichnung besteht aus <appname>_app_<plattform>_<gerätetyp>.
+;level1:Dies ist die Bezeichnung der App im Google Ad Manager und wird von der iq digital vorgegeben. Die Bezeichnung besteht aus <appname>_app_<plattform>_<gerätetyp>.
 :;appname:Der Name der App
 :;plattform:Das Betriebsystem, also ''ios'' oder ''android''
 :;gerätetyp:Der Gerätetyp, also '''phone''' oder ''tablet''
-;level2:Dies ist die Bezeichnung einer Rubrik der App, z.B. ''politik''
+;level2:Dies ist die Bezeichnung einer Rubrik der App oder der Startseite, z.B. ''politik'', ''openingpage''
-;level3 (usw.):Dies ist die Bezeichnung für eine Unterrubrik, z.B. im Falle von ''politik'' als level2 wäre ''ausland'' eine Unterrubrik für level3. Level4 und höher sind weitere tiefere Verzweigungen der App, diese werden im Normalfall nicht also Adunits angelegt und solche Seiten würden unter dem level3 angelegt werden.
+;level3 (usw.):Dies ist die Bezeichnung für eine Unterrubrik, z.B. im Falle von ''politik'' als level2 wäre ''ausland'' eine Unterrubrik für level3. Level4 und höher sind weitere tiefere Verzweigungen der App, diese werden im Normalfall nicht als Adunits angelegt. Solche Seiten würden dann über das übergeordnete level3 vermarktet werden. Beispiel: Eine Seite ''politik/ausland/usa'' ist zu speziell, um sie einzeln zu vermarkte. In so einem Fall ist es sinnvoll, dass sie nur bis level3, also als ''politik/ausland'', vertaggt wird.
-;seitentyp:In Apps mit Banner-Anzeigen (z.B. News Apps) bezeichnet ''seitentyp'' die unterschiedlichen Seitentypen, also ob es sich z.B. um eine Übersichts-, Artikel- oder Bildergalerieseite handelt. Übliche Werte dafür sind ''homepage'', ''index'', ''artikel'', ''bildgal''. In Apps mit Fullscreen-Anzeigen (z.B. epaper oder Zeitungs Apps) werden mit ''seitentyp'' die unterschiedlichen Anzeigeplätze innerhalb der Rubrik gemeint, also ob es sich z.B. erste, zweite oder dritte Swipe Anzeige handelt. Übliche Werte sind ''openingpage'', ''swipe_1'', ''swipe_2'', ''swipe_3'' usw.
+;seitentyp:In Apps mit Banner-Anzeigen (z.B. News Apps) bezeichnet ''seitentyp'' die unterschiedlichen Seitentypen, also ob es sich z.B. um eine Übersichts-, Artikel- oder Bildergalerieseite handelt. Übliche Werte dafür sind ''homepage'', ''index'', ''artikel'', ''bildgal''. In Apps mit Fullscreen-Anzeigen (z.B. epaper oder Zeitungs Apps) werden mit ''seitentyp'' die unterschiedlichen Anzeigeplätze innerhalb der Rubrik gemeint, also ob es sich z.B. erste, zweite oder dritte Swipe Anzeige handelt. Übliche Werte sind ''swipe_1'', ''swipe_2'', ''swipe_3'' usw.
 ====Beispiel für die fiktive Rheinischer Kurier News App mit Banner-Anzeigen:====
@@ Zeile 72: / Zeile 76: @@
 */183/Rheinischer_Kurier_epaper_app_ios_tablet
 */183/Rheinischer_Kurier_epaper_app_ios_tablet/preloading_ad
-*/183/Rheinischer_Kurier_epaper_app_ios_tablet/openingpage
+*/183/Rheinischer_Kurier_epaper_app_ios_tablet/openingpage/swipe_1
 */183/Rheinischer_Kurier_epaper_app_ios_tablet/politik/swipe_1
 */183/Rheinischer_Kurier_epaper_app_ios_tablet/politik/swipe_2
@@ Zeile 82: / Zeile 86: @@
 ===Creative Sizes===
-Im Google Ad Manager stehen die Creative Sizes für die Werbemittel-Größen. Dabei ist es möglich dass die tatsächlich ausgespielte Größe eines Werbemittels von der CreativeSize abweicht (in so einem Fall wird von Pseudogröße gesprochen). Die App muss für ein Adrequest der entsprechenden Platzierung alle zugehörigen Creative Sizes abfragen. Die oft lange Liste aus Größen ergibt sich aus den vielen möglichen unterschiedlichen Werbeformen und den unterschieden in direkter und programmatischer Vermarktung.
+Im Google Ad Manager stehen die Creative Sizes für die Werbemittel-Größen. Dabei ist es möglich dass die tatsächlich ausgespielte Größe eines Werbemittels von der CreativeSize abweicht (in so einem Fall wird von Pseudogröße gesprochen). Die App muss für ein Adrequest der entsprechenden Platzierung alle zugehörigen Creative Sizes abfragen. Die oft lange Liste aus Größen ergibt sich aus den vielen möglichen unterschiedlichen Werbeformen und den Unterschieden in direkter und programmatischer Vermarktung.
 Bei Fullscreen Ad und Preloading Ad Platzierungen werden meist Größen für Portrait- und Landscape-Modus gemeinsam abgefragt.
@@ Zeile 112: / Zeile 116: @@
 ;doc:Die Bezeichnung des Seitentyps. Gültige Werte sind homepage, index, artikel, bildgal
 ;iqadtype:Die Angabe der Plattform. Gültige Werte sind online, mew, app, amp
-;appver:Die Bezeichnung der Appversions-Nummer (s.u.)
+;appver:Die Bezeichnung der Appversions-Nummer. Beispiel: Version 4.01 sollte dann appver=4_01 sein. Es sollte eine sinnvolle Bezeichnung sein, damit im Problemfall eine bestimmte Appversion von der Vermarktung ausgeschlossen werden kann.
 Angaben welche Keywords für welche Platzierung verwendet werden sollen, finden sich in der creative_sizes_and_keywords.xlsc Tabelle, die von der iq digital zu Projektstart zur Verfügung gestellt wird.
@@ Zeile 119: / Zeile 123: @@
 *https://developers.google.com/ad-manager/mobile-ads-sdk/ios/targeting#custom_targeting
 *https://developers.google.com/ad-manager/mobile-ads-sdk/android/targeting#custom_targeting
+===Content-Url Parameter im Adrequest===
+Damit programmatische Partner (z.B. Adexchange, Headerbidding oder Backfill) möglichst hoch um eine Werbeplatzierung bieten, muss dieser App-Werbeplatzierung mitgeteilt werden, zu welcher stationären Webseite sie tatsächlich gehört. Dies geschieht über den content-url Parameter im Adrequest. Hier ist als Wert die URL der Webseite zu übergeben, die möglichst genau zu dem Inhalt in der App passt. Beispiel: Ein App-Artikel sollte im content-url Parameter auf seinen stationären Webartikel verlinken, eine App Startseite auf die Homepage usw.
+Das GMA SDK besitzt dazu eine setContentUrl-Funktion.
+Dies wird hier genauer beschrieben:
+*https://developers.google.com/ad-manager/mobile-ads-sdk/ios/targeting?hl=de#content_url
+*https://developers.google.com/ad-manager/mobile-ads-sdk/android/targeting?hl=de#content_url
 ===Debugging===
 [[Datei:Easteregg dialog.png|300px|thumbnail|Beispiel aus einer Android App mit Textfeld für Keywords und Checkbox für USB Debugging]]
-Es muss eine "Easter-Egg"-Funktion eingebaut in die App eingebaut werden, damit die iq digital Probleme und neue Werbeformen innerhalb der Live App (Version aus dem App- bzw. Playstore) testen kann. Der Adserver DFP bietet die Möglichkeiten Testschaltungen über ein Keyword in der App auszuspielen.
+Es muss eine "Easter-Egg"-Funktion in die App eingebaut werden, damit die iq digital Probleme und neue Werbeformen innerhalb der Live App (Version aus dem App- bzw. Playstore) testen kann. Der Adserver DFP bietet die Möglichkeiten Testschaltungen über ein Keyword in der App auszuspielen.
 In einem selten frequentierten Bereich der App, wie z.B. dem Impressum, sollte es daher die Möglichkeit für Eingeweihte geben, einen kleinen Dialog aufzurufen. Durch diesen kann man ein selbst gewähltes Keyword jedem zukünftigen Adrequest anhängen. Gleichzeitig oder durch das Aktivierung einer Checkbox kann der USB-Debug-Modus, um die Werbe Webviews in der Android App auf dem Desktop Chrome zu inspizieren, aktiviert werden.
@@ Zeile 139: / Zeile 150: @@
 Es gibt vielfältige Optionen, wie das Easter-Egg aktiviert werden kann. Mehrfache/unsinnige Taps auf UI-Elemente oder eine ganz spezielle Eingabe ins Suchfeld seien hier beispielhaft genannt. Die iq digital erlaubt sich aber die Vorgabe, dass unter Android und iOS das  Debug-Easter-Egg identisch aktiviert wird. Bei der Art der Aktivierung des Debug-Easter-Egg stehen wir gerne beratend zur Seite.
-===App-Versions-Targeting===
-Es soll die Möglichkeit geben, dass wir ältere App-Versionen, die noch im Spiel sind, aber einen in Hinblick auf die Werbung relevanten Bug aufweisen, von der Werbeausspielung ausschließen können.
-Die addCustomTargeting Methode (siehe oben Punkt "Anhängen von Key-Value-Paaren"), müsste dazu benutzt werden. Nur würde hier nicht als Key "kw" sondern "appver" benutzt werden.
-Damit das Ganze auch praktikabel ist, bedarf es hier ein bisschen Fingerspitzengefühl, was das Value angeht.
-Das Problem ist, dass wir diese Werte lediglich als Zeichenketten im AdServer sehen und daraufhin operieren können. Wir können zwei Strings lediglich abgleichen.
-Was leider nicht geht, ist eine Bedingung wie "Wenn die Appversion kleiner oder gleich 3, dann dort keine Werbe-Ausspielung".
-Es darf also nicht inflationär viele verschiedene Versionsnummern gleichzeitig in der Gesamtheit der Nutzer geben.
-Sinnvoll wäre also eine Major-Versionsnummer und ein oder zwei "Nachkommastellen", getrennt mit einem Unterstrich. Also z.B. "1_12". Gewünscht ist nicht eine extra Versionsnummer nur für die Werbung, sondern ein sinnvoller Substring der internen Versionierung.
-Entscheidend ist aber, dass dieser Wert zumindest dann inkrementiert wird, wenn sich irgendwie Auswirkungen auf die Werbeintegration ergeben könnten.
-Mit Fingerspitzengefühl meine ich konkret, dass man sich die Frage stellt...
-•	Wird das Google Ads SDK in einer neuen Version benutzt? -> immer inkrementieren
-•	Wurde etwas an den Aufrufen der Methoden des Google Ads SDK verändert, z.B. Timings? -> immer inkrementieren
-•	Wurde etwas an der Swipe-View-Struktur verändert? -> besser inkrementieren
-•	Wurde etwas am Layout verändert? -> vielleicht inkrementieren
-Bei den beiden erst genannten Punkten gehen wir davon aus, dass das nicht ohne Rücksprache mit uns erfolgt.
 ===Wichtige Hinweise zu dieser Anleitung===
@@ Zeile 202: / Zeile 197: @@
 *im Falle einer Buchung:
 **erzeugt das Interstitial mit Hilfe des GMA SDKs
-**vergößert den Werbecontainers auf Display-Größe
+**vergrößert den Werbecontainers auf Display-Größe
 *bei Orientationchange- oder Resize-Event: passt die Werbeseite und den Werbecontainer an die neuen Display-Maße an
 *bereitet im Hintergrund weiter den Content vor
@@ Zeile 287: / Zeile 282: @@
 *erstellt den Werbecontainer mit Größe, welche in der Antwort vom Andserver auf das Adrequest mitgeliefert wird
 *lauscht mit dem EventListener auf mögliche setsize- oder noad-Events und verändert den Werbecontainer entsprechend.
-*im Falle einer Ausbuchung: empfängt sie ein noad-Event, muss sie die Werbeplatzierung und die zugehörige Anzeigenkennzeichnung komplett entfernen bzw. ausblenden
+*im Falle einer Ausbuchung:
+**empfängt sie ein setsize-Event muss sie die Werbeplatzierung und den Werbecontainer an die neue Größe anpassen, sofern sich diese von der aktuellen Größe unterscheidet
+**empfängt sie ein noad-Event, muss sie die Werbeplatzierung und die zugehörige Anzeigenkennzeichnung komplett entfernen bzw. ausblenden
 |workflowad=
 #App sendet Adrequest an Adserver
 #Adserver antwortet mit Werbebuchung
-#App erzeugt dynamisch die Werbeseite
+#App erzeugt Werbecontainer mit der Größe, die in der Response des Adservers enthalten ist
-#Werbecontainer wird auf die Display-Abmaße aufgezogen
+#eventuell muss der Werbecontainer auf Grund eines setsize-Events angepasst werden
-#Werbetemplate skaliert Werbemittel in dem Container
 |workflownoad=
 #App sendet Adrequest an Adserver
-#Adserver antwortet, dass er keine Werbebuchung hat
+#Adserver antwortet mit Ausbuchung als Werbebuchung
-#App erzeugt '''keine''' Werbeseite bzw. entfernt eine zuvor erzeugte Werbeseite aus dem Seitenfluss
+#App empfängt eine Response mit der Größe 99x1 und erhält kurze Zeit später ein noad-Event
+#App blendet Werbeplatzierung und Anzeigenkennzeichnung bis zum nächsten Pagerequest aus
 |creativesizes=
 x50, 320x53, 320x80, 320x106, 320x160, 320x320, 320x416, 320x460, 300x50, 300x75, 300x100, 300x150, 300x200, 300x250, 300x600
@@ Zeile 310: / Zeile 307: @@
 }}
-===Beschreibung===
+==Dokumentation der iq digital App Events==
-Die Werbeplatzierungen sind Banner-Platzierungen innerhalb der Content-Seite, die üblicherweise 320px Breite und eine bestimmte Höhe einnehmen. Sollte keine Werbung gebucht sein, wird die Platzierung ausgeblendet, es sollte kein Weißraum entstehen.
+Die Werbetemplates der iq digital senden in bestimmten Situationen Events an die App. Die App muss auf diese Events reagieren und gemäß der folgenden Spezifikation den Werbecontainer verändern. Die App Events bestehen dabei immer aus dem Namen und einem "data"-String.
-Die  Adrequests für diese Platzierungen sollten initial beim Pagerequest erfolgen. Bei sehr langen Seiten, ist es auch möglich weiter unten liegende Banner Platzierungen erst zu laden, wenn der untere Content generiert wird. Jedoch sollte dabei immer berücksichtigt werden, dass das Ad genug Zeit hat, rechtzeitig angezeigt zu werden.
-Für Banner-Platzierungen benutzen wir Pseudo-größen (z.B. 310x1, 310x4, 310x8 usw.). Damit das Banner in der korrekten Größe dargestellt wird, rufen die iq digital Templates ein bestimmtes Event auf. Dazu stellt die iq digital ein EventHandler-Klasse für Android zur Verfügung, die in die App integriert werden muss. Für iOS muss diese Klasse von den Appentwicklern portiert werden. Die EventHandler-Klasse benutzt eine spezielle Syntax für ein resize-Event. Die App muss bei Erhalt des Events dann entsprechend der Logik die Größe des Ad entsprechend ändern.
-Die App Events, die von der EventHandler-Klasse behandelt werden müssen, sind im Anhang A dokumentiert. Für Android gibt es mit der PublisherAdAppEventListener.java eine Vorlage, die nur noch um appspezifischen Code erweitert werden muss.
-==Dokumentation der iq digital App Events==
+===Wichtige Links in der GMA SDK Dokumentation===
-Die App Events bestehen aus dem Namen und einem "data"-String
+*[https://developers.google.com/ad-manager/mobile-ads-sdk/ios/banner#app_events GMA SDK iOS App Events]
+*[https://developers.google.com/ad-manager/mobile-ads-sdk/android/banner#app_events GMA SDK Android App Events]
 ===setsize – Event===
@@ Zeile 327: / Zeile 322: @@
 ;width:Die neue Breite des Adviews in Pixel  (Device-Independent-Pixel) als ganze Zahl.
 ;height:Die neue Höhe des Adviews in Pixel  (Device-Independent-Pixel) als ganze Zahl.
-{{Warnung|text=Ausnahme: Für eine Anpassung auf die maximal verfügbare Breite oder Höhe wird der Wert '''max''' verwendet.}}
+{{Warnung|text=Ausnahme: Für eine Anpassung auf die maximal verfügbare Breite oder Höhe wird der Wert '''max''' verwendet. Mit maximaler verfügbare Breite bzw. Höhe ist im Normalfall die Displaybreite bzw. -Höhe gemeint. Sollte eine App hier zwingende Abweichungen haben, wie einen notwendigen Rand, muss dies unbedingt '''frühzeitig mit iq digital''' besprochen werden.}}
 Beispielaufrufe:
@@ Zeile 338: / Zeile 334: @@
 Das noad-Event wird von den Werbetemplates der iq digital aufgerufen, um der App zu signalisieren, dass für die Platzierung keine Buchung vorliegt und die App die Werbeplatzierung '''und die zugehörige Anzeigenkennzeichnung''' entfernen soll.
-Der "data"-String hat für dieses Event keine Bedeutung und kann ignoriert werden.
+Der "data"-String hat für dieses Event keine Bedeutung und kann ignoriert werden. Da das AppEventListener Interface von Google eine @NonNull Annotation für data hat, wird beim noad-Event einfach der Wert "noad" für data übergeben, da der leere String von Google als null umgewandelt wird.
 [[Kategorie:Ad Technology]][[Kategorie:APP]]
 [[en:Integration of the Google Mobile Ads SDK]]