Grundsätzliche Regeln und Hinweise zum Einbau von Banner-Anzeigen

Aus Dokumentation
Version vom 10. Juni 2021, 09:55 Uhr von Tlohmann (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „==Banner Anzeigen== *Double Click Ausspielungsalgorithmus benutzt ein Priorisierungsmodell und agiert im Jetzt. Eine frühere Entscheidung, ob eine Werbebuchun…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

  • Double Click Ausspielungsalgorithmus benutzt ein Priorisierungsmodell und agiert im Jetzt. Eine frühere Entscheidung, ob eine Werbebuchung ausgespielt werden soll, ist eventuell wenige Millisekunden später bereits veraltet. Es ist daher nicht möglich im Voraus zu bestimmen (z.B. bei Appstart), ob zu einem späteren Zeitpunkt eine Werbeplatzierung belegt ist
  • Adrequests werden immer zu Beginn eines Pagerequests abgerufen, es sei denn für eine Platzierung gilt, dass sie „in-view“ abgerufen werden soll, also abhängig von der Scrollposition. In-View Platzierungen werden im Vertaggungsplan gesondert gekennzeichnet
  • Geladene Ads verbleiben in der Seite, ein erneutes darüber scrollen darf die Werbung nicht erneut abrufen
  • Manche Werbemittel kommunizieren über den Eventhandler mittels setsize-Event eine Veränderung der Größe, andere (z.B. programmatische) Werbemittel nutzen kein setsize-Event. Die App kann sich also nicht darauf verlassen, dass ein setsize-Event eintritt. Platzierungen, für die keine Werbung vorgesehen sind, enthalten Ausbuchungen (Werbemittel, die ein noad-Event benutzen). In diesem Fall kann die Werbung inklusive Anzeigenkennzeichnung ausgeblendet bleiben
  • Die App darf Werbung nicht generell ausblenden und erst nachträglich anzeigen. Um ein Springen der Seite zu vermeiden, kann die App einen „kurzen“ Zeitraum warten, ob ein noad-Event kommt. Falls in diesem keines kommt, muss sie dann die Werbung anzeigen. Sollte auf Grund schlechter Datenübertragung verzögert doch ein noad-Event kommen, kann ein Springen nicht vermieden werden. Ausbuchungen haben die Größen 320x1, 320x3, 320x4 und 320x8 (je nach Platzierung)
  • Die App muss den Adcontainer komplett darstellen und darf ihn nicht abschneiden oder mit übergeordnetem padding oder margin aus dem Display schieben. Auf schmalen Displays (z.B. iPhone SE mit Viewport-Breite von 320px) muss die komplette Breite des Werbemittels sichtbar sein. Die App darf Werbemittel nicht skalieren
  • Im Zeitraum der Werbeintegration vor dem Livegang schalten wir Testbuchungen auf alle Platzierungen. Sofern alle notwendigen Parameter (creative-sizes, Keywords und Adunit) korrekt eingepflegt wurden, wird ein vom AdServer zurückgegebenes Test-Ad die positive Rückmeldung dafür sein
  • Korrekte creative-sizes, Keywords und Adunit sind notwendig, damit eine (Test-)Buchung angezeigt wird. Wenn der Adserver eine negative Antwort liefert („No ad to show“), gibt es für die Kombination creative-size, Keyword und Adunit keine Buchung. Dies kann an einer falschen Konfiguration in der App oder in der Buchung liegen (falls die Appkonfiguration stimmt)

Swipebare Fullscreen Anzeigen

  • Double Click Ausspielungsalgorithmus benutzt ein Priorisierungsmodell und agiert im Jetzt. Eine frühere Entscheidung, ob eine Werbebuchung ausgespielt werden soll, ist eventuell wenige Millisekunden später bereits veraltet. Es ist daher nicht möglich im Voraus zu bestimmen (z.B. bei Appstart), ob zu einem späteren Zeitpunkt eine Werbeplatzierung belegt ist
  • Das Timing der Adrequests muss dergestalt sein, dass das Ad eine hohe Kontaktchance hat. Bei swipebaren Fullscreen Anzeigen sollen sie 1-2 Seiten vor der Platzierung abgeschickt werden und nicht alle direkt zum Appstart
  • Die App muss die manuelle Impressionzählung nutzen und sollte das Impressiontracking einmalig durchführen, sobald mindestens 1 Pixel der Anzeige sichtbar ist. Ein erneutes Swipen über das Ad, darf nicht zu erneutem Impressiontracking führen
  • Geladene Ads verbleiben in der Ausgabe, ein erneutes swipen über die Platzierung soll keinen erneuten Adrequest verursachen.
  • Die App darf nicht aus Speichermangel abstürzen, wenn eine Werbung geladen wird. Das Speichermanagement muss zur Not bereits gesehene Platzierungen aus dem Speicher werfen und in diesem Fall bei erneutem Swipe über die Stelle, wieder neu requesten. Ein erneut geladenes Ad muss dann natürlich wieder die Impression manuell tracken (s.o.)
  • Die App muss den AdContainer auf Displaygröße aufziehen (Methoden siehe Doku). Das im WebView enthaltene Werbemittel reagiert auf das darauf folgende Resize-Event passiv und passt sich in den AdContainer ein.
  • Die App soll die Werbeanzeige nach Möglichkeit nicht überlagern und sofern möglich die Statusleiste des Betriebssystems auf der Werbeseite ausblenden, damit 100% des Screens für die Werbung genutzt werden können.
  • Im Zeitraum der Werbeintegration vor dem Livegang schalten wir Testbuchungen auf alle Platzierungen. Sofern alle notwendigen Parameter (creative-sizes, Keywords und Adunit) korrekt eingepflegt wurden, wird ein vom AdServer zurückgegebenes Test-Ad die positive Rückmeldung dafür sein
  • Korrekte creative-sizes, Keywords und Adunit sind notwendig, damit eine (Test-)Buchung angezeigt wird. Wenn der Adserver eine negative Antwort liefert („No ad to show“), gibt es für die Kombination creative-size, Keyword und Adunit keine Buchung. Dies kann an einer falschen Konfiguration in der App oder in der Buchung liegen (falls die Appkonfiguration stimmt)

Preloading Ad

  • Soll während des Splashscreens ausgeführt werden
  • Die Startseite darf erst angezeigt werden, wenn das Preloading Ad manuell oder automatisch durch das Ad selbst (Autoclose-Timeout) geschlossen wird.
  • Für den unwahrscheinlichen Fall, dass der Adserver keine Antwort senden kann (Serverausfall), soll die App die Startseite laden. Hierzu muss sie allerdings einen Zeitpuffer warten, um den Server auch bei schlechter Datenverbindung eine Antwortmöglichkeit zu geben (empfohlen werden 10s)