Serverseitige Implementierung

Diese Funktion steht nur für Netzwerke mit eigenem Account Manager von Google zur Verfügung und ist möglicherweise nicht für Ihr Netzwerk aktiviert. Weitere Informationen erhalten Sie von Ihrem Account Manager. Falls Sie keinen Account Manager haben, steht diese Funktion nicht für Ihr Netzwerk zur Verfügung.

Möglicherweise möchten Sie Anzeigenanfragen über Server von Drittanbietern oder eigene Server, über Anbieter für das dynamische Anzeigen-Stitching oder über Anbieter für das serverseitige Einfügen von Anzeigen an Google Ad Manager senden. Gehen Sie wie im Folgenden beschrieben vor, um serverseitige Anzeigenanfragen an Google Ad Manager zu senden und genaue Berichte zu Impressionen, Klicks und zugeordneten Conversions zu erstellen.

1. Anleitung für die Integration an serverseitige Technologiepartner senden

Damit serverseitige Aufrufe von Servern von Drittanbietern (zum Beispiel von Anbietern für das dynamische Einfügen von Anzeigen oder serverseitigen Stitching-Anbietern) in Google Ad Manager authentifiziert werden, muss eine Verbindung zu den Google Ad Manager-Servern hergestellt werden. Dazu benötigen Sie ein SSL-Zertifikat, das von Google Ad Manager ausgestellt wird.

Bitten Sie Ihren serverseitigen Technologiepartner die auf dieser Seite beschriebenen Schritte auszuführen.

Bei serverseitigen Anzeigenanfragen in Campaign Manager 360 muss außerdem ein SSL-Zertifikat installiert werden. Der serverseitige Technologiepartner muss die Anleitung für die Integration in Campaign Manager 360 beachten, wenn Video-Creatives über serverseitige Aufrufe angefordert werden.

2. Serverseitiges Anzeigen-Tag generieren

Publisher, die Anzeigenanfragen über Server von Drittanbietern an Google Ad Manager senden, müssen ein Video-Tag erzeugen. Dafür haben sie zwei Möglichkeiten:

In der Google Ad Manager-Benutzeroberfläche

Sehen Sie sich an, wie Sie ein Video-Tag in Ad Manager erstellen. 

URL für das Videoanzeigen-Tag manuell einrichten

Sehen Sie sich an, welche erforderlichen und optionalen URL-Parameter für VAST-Tags für Videoanzeigen zulässig sind, und lesen Sie die zusätzlichen Anforderungen für das Erfassen von Aufrufen, Conversions und Klicks.

URLs von serverseitigen Anzeigen-Tags, die auf /gampad/ads oder /gampad/live/ads verweisen, müssen serverside.doubleclick.net nutzen (und nicht pubads.g.doubleclick.net). Unter Umständen müssen Sie die URLs Ihrer Anzeigen-Tags manuell anpassen, damit die Anforderungen erfüllt werden.

3. Serverseitige Anzeigenanfrage generieren

Sobald das Anzeigen-Tag erstellt wurde, muss der Technologiepartner, der die serverseitige Anzeigenanfrage an Google Ad Manager sendet, folgende Schritte ausführen:

• Übergeben Sie in der Google Ad Manager-Anfrage die serverseitige Stitching-Quelle als Wert des Parameters ssss.

  Beim Wert des Parameters ssss wird zwischen Groß- und Kleinschreibung unterschieden. Wenn dem Publisher der Wert examplesource zugewiesen wird, ist die Übergabe von ssss=examplesource korrekt, während ssss=ExampleSource nicht korrekt ist.
  Anbieter für Video-Stitching-Technologie, die eine Server-zu-Server-Integration mit Google nutzen, erhalten den entsprechenden Wert von Google und können ihn dann an Sie weitergeben. Wenden Sie sich an Ihren Google Account Manager, wenn Sie Fragen zum Wert für diesen Parameter haben.

• Die IP-Adresse des Clientgeräts muss dynamisch weitergegeben werden. Dazu muss entweder der Header X-Forwarded-For oder ein Wert für den Parameter ip in der Ad Manager-Anfrage enthalten sein. Eine der genannten Methoden muss genutzt werden, aber nicht beide.

  Wird die vollständige IP-Adresse des Clientgeräts nicht mit einer der genannten Methoden korrekt weitergegeben, führt das unter Umständen zu Problemen bei der Anzeigenbereitstellung.

• Die vollständigen HTTP-Header des Clientgeräts/der Clientumgebung müssen weitergegeben werden. Dazu gehören Folgende:

  • User-Agent: Das sollte der gesamte unveränderte String sein, der vom Browser des Nutzers ausgegeben wird.  Bei mobilen Anzeigen, die in WebViews oder nativen mobilen Browsern gerendert werden, muss der User-Agent übergeben werden, der von der mobilen Plattform für WebViews oder dem Browser verwendet wird (z. B. bei iOS-Geräten der User-Agent der Safari-Version für Mobilgeräte). Wenn Anzeigen in der nativen mobilen App gerendert werden, muss der User-Agent die Richtlinien für mobile Apps einhalten.

    User-Agent-Strings, die über die URL-Verbindungsklassen der mobilen Plattform generiert werden, sind ungültig, zum Beispiel „Dalvik“ bei Android- oder „CFNetwork“ bei iOS-Geräten.

  • Accept-Encoding: Damit Ad Manager die Antworten komprimieren kann, sollte der Wert auf gzip,deflate festgelegt werden. Das ist wichtig, weil unkomprimierte Antworten 20-mal größer sind.

Der Cookie-Header sollte als einziger Header nicht in der serverseitigen Anzeigenanfrage weitergeleitet werden.

Zusätzliche Anforderungen für das Erfassen von Aufrufen, Conversions und Klicks

Wir empfehlen, alle Aufrufe und Conversions über den Client statt über den Server zu senden. Publisher sollten Impressions- und Conversion-Pings ebenfalls über den Client senden. In einigen bestimmten Fällen ist es für Publisher möglich, Aufrufe, Conversions und Klicks über den Server zu erfassen.

Wenn es aus technischer Sicht erforderlich ist, Aufrufe, Conversions und Klicks vom Server zu senden, muss die erste Anzeigenanfrage aus der serverseitigen Umgebung ipe=ssb enthalten.

Nachfolgend finden Sie weitere empfohlene Best Practices, mit denen sich dazu beitragen lässt, dass Ad Manager Anzeigenanfragen und Conversions aus Implementierungen verarbeiten kann, die serverseitig gemessen werden:

• Senden Sie alle Aufruf-, Conversion- und Klickereignisse in der Reihenfolge, in der sie auftreten. Übergeben Sie beispielsweise kein Klickereignis vor einem Impressionsereignis, weil ein Nutzer keinen Klick ausführen kann, bevor die Impression ausgelöst und die Anzeige gerendert wurde.
• Senden Sie Ereignisse nicht im Batch, sondern genau dann, wenn das Ereignis registriert wurde.

Dieser Traffic ist nur für die Reservierungsnachfrage gültig und wird nicht vom MRC akkreditiert, es sei denn, Sie haben im Rahmen einer Betaversion eine entsprechende Vereinbarung getroffen.