Suche
Suche löschen
Suche schließen
Google-Apps
Hauptmenü

GPT-Modi und Tag-Typen

Beim Tagging Ihrer Seiten empfehlen wir die Verwendung eines asynchronen Renderings mit aktiviertem Einzelanfragemodus. Mit dieser Kombination sorgen Sie für einen optimalen Ladevorgang der Seite. Zudem haben Sie mit diesen Einstellungen die Möglichkeit, garantierte Roadblocks oder Konkurrenzausschlüsse zu nutzen.

Codierungsstil Ihrer Anzeigen-Tags

  • Asynchron: Mit diesem Tag-Typ können Sie die Seitenladezeit Ihrer Website reduzieren, da Ihr Content gleichzeitig mit der Anzeige statt nach ihr geladen wird. Die Anzeigen werden hierbei in Frames gerendert, die auf der Seite reserviert sind, bis die Anzeige eingeblendet werden kann. Wir empfehlen diese Option, da sie die nutzerfreundlichste Tag-Option ist.
  • Einzelanfragemodus: Mit dieser Option können Sie in einigen Fällen dafür sorgen, dass die Seite schneller geladen wird. Mit dieser Art von Tags werden alle Anzeigen auf einer Seite gleichzeitig statt einzeln nacheinander im Header Ihres Contents aufgerufen.
  • Synchron: Mit synchronen Tags werden Anzeigen geladen, während das Rendering des restlichen Seitencontents blockiert wird. Bei der Verwendung synchroner Tags werden die Anzeigen in einem div-Element auf der Seite bereitgestellt. Je nach Creative werden die Creatives möglicherweise schließlich in einem iFrame innerhalb des div-Elements ausgeliefert. Im Allgemeinen raten wir von der Verwendung synchroner Tags ab, allerdings gibt es auch Ausnahmen, in denen der synchrone Modus erforderlich ist.

Unten finden Sie weitere Informationen zu den unterschiedlichen GPT-Modi und Tag-Typen.

Zeichenbeschränkungen für GPT-Anzeigenanfragen

Google Publisher-Tags verwenden die HTTP-GET-Methode, um Anzeigen anzufragen, wodurch sich die Anzahl der Bytes verringert, die bei den einzelnen Anfragen weitergegeben werden können. Anzeigen-Tags mit synchronem Rendering dürfen pro Anfrage höchstens 4.096 Zeichen enthalten. Falls der Tag-Typ allerdings asynchron ist und den Wert von 4.096 Zeichen überschreitet, verwenden die GPTs automatisch die POST-Methode, wodurch sich dieser Grenzwert auf 8.192 Zeichen erhöht.*

* Die Erhöhung der Zeichenbeschränkung bei Verwendung der POST-Methode gilt nicht für Anzeigen, die in Internet Explorer 9 oder früheren Internet Explorer-Versionen gerendert werden.

Asynchrones Rendering

Asynchronous and synchronous rendering (4:21)

Was ist das asynchrone Rendering und warum wird es empfohlen?

Beim asynchronen Abruf wird der Ladevorgang der folgenden HTML-Inhalte nicht mit dem GPT-Code auf Ihrer Seite blockiert. Wenn Sie beispielsweise eine Leaderboard-Anzeige mit komplexem Content mit asynchronen Tags ausliefern, das eine gewisse Zeit zum Laden benötigt, wird der Rest der Seite geladen, während das Creative für die Anzeige vorbereitet wird. Es muss also nicht gewartet werden, bis das Creative fertig ist. Dies führt zu einer besseren Nutzererfahrung und einer gefühlt geringeren Latenz.

Das asynchrone Rendering unterstützt im Gegensatz zum synchronen Rendering die dynamische Zuordnung von Video-Companions. Weitere Informationen erhalten Sie im Artikel Companion-Tags erstellen. Zudem können Anzeigenflächen nur im asynchronen Modus über pubService.refresh(slots) aktualisiert werden. Weitere Informationen erhalten Sie im Referenzhandbuch für die Google Publisher Tag API.

Bei Verwendung von GPTs gibt es zwei Ebenen des asynchronen Ladens:

  • Asynchroner Ladevorgang der GPT-JavaScript-Bibliothek. Bei Verwendung des asynchronen Modus, der im <head>-Tag aufgerufen wird, wird der <body>-Abschnitt Ihrer Seite angezeigt, auch wenn die GPT-JavaScript-Bibliothek noch nicht geladen wurde.
  • Asynchrone Darstellung der Creatives im <body>-Abschnitt des Dokuments. Dadurch können HTML-Elemente bereits vor der Darstellung der Creatives geladen werden.

Es empfiehlt sich, sowohl die Bibliothek als auch die Creatives asynchron zu laden, um die beste Leistung zu erzielen. Diese Einstellung wird standardmäßig vom DFP Tags Generator verwendet.

SafeFrame mit GPTs verwenden

Für die Maximierung empfehlen wir statt Friendly iFrames die Verwendung von SafeFrame und Creatives, die mit SafeFrame kompatibel sind. SafeFrame wird in DFP unterstützt und ist standardmäßig aktiviert, wenn GPTs eingesetzt werden. Dadurch sind in DFP transparente und komplexe Interaktionen zwischen dem Seitencontent und den Anzeigen möglich. Dabei wird der externe Zugriff auf vertrauliche Daten verhindert und dem Publisher stehen mehr Steuerungsmöglichkeiten zur Verfügung, um zu bestimmen, welche Creatives ausgeliefert werden. Weitere Informationen zum Rendering von Creatives mit SafeFrame

Reservierungen werden standardmäßig in einem SafeFrame bereitgestellt. Sie können diese Einstellung auf Creative-Ebene aber auch deaktivieren und stattdessen Friendly iFrames nutzen.

Anzeigen im asynchronen GPT-Modus in Friendly iFrames ausliefern

Es kann vorkommen, dass einige Anzeigen nicht korrekt in den Frames dargestellt werden. Dazu gehören beispielsweise Expandable-Anzeigen, die normalerweise direkt im obersten Frame erscheinen, oder Creatives, die versuchen, direkt auf der Seite auf die DOM-Elemente und die JavaScript-Umgebung zuzugreifen. Wenn Sie außerdem ein Creative eines Drittanbieters mit einer von der Anzeigenfläche abweichenden Größe verwenden, wird die Anzeige vom iFrame abgeschnitten oder es entsteht ein zusätzlicher leerer Bereich. Sie können einige Dinge beachten, um sicherzustellen, dass Ihre Anzeigen im asynchronen GPT-Modus ordnungsgemäß dargestellt werden:

  • Zur Verwendung von nutzerfreundlichen iFrames müssen die benutzerdefinierten Vorlagen konvertiert werden. Wenden Sie sich zudem an Ihren Rich Media-Anbieter, um für iFrames geeignete Anzeigen-Tags zu entwickeln oder zu erhalten.
  • Lesen Sie die Best Practices des IAB zum Erstellen von Anzeigen mit komplexem Content, die in iFrames gerendert werden können (PDF in Englisch). Wenn Sie sich an diese Best Practices halten, sollten die meisten Rich Content-Anzeigen auch im asynchronen Modus richtig angezeigt werden.
  • Implementieren Sie eine von zwei üblichen Methoden, um zu gewährleisten, dass Expanding- und Floating-Creatives ordnungsgemäß mit iFrames funktionieren: nutzerfreundliche iFrames (empfohlen) oder iFrame-Busting-Dateien. Beide Methoden werden nachstehend beschrieben.

Nutzerfreundliche iFrames

Vorteile Nachteile
iFrame-Busting-Datei wird nicht benötigt. Werden von einer begrenzten Anzahl von Rich Content-Anbietern unterstützt.
IAB hat Empfehlungen für nutzerfreundliche iFrames herausgegeben.
Werden vom asynchronen GPT-Modus unterstützt

Der asynchrone GPT-Modus nutzt iFrames, die sich auf derselben Domain befinden wie die Hauptseite. Wenn sich die Hauptseite und der iFrame innerhalb derselben Domain befinden, handelt es sich bei dem iFrame um einen nutzerfreundlichen iFrame. Einige Rich Content-Anbieter wie DoubleClick Studio können nutzerfreundliche iFrames direkt ansteuern, d. h. ohne eine iFrame-Busting-Datei.

Innerhalb des nutzerfreundlichen iFrames wird die Anzeige mithilfe eines JavaScript-Tags geschaltet, d. h. innerhalb des iFrames. Damit das gesamte Creative sichtbar wird, muss noch der iFrame maskiert werden. Über den Anzeigencode wird ermittelt, dass ein Friendly iFrame verwendet wird. Das Creative wird dann im obersten Frame platziert. Schließlich befindet sich das Creative auf der Seite und zwar außerhalb des iFrames, in dem der Anzeigencode bereitgestellt wurde. Eine iFrame-Busting-Datei wird nicht benötigt.

Vor der Implementierung des asynchronen GPT-Modus sollten Sie zusammen mit Ihren Rich Content-Anbieter prüfen, ob er die direkte Umschreibung nutzerfreundlicher iFrames unterstützt. Wenn der Anbieter diese Variante nicht unterstützt, kann eine iFrame-Busting-Datei mit nutzerfreundlichen iFrames verwendet werden, die nachstehend beschrieben wird.

iFrame-Busting-Datei

Vorteile Nachteile
Wird von den meisten Rich Content-Anbietern unterstützt Der Publisher muss eine iFrame-Busting-Datei für jeden Rich Content-Anbieter hosten.
Werden vom asynchronen GPT-Modus unterstützt

Wenn der Rich Content-Anbieter, z. B. Eyeblaster, Pointroll oder DoubleClick Studio, keine nutzerfreundlichen iFrames unterstützt, besteht eine gängige Problemumgehung darin, dass Ihnen die einzelnen Anbieter eine iFrame-Busting-Datei im HTML-Format zur Verfügung stellen. Diese HTML-Datei muss auf Ihrem Server abgelegt werden, in der Regel auf demselben, auf dem auch Ihre Website liegt. Wenn sich die Datei auf dem Server befindet, kann sie grundsätzlich für alle Anzeigen von diesem Anbieter von komplexem Content verwendet werden.

Bei dieser Implementierung befindet sich das Creative im obersten Frame und kann auf den Seitencontent zugreifen. Einige Publisher sehen dadurch die Sicherheit oder den Datenschutz gefährdet.

Bei Schaltung der Anzeige innerhalb eines iFrames wird ein zusätzlicher iFrame erstellt. Über den zusätzlichen iFrame wird die iFrame-Busting-Datei aufgerufen. Die Anzeige nutzt dann die iFrame-Busting-Datei, um das Creative im obersten Frame zu platzieren. Schließlich befindet sich das Creative auf der Seite und zwar außerhalb des iFrames, in dem der Anzeigencode bereitgestellt wurde.

Die meisten Anbieter von komplexem Content unterstützen diese Problemumgehung. Fragen Sie bei Ihrem Anbieter nach.

Einzelanfrage-Architektur

Single request architecture (5:54)Was versteht man unter dem Einzelanfragemodus und warum wird er empfohlen?

Im Einzelanfragemodus werden alle im Header definierten Anzeigen beim ersten Aufruf der Funktion display() geladen, statt dass jede Anzeige einzeln inline mit der Anzeigenfläche angefordert wird. Wir empfehlen den Einzelanfragemodus, weil Sie durch die Zusammenfassung aller Anzeigenaufrufe in einer einzigen Anfrage Roadblocks garantieren können, also die gemeinsame Auslieferung aller Creatives einer Werbebuchung auf derselben Seite. Zudem kann sich die Ladeleistung Ihrer Seite verbessern, wenn weniger Anfragen gesendet werden.

Wenn Sie den Einzelanfragemodus aktiviert haben, können Sie auch garantierte Roadblocks für Ihr Netzwerk aktivieren. Mit dieser Funktion wird die Einstellung Creatives anzeigen in Ihren Werbebuchungen optimiert, da Sie nun auch "Alle" auswählen können. Wenn Sie "Alle" auswählen, schaltet DFP die Werbebuchung nur dann, wenn eine Anzeigenanfrage genügend Anzeigenflächen enthält, um alle Creatives dieser Werbebuchung darzustellen. Sie können Garantierte Roadblocks aktivieren, indem Sie auf den Tab Admin klicken und dann in der Spalte links Funktionen auswählen.

Sie können auch Master-/Companion-Roadblocks einrichten, die garantieren, dass alle Creatives gemeinsam geschaltet werden oder dass zumindest ein Companion-Creative stets mit dem Master-Creative geschaltet wird.

Diese Funktionen sind nur auf Seiten nutzbar, die mit Google Publisher-Tags bei aktiviertem Einzelanfragemodus versehen sind.

Sehen Sie sich unsere Beispiel-Tags an, wenn Sie erfahren möchten, wie Sie den Einzelanfragemodus aktivieren.

Fälle, in denen die Verwendung des Einzelanfragemodus eventuell nicht sinnvoll ist

Alle DFP-Creative- und Werbebuchungstypen werden vom Einzelanfragemodus unterstützt. Dynamische Anzeigen von DoubleClick Rich Media sind nicht mit dem Einzelanfragemodus kompatibel.

Synchrones Rendering

Wir raten von der Verwendung synchroner Tags ab, weil sie verhindern, dass der Content der Seite vor der Anzeige geladen wird. Dies kann zu einer erhöhten Latenz und einer schlechten Nutzererfahrung führen. Anders als bei Verwendung asynchroner Tags wird beim synchronen Rendering zudem die dynamische Zuordnung von Video-Companions sowie die Möglichkeit unterstützt, Anzeigenflächen mithilfe von pubService.refresh(slots) zu aktualisieren.

Bei Nutzern mit langsamen Verbindungen wie 2G kann das dynamische Einfügen externer Skripte über document.write() dazu führen, dass sich das Anzeigen des Contents der Hauptseite mehrere Sekunden verzögert. Dies ist ein weiterer Grund, warum wir statt eines synchronen Renderings die Verwendung asynchroner Tags empfehlen. Weitere Informationen zu den Problemen mit 2G und document.write()

In bestimmten Fällen sind synchrone Tags aber dennoch notwendig:

  • Bei Prestitial-Anzeigen, die verwendet werden, um eine Anzeige vor dem restlichen Seitencontent zu laden. Mit diesem Anzeigentyp wird garantiert, dass die Anzeige vor dem gesamten anderen Content der Seite erscheint. Wir raten allerdings von der Verwendung von Prestitials ab und empfehlen stattdessen die Verwendung von Interstitials. Diese können asynchron geladen werden und werden dann zwischen den Seitennavigationen ausgeliefert, sodass der Nutzer nicht bei seinen Aktivitäten unterbrochen wird.
  • Bei Seiten mit Anzeigenanfragen mit mehreren Größen, bei denen der restliche Seitencontent erst geladen wird, wenn die Größe des Creatives feststeht, das zurückgegeben wird
  • Bei Rücksendungs-Tags wird immer der synchrone Modus verwendet. Sie sind allerdings nie die primären Ad-Server-Tags auf einer Seite, sodass sie nie verhindern sollten, dass der Seitencontent geladen wird.
Kann ich auf meiner Website oder auf einer Seite sowohl asynchrone als auch synchrone Tags verwenden?

Die Kombination von asynchronen und synchronen Anzeigen-Tags auf derselben Webseite ist NICHT empfehlenswert. Sie können auf einigen Seiten Ihrer Website asynchrone und auf anderen Seiten synchrone Tags verwenden.

Hier sehen Sie einige Beispiele für synchrone und asynchrone Tags.

War dieser Artikel hilfreich?
Wie können wir die Seite verbessern?