Online Werbung im Responsive Webdesign: Eine Lösungssuche

published 11.04.2013 · updated: 05.10.2013 · Es wird zu wenig über gute Werbe-Lösungen im Responsive Design (= Adaptiv Design oder Liquid Layout) gesprochen. Das ist auch der Grund, warum wir Responsive Design in Deutschland nur dort sehen, wo Display Advertising nicht das Business Model ist. Aber die Werbung ist genau der Punkt an dem wir jetzt ansetzen müssen. Wenn wir der Online-Advertising-Branche eine stabile Lösung zeigen können, wie man Display Ads in einem dynamischen Frontend ausspielt, werden wir (hoffentlich) endlich auch dynamische Lösungen für große Seiten und Portale sehen. Lasst uns anfangen!

Online Advertiser als Online Innovations Bremser?

Die Vorteile von Responsive Design nicht erkannt?

Das eigentlich paradoxe ist, dass die Vermarkter alle Vorteile von guten Responsive Lösungen voll für sich nützen können: Es ergeben sich wunderbare Synergien, weil nur ein System für Auslieferung und Targeting genützt wird. Endlich sieht man das große Bild in einem System. Man kann endlich wirklich präzise nach Device und Auflösung ausliefern. Wenn man zum ersten mal sieht welche Zielgruppen wirklich mit welchen Geräten und Auflösungen zugreifen, kann man ganz neue, conversion-stärkere Werbemittel in den Markt zu bringen. Und Responsive Design bietet Zukunftssicherheit, weil man nicht mit jedem neuen Device Angst haben muss dass Platzierungen an Sichtbarkeit verlieren. Trotzdem sehen wir in den Portfolios der großen deutschen Vermarkter nur statische Webseiten. Wir müssen diesen Wiederspruch lösen. So schwer ist das nicht, denn die meisten Probleme, die im Zusammenhang mit Responsiv Design, besprochen werden, sind eigentlich keine.

Deutschland setzt auf veraltet Formate

Sehr wohl ein Problem ist die kauzige Vorliebe aller deutschen Vermarkter für lustige Kombi-Multi-Ads, die sich aus möglichst vielen Standard-Formaten zusammensetzen. Tut mir leid, aber das ist der falsche Weg (und er wird dynamische Webseiten nicht überleben). Die Amerikaner machen es uns vor und verwenden ihre Zeit lieber darauf, in stabilen Formaten wie Billboards und Rechtangle atemberaubende Werbung zu designen, statt immer wieder neu herausfinden zu müssen, wo ein Superbanner aufhört, damit man einen Skyscraper dranflanschen kann. Und überhaupt ist es der Skyscaper, der in den US langsam ausstirbt und uns damit den ganz sanften Hinweis gibt, dass wir hier in Deutschland, mit unserer großen Liebe für ihn, drohen, zu stark auf unpraktische und altmodische Formate zu setzen. Wenn wir international nicht abgehängt werden wollen, müßen die Standard-Formate-Puzzles (und der Skyscraper?) aus den Portfolios verschwinden.

Zwei Probleme, die es gar nicht gibt

Es geht nicht darum Display Ads zu skalieren

Es gibt Leute, die denken Responsive hätte immer etwas damit zu tun, dass man das Browserfenster packt, seine Größe verändert und die Elemente der Seite passen sich dann schön flüssig an diese verschiedenen Breiten an. Das Herumspielen mit der Breite des Browserfensters macht man aber ja nur bei Abnahmen oder, um auf einen Blick zu zeigen, wie wunderbar dynamisch sich das Design verhält. Der User wird wahrscheinlich nie die Grösse seines Browserfensters verändern. Unser eigentliches Ziel muss es sein, beim Aufruf der Seite, die für den User optimale Darstellung zu erreichen. Im Fall von Werbung also initial, die für die Bildschirmbreite des Users optimalen Werbemittel auszuspielen. Es ist nicht nötig die feste Größe der Display Ads zu verändern und - obwohl wir aus den USA erste sehr schöne Ansätze für flexible Ads sehen (z.B. von Rob Flaherty oder ResponsiveAds) - halte ich es im Moment (noch) für keine gute Idee. Weil es Probleme mit Rich Media Ads (Animationen, Videos) erzeugt und der Performance schadet (Advertiser würden Ads in der größt-möglichen Größe anliefern). Vor allem aber, weil Responsiv Ads den Mythos generieren, man könne erst dann Werbung in einem Responsiv Frontend ausspielen, wenn alle Werbemittel der Advertiser responsiv sind. Das ist nicht wahr. Es geht darum in einem Responsiv Design initial die optimalen statischen Werbemittel auszuspielen (die wir heute schon kennen).

Es geht auch kein Inverntar verloren

Einem User, der mit einem SmallScreen (ich sag mal absichtlich nicht „Mobile“ – das lassen wir schön in den 90ern, wo es hingehört) Device zugreift, zeigen wir keine BigScreen-Ads an. Er kann sie nicht vollständig sehen, sie überfordern sein Device und die Landingpage des Kunden, ist höchstwahrscheinlich auch nicht für SmallScreen-Geräte optimert. Wir lösen heute schon das Device auf und entscheiden hart in Small- und BigScreen. Fast alle großen Webseiten oder Portale da draußen haben heute eine statische SmallScreen („Mobile“) und eine statische BigScreen Version (die „normale“ Webseite). Das wird auch in einem Responsiv Frontend so sein und bleiben. Und nur weil wir unsere Ads jetzt in einem Frontend ausspielen, statt in zwei statischen Mandanten, ändert sich dadurch, weder die Anzahl der User, die darauf mobile zugreifen, noch die Anzahl der Advertiser, die "mobile" nicht buchen können (weil sie nur eine statische BigScreen Seite haben). Es geht darum initial die optimalen Werbemittel für das Device des Users auszuspielen - das tun wir heute auch schon. Die Frage ist vielleicht, ob man Zwischenstufen braucht, zwischen Big und Small. Kann sein. Das wird sich zeigen. Aber anfangen können wir auf jeden Fall mit dem, was wir heute schon haben.

BigScreen / SmallScreen AdTags nach Device ausspielen

Responsive mit einem Breakpoint

Los geht’s. Was für grundsätzliche Lösungen sind vorstellbar? Wie gesagt, haben eigentlich alle großen Webseiten eine statische SmallScreen („Mobile“) und eine statische BigSreen Version (die „normale“ Webseite). In beiden Versionen spielt ein Adserver Werbung aus. Wir werfen diese beiden Mandanten zusammen und liefern (mit den unveränderten AdTags) Big- und SmallScreen Ads, in einem Frontend, und mit einem Adserver, aus. Also responsive mit einem Breakpoint. Damit haben wir schon mal solide alle Breiten von 200-460px (SmallScreen) und 960-1400px (normale Webseite) abgedeckt.

Woher kommen initial die AdTags?

Wie entscheiden wir, wann wir Big- und wann SmallScreen AdTags ausliefern? Die einfachste Lösung ist, beim Laden der Seite (Server-seitig oder per JavaScript) hart (per Device-Liste (Fallback für "unknown" ist SmallScreen)) nach Device aufzulösen und dann einmalig das unveränderte Set von Small- oder BigScreen-Adtags (aus den bestehenden statischen Versionen) auszuspielen. Schon an dieser Stelle hätten wir einen Punkt erreicht, der besser ist als der Status Quo der meisten Portale da draußen. Man könnte jetzt im Froontend mit wenigen dynamische Breiten (zum Beispiel für den Text) Zwischen-Auflösungen besser abfedern, man könnte die Synergien von Responsive Design nützen, und man könnte darauf aufbauen (ohne die bestehenden Ad Technologie zu ändern).

Matching der AdTags und Device & Viewport per Adserver

Matching der AdTags

Noch besser wäre es natürlich das Device, die Auflösung und die tatsächliche Größe des Browserfensters im AdCall / AdTag an den Adserver weiterzugeben, der dann entscheidet, welches Werbemittel (in einem einzigen AdTag für Small- und BigScreen) ausgespielt werden soll. Dafür sind Adserver schließlich da. Der Vermarkter gewinnt damit die volle Kontrolle über seine Werbemittel zurück. Der Nachteil ist, dass der AdTag schon da sein muss. Ein responsive Fontend, das Werbung für Big- und SmallScreen, über den AdServer auflöst, müsste also alle Adtags aus der Bigscreen-Version enthalten und in der SmallScreen-Version einige davon unbespielt lassen. Das ist nicht ganz einfach, weil die Position der AdTags soweit übereinstimmen muss, dass BigScreen minus x SmallScreen ergibt (Obwohl ich glaube, dies ist meistens sowieso der Fall?).

NoGo: Leere AdCalls

Viel schlimmer ist, dass bei diesem Ansatz, wie gesagt, in allen SmallScreen Aufrufen, einige BigScreen AdTags leer bleiben werden. Das geht nicht, weil auch leere AdCalls Geld kosten. Natürlich wird es (z.B. bei Exklusiv-Belegungen) gemacht, aber SmallScreen dürfte etwa 15 % der Aufrufe ausmachen, und ich rechne mit zwei bis drei leeren AdTags. Das sind Dimensionen, die gehen leider gar nicht.

Adtags nach Breakpoints & Device / Viewport per Adserver

Die Mischung macht´s

Die ideale Lösung (auch für Frontends mit mehr als einem Breakpoint) ist (meiner Meinung nach) eine Kombination aus den oben genannten Lösungen: Zwischen Publisher und Vermarkter werden die Breakpoints des Frontends abgestimmt. Für jede Darstellung zwischen zwei Breakpoints wird ein Set von AdTags definiert, dass initial hart (Sever-seitig) ausgespielt wird. Zusätzlich werden Device, Auflösung und Größe des Browserfensters im AdCall / AdTag an den AdServer übergeben. Es gibt keine leeren AdSalls und der Vermarkter hat innerhalb der "AdTag-Sets" die volle Kontrolle über seine Werbeausspielung.

Konkreter Vorschlag in Arbeit

Für mich ist das ein guter Stand, um eine kleine Pause zu machen. Aber ich will dieses Fazit nicht so schwammig stehen lassen. In meinem nächsten Post nehme ich mir die gängigsten Auflösungen, Devices und Werbe-Formate vor und versuche einen konkreten Vorschlag zu Breakpoints, Breiten und super-stabilen AdPositionen / -Slots. Gibt es irgendjemanden, der nachvollziehen kann, was ich da schreibe? Macht das Sinn? Habe ich irgendwas Wichtiges vergessen? Ich freue mich auf Euer Feedback, Eure Anregungen und Eure Kritik.

Der Autor :

Mein Name ist Stefan Weiss. Seit 2002 entwickle und optimiere ich CMS-basierte high-performance Portale und Online Produkte. In dieser Zeit habe ich viele Aspekte der Online Produktentwicklung kennengelernt. Ich lebe und arbeite in München. In meinem UX Blog schreibe ich über die Online Produktentwicklung mit Schwerpunkten auf Design, Informationsarchitektur und Online Werbung.