Protected Audience API (früher FLEDGE)

Im Rahmen der Privacy Sandbox hat Chrome die Protected Audience API vorgeschlagen. Diese In-Browser-API ermöglicht es Werbetreibenden und Unternehmen im Bereich Anzeigentechnologie, Anzeigen mit Interessengruppen-Targeting auszuliefern, ohne auf Drittanbieter-Cookies angewiesen zu sein. Gleichzeitig werden Nutzer vor websiteübergreifendem Tracking geschützt.

In Chrome wird ein Ursprungstest für die Protected Audience API durchgeführt. Authorized Buyers-Partner können an den Tests der Protected Audience API für Publisher-Inventar in Ad Manager teilnehmen. Bieter können durch das Testen der Protected Audience API Folgendes erreichen:

  • Die Effektivität der Protected Audience API-Abläufe iterieren und analysieren.
  • Feedback zu potenziellen API-Verbesserungen in öffentlichen Foren geben, z. B. auf GitHub.
  • Vorbereitung auf die Unterstützung personalisierter Werbung über die API ohne Drittanbieter-Cookies

Authorized Buyers, die Tests durchführen möchten, finden hier weitere Informationen.

Zusammenfassung des Auslieferungsablaufs

Hier finden Sie eine Zusammenfassung des Ablaufs der Anzeigenbereitstellung mit Protected Audience für Authorized Buyers-Partner:

Flussdiagramm

  1. Ein Bieter arbeitet mit seinen Werbetreibenden zusammen, um Interessengruppen für jeden Werbetreibenden zu verwalten. Häufig fügen Werbetreibende das Tag eines Bieters auf ihrer Seite ein, um Browser zu Interessengruppen hinzuzufügen.
  2. Ein Endnutzer besucht die Seite eines Werbetreibenden. Die Seite enthält möglicherweise das Tag des Bieters.
  3. Das Tag des Bieters ruft die Protected Audience API joinAdInterestGroup() auf. Mit diesem Aufruf wird der Browser aufgefordert, den Nutzer einer Interessengruppe hinzuzufügen.
  4. Der Endnutzer besucht eine Publisher-Webseite. Der Browser des Nutzers fordert das Publisher-Anzeigen-Tag von Google an.
  5. Das Publisher-Anzeigen-Tag von Google sendet eine kontextbezogene Anzeigenanfrage an einen Google-Server.
  6. Google sendet kontextbezogene Gebotsanfragen an die teilnehmenden Bieter. Weitere Informationen finden Sie im Abschnitt Änderungen bei Gebotsanfragen.
  7. Der Bieter gibt eine Gebotsantwort zurück, die die InterestGroupBidding-Nachricht enthält, die für die Teilnahme an der Auktionsgruppe erforderlich ist. In OpenRTB wird dies mit dem Feld BidResponse.ext.igbid angegeben, im eingestellten RTB-Protokoll von Google mit dem Feld BidResponse.interest_group_bidding. Wenn der Bieter diese Informationen nicht angibt, nimmt Google den Ursprung des Bieters nicht in interestGroupBuyers in der Auktionskonfiguration auf. InterestGroupBidding kann auch optionale käuferspezifische Signale enthalten, die während der In-Browser-Auktion an die Gebotsfunktion des Bieters übergeben werden. In OpenRTB wird dies mit dem Feld BidResponse.ext.igbid.igbuyer.buyerdata angegeben, im eingestellten Google RTB-Protokoll mit dem Feld BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Weitere Informationen finden Sie im Abschnitt Änderungen an Gebotsantworten.
  8. Google führt die serverseitige Auktion aus und gibt eine Gebotsantwort an den Browser zurück. Bei der serverseitigen Auktion werden herkömmliche serverseitige Gebote berücksichtigt. Die Gebotsantwort kann Informationen zu einem kontextbezogenen Gewinnergebot enthalten (falls vorhanden).
  9. Die Gebotsantwort enthält eine Auktionskonfiguration für die In-Browser-Auktion. Dazu können Kontextsignale von jedem teilnehmenden Käufer gehören (die zuvor über buyerdata von OpenRTB oder per_buyer_signals des eingestellten Google RTB-Protokolls gesendet wurden), Informationen zum Kontext des Gewinners und Einstellungen für die Gebotsberechtigung.
  10. Das Publisher-Tag von Google ruft die Protected Audience API runAdAuction() auf, um die On-Device-Auktion für Interessengruppen zu starten. Google berücksichtigt nur Käufer, die bei der Auktionskonfiguration als InterestGroupBuyer in InterestGroupBidding angegeben wurden.
  11. Google übergibt die optionalen käuferspezifischen Signale jedes infrage kommenden Bieters an die Protected Audience-Auktionskonfiguration.
  12. Wenn in den Interessengruppen eines bestimmten Bieters die trustedBiddingSignalsUrl angegeben ist, sendet der Browser eine Anfrage an die trustedBiddingSignalsUrl jeder Gruppe, um Echtzeitsignale für jede Gruppe abzurufen. Weitere Informationen finden Sie in der Protected Audience API-Spezifikation.
  13. Der Browser ruft die generateBid() des Bieters für jede Interessengruppe auf, die sich angemeldet hat und für die Teilnahme an der In-Browser-Auktion infrage kommt. In diesem Schritt wird das Gebot berechnet und ein Creative ausgewählt. generateBid() hat Zugriff auf die optionalen Käufersignale, die vom Bieter bereitgestellt werden, und auf die vertrauenswürdigen Gebotssignale für die jeweilige Interessengruppe.
  14. Der Browser ruft das scoreAd() des Verkäufers (in diesem Fall Google) auf, um jedem Gebot in der Anzeigenauktion für die Interessengruppe einen Rang zuzuweisen. Gebote werden anhand von Publisher-Schutzmaßnahmen, Anzeigenrichtlinien und anderen Einschränkungen eingestuft und gefiltert.
  15. Der Browser führt eine Auktion mit den infrage kommenden Geboten für Interessengruppen durch. Das kontextbezogene Gebot mit dem höchsten Rang nimmt an der In-Browser-Auktion teil.
  16. Wenn es nach der Auktion einen Gewinner der Interessengruppe gibt, ruft der Browser die reportResult() des Verkäufers und die reportWin() des Bieters auf, um die jeweiligen Parteien über den Gewinner der In-Browser-Auktion zu informieren.
  17. Wenn eine Anzeige für eine Interessengruppe gewinnt, wird die Anzeige durch das Publisher-Tag von Google in einem iFrame gerendert.

Details zum Bereitstellungsablauf

Vor der Anzeigenbereitstellung

Creative-Überprüfung

Creatives müssen von Google überprüft und genehmigt werden, bevor sie über Protected Audience-Auktionen im Browser ausgeliefert werden können. Sie können Creatives zur Überprüfung über die Real-time Bidding API oder über die automatische Creative-Überprüfung einreichen. Creatives für auf Interessengruppen basierende Anzeigenauktionen mit der Protected Audience API im Browser müssen renderUrls zur Überprüfung enthalten.

Anforderungen für renderUrls:

  • Die über die API eingereichte renderUrl muss mit der renderUrl übereinstimmen, die in der Anzeigenauktion für Interessengruppen verwendet wird.
  • Jedes renderUrl darf nur einen einzelnen Werbetreibenden oder eine einzelne Werbekampagne repräsentieren. Ein bestimmtes renderUrl darf nicht verwendet werden, um Anzeigen im Namen mehrerer Werbetreibender zu rendern. Jede renderUrl muss einem einzelnen Creative zugeordnet sein.
  • Die renderUrl muss für die Offline-Systeme von Google zur Überprüfung von Creatives bis zu 7 Tage nach dem letzten Gebot für die Anzeige zugänglich und abrufbar sein.
Real-time Bidding API

Bieter können die API für Echtzeitgebote verwenden, um Creatives für Gebote für Interessengruppen hochzuladen.

Automatisches Scannen von Creatives

Bieter können die automatische Creative-Prüfung für Creatives einrichten, die nicht über die Real-time Bidding API hochgeladen werden.

Wenn Sie die automatische Creative-Prüfung einrichten, werden Creatives in der In-Browser-Auktion von Google gefunden und automatisch geprüft, damit sie für zukünftige Auktionen infrage kommen.

So aktivieren Sie das automatische Creative-Scanning:

  • Fügen Sie dem Authorized Buyer-Konto alle renderUrl-Ursprünge des Creatives für die Interessengruppe hinzu.

  • Fügen Sie der HTTP-Antwort des Creatives die folgenden benutzerdefinierten HTTP-Header hinzu:

    Authorized-Buyers-Creative-ID

    String

    Käuferspezifische Creative-ID. Die maximale Länge der Creative-ID beträgt 128 Bytes.
    Authorized-Buyers-Click-Through-URLs

    String

    Die Gruppe der deklarierten Ziel-URLs für das Creative, codiert gemäß RFC2396.

Beispiel:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Creative-Ablauf

Creatives werden für 15 Tage genehmigt. Wenn Sie Creatives über die Real-time Bidding API einreichen, müssen Sie das Creative nach 15 Tagen noch einmal einreichen. Wenn Sie das automatische Creative-Scanning verwenden, werden die Creatives automatisch noch einmal gescannt.

Berichts-ID des Käufers

Sie können Berichtsstatistiken wie Impressionen mithilfe von Dimensionen aufschlüsseln, die vom Käufer bereitgestellt werden, z. B. Kampagnen-ID oder Werbetreibenden-ID. Wenn Sie eine Dimension für Ausgaben für Interessengruppen hinzufügen möchten, geben Sie beim Hinzufügen des Geräts des Nutzers zur Interessengruppe eine buyerAndSellerReportingId für Ihre Anzeige an. Weitere Informationen finden Sie in der Protected Audience-Dokumentation.

Im Folgenden finden Sie ein Beispiel dafür, wie Sie buyerAndSellerReportingId in die Konfiguration der Interessengruppe einfügen:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

Die buyer_reporting_id wird als neue Dimension im Reporting-Tool des autorisierten Käufers angezeigt, nämlich als Dimension „Käufer-Berichts-ID“.

Serverseitige Auktion

Änderungen bei Gebotsanfragen

Die folgenden Protokolle sind frühe Versionen der unterstützten Protokolle, die im Test verwendet werden:

Unterstützung von Auktionen für Interessengruppen angeben

Gebotsanfragen enthalten neue Felder, um die Unterstützung für Auktionen für Interessengruppen anzugeben:

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • RTB-Protokoll von Google (eingestellt):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

Mit diesem Feld können Sie zwischen Impressionen unterscheiden, die die Protected Audience-Auktion für Interessengruppen im Browser unterstützen, und solchen, die nur die herkömmliche serverseitige Exchange-Auktion unterstützen. Das Enum AuctionEnvironment kann die folgenden Werte haben:

  • SERVER_SIDE_AUCTION (OpenRTB-JSON: 0): Die Auktion, bei der die Gewinneranzeige ermittelt wird, wird auf den Servern der Exchange ausgeführt.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): Anfragen mit Unterstützung für Protected Audience, bei denen eine kontextbezogene Auktion auf den Servern der Exchange ausgeführt wird und die Gebotsabgabe für Interessengruppen sowie die endgültige Auktion im Browser erfolgen.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): Die kontextbezogene Auktion wird auf den Servern der Exchange ausgeführt. Die Gebotslogik für Gebote für Interessengruppen und die Scoring-Logik zur Ermittlung der endgültigen Gewinneranzeige werden auf den Gebots- und Auktionsservern ausgeführt.
Größe der Anzeigenfläche für Protected Audience angeben

Die Gebotsanfrage enthält die folgenden Felder, um Ihnen die Anzeigenslotgröße für die geschützte Zielgruppe mitzuteilen:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • RTB-Protokoll von Google (eingestellt):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

Diese Felder geben die Größe des Anzeigenblocks für die Protected Audience-Auktion in Pixel an.

Diese Größe kann von den Größen in der kontextbezogenen Anfrage abweichen, z. B. von den Größen in den Feldern BidRequest.imp.banner.format.w und BidRequest.imp.banner.format.h von OpenRTB oder den Feldern BidRequest.adslot.width und BidRequest.adslot.height des eingestellten Google RTB-Protokolls.

Die kontextbezogene Anfrage kann mehrere Größen haben. Die gewinnende On-Device-Auktionsanzeige sollte nur einen einzelnen Slot mit fester Größe ausfüllen.

Angeben, ob Protected Audience-Anzeigen gerendert werden können

Protected Audience-Anzeigen werden je nach Integrationsphase möglicherweise gerendert (siehe Experiment ohne Rendering). Das Feld render_interest_group_ads in der Gebotsanfrage gibt an, ob die gewinnende Protected Audience-Anzeige gerendert wird.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • RTB-Protokoll von Google (eingestellt): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Weniger auf User-IDs angewiesen sein

Kontextbezogene Gebotsanfragen, die für die Protected Audience API-Tests infrage kommen, können weiterhin herkömmliche cookiebasierte Kennzeichnungen enthalten, sofern diese vom Browser verfügbar sind, z. B. die Felder BidRequest.user.id und BidRequest.user.buyerid oder BidRequest.google_user_id und BidRequest.hosted_match_data im eingestellten Google RTB-Protokoll. Das Vorhandensein solcher Kennzeichnungen in Gebotsanfragen unterliegt den bestehenden Datenschutzrichtlinien. Wir empfehlen, während des Tests nicht auf cookiebasierte IDs für Targeting und Gebote zu setzen, um sich besser auf effiziente Käufe vorzubereiten, wenn Drittanbieter-Cookies nicht mehr verfügbar sind.

Google führt möglicherweise auch Tests in kleinem Maßstab durch, bei denen cookiebasierte Kennungen aus Gebotsanfragen entfernt werden, die für die Protected Audience API-Tests infrage kommen. So soll die potenzielle Auswirkung der Einstellung von Drittanbieter-Cookies bewertet werden.

Zur Vorbereitung auf die Einstellung von Drittanbieter-Cookies (3PCD) im Jahr 2024 bietet Chrome jetzt von Chrome unterstützte Tests.

Websites und Anbieter können von Chrome unterstützte Tests verwenden, um ihre Systeme unter 3PCD zu testen. Im Test werden Chrome-Browser einer 3PCD-Testgruppe zugewiesen, entweder Modus A oder Modus B. Jedem Browser wird ein einheitliches Label zugewiesen, das einer bestimmten 3PCD-Testgruppe entspricht. Sie können über die Chrome-API im Browser darauf zugreifen.

Google übergibt das unveränderte Label aus der Chrome API in der RTB-Gebotsanfrage. Aufgrund der geringen Traffic-Anteile eines einzelnen Labels wird es von Google nicht immer in datenschutzbeschränkten Kontexten berücksichtigt.

In den folgenden Feldern können Sie das Label sehen:

  • OpenRTB: BidRequest.device.ext.cdep
  • RTB-Protokoll von Google (eingestellt): BidRequest.device.cookie_deprecation_label

Änderungen bei Gebotsantworten

Teilnahme an Auktionen für Interessengruppen angeben

Sie sind dafür verantwortlich, Ihre Absicht, an der In-Browser-Auktion teilzunehmen, explizit anzugeben, indem Sie das InterestGroupBidding-Objekt in der kontextbezogenen Gebotsantwort zurückgeben:

  • OpenRTB: BidResponse.ext.igbid
  • RTB-Protokoll von Google (eingestellt): BidResponse.interest_group_bidding

Sie müssen eine kontextbezogene Gebotsantwort angeben. Die Antwort muss kein kontextbezogenes Gebot enthalten. Das InterestGroupBidding-Objekt sollte die origin für jede InterestGroupBuyer enthalten, die mit einem der Startorte übereinstimmen sollte, die vom Bieter für sein Konto konfiguriert wurden. Der origin wird der interestGroupBuyers der Auktionskonfiguration hinzugefügt, wenn das Google Publisher-Tag runAdAuction() aufruft.

Kontextsignale des Käufers weitergeben

Sie können die Signale eines Käufers in die kontextbezogene Gebotsantwort aufnehmen. Google übergibt sie als JSON-Objekt über das Argument perBuyerSignals an die Gebotsfunktion auf dem Gerät. Je nach Protokoll kann dies mit den folgenden Feldern in die Gebotsantwort aufgenommen werden:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (eingestellt): BidResponse.interest_group_bidding.per_buyer_signals
Kontextbezogene Rendering-Signale des Käufers weitergeben

Bei der Darstellung von Creatives für Interessengruppen können eingeschränkte kontextbezogene Signale verwendet werden. Dazu werden diese Signale über die kontextbezogene Gebotsantwort gesendet und in der Anfrage für die Darstellungs-URL mithilfe der Makroerweiterung empfangen. Rendering-Signale können beispielsweise verwendet werden, um das Erscheinungsbild eines Creatives anzupassen und so die Leistung im Kontext einer bestimmten Anzeigenfläche oder Publisher-Seite zu verbessern.

Sie können die Rendering-Signale eines Käufers, die als URL-sicherer String serialisiert sind, in die kontextbezogene Gebotsantwort einfügen. Google ersetzt sie in der Render-URL der Gewinner-Interessengruppe, indem das ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}-Makro erstellt wird.

Rendering-Signale können in der Gebotsantwort mit den folgenden Feldern angegeben werden, je nach Protokoll:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (eingestellt): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

In der Gebotsantwort können bis zu drei Gruppen von Rendering-Signalen mit unterschiedlichen Makrosuffixen enthalten sein, um verschiedene Signale zu unterscheiden. Ein Suffix kann beispielsweise verwendet werden, um eine bestimmte Gruppe von Signalen abzugleichen, die nur für Creatives mit dem entsprechenden Makro in der Render-URL gelten. Dadurch wird die Größe der Datenübertragung reduziert.

Der Käufer der Interessengruppe wird von der Teilnahme an der Protected Audience-Auktion ausgeschlossen, wenn die Signale nicht URL-sicher sind, Makrosuffixe nicht eindeutig sind oder mehr als drei Signalgruppen bereitgestellt werden.

Maximales Gebot im Browser angeben

Im Protected Audience-Vorschlag werden die Gebotsberechnung und die endgültige Auktion voraussichtlich lokal auf dem Gerät ausgeführt. Dadurch können potenzielle Missbrauchsmöglichkeiten entstehen, die sich auf die Integrität der endgültigen Auktionsergebnisse auswirken, z. B. auf den Preis des erfolgreichen Gebots.

Als Gegenmaßnahme, die während der Protected Audience API-Tests von Google für seine RTB-Partner unterstützt wird, können Sie in jeder kontextbezogenen Gebotsantwort einen erwarteten maximalen Gebotswert angeben. Das erwartete Höchstgebot ist der maximale Gebotspreis, den Ihre Gebotsfunktion voraussichtlich zurückgeben wird. Wenn das in der In-Browser-Auktion gemeldete erfolgreiche Gebot diesen Betrag überschreitet, wird es nicht als abrechenbares Ereignis gezählt. Dieser Ansatz kann sich ändern.

In der Gebotsantwort können Sie den erwarteten Höchstgebotswert in den folgenden Feldern angeben:

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(in CPM-Währungseinheiten)
  • RTB-Protokoll von Google (eingestellt): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (in Mikro-CPM)
Impressionen mehreren Konten zuordnen

Ein Bieter muss eine Abrechnungs-ID auswählen, um die Impressionen seines Gebots für eine Interessengruppe mithilfe der folgenden Felder zuzuordnen:

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • RTB-Protokoll von Google (eingestellt): BidResponse.interest_group_bidding.interest_group_buyers.billing_id

Die ausgewählte Abrechnungs-ID muss eine zulässige Abrechnungs-ID aus der Gebotsanfrage sein:

  • OpenRTB: BidRequest.imp.ext.billing_id
  • RTB-Protokoll von Google (eingestellt): BidRequest.adslot.matching_ad_data.billing_id

Wenn die Abrechnungs-ID, der Impressionen aus Geboten für Interessengruppen zugeordnet werden sollen, nicht angegeben wird, nimmt der Bieter nicht an der Protected Audience-Auktion teil.

Untergeordnete Konten können bis zu zwei Abrechnungs-IDs haben. Der Käufer könnte eine Abrechnungs-ID für kontextbezogene Ausgaben und die andere für Ausgaben für Interessengruppen verwenden. Wenden Sie sich an Ihren Account Manager, wenn Sie zwei Abrechnungs-IDs für ein untergeordnetes Konto konfigurieren möchten.

Für jede Abrechnungs-ID kann ein Tagesbudget festgelegt werden. Wenden Sie sich an Ihren Account Manager, um das Tagesbudget für die Abrechnungs-IDs der untergeordneten Konten festzulegen.

Die Abrechnungs-IDs für alle untergeordneten Konten mit verfügbarem Budget, die für das Gebot für die Impression infrage kommen, werden in der Gebotsanfrage für die Auswahl der Ausgabenattribution angezeigt. Wenden Sie sich an Ihren Account Manager, um das Budget für eine Abrechnungs-ID für eine Interessengruppe zu ändern.

Während der In-Browser-Auktion

Gebote im Browser generieren

Verwenden Sie generateBid(), um Gebote im Browser zu generieren.

Google stellt die folgenden Parameter zur Verfügung:

  • auctionSignals: Leer
  • perBuyerSignals: Ein JavaScript-Objekt mit denselben Signalen, die vom Bieter in der kontextbezogenen Antwort bereitgestellt werden.

Die folgenden Parameter werden zurückgegeben:

  • ad: Google ignoriert dieses Feld.
  • bid: Ein numerisches Gebot, das in die Auktion eingeht. Muss in CPM-Einheiten angegeben werden (nicht in Mikros).
  • render: Die gerenderte URL, die zum Anzeigen des Creatives verwendet wird, wenn das Gebot die Auktion gewinnt. Google muss diese URL überprüfen und genehmigen, da sie sonst aus der Auktion herausgefiltert wird.
  • allowComponentAuction: Muss true sein. Google unterstützt derzeit Tests von Auktionen mit mehreren Verkäufern.

Beispiel:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Eine Erklärung der Funktion generateBid() finden Sie im Abschnitt On-Device Bidding der Protected Audience-Spezifikation.

Gebotswährung

Gebote für In-Browser-Auktionen werden in Einheiten des CPM der ausgewählten Gebotswährung abgegeben.

Die Währung des Gebots muss sowohl in der kontextbezogenen Gebotsantwort als auch im Rückgabewert von generateBid angegeben werden. Sie muss ein gültiger ISO 4217-Alphacode sein, z. B. „USD“, „EUR“ oder „JPY“.

Verwenden Sie in OpenRTB das neue Feld cur im InterestGroupBuyer-Objekt in der Google-Erweiterung für Gebotsantworten.

Beispiel:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Verwenden Sie im Google RTB-Protokoll das neue Feld currency in der Nachricht InterestGroupBuyer in der Gebotsantwort.

Beispiel:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Die generateBid-Funktionen von Bietern müssen Gebote in derselben Währung zurückgeben, die in der kontextbezogenen Gebotsantwort angegeben ist. Füllen Sie das neue Attribut bidCurrency im Rückgabewert von generateBid aus:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Wenn sich die Währung aus der kontextbezogenen Gebotsantwort von der Währung unterscheidet, die von generateBid zurückgegeben wird, oder wenn eine der beiden eine ungültige Währung zurückgibt, wird das Gebot vor der Auktion herausgefiltert.

Überprüfungen der Anzeigenqualität

Die Durchsetzung von Creative-Richtlinien und Publisher-Einstellungen kann bei Geboten für Interessengruppen im Browser während des Protected Audience API-Tests für RTB-Partner restriktiver sein.

Unterstützung des Gesetzes über digitale Dienste

Gemäß Artikel 26 des Gesetzes über digitale Dienste (Digital Services Act, DSA) können Publisher von Käufern verlangen, dass sie Offenlegungen zur Transparenz in Anzeigen rendern. Wenn ein Publisher das Steuerelement „Käufer dazu auffordern, nur Anzeigen mit DSA-Transparenz auf meiner Website oder in meiner App im EWR zu schalten“ aktiviert, können Käufer von Interessengruppen anhand der Werte von BidRequest.regs.dsa.required und BidRequest.dsa.pubrender in der Gebotsanfrage (BidRequest.dsa.dsa_support bzw. BidRequest.dsa.publisher_rendering_support im eingestellten Google RTB-Protokoll) ermitteln, für welche Möglichkeiten sie die Käufertransparenz rendern müssen.

Wenn ein Bieter, der an Protected Audience API-Auktionen teilnehmen möchte, in der Gebotsanfrage das Signal erhält, dass die DSA-Transparenz für Anzeigen, die über die Protected Audience API ausgeliefert werden, angezeigt werden muss, sollte er prüfen, ob die erforderlichen Informationen angemessen dargestellt werden können. Er kann dies angeben, indem er BidResponse.ext.igbid.igbuyer.dsaadrenderBidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render im eingestellten Google RTB-Protokoll festlegt. Andernfalls wird der Käufer nicht in die Protected Audience API‑Auktion einbezogen.

Weitere Informationen zur Anzeigentransparenz gemäß dem Gesetz über digitale Dienste finden Sie im Hilfeartikel zur Unterstützung des Gesetzes über digitale Dienste.

Gebotsfilterung

Google setzt während der On-Device-Auktion Publisher-Einstellungen und Werberichtlinien durch.

Nach der In-Browser-Auktion

Auktionsergebnis an Käufer melden: reportWin()

Die folgenden Argumente werden von Google nicht ausgefüllt:

  • auctionSignals
  • sellerSignals

Verwenden Sie reportWin(), um dem Käufer das Auktionsergebnis zu melden.

Weitere Informationen finden Sie im Abschnitt Buyer Reporting on Render and Ad Events (Berichterstellung für Käufer zu Render- und Anzeigenereignissen) im Protected Audience API-Explainer.

Makros

Das renderUrl, das auf das Protected Audience API-Creative verweist, kann einen oder mehrere Platzhalter, sogenannte Makros, enthalten. Nach Abschluss der Auktion für die Interessengruppe, aber vor dem Rendern, werden Makros durch die entsprechenden Werte ersetzt. renderUrl, die in der On-Device-Auktion verwendet werden, können die folgenden Makros enthalten:

${GDPR} Wird zu 0 erweitert, wenn die DSGVO nicht gilt, und zu 1, wenn die DSGVO gilt. Dokumentation ansehen
${GDPR_CONSENT_XXXX} Das Makro wird in den Transparency & Consent-String (TC-String) erweitert, der der Anfrage zugeordnet ist. Sollte der TC-String leer oder ungültig sein, wird das Makro nicht erweitert.

Verwenden Sie dieses Makro, um den TC-String in einer URL an einen in der IAB GVL registrierten Anbieter weiterzugeben. Ersetzen Sie XXXX durch die IAB GVL-ID des bei der IAB GVL registrierten Anbieters. Sollte der TC-String leer oder ungültig sein, wird das Makro nicht erweitert.

Creatives mit dem Makro ${GDPR_CONSENT_XXXX} werden unter Umständen blockiert, wenn der IAB GVL-registrierte Anbieter, dem die eingegebene IAB GVL-ID zugeordnet ist, keine Nutzereinwilligung eingeholt hat.

Das ${GDPR_CONSENT_XXXX}-Makro sollte nur einmal im renderUrl vorkommen.
${ADDL_CONSENT} Das Makro wird in den String für zusätzliche Einwilligung erweitert, der der Anfrage zugeordnet ist.
${AD_WIDTH}, ${AD_HEIGHT) Mit diesen Makros werden Breite und Höhe des Anzeigenblocks eingefügt.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Makro mit Käufersignalen zur Renderzeit, die in der Gebotsantwort angegeben sind.

Ersetzen Sie den Platzhalter buyer.origin.example durch den Ursprung des Käufers der Interessengruppe, der interest_group_buyers.origin in der Gebotsantwort entsprechen sollte. Sie können ein _OPTIONAL_SUFFIX einfügen, um bis zu drei verschiedene Werte für das Rendering-Signal anzugeben.

Impressionen zählen

Während der Protected Audience API-Tests mit RTB-Partnern zählt Google Impressionen, wenn der Browser die reportResult()-Funktion aufruft und anschließend die Reporting-URL von Google in einem Aufruf von sendReportTo() abruft.

Da das Ereignis, das von Google zum Zählen von Impressionen in Protected Audience-Auktionen im Browser verwendet wird, sich möglicherweise von dem Ereignis unterscheidet, das von den RTB-Käuferpartnern zum Zählen von Impressionen verwendet wird, können sich die Impressionenanzahlen unterscheiden.

Eines der Ziele von Google beim Testen der Protected Audience API ist es, diese Abweichungen zu erkennen und zu verringern.

Attribution abrechenbarer Impressionen

Alle Ausgaben eines Bieters aus Protected Audience-Auktionen im Browser werden einem einzelnen Bieterkonto zugeordnet. Grundlage dafür ist die Zuordnung der Ursprünge des Inhabers der Interessengruppe, die für den Bieter konfiguriert sind. Die Zuordnung von Ausgaben zu verschiedenen untergeordneten Sitzplatzkonten eines Bieters wird nicht unterstützt.

Tägliches Budgetlimit

Während des Protected Audience API-Tests hat jedes Konto ein Tagesbudgetlimit für Ausgaben auf Kontoebene. Das Tagesbudgetlimit begrenzt das Risiko in der In-Browser-Auktionsumgebung. Sobald die Obergrenze für das Tagesbudget erreicht ist, werden keine für Protected Audience geeigneten Gebotsanfragen mehr für das Konto empfangen.

Das Konto kann weiterhin an serverseitigen kontextbezogenen Auktionen teilnehmen, nachdem das Protected Audience-Limit erreicht wurde. Ein Bieterkonto, das das Protected Audience-Limit erreicht hat, erhält beispielsweise möglicherweise eine Gebotsanfrage mit auction_environment = SERVER_SIDE_AUCTION (OpenRTB-JSON: 0), auch wenn die Gebotsanfrage für eine Protected Audience-Auktion infrage kommt.

Echtzeitfeedback und Mindestgebot, um zu gewinnen

Bieter, die Echtzeitfeedback aktiviert haben, erhalten Feedback für Interessengruppenkäufer, die in eine Protected Audience-Auktion auf dem Gerät aufgenommen werden sollen. Jeder Käufer von Interessengruppen, den ein Bieter in einer Gebotsantwort angibt, erhält ein Feedback-Objekt, unabhängig davon, wie viele Gebote der Käufer von Interessengruppen in der Protected Audience-Auktion abgibt. Die folgenden Informationen sind im Objekt für das Käufer-Feedback zur Interessengruppe verfügbar:

  • Der Feedbacktyp des Feedbackobjekts ist INTEREST_GROUP_BUYER_FEEDBACK.
  • Der Ursprung des Käufers der Interessengruppe.
  • Das Mindestgebot, das der Käufer der Interessengruppe abgeben muss, um die gesamte Auktion zu gewinnen.
  • Das Mindestgebot, das der Käufer der Interessengruppe abgeben muss, um das höchstrangige Gebot der serverseitigen Komponente der Gesamtauktion zu überbieten.
  • Der Statuscode des Käufers der Interessengruppe. Mögliche Statuscodes sind in interest-group-buyer-status-codes.txt definiert.

Die spezifischen Feldnamen finden Sie in der Protokolldokumentation für Authorized Buyers RTB und OpenRTB-Erweiterungen.

Benachrichtigung zu Gebotsfeedback

Chrome bietet eine temporäre Debugging-API für die Protected Audience API, mit der Ad Manager Server-zu-Server-Debugging-Benachrichtigungen in Echtzeit senden kann, die Feedback zu einem Protected Audience-Gebot enthalten. Diese Benachrichtigung enthält Gründe, warum Gebote in der Protected Audience-In-Browser-Auktion gefiltert wurden, sowie weitere Informationen zu einem Gebot, die unten beschrieben werden.

Bieter können sich an ihren Account Manager wenden, um eine statische URL zu konfigurieren, die zum Senden von Benachrichtigungen mit Gebotsfeedback für das Protected Audience-Debugging verwendet wird. Diese statische URL wird von Google-Servern abgerufen, wobei ausgewählte Makros ersetzt werden, nachdem die Protected Audience-Auktion abgeschlossen ist. Die folgenden Makros werden unterstützt:

  • %%GOOGLE_QUERY_ID%%: Dieses Makro wird durch die Google-Abfrage-ID ersetzt, die in der kontextbezogenen Gebotsanfrage mit Protected Audience-Unterstützung gesendet wurde. Im OpenRTB-Protokoll wird dies mit BidRequest.ext.google_query_id angegeben, während im eingestellten RTB-Protokoll von Google BidRequest.google_query_id verwendet wird.
  • %%INTEREST_GROUP_OWNER%%: Der Ursprung des Inhabers der Interessengruppe.
  • %%BID_CPM%%: Der vom Käufer in der Funktion generateBid() angegebene Gebotspreis in CPM.
  • %%RENDER_URL%%: Die Render-URL des Creatives.
  • %%STATUS%%: Ein Statuscode, wenn das Gebot innerhalb von scoreAd() abgelehnt wurde. Mögliche Werte sind Creative-Statuscodes.

Hier ist ein Beispiel für eine statische URL, die ein Bieter seinem Kundenbetreuer zur Verfügung stellen könnte:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

Die Benachrichtigung über Gebotsfeedback ist eine temporäre Funktion, die von der temporären ForDebuggingOnly API von Chrome abhängt.

TURTLEDOVE auf Produktebene

Anzeigen aus mehreren Teilen oder TURTLEDOVE auf Produktebene (Product-Level TURTLEDOVE, PLTD) wird für Google-RTB-Partner während der Protected Audience API-Tests unterstützt. Teilen Sie Ihrem Kundenbetreuer während der Integration mit, ob Sie PLTD testen möchten, da zusätzliche Ressourcen und Konfigurationen erforderlich sind.

Onboarding

So können Sie die Protected Audience API testen:

Schritte

  1. Füllen Sie das Anfrageformular aus, um am Protected Audience API-Test teilzunehmen.
  2. Nachdem Sie das Antragsformular gesendet haben, wenden Sie sich an Ihren Account Manager oder erstellen Sie ein Ticket über die Authorized Buyer-Hilfe.
  3. Sobald das Konto konfiguriert ist, können sowohl Google als auch der Partner die Integration anhand der Schritte unter Testphasen überprüfen.

Creative-Überprüfung

Wenn Sie mit Anzeigen auf Produktebene (Anzeigen, die aus mehreren Teilen bestehen) an Protected Audience API-Auktionen teilnehmen möchten, müssen Sie die folgenden Anforderungen erfüllen:

  • Fügen Sie den Suchparameter &pltd=True in den renderUrl für den Container der Komponentenanzeige (auch als renderUrl auf oberster Ebene bezeichnet) ein, um renderUrls auf oberster Ebene bei der Creative-Überprüfung zu unterscheiden.
  • Rendern Sie ein repräsentatives Creative, wenn der Container der Komponentenanzeige für eine Creative-Überprüfung durch Google abgerufen wird. Um zu verstehen, wann ein repräsentatives Anzeigen-Rendering zurückgegeben werden sollte, können Sie sich den Abfrageparameter validation=True ansehen, der vom Google-System zur Creative-Überprüfung festgelegt wird.

Checkliste für die Integration

  • Richten Sie einen Endpunkt für Gebotsanfragen ein, mit dem Protected Audience API-bezogene Felder in der kontextbezogenen Gebotsantwort ausgefüllt werden, z. B. interest_group_bidding.
  • Implementieren Sie das Tagging auf den Seiten des Werbetreibenden, um den Browser des Nutzers mit der Interessengruppe zu verknüpfen.
  • Implementieren Sie generateBid() und reportWin().
  • Wählen Sie die Ursprünge des Inhabers der Interessengruppe aus und fügen Sie sie dem Authorized Buyer-Konto hinzu.
    • Die Ursprünge des Inhabers der Interessengruppe müssen mit den Ursprüngen übereinstimmen, auf denen die generateBid()-Funktionen gehostet werden.
    • Wenden Sie sich an den Kundenbetreuer oder erstellen Sie ein Ticket über die Hilfe für autorisierte Käufer, um diesen Schritt auszuführen.
  • Richten Sie das Pretargeting für Inventar ein, das für Tests der Protected Audience API relevant ist.
  • Reichen Sie Creatives über die Creatives API zur Überprüfung und Genehmigung ein.
  • (Optional) Richten Sie die Endpunkte für vertrauenswürdige Gebotssignale ein.
  • Optional: Richten Sie eine Testseite für Werbetreibende ein, damit Google-Entwickler ihren Browser den Interessengruppen hinzufügen können, die dem Ursprung des Käufers Ihrer Interessengruppe gehören. So können wir Protected Audience-Auktionen manuell auslösen.
  • Optional: Aktivieren Sie Echtzeit-Feedback für Ihr Konto, um Feedback für Interessengruppenkäufer zu erhalten, die in eine Protected Audience-Auktion aufgenommen werden sollen.
  • Optional: Wenden Sie sich an Ihren Account Manager, um eine statische URL zu konfigurieren, über die Sie eine Server-zu-Server-Benachrichtigung mit Gebotsfeedback für Protected Audience zum Status eines Gebots aus einer Protected Audience-Auktion auf dem Gerät erhalten. So können Sie unerwartete Probleme leichter beheben. Weitere Informationen finden Sie unter Benachrichtigung zum Gebotsfeedback.

Testphasen

Phase 1: Manueller Test

So lösen Sie manuell eine Protected Audience-Auktion aus, sorgen dafür, dass die Anzeige gerendert werden kann, und erfassen die Impression:

  1. Verwenden Sie Chrome 101 oder höher.
  2. Aktivieren Sie die Privacy Sandbox API und Fenced Frame mit chrome://flags/#privacy-sandbox-ads-apis und chrome://flags/#enable-fenced-frames. Weitere Informationen
  3. Senden Sie ein Creative zur Genehmigung über die Real-time Bidding API.
  4. Verwenden Sie die vom Bieter bereitgestellte Werbetreibendenseite, um der Bieter-eigenen Interessengruppe einen Browser hinzuzufügen.

  5. Verwenden Sie die folgende von Google bereitgestellte Test-Publisherseite, um eine Protected Audience-Auktion auszulösen:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    Die Interessengruppe im Browser muss hoch genug bieten, um die Auktion zu gewinnen, da sie möglicherweise mit herkömmlichen serverseitigen Geboten konkurriert. Google stellt außerdem für jeden Partner eine spezielle Testpublisherseite zur Verfügung, auf der nur der jeweilige Partner an der Auktion teilnehmen kann. Es kann einfacher sein, Browserauktionen auf einer partnerspezifischen Seite zuverlässig zu gewinnen.

  6. Gehen Sie so vor:

    1. Die erwartete Gewinneranzeige wird gerendert.
    2. Das Auktionsergebnis wird serverseitig gesendet. Das bedeutet, dass ein erfolgreicher Bieter einen Ping von reportWin() erhält.
    3. In den Konsolenlogs der Testpublisherseite wird für jedes Gebot eine Debugging-Meldung mit den folgenden Informationen protokolliert:
      • renderUrl: Die Render-URL des Gebots.
      • interestGroupOwner: Der Inhaber der Interessengruppe des Gebots.
      • accepted: Dieses Feld ist true, wenn das Gebot akzeptiert wurde, und false, wenn das Gebot von scoreAd() abgelehnt wurde.
      • externalBidStatus: Ein Statuscode, wenn das Gebot innerhalb von scoreAd() abgelehnt wurde. Mögliche Werte sind Creative-Statuscodes.

Phase 2 (optional): Test ohne Rendering

Nachdem Google und der Partner manuell überprüft haben, ob der Partner an der Protected Audience-Auktion teilnehmen kann, gibt Google den Partner für die nächste Testphase frei.

Google weist eine geringe Menge an Live-Traffic zu, um Protected Audience-Auktionen durchzuführen. Google und der Partner müssen dann nicht mehr manuell eine Protected Audience-Auktion auslösen. Das Ergebnis der Protected Audience-Auktion wird nicht gerendert. So können wir die Integration im großen Maßstab testen.

Wenden Sie sich an Ihren Account Manager oder reichen Sie ein Ticket über die Authorized Buyers-Hilfe ein, wenn Sie bereit sind. Google aktiviert das Konto für diese Phase.

Phase 3: Renderingtest

Sobald Google und der Partner Protected Audience-Auktionen im großen Maßstab ohne Rendering überprüft haben, kann Google dem Partner das Rendern der Protected Audience-Gewinneranzeige ermöglichen. Bei Google gibt es nur wenig Traffic, bei dem Protected Audience-Auktionen ausgeführt werden können und Anzeigen der Gewinner-Interessengruppe gerendert werden. Die In-Browser-Gebote der teilnehmenden Bieter konkurrieren mit den herkömmlichen Geboten.

Wenden Sie sich an Ihren Account Manager oder reichen Sie ein Ticket über die Authorized Buyers-Hilfe ein, wenn Sie bereit sind. Google aktiviert das Konto für diese Phase.

Zusätzliche Funktionen

Die folgenden Funktionen sind Erweiterungen des Kernprotokolls.

Parallelisierung

Die Parallelisierung ist eine Optimierung, die die End-to-End-Auktionslatenz verringert, indem die kontextbezogene Anzeigenanfrage parallel zu den Anfragen an die vertrauenswürdigen Käufer-Server, die in trustedBiddingSignalsUrl angegeben sind, initiiert wird.

Durch die Parallelisierung wird die Latenz verringert, aber die Eignung von Käufern für Interessengruppen und die Unterstützung für koordinierte Tests werden beeinträchtigt. Die Parallelisierung gilt für alle Bieter, die an der On-Device-Interessengruppenauktion teilnehmen. Bieter müssen keine Maßnahmen ergreifen, um an parallelen Auktionen teilzunehmen. Sie sollten sich jedoch damit vertraut machen, wie sich die Parallelisierung auf ihre Berechtigung bei On-Device-Auktionen auswirken kann. Testgruppen-IDs für koordinierte Tests werden in parallelen Auktionen noch nicht unterstützt.

Zusammenfassung des Auslieferungsablaufs

Hier eine Zusammenfassung des Ablaufs paralleler Auktionen: Flussdiagramm

Berechtigung von Käufern für On-Device-Interessengruppen

Bei parallelen Auktionen erfolgt der Aufruf von navigator.runAdAuction vor der Rückgabe der Antwort für kontextbezogene Anzeigen. Um vertrauenswürdige Serveraufrufe des Käufers zu starten, muss für navigator.runAdAuction der Parameter interestGroupBuyers als Wert übergeben werden. Für die verbleibenden Auktionsparameter sind JavaScript-Promises zulässig, die nach der kontextbezogenen Anzeigenantwort aufgelöst werden können. Da interestGroupBuyers vor der kontextbezogenen Anzeigenantwort übergeben wird, kann die kontextbezogene Anzeigenantwort (einschließlich Gebotsantworten) nicht verwendet werden, um auszuwählen, welche Käufer an der parallelisierten Auktion für die jeweilige Anfrage teilnehmen. Stattdessen werden im Browser des Nutzers die interestGroupBuyers-Parameter aus früheren navigator.runAdAuction-Ausführungen in der Google-Publisher-Tag-Cache für dieselbe Domain gespeichert.

Bei der Parallelisierung sind einige wichtige Aspekte zu beachten:

  1. Auktionssignale, die für Anfragen an vertrauenswürdige Käufer-Server nicht erforderlich sind, z. B. perBuyerSignals, können weiterhin in RTB-Gebotsantworten angegeben werden, genau wie bei nicht parallelisierten Auktionen. Sobald die Promises für diese Signale aufgelöst wurden, werden die verbleibenden Schritte der On-Device-Auktion auf dieselbe Weise wie beim nicht parallelen Auktionsablauf abgeschlossen.

  2. Da bei der Parallelisierung die Liste der Käufer von Interessengruppen im Cache gespeichert wird, führt Google nicht immer eine parallele Auktion durch, da der Parallelisierungs-Cache leer oder abgelaufen sein kann. Wenn der Cache leer oder abgelaufen ist, führt Google eine standardmäßige nicht parallele Protected Audience API-Auktion durch und verwendet die Käuferabsicht, um an der nicht parallelen Auktion teilzunehmen und den Käufercache für Interessengruppen zu erstellen.

  3. Wenn mindestens ein Käufer für einen Bieter für die aktuelle Publisher-Domain im Cache gespeichert ist, führt Google eine parallele Auktion durch. Dies wird in der Gebotsanfrage angegeben:

    • RTB-Protokoll von Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. Für jede registrierte Käuferherkunft der Interessengruppe für einen bestimmten Bieter, die in der parallelen Auktion enthalten war, gibt es einen entsprechenden ParallelAuctionBuyer-Eintrag:

    • RTB-Protokoll von Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. Wenn eine parallele Auktion durchgeführt wird, aber ein bestimmter Käuferursprung nicht im Cache vorhanden ist, kann dieser Käufer nicht der aktuellen On-Device-Auktion hinzugefügt werden. Dies wird durch eine Anfrage mit parallelized=True angezeigt, in der ein ParallelAuctionBuyer-Eintrag für einen bestimmten Käuferursprung der Interessengruppe fehlt. Bieter, die Interesse zeigen, indem sie gültige und zulässige InterestGroupBuyer in ihre Gebotsantwort aufnehmen, haben jedoch die entsprechenden Ursprünge der Interessengruppenkäufer im Cache. Diese Ursprünge sind für zukünftige parallelisierte Anfragen desselben Browsers und derselben Domain zulässig. Die Absicht, an Auktionen für Interessengruppen teilzunehmen, kann in den folgenden Feldern angegeben werden:

    • RTB-Protokoll von Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. Für zwischengespeicherte Käuferursprünge (die im Parameter interestGroupBuyers der parallelen Auktion enthalten sind), für die ein Bieter in seiner Gebotsantwort keine Absicht zur Teilnahme angibt, kann ein Aufruf des vertrauenswürdigen Käuferservers erfolgen, sie nehmen jedoch nicht an der parallelen Auktion teil.