Antwort erstellen

Nachdem Ihre Anwendung die Gebotsanfrage von Google verarbeitet hat, muss sie eine Antwort erstellen und senden. In dieser Anleitung wird erläutert, wie Sie Ihre Anwendung für das Erstellen der Antwort codieren.

BidResponse-Nachricht erstellen

Authorized Buyers sendet die BidRequest als Nachrichtentext eines HTTP-POST. Für die von Ihrer Anwendung gesendete Antwort muss der Header Content-Type auf application/octet-stream gesetzt sein und der Nachrichtentext aus einem serialisierten Protokollpuffer bestehen. Der Protokollpuffer ist eine BidResponse-Nachricht, wie in realtime-bidding.proto definiert. Ihre Anwendung muss als Antwort auf jeden BidRequest eine analysierbare BidResponse zurückgeben. Zeitüberschreitungen und Antworten, die nicht geparst werden können, werden als Fehler betrachtet. Bieter mit hohen Fehlerraten werden von Google gedrosselt.

Wenn Sie nicht auf eine Impression bieten möchten, legen Sie nur einen Wert im Feld processing_time_ms fest und lassen Sie die anderen Felder leer. Sie können realtime-bidding.proto auf der Seite Referenzdaten abrufen.

Creative-ID

In BidResponse wird ein Creative über das Feld buyer_creative_id angegeben (maximal 64 Byte). Auch ähnliche Creatives müssen eindeutige Werte für buyer_creative_id haben, wenn sie sich in wichtigen Merkmalen unterscheiden, einschließlich, aber nicht beschränkt auf Größe, deklarierte URL, Creative-Attribute und Anbietertypen. Sie müssen also zwei Anzeigen unterschiedliche Creative-IDs zuweisen, die:

  • Aussehen oder Verhalten variieren.
  • Mit verschiedenen Bildern rendern.
  • Sie werden auf unterschiedliche Weise gerendert. So besteht eine Anzeige beispielsweise aus einem Bild, die andere enthält Flash.

Beim Entwerfen Ihrer Anwendung sollten Sie sich für eine systematische Methode zur Generierung von Kennungen entscheiden, die für die Arten von Creatives, die Sie senden möchten, sinnvoll ist.

Anzeigenattribute

Die Creative-Attribute, mit denen die Anzeigeneigenschaften und die Ausrichtung umfassend beschrieben werden, müssen in BidResponse.Ad.attribute deklariert werden. Folgende Attribute müssen deklariert werden. Eine vollständige Liste der unterstützten Attribute finden Sie unter buyer-declarable-creative-attributes.txt:

  • 7 Tagging: IsTagged
    Die Anzeige enthält ein Pixel oder ein Web-Beacon, um eine Liste von Cookie-IDs für ein nachfolgendes Remarketing zu erstellen.
  • 8 Remarketing: IsRemarketing
    Die Anzeige wird anhand ihrer Cookie-ID oder Geräte-ID auf Nutzer ausgerichtet. Die Liste der Cookie-IDs oder Geräte-IDs steht für eine Gruppe von Nutzern, die bereits mit einer Website interagiert haben, die der Käufer besitzt oder die er repräsentiert.
  • 9 UserInterestTargeting: IsUserInterestTargeted
    Die Anzeige wird anhand ihrer Cookie-ID oder Geräte-ID auf Nutzer ausgerichtet, wobei die Liste der Cookie-IDs oder Geräte-IDs eine Nutzergruppe darstellt, die vom Käufer als Gruppe mit gemeinsamen Interessen definiert wurde.
  • 30 InstreamVastVideoType: Vpaid
    Zum Rendern der Anzeige ist VPAID-Unterstützung erforderlich.
  • 32 MraidType: MRAID
    Zum Rendern der Anzeige ist die MRAID API erforderlich.

Außerdem werden die folgenden Attribute unterstützt, ihre Deklaration ist jedoch nicht erforderlich, da Authorized Buyers sie automatisch erkennt und Ihre Creatives auf Grundlage der erkannten Werte blockiert (oder zugelassen) und nicht auf Grundlage Ihrer Deklaration. Informationen dazu, wie Sie Feedback zu den erkannten Eigenschaften Ihrer Creatives erhalten, finden Sie unter Creatives API.

  • 34 RichMediaCapabilityType: RichMediaCapabilityFlash
    Zum Rendern der Anzeige ist Flash-Unterstützung erforderlich.
  • 50 RichMediaCapabilityType: RichMediaCapabilityNonFlash
    Für die Darstellung der Anzeige ist kein Flash erforderlich.
  • 47 RichMediaCapabilityType: RichMediaCapabilitySSL
    Die Anzeige kann auf einer SSL-Seite gerendert werden. In Authorized Buyers werden Creatives mit unterschiedlichen deklarierten Werten für dieses Attribut als unterschiedlich behandelt. Sie werden separat geprüft und haben einen unterschiedlichen Freigabestatus. Wenn Sie für dieselbe Anzeige sowohl SSL- als auch Nicht-SSL-Versionen verwenden, sollten Sie dieses Attribut entsprechend deklarieren, damit diese Unterscheidung in AdX korrekt widergespiegelt wird.

Open Bidding-Felder

Gebotsantworten, die von Bietern auf Anzeigenplattform und Netzwerken gesendet werden, die Open Bidding nutzen, ähneln denen von Authorized Buyers, die standardmäßige Echtzeitgebote nutzen. Open Bidding-Kunden können eine kleine Anzahl zusätzlicher Felder angeben. Einige der vorhandenen Felder können für andere Zwecke genutzt werden. Dazu gehören:

OpenRTB Authorized Buyers Details
BidResponse.imp[].pmp.deals[].id BidResponse.ad[].adslot[].exchange_deal_id

Die Deal-ID aus dem Namespace der Anzeigenplattform, die mit diesem Gebot verknüpft und an Publisher gemeldet wurde.

BidResponse.seatbid[].bid[].ext.exchange_deal_type BidResponse.ad[].adslot[].exchange_deal_type

Die Art des Deals, der den Publishern gemeldet wird und sich darauf auswirkt, wie der Deal in der Auktion behandelt wird.

BidResponse.seatbid[].bid[].ext.third_party_buyer_token BidResponse.ad[].adslot[].third_party_buyer_token Token zur Identifizierung von Drittanbieter-Käuferinformationen, wenn die Anzeigenplattform als Open Bidding-Bieter fungiert. Diese wird vom Drittanbieterkäufer abgerufen und muss in der Gebotsantwort unverändert an Google übergeben werden.

Empfehlungen

  • Aktivieren Sie dauerhafte HTTPS-Verbindungen auf Ihren Servern. Diese werden auch als „Keep-Alive“ oder „Wiederverwendung von Verbindungen“ bezeichnet. Legen Sie das Zeitlimit auf mindestens 10 Sekunden fest. Höhere Werte sind in vielen Fällen vorteilhaft. Google überprüft dies während der anfänglichen Latenztests Ihrer Anwendung, da Authorized Buyers Anfragen mit einer hohen Rate sendet und der Latenz-Overhead zum Herstellen einer separaten TCP-Verbindung für jede Anfrage vermieden werden muss.
  • Geben Sie die optionale Impressions-Tracking-URL an, damit erfasst wird, wann die Impression gerendert wird und nicht, wann der Bieter gewinnt. Aufgrund der Abfallrate zwischen Gewinnen und Renderings liefert dies genauere Tracking-Statistiken.

  • Halten Sie Ihren Bietercode frei von Abhängigkeiten von veralteten Feldern, da Ihre Gebote andernfalls möglicherweise fehlschlagen.
  • Nimm BidResponse.Ad.width und BidResponse.Ad.height in deine BidResponse auf. Eine BidResponse zu einer Anfrage mit mehreren Anzeigengrößen muss die Werte width und height enthalten. Andernfalls wird sie aus der Auktion ausgeschlossen.
  • Beschränken Sie die Antwortgröße auf weniger als 8 KB. Sehr große Antworten können die Netzwerklatenz erhöhen und Zeitüberschreitungen verursachen.
  • Beachten Sie die Richtlinien für Gebote für iOS-Inventar, für die eine SKAdNetwork-Attribution erforderlich ist.

Beispiel für eine Gebotsantwort

Die folgenden Beispiele stellen für Menschen lesbare Beispiele der Protobuf- und JSON-Anfragen dar.

Google

OpenRTB-JSON

OpenRTB-Protokollzwischenspeicher

Wichtig:Die in den Beispielen dargestellten Protobuf-Meldungen werden hier als menschenlesbarer Text dargestellt. Dies ist jedoch nicht die Art und Weise, wie die Nachrichten über die Leitung gesendet werden. Bei Verwendung des Google- oder OpenRTB-Protobuf-Formats werden nur serialisierte BidResponse-Nachrichten akzeptiert.

Mit dem folgenden C++-Code können Sie eine BidResponse-Nachricht erstellen und serialisieren:

BidResponse bid_response;
// fill in bid response with bid information
string post_response;
if (bid_response.SerializeToString(&post_response)) {
  // respond to the POST with post_response as the content
} else {
  // return an error to the POST
}

Creative angeben

Ihre Gebotsantwort gibt das Creative an, das ausgeliefert werden soll, wenn Ihr Gebot gewinnt. Ihr Gebot muss eines der unterstützten Anzeigenformate enthalten (AMP, Video, nativ). In diesem Beispiel wird das Creative im Feld html_snippet angegeben.

Alternativ können Sie Ihr Creative je nach Anzeigenformat mit einem der folgenden Felder angeben:

  • Vom SDK gerenderte Anzeige
    • BidResponse.Ad.sdk_rendered_ad
  • AMP
    • BidResponse.Ad.amp_ad_url
  • Video
    • BidResponse.Ad.video_url oder
    • BidResponse.Ad.video_vast_xml
  • Nativ
    • BidResponse.Ad.native_ad

Geben Sie eine Anzeige, die auf Ihren eigenen Servern gehostet wird, mithilfe eines HTML-Snippets im Feld html_snippet der Datei BidResponse an. Das Snippet ist in einem in die Webseite eingefügten iFrame enthalten. Dadurch wird die Anzeige abgerufen und gerendert, wenn die Seite geladen wird. Sie müssen das HTML-Snippet so gestalten, dass die Anzeige (Banner oder Interstitial) in einem iFrame korrekt und in einer für die Anzeigenfläche, auf die Sie bieten, geeigneten Größe gerendert wird.

Außerdem muss die in der Gebotsantwort angegebene Anzeigengröße genau mit einer der Größenkombinationen in der Gebotsanfrage übereinstimmen, wenn

  • Eine Anzeige ist ein normales Banner (keine Video-, nativen oder Interstitial-Anzeigen).
  • Der Bieter hat die Größe in der Gebotsantwort deklariert. Eine Größendeklaration ist immer erforderlich, wenn in der Anfrage mehr als eine Größe angegeben ist.
  • Eine Ausnahme gilt für Interstitial-Anzeigen. Bei Interstitials muss die Breite mindestens 50% der Bildschirmbreite und die Höhe mindestens 40% der Bildschirmhöhe betragen.

Das Feld html_snippet unterstützt jeden gültigen HTML-Code, der korrekt gerendert wird. Beachten Sie jedoch die Einschränkungen bei der Angabe des Felds buyer_creative_id im Abschnitt BidResponse-Nachricht erstellen. Eine Möglichkeit besteht darin, zusätzliche Informationen in die Argumente der URLs aufzunehmen, die von Ihren Servern im Rahmen des Renderings der Anzeige abgerufen werden. So können Sie beliebige Daten über die Impression zurück an Ihre eigenen Server übergeben.

Die meisten Richtlinien für HTML-Snippets, die in Gebotsantworten zurückgegeben werden, entsprechen denen für Drittanbieteranzeigen. Weitere Informationen finden Sie in den Authorized Buyers-Programmrichtlinien, den Anforderungen für die Anzeigenbereitstellung durch Drittanbieter und unter Klick-URLs in Anzeigen deklarieren.

Makros angeben

Das HTML-Snippet, mit dem ein Creative definiert wird, kann ein oder mehrere spezielle Konstrukte, sogenannte Makros, enthalten. Bei der Anzeigenbereitstellung werden Makros durch Werte ersetzt. Ihre Client-Gebotsanwendung könnte beispielsweise mit dem Makro WINNING_PRICE ermitteln, wie viel sie für die Anzeige bezahlt hat, wenn sie die Auktion gewinnt. Zum Parsen dieses Makros müssen Sie eine Anwendung implementieren, die Preisbestätigungen entschlüsselt. Weitere Informationen finden Sie auf der Seite Preisbestätigungen entschlüsseln.

Geben Sie ein Makro als Teil eines HTML-Snippets im Format %%MACRO%% an, wobei MACRO eines der unterstützten Makros ist, die in der folgenden Tabelle aufgeführt sind.

Im Creative der von einem Drittanbieter ausgelieferten Anzeige muss das Makro CLICK_URL_UNESC oder CLICK_URL_ESC verwendet werden. Google verwendet die CLICK_URL-Makros für das Klick-Tracking.

Wenn Sie ein Makro verwenden möchten, fügen Sie es in die Anzeige ein, sodass die URL abgerufen wird, wenn jemand darauf klickt. Der Rückgabewert des Abrufs ist eine Weiterleitung zu einer anderen URL, die Sie an die CLICK_URL anhängen.

Makro Beschreibung
ADVERTISING_IDENTIFIER Damit erhalten Käufer beim Impressions-Rendering die IDFA von iOS oder die Werbe-ID von Android. Weitere Informationen finden Sie unter Werbetreibenden-IDs entschlüsseln.
CACHEBUSTER Stringdarstellung einer zufälligen, vorzeichenlosen Vier-Byte-Ganzzahl.
CLICK_URL_UNESC

Die Klick-URL ohne Escape-Zeichen für die Anzeige. Im Snippet sollte direkt auf das Makro eine maskierte Version der Klick-URL des Drittanbieters folgen.

Wenn die Drittanbieter-Klick-URL beispielsweise http://my.adserver.com/some/path/handleclick?click=clk lautet, kann der folgende Code mit der einfach maskierten Version der Drittanbieter-Klick-URL nach dem Makroaufruf verwendet werden:

<a href="%%CLICK_URL_UNESC%%http%3A%2F%2Fmy.adserver.com%2Fsome%2Fpath%2Fhandleclick%3Fclick%3Dclk"></a>

Bei der Anzeigenbereitstellung wird dies wie folgt erweitert:

<a href="http://google-click-url?...&ad_url=http%3A%2F%2Fmy.adserver.com%2Fsome%2Fpath%2Fhandleclick%3Fclick%3Dclk"></a>

Die URL registriert den Klick zuerst bei Google und leitet ihn dann an die Klick-URL des Drittanbieters weiter.

CLICK_URL_ESC

Die Klick-URL mit Escape-Zeichen für die Anzeige. Verwenden Sie dieses anstelle von CLICK_URL_UNESC, wenn der Wert zuerst über einen anderen Server übergeben werden muss, der dann eine Weiterleitung zurückgibt.

Beispielsweise könnte der folgende Code in einem HTML-Snippet verwendet werden:

<a href="http://my.adserver.com/click?google_click_url=%%CLICK_URL_ESC%%"></a>

Bei der Anzeigenbereitstellung wird dies wie folgt erweitert:

<a href="http://my.adserver.com/click?google_click_url=http://google-click- url%3F...%26ad_url%3D"></a>

Dadurch wird der Klick bei my.adserver.com registriert, der dann für die Weiterleitung an die im google_click_url-Parameter übergebene URL verantwortlich ist. Dies setzt voraus, dass my.adserver.com den Parameter google_click_url decodiert.

Sie können eine URL mit doppelter Escape-Angabe nach %%CLICK_URL_ESC%% anhängen. Nach der Decodierung durch my.adserver.com bleibt eine einfach maskierte Version der URL an google_click_url angehängt. Wenn das google_click_url abgerufen wird, wird es noch einmal decodiert und dann weitergeleitet.

CLICK_URL_ESC_ESC

Die doppelt maskierte URL der Anzeige. Verwenden Sie dieses anstelle von CLICK_URL_UNESC, wenn der Wert zuerst über einen anderen Server übergeben werden muss, der dann eine Weiterleitung zurückgibt.

Beispielsweise könnte der folgende Code in einem HTML-Snippet verwendet werden:

<a href="http://my.adserver.com/click?google_click_url=%%CLICK_URL_ESC_ESC%%"></a>

Bei der Anzeigenbereitstellung wird dies wie folgt erweitert:

<a href="http://my.otheradserver.com/click?google_click_url=http%3A%2F%2Fmy.adserver.com%2Fclick%3Fgoogle_click_url%3Dhttp%3A%2F%2Fgoogle-click-%20url%253F...%2526ad_url%253D"></a>
SCHEME Es wird auf http: erweitert, wenn für die Gebotsanfrage kein SSL erforderlich ist, bzw. auf https:, wenn für die Gebotsanfrage SSL erforderlich ist.
SITE Die URL-Escaping-Domain der Content-URL oder die anonyme ID bei anonymem Inventar.
SITE_URL Veraltet. Dieses Makro wird durch das Makro SITE ersetzt, das identische Funktionen bietet.
TZ_OFFSET Die Zeitverschiebung.
VERIFICATION Die verschiedenen Werte für die Produktion und den Zeitpunkt, zu dem das Creative in der Überprüfungspipeline gescannt wird Das Format ist %%?VERIFICATION:true-val:false-val%%, wobei für true-val und false-val alle Werte außer Makros verwendet werden können, auch leere Strings. Für Open Bidding wird empfohlen, dieses Makro für Anzeigenplattformen zu verwenden. Danach müssen auf Demand-Side-Plattformen keine Änderungen vorgenommen werden.

Wenn ein Creative beispielsweise %%?VERIFICATION:-1:5000%% enthält, würde der Textersatz bei der Auslieferung 5000 und bei der Überprüfung -1 lauten. Dies soll helfen, zwischen diesen beiden Arten von Pings zu unterscheiden.
WINNING_PRICE Die codierten Kosten der Impressionen (d. h. CPI statt CPM) in millionstel Einheiten der Kontowährung. Ein erfolgreiches CPM-Gebot von 5 $entspricht beispielsweise einem CPM von 5.000.000 micros. Der CPI liegt bei 5.000 micros. Der decodierte Wert von WINNING_PRICE wäre in diesem Fall 5.000. Der Preis für das erfolgreiche Gebot ist als CPI angegeben.
WINNING_PRICE_ESC WINNING_PRICE mit URL-Escaping.

Die URL-Escaping-Funktion in Makros verwendet das folgende Schema:

  • Das Leerzeichen wird durch ein Pluszeichen (+) ersetzt.
  • Alphanumerische Zeichen (0–9, a–z, A–Z) und die Zeichen !()*,-./:_~ bleiben unverändert.
  • Alle anderen Zeichen werden durch %XX ersetzt, wobei XX der Hexadezimalzahl entspricht, die das Zeichen darstellt.

Beschränkungen durch den Publisher

Publisher verwenden das BidRequest, um Einschränkungen für zugelassene Anzeigen zu übergeben. Sie müssen die Einschränkungen in den folgenden Feldern erzwingen:

  • allowed_vendor_type
  • excluded_attribute
  • excluded_sensitive_category

Das eine Feld gibt die zulässigen Funktionen der Anzeige an, das andere gibt die unzulässigen Merkmale an. Geben Sie keine Anzeige mit einer nicht zugelassenen Funktion zurück. Für zulässige Features wie den Anbietertyp wird nur dann eine Anzeige zurückgegeben, wenn der entsprechende Anbietertyp in der Liste allowed_vendor_type im BidRequest enthalten ist. Weitere Informationen finden Sie in den Kommentaren zu diesen Feldern in der Protokollpufferdefinition BidRequest.

Wenn in BidResponse ein HTML-Snippet zurückgegeben wird, müssen die Felder attribute, category und click_through_url in BidResponse richtig festgelegt werden. Wenn eine Anzeige mehrere anwendbare Werte für diese Felder hat, muss jeder Wert angegeben werden. Weitere Informationen finden Sie in den Kommentaren zu diesen Feldern in der BidResponse-Protokollpufferdefinition. Antworten, für die diese Felder nicht festgelegt sind, werden verworfen.

Für BidRequest.excluded_attribute sind folgende Werte möglich (siehe publisher-excludable-creative-attributes.txt):

  • 7 Tagging: IsTagged
    Anzeigen sind nicht zulässig, wenn sie ein Pixel oder ein Web-Beacon enthalten, um eine Liste von Cookie-IDs für ein späteres Remarketing zu erstellen.
  • 8 CookieTargeting: IsCookieTargeted
    Anzeigen sind nicht zulässig, wenn sie basierend auf ihrer Cookie-ID auf Nutzer ausgerichtet sind. Die Liste der Cookie-IDs steht für eine Gruppe von Nutzern, die bereits mit einer Website interagiert haben, die dem Käufer gehört oder von ihm repräsentiert wird.
  • 9 UserInterestTargeting: IsUserInterestTargeted
    Anzeigen sind nicht zulässig, wenn sie basierend auf ihrer Cookie-ID auf Nutzer ausgerichtet werden. Die Liste der Cookie-IDs steht für eine Nutzergruppe, die vom Käufer als Gruppe mit gemeinsamen Interessen definiert wurde.
  • 21 CreativeType: Html
    Anzeigen dürfen das Feld html_snippet oder snippet_template in BidResponse.Ad nicht verwenden.
  • 22 CreativeType: VastVideo
    Anzeigen dürfen das Feld video_url in BidResponse.Ad nicht verwenden.
  • 30 InstreamVastVideoType: Vpaid
    Für das Rendering von Anzeigen darf keine VPAID-Unterstützung erforderlich sein.
  • 32 MraidType: MRAID
    Anzeigen dürfen kein Rendering über die MRAID API erfordern.
  • 34 RichMediaCapabilityType: RichMediaCapabilityFlash
    Anzeigen dürfen nur mit Flash-Unterstützung gerendert werden.
  • 39 RichMediaCapabilityType: RichMediaCapabilityHTML5
    Für das Rendern von Anzeigen dürfen keine HTML5-Funktionen erforderlich sein.
  • 48 RichMediaCapabilityType: RichMediaCapabilityNonSSL
    Anzeigen dürfen keine Nicht-SSL-Anfragen stellen.

Wenn das Feld excluded_attribute also den Wert 7 enthält, sollten Sie keine Anzeige zurückgeben, die ein Pixel oder ein Web-Beacon zum Erstellen einer Liste verwendet. In diesem Fall muss eine Anzeige den Wert 7 im Attributfeld von BidResponse festlegen. Wenn das Feld excluded_attribute den Wert 48 enthält, sollten Sie nur Anzeigen zurückgeben, die auf einer SSL-Seite gerendert werden können. Deklarieren Sie entsprechend das Attribut 47 RichMediaCapabilityType: RichMediaCapabilitySSL.

Außerdem verwendet das Feld excluded_sensitive_category in BidRequest Codes aus der Datei ad-sensitive-categories.txt, die auf der Seite Referenzdaten verfügbar ist. Im Folgenden finden Sie ausführliche Beschreibungen einiger dieser Codes:

  • 3 Politics
    Umfasst politische und kontroverse soziale Themen; beinhaltet keine Anzeigen für Nachrichtenagenturen, die im Allgemeinen nicht mit voreingenommenen Ansichten zu Themen in Verbindung gebracht werden.
  • 4 Dating
    Umfasst Dating-Services und Onlinedating-Communities.
  • 5 Religion
    Umfasst religiöse Anzeigen und Anzeigen, die sich für oder gegen religiöse Ansichten aussprechen; beinhaltet keine astrologischen Anzeigen oder Anzeigen mit nichtkonfessionellen, spirituellen Aussagen.
  • 7 Video Games (Casual & Online)
    Umfasst Videospiele, Onlinespiele und herunterladbare Spiele; beinhaltet keine Videospielkonsolen.
  • 8 Ringtones & Downloadables
    Add-ons für Mobilgeräte (z. B. Klingeltöne) und andere Downloads, etwa Bildschirmschoner und -hintergründe für Desktop-PCs oder Profillayouts und Grafiken für soziale Netzwerke
  • 10 Get Rich Quick
    Modelle, die schnelle Einnahmen versprechen
  • 18 Weight Loss
    Umfasst Gewichtsabnahme, Diäten und damit verbundene Produkte und Programme; beinhaltet keine Anzeigen, die sich auf gesunde Ernährung oder allgemeine Fitness beziehen.
  • 19 Cosmetic Procedures & Body Modification
    Umfasst Lifting, Fettabsaugung, Lasern, Haarentfernung und -transplantation, Tätowierungen und Körpermodifikationen.
  • 23 Drugs & Supplements:
    Umfasst Arzneimittel, Vitamine, Nahrungsergänzungsmittel und damit verbundene Händler; beinhaltet keine Ressourcen, die Informationen zu Drogen enthalten.
  • 24 Sexual & Reproductive Health
    Umfasst Anzeigen, die sich mit der sexuellen Funktion und der Fruchtbarkeit befassen; beinhaltet keine herkömmlichen Schwangerschaftsressourcen.
  • 35 Social Casino Games
    Umfasst Glücksspielsimulationen, darunter Poker, Spielautomaten, Bingo, Lotterien, Sportwetten, Wetten auf Rennen, sonstige Kartenspiele und Casinospiele, bei denen es nichts Werthaltiges wie Geld oder Preise zu gewinnen gibt.
  • 36 Significant Skin Exposure
    Anzeigenbilder, auf denen ein menschlicher Körper zwischen Brustbein und Oberschenkel nicht oder nur mit Unterwäsche, Badebekleidung, Dessous, durchsichtiger Kleidung oder Stoff wie einem Handtuch oder Bettlaken bekleidet ist
  • 37 Sensationalism
    Anzeigen, mit denen die Neugier von Nutzern geweckt werden soll, damit sie auf die Anzeige klicken. Hierzu wird oft ein Teaser mit effekthaschendem Text oder entsprechenden Bildern verwendet. Dazu gehören Anzeigen zu reißerischen Themen (z. B. Verhaftungen, Todesfälle oder Scheidungen von Prominenten) oder Anzeigen, die schockieren sollen.

Offene Messung

Mit Open Measurement können Sie Drittanbieter angeben, die unabhängige Mess- und Verifizierungsdienste für Anzeigen bereitstellen, die in mobilen App-Umgebungen ausgeliefert werden.

Derzeit werden Video-, Banner- und Interstitial-Anzeigen unterstützt. Weitere Informationen zur Verwendung von Open Measurement in einer Gebotsantwort mit diesen Formaten finden Sie im Hilfeartikel Open Measurement SDK.

Beispiele für Gebotsantworten

In den folgenden Abschnitten sehen Sie Beispiele für Gebotsantworten für verschiedene Anzeigentypen.

App-Banner

Google

OpenRTB-JSON

OpenRTB-Protokollzwischenspeicher

App-Interstitial

Google

OpenRTB-JSON

OpenRTB-Protokollzwischenspeicher

App-Interstitial-Video

Google

OpenRTB-Protokollzwischenspeicher

App-nativ

Google

OpenRTB-JSON

OpenRTB-Protokollzwischenspeicher

Webvideo

Google

Mobiles Web-Banner für Anzeigenplattform-Bieter

OpenRTB-Protokollzwischenspeicher