Videoanzeigen

In diesem Leitfaden werden die Integrationsanforderungen, die Konfiguration und die relevanten Felder beschrieben, die Sie beim Abgeben von Geboten für Videoinventar verwenden können.

Google unterstützt In-Stream-, native und Interstitial-Videoanzeigen, die als einzelne Anzeigenmöglichkeiten oder dynamische Videoanzeigengruppen dargestellt werden. Dynamische Pods sind Gruppen von Videoanzeigen, die nacheinander ausgeliefert werden. Die maximale Dauer des Pods wird in ein oder mehrere Videos mit unterschiedlicher Länge aufgeteilt. Weitere Informationen zu diesen Formaten finden Sie in den Anleitungen für die Anzeigenformate Nativ und Interstitial.

Anforderungen an Käufer

RTB-Protokoll

In diesem Leitfaden wird im Allgemeinen auf das Protobuf-Format verwiesen. Feldnamen und ‑pfade sind jedoch zwischen dem Protobuf- und dem JSON-Format identisch, sofern nicht anders angegeben.

Das OpenRTB-Proto und die Google-spezifischen OpenRTB-Erweiterungen finden Sie auf der Seite Protos und Referenzdaten. Weitere Informationen zum Entwickeln eines Bieters finden Sie unter Anfrage verarbeiten und Antwort erstellen.

Creative-Überprüfung

Google empfiehlt, Creatives zur Genehmigung einzureichen, bevor Sie Gebote dafür abgeben. Sie können den Überprüfungsprozess mit der Creatives-Ressource der Real-Time Bidding API starten.

Pre-Targeting-Konfiguration

Damit Sie Videoinventar erhalten, muss in Ihrem Authorized Buyers-Konto eine Pre-Targeting-Konfiguration erstellt werden, die Videoinventar enthält.

Makros

Sie können Makros entweder im Video-URL-Link oder im VAST-XML-Code angeben, der in BidResponse.seatbid.bid.adm definiert ist. Wenn Sie eine Video-URL angeben, können Sie auch Makros im verknüpften VAST-XML-Dokument platzieren. Die folgenden Makros werden für Video-Creatives unterstützt:

  • %%CACHEBUSTER%%
  • %%WINNING_PRICE%%
  • %%SITE%%

Klick-Makros wie CLICK_URL_ESC werden nicht unterstützt, da Authorized Buyers seine Klick-Tracker in einen VAST-Wrapper einfügt. Weitere Informationen zu unterstützten Makros finden Sie unter Makros angeben.

Details zu Zusatzinformationen

Mit dem Feld BidRequest.imp.video von OpenRTB können Sie ermitteln, ob eine eingehende Gebotsanfrage für In-Stream- oder Interstitial-Videoinventar gilt, und zusätzliche videospezifische Informationen zur Anfrage abrufen. Außerdem können Sie für natives Anzeigeninventar BidRequest.imp.native.{request/request_native}.assets.video für ähnliche videospezifische Informationen verwenden.

BidRequest.{app/site}.content.producer.domain

Die URL der Seite, auf der die Videoinhalte beschrieben werden, ohne Parameter. Der Verlag oder Webpublisher sendet diese URL an Google. Beispiel:

http://www.publisher.com/watchpagelink
banner.vcm
Wenn der Wert auf true festgelegt ist, kann die Companion-Anzeige nach der Wiedergabe der Videoanzeige als Endcard (Infokarte) im Videofeld ausgewählt werden. Andernfalls wird die Companion-Anzeige nicht als Endbanner gerendert.
BidRequest.imp.rwdd
Wenn auf true festgelegt, erhält der Nutzer eine Prämie für das Ansehen der Videoanzeige. Typische Prämien sind beispielsweise das kostenlose Lesen eines zusätzlichen Artikels, ein Extraleben in einem Spiel oder eine gesponserte Musikwiedergabe ohne Anzeigen.
BidRequest.imp.video.maxduration

Die maximal zulässige Dauer in Sekunden für jede einzelne Anzeige, die in der Gebotsantwort enthalten ist. Wenn nicht festgelegt, gibt es keine maximale Dauer. Wenn BidRequest.imp.video.skip gleich true ist, kann sich das Verhalten ändern. Weitere Informationen finden Sie unter Maximale Dauer überspringbarer Videos.

BidRequest.imp.video.maxseq

Die maximale Anzahl von Anzeigen, die in einem dynamischen Videoanzeigen-Pod ausgeliefert werden können. Wenn poddur festgelegt ist, aber maxseq nicht festgelegt oder 0 ist, gibt es keine Einschränkung hinsichtlich der Anzahl der Anzeigen, die in einem Video-Pod ausgeliefert werden können. Google unterstützt nur dynamische Pods.

Die tatsächliche Anzahl der ausgelieferten Videoanzeigen kann kleiner oder gleich diesem Wert sein, darf ihn aber nicht überschreiten.

BidRequest.imp.video.minduration
Die Mindestdauer in Sekunden für jede einzelne Anzeige, die in der Gebotsantwort enthalten ist. Wenn nicht festgelegt, gibt es keine Mindestdauer.
BidRequest.imp.video.plcmt
Gibt an, wo das Video wiedergegeben wird.
PLCMT_UNKNOWN Das Placement ist unbekannt oder nicht bestimmbar.
PLCMT_INSTREAM Pre-Roll-, Mid-Roll- und Post-Roll-Anzeigen, die vor, während oder nach dem Streaming von Videoinhalten abgespielt werden, die der Nutzer angefordert hat. Bei In-Stream-Videoanzeigen muss der Ton beim Start des Players standardmäßig aktiviert sein oder es muss eine eindeutige Nutzerabsicht vorliegen, sich den Videocontent anzusehen. Auch wenn sich um den Player herum andere Inhalte befinden, muss der Videocontent der ausschlaggebende Grund für den Aufruf des Nutzers sein. Es sollte der primäre Inhalt auf der Seite und der einzige sichtbare Videoplayer sein, der bei der Wiedergabe Audio ausgeben kann. Wenn der Player in einen unverankerten/fixierten Player umgewandelt wird, sollten bei nachfolgenden Anzeigenaufrufen die aktualisierte Playergröße korrekt angegeben werden.
PLCMT_ACCOMPANYING_CONTENT Pre-Roll-, Mid-Roll- und Post-Roll-Anzeigen, die vor, während oder nach Streaming-Videoinhalten ausgeliefert werden. Der Videoplayer wird vor, zwischen oder nach Textabsätzen oder grafischen Inhalten geladen und wiedergegeben. Die Wiedergabe beginnt erst, wenn der Player in den sichtbaren Bereich gelangt. Die Wiedergabe von begleitendem Videocontent sollte erst beginnen, wenn der Content in den Darstellungsbereich kommt. Beim Scrollen von der Seite kann der Player in einen Floating- oder Sticky-Player umgewandelt werden.
PLCMT_INTERSTITIAL Videoanzeigen, die ohne Videocontent ausgeliefert werden. Während der Wiedergabe muss sie den Schwerpunkt der Seite bilden und den Großteil des Darstellungsbereichs einnehmen. Sie darf nicht aus dem Blickfeld gescrollt werden. Das kann in Placements wie In-App-Videos oder Diashows erfolgen.
PLCMT_NO_CONTENT_STANDALONE Videoanzeigen, die ohne Streaming-Videocontent abgespielt werden. Das kann in Placements wie Diashows, nativen Feeds, In-Content- oder Sticky-/Floating-Anzeigen erfolgen.
BidRequest.imp.video.playbackmethod
Beschreibt, wie die Videoanzeige wiedergegeben wird. Die Wiedergabemethode wird anhand der besten verfügbaren Messung als Autoplay oder Click-to-Play bestimmt.
AUTO_PLAY_SOUND_ON Wird beim Laden der Seite mit aktiviertem Ton gestartet.
AUTO_PLAY_SOUND_OFF Wird beim Laden der Seite ohne Ton gestartet.
CLICK_TO_PLAY Wird durch Klicken mit aktiviertem Ton ausgelöst.
MOUSE_OVER Wird bei Mouseover mit Ton ausgelöst.
ENTER_SOUND_ON Wird beim Aufrufen des Darstellungsbereichs mit aktiviertem Ton ausgelöst.
ENTER_SOUND_OFF Wird beim Einblenden des Darstellungsbereichs mit standardmäßig ausgeschaltetem Ton ausgelöst.
BidRequest.imp.video.skip
Wenn true, bedeutet das, dass der Player das Überspringen des Videos zulässt oder dass überspringbare Anzeigen zulässig sind. Andernfalls bedeutet das, dass überspringbare Anzeigen nicht zulässig sind.
BidRequest.imp.video.startdelay

Ein Wert von 0 bedeutet Pre-Roll, -1 bedeutet Mid-Roll und -2 bedeutet Post-Roll.

Jeder andere positive Wert ist die Zeit in Sekunden vom Beginn des Videos bis zu dem Zeitpunkt, an dem die Anzeige ausgeliefert wird.

BidRequest.imp.video.durfloors und BidRequest.imp.audio.durfloors

Ein Array von DurFloors-Objekten, das die jeweiligen Mindestpreise für Video- oder Audio-Creatives mit unterschiedlichen Laufzeiten angibt, mit denen der Käufer Gebote abgeben kann.

Das folgende Beispiel zeigt, wie eine von Google angegebene durfloors aussehen würde:

  1. {"maxdur": 16, "bidfloor": 5} steht für (0, 16) Sekunden bei $5.
  2. {"mindur": 16, "maxdur": 31, "bidfloor": 10}, was [16, 31) Sekunden bei $10 entspricht.
  3. {"mindur": 31, "bidfloor": 20} steht für [31, inf) Sekunden bei $20.

Diese Signale sind nicht nur für Video-Creatives relevant, sondern für Gebotsabgabe-Tools besonders wertvoll:

BidRequest.device.ifa
Dieses Feld ist eine 36 Zeichen lange UUID, die nur bei Verwendung von SSL festgelegt wird und nicht gehasht ist. Es handelt sich um die unverschlüsselte Version von BidRequest.device.dpidm5. Für iOS-Geräte enthält sie den Identifier for Advertisers (IDFA) in Großbuchstaben. Bei Android-Geräten enthält sie die Android-Kennung (ADID) in Kleinbuchstaben. Für Geräte für internetfähige Fernseher enthält sie die eindeutigen IDs (z. B. die RIDA von Roku).
BidRequest.device.devicetype
Gibt den Gerätetyp an.
MOBILE Ein veralteter Alias für HIGHEND_PHONE oder TABLET.
PERSONAL_COMPUTER Umfasst Computer und Laptops.
CONNECTED_TV umfasst sowohl vernetzte Fernseher (d. h. Smart-TVs) als auch vernetzte Geräte (z. B. Roku, Apple TV usw.).
HIGHEND_PHONE Auch High-End-Smartphones sind enthalten.
TABLET Schließt Tablets ein.
CONNECTED_DEVICE Schließt spezielle Gaming-Geräte ein.
SET_TOP_BOX Auch Set-Top-Boxen sind enthalten.
OOH_DEVICE Umfasst Geräte für Außenwerbung, z. B. digitale Billboards.
BidRequest.device.make
Gibt die Marke des Geräts an, z. B. Nokia oder Samsung.
BidRequest.device.model
Gibt das genaue Modell des Geräts an, z. B. N70 oder Galaxy, sofern verfügbar. Andernfalls enthält es ein generisches Modell wie „iphone“ oder „ipad“.
BidRequest.imp.metric
Wenn Metric.type auf completion_rate festgelegt ist, ist Metric.value ein Bruch im Bereich [0.0, 1.0], der die bisherige Abschlussrate für Videoanzeigen darstellt, die in der Anzeigenfläche ausgeliefert wurden. Der Standardwert -1.0 gibt an, dass keine Verlaufsdaten zur Abschlussrate verfügbar sind.
BidRequest.imp.video.poddur
Die Dauer in Sekunden, die Sie für einen dynamischen Videoanzeigen-Pod festlegen können. Dieses Feld bezieht sich auf die Länge der gesamten Werbeunterbrechung. Wenn nicht festgelegt, ist die Anzeigenfläche nicht Teil eines Pods.

Die Video-Gebotsanfrage enthält auch Informationen zum Inventar, z. B. zur Branche, zu zulässigen Anbietern und zum Channel. Alle anderen vorhandenen Felder in der Gebotsanfrage gelten auch für Video.

Die Felder „Breite“ und „Höhe“ in der AdSlot-Nachricht einer Videoanfrage entsprechen der Größe des Videoplayer-Anzeigenfelds.

BidRequest.imp.ext.allowed_vendor_type
Die zulässigen Anbieter. Eine Liste der IDs finden Sie in der technischen Dokumentation in der Datei vendors.txt. Beispiel: 309 = DFA Video Unit.
BidRequest.imp.video.mimes
Eine Zulassungsliste mit den unterstützten MIME-Typen für Inhalte für Anzeigen, die als Reaktion auf die Gebotsanfrage ausgeliefert werden, z. B. „video/mp4“. Die Gebotsantwort muss mindestens eine der Technologien unterstützen.
BidRequest.imp.video.protocols
Beschreibt die vom Publisher unterstützten VAST-Versionen für Videoanzeigenanfragen. Enthält ein Array von Protocol-Enum-Werten, darunter: VAST_2_0, VAST_3_0, VAST_2_0_WRAPPER, VAST_3_0_WRAPPER, VAST_4_0, VAST_4_0_WRAPPER und mehr.
BidRequest.imp.video.companionad
Dieses Feld enthält ein Array mit Banner-Objekten, die Begleit-Anzeigen darstellen, sofern verfügbar.
BidRequest.site.page

Die URL der Wiedergabeseite des Videos oder die URL der Seite, auf der das Video eingebettet ist. Beispiel:

http://www.publisher.com/watchpagelink

Bei der Antwort auf eine Videoanfrage sollte der Bieter eine VAST-Weiterleitungs-URL oder VAST-XML im Feld BidResponse.seatbid.bid.adm zurückgeben. Die Gebotsantwort sollte auch die richtige Deklaration für die Videoanzeige enthalten. Hier ist ein Auszug aus einer korrekten Gebotsantwort für Video: 

id: "n40G42d551UX18627ao8lt"
seatbid {
  bid {
    id: "17u6BnD62h88r5q7066"
    impid: "1"
    price: 0.797848
    adm: "https://video.test.com/ads?id=123456&wprice=%%WINNING_PRICE%%"
    adomain: "google.com"
    crid: "test_creative_id_987914"
    w: 320
    h: 480
    cattax: GOOGLE_CATEGORIES
    [com.google.doubleclick.bid] {
      attribute: 47
      attribute: 50
      billing_id: 55383762512
      skadn {
        version: "4.0"
        network: "306el65O"
        itunesitem: "832461214"
        sourceapp: "977150768"
        fidelities {
          fidelity: VIEW_THROUGH_ADS
          nonce: "0054e0b9-0b53-4426-99dd-a1eefeb45565"
          timestamp: "1757329316673"
          signature: "oE3Ek8347oZV1Yl1J42G2c88BSKr2dqEbiOK2S4ni7NVDh3v128NN0hlzWK5aX96ecV1504E9k288i0t0wGX73P317812WE7"
        }
        fidelities {
          fidelity: STOREKIT_RENDERED_ADS
          nonce: "0054e0b9-0b53-4426-99dd-a1eefeb45565"
          timestamp: "1757329316673"
          signature: "b1GqXA4v889p842512GQ1p3249q5VmPt1335f1H1zdK92fq24j7a7ml419W7u8B7rhhH97s507f2251923oWi89XF1voZv4b"
        }
        sourceidentifier: "8396"
      }
      app_promotion_type: INSTALLS
      clickurl: "google.com"
    }
  }
}
[com.google.doubleclick.bid_response] {
  processing_time_ms: 20
}

Die wichtigen Felder in einer Videobietantwort sind:

BidResponse.seatbid.bid.ext.attribute
Attribute für die Anzeigen, die über das Snippet ausgeliefert werden können. Eine Liste der IDs finden Sie in der Datei buyer-declarable-creative-attributes.txt. Wir prüfen, ob eines dieser Attribute mit den Attributen übereinstimmt, die vom Publisher in der Gebotsanfrage nicht zugelassen wurden. Wenn Sie beispielsweise festlegen, ob eines der Felder 30 enthält, würde dies darauf hinweisen, dass für das Rendern der Anzeige VPAID-Unterstützung erforderlich ist.
BidResponse.seatbid.bid.adm

Bei Videoanzeigen ist das die VAST-Weiterleitungs-URL der Videoanzeige. Beispiel:

http://ad.doubleclick.net/pfadx/N270.132652.1516607168321/B3442378.3;dcadv=1379578;sz=0x0;ord=79879;dcmt=text/xml

Alternativ kann es sich um reines VAST-XML handeln.

Beispiel für Gebotsanfragen und ‑antworten

Videoformate

So können Käufer Videos einfügen

In den folgenden Tabellen sehen Sie, wie Käufer Videos in ihre Creatives einbinden können und in welche Placements sie für das Web bzw. für mobile Apps ausgeliefert werden können.

Web

Video-Creative In‑Stream (alle) In-Feed-/Artikelanzeigen Native In-Feed-/In-Article-Anzeigen Interstitial In-Banner

VPAID + VAST

 

VAST

 

MRAID + JS

 

 

 

 

 

Benutzerdefiniertes JS

 

Nativ + VAST

 

Mobile App

Video-Creative In‑Stream (alle) In-Feed-/Artikelanzeigen Native In-Feed-/In-Article-Anzeigen Interstitial In-Banner

VPAID + VAST

 

 

 

 

 

VAST

MRAID + JS

Benutzerdefiniertes JS

Nativ + VAST

Schlüssel: Format/Technologie nicht verfügbar

Video-Creative in diesem Placement akzeptiert, vorbehaltlich der Publisher-Blockierungen

Video-Creative ist für dieses Placement nicht verfügbar

Empfohlene OpenRTB-Signale

In den folgenden Tabellen sind die empfohlenen OpenRTB-Signale für alle Videoformate für Websites für Computer und das mobile Web sowie für mobile Apps aufgeführt.

Computer und mobiles Web

Videoformat Empfohlene Signale (nur videorelevante Signale) Zugehörige Signale (nur videorelevante Signale)

Instream (VPAID)

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM   &

In-Stream (kein VPAID)

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM    &
video.api = 1 VPAID 1.0 or 2:VPAID 2.0

Nicht In-Stream

VIDEO-Objekt vorhanden

video.linearity: linear
Die Platzierung hängt von der tatsächlichen
Platzierung ab. Die Werte sind unten aufgeführt.
Video.startdelay = 0

In-Feed

VIDEO-Objekt vorhanden   &
video.placement = IN-FEED

In-Article

VIDEO-Objekt vorhanden   &
video.placement = IN-ARTICLE

Nativ

NATIVE-Objekt vorhanden und

In-Banner

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (vom Nutzer initiiert)

Mobile App

Videoformat Details zur Gebotsanfrage (nur die videorelevanten Details)

In-Stream

VIDEO-Objekt vorhanden   &
video.placement = INSTREAM    &

video.api = 1 VPAID 1.0 oder 2: VPAID 2.0

Nicht In-Stream

VIDEO-Objekt vorhanden

video.linearity: linear
Die Platzierung hängt von der tatsächlichen
Platzierung ab. Die Werte sind unten aufgeführt.
Video.startdelay = 0

In-Feed

VIDEO-Objekt vorhanden   &
video.placement = IN-FEED

In-Article

VIDEO-Objekt vorhanden   &
video.placement = IN-ARTICLE

Nativ

NATIVE-Objekt vorhanden und

Interstitial (VAST)

VIDEO-Objekt vorhanden   &
video.placement = INTERSTITIAL

Interstitial (ohne VAST)

VIDEO-Objekt vorhanden   &
video.placement = INTERSTITIAL

Gefiltert

In-Banner (MRAID)

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (nutzerinitiiert)

In-Banner

(kein MRAID)

Videoobjekt nicht vorhanden &
banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe) &
banner.battr ≠ 7 In-Banner-Video (nutzerinitiiert)

So können Publisher Videos zulassen oder nicht zulassen

In der folgenden Tabelle sehen Sie, wie Publisher Videos in ihren Placements zulassen oder nicht zulassen können.

Option für die Veröffentlichung Anwendbare Formate In der Gebotsanfrage beschrieben als

Instream-Video und Einheit angeben

In‑Stream (alle)

Videoobjekt vorhanden &
video.placement = INSTREAM

VPAID aktivieren

In-Stream-Web

Videoobjekt vorhanden &
video.api = 1 (VPAID 1.0) oder 2 (VPAID 2.0)

IBV aktivieren

In-Banner

Interstitial

banner.battr ≠ 6 In-Banner-Video (automatische Wiedergabe)7 und/oder In-Banner-Video (nutzerinitiiert)

Aktivieren Sie (Anleitung).

In-Feed

In-Article

Videoobjekt vorhanden &
video.placement = IN-FEED oder IN-ARTICLE

Non-Instream-Anzeigen aktivieren (Anleitung)

Nativ

Natives Objekt vorhanden

Video-Interstitial blockieren

Interstitial-App

VIDEO-Objekt nicht vorhanden

Sonderfälle

# Fallbeschreibung Kommentare Gebotsanfrage

1

Verzögertes benutzerdefiniertes Schließen mit MRAID

Bei Interstitials kann durch Schließen der Anzeige eine Benachrichtigung an den Käufer gesendet werden, auch wenn er keinen benutzerdefinierten Schließen-Button verwendet hat.


Das von Authorized Buyers angewendete „X“ wird immer über einem benutzerdefinierten Schließen-Button angezeigt, auch wenn dieser nach 5 Sekunden darunter erscheint.

Glossar

Glossar zu Video-Begriffen in Authorized Buyers

Relevante Felder für In-Stream- und Nicht-In-Stream-Formate

Weitere Informationen finden Sie unter OpenRTB 2.5 (ab Seite 47).

BidRequest.Video.
Placement
In-Stream mWeb

1: In-Stream
2: In-Banner

mApp

1: In-Stream
2: In-Banner
Nicht In-Stream mApp Interstitial

5: Interstitial

Native

3: In-Article
4: In-Feed

Rewarded

rwdd: bool
linearity

Gibt an, ob die Impression linear oder nicht linear sein muss usw. Wenn keine angegeben sind, wird davon ausgegangen, dass alle zulässig sind.

In-Stream mWeb

1: LINEAR (In-Stream)

mApp

1: LINEAR (In-Stream)
Nicht In-Stream mApp Interstitial

2: INTERSTITIAL

Native

3: IN_FEED
5: IN_ARTICLE
videoad_start_delay
In-Stream mWeb

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL

mApp

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL
Nicht In-Stream Rewarded

>0: start delay in seconds
 0: PRE_ROLL
-1: GENERIC_MID_ROLL
-2: GENERIC_POST_ROLL

Quelle des Gebotsanfragewerts

OpenRTB-Objekt
Felder Authorized Buyers
/Exchange
Bidding
Non-Instream		 Beispielwerte Wer legt sie fest?
/Woher kommt dieser Wert?
Objekt
Video Mimes Ja ["application/javascript",
"video/mp4"]",		 Google
minduration Nein Vom Publisher konfiguriert
maxduration Ja Vom Publisher konfiguriert
playbackmet
hod		 Ja [6] Normalerweise Publisher
Konfiguriert
API (MRAID) Ja [1,2] Google
Protokolle Ja [2,3,5,6,7,8] Google
Linearität Ja [1] Google
placement Ja [1] Google
Playerbreite Ja 400,400,300 Google
Playerhöhe Ja 225.300.153 Google
Startverzögerung Ja 0 Google, Standard 5 Sek.
Überspringen Ja 1 Publisher/Google
– für Interstitials => Google
– für In-Stream-Anzeigen => Publisher
entscheidet, ob überspringbare, nicht überspringbare oder beide Arten von Anzeigen zulässig sind.

Anzeigen mit Prämie, immer nicht überspringbar;
Minimale Bitrate Nein Google
Maximale Bitrate Nein Google
pos Ja 1 Google
Gerät
Px-Verhältnis Ja 1 Google
Impression
Sicher Ja 1 Google
standardmäßig auf „true“
gesetzt, da das Ad-Tag immer
sicher ist