Cookie-Abgleich

Mit dem Cookie-Abgleich können Sie Ihr Cookie, z. B. eine ID für einen Nutzer, der Ihre Website besucht hat, mit einer entsprechenden bieterspezifischen Google-Nutzer-ID abgleichen und Nutzerlisten erstellen, die Ihnen helfen, effektivere Gebote abzugeben. In diesem Leitfaden werden die beim Cookie-Matching verwendeten Konzepte sowie verschiedene Cookie-Matching-Workflows und mögliche Varianten für bestimmte Anwendungsfälle beschrieben.

Konzepte

Domaininhaber legen in der Regel den Inhalt von Cookies für Nutzer fest, die ihre Website besuchen. Diese Cookies werden verwendet, um Nutzer innerhalb dieser Domain zu identifizieren. Selbst wenn zwei Domaininhaber dem Austausch dieser Daten zustimmen würden, verhindert das Sicherheitsmodell von Internetbrowsern, dass ein Cookie einer anderen Domain gelesen wird.

Im Zusammenhang mit digitaler Werbung identifiziert Google Nutzer anhand von Cookies, die zur Domain doubleclick.net gehören. Bieter, die am Echtzeitgebotsverfahren teilnehmen, haben möglicherweise eine eigene Domain, in der sie Nutzer identifizieren, denen sie Anzeigen präsentieren möchten. Beim Cookie-Abgleich kann der Bieter seine Cookies mit denen von Google abgleichen, um festzustellen, ob eine in einer Gebotsanfrage gesendete Impression mit einem der Nutzer verknüpft ist, auf die das Targeting erfolgt. Er erhält entweder seine eigenen Cookiedaten oder eine bieterspezifische Google Nutzer-ID, die eine verschlüsselte Form des doubleclick.net-Cookies in der Gebotsanfrage ist.

Der in diesem Leitfaden beschriebene Cookie-Abgleichsdienst erleichtert das Erstellen und Pflegen der Verknüpfung zwischen dem Cookie eines Bieters und der Google-Nutzer-ID. Außerdem können damit Nutzerlisten erstellt werden.

Match-Tables

Mit einer Abgleichtabelle können Sie eine ID oder andere Daten aus einer Domain einer anderen zuordnen. Bieter können mit dem Cookie-Abgleichdienst ihre eigenen Match-Tables ausfüllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google Nutzer-ID des Nutzers zuordnen oder eine von Google gehostete Match-Table ausfüllen. Abgleichstabellen sind erforderlich, damit die Bieteranwendung eines Bieters auf Cookie-Daten für den Nutzer zugreifen kann, dem die Impression präsentiert wird.

Von Google gehostete Match-Tables

Für eine einfachere Wartung, geringere Latenz und Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen sollten Sie Google erlauben, Ihre Abgleichstabelle zu hosten. So kannst du einen websicheren base64-codierten String angeben, der der Google Nutzer-ID für einen bestimmten Nutzer zugeordnet wird. Der String wird im Folgenden als gehostete Abgleichsdaten bezeichnet. Sobald eine Übereinstimmung festgestellt wurde, kann sie auf folgende Arten verwendet werden:

  • Echtzeitgebote: Bei nachfolgenden Gebotsanfragen für Impressionen, die mit dem Nutzer verknüpft sind, sendet Google Ihnen die gehosteten Abgleichsdaten, die Sie mit der Google-Nutzer-ID abgeglichen haben. In der OpenRTB-Implementierung von Google wird BidRequest.user.buyeruid als websicherer Base64-codierter String angegeben. Wenn Ihr Gebotsendepunkt für die Verwendung des eingestellten Google RTB-Protokolls konfiguriert ist, erhalten Sie diese als decodierte Bytes über das Feld BidRequest.hosted_match_data.

  • Nutzerlisten: Nutzerlisten können entweder mit Google-Nutzer-IDs oder gehosteten Abgleichsdaten ausgefüllt werden.

  • Pre-Targeting: Sie können das Pre-Targeting so konfigurieren, dass Sie nur Gebotsanfragen mit gehosteten Abgleichsdaten erhalten. So lassen sich weniger relevante Impressionen für Nutzer außerhalb Ihres Cookie-Speichers ausschließen.

Nutzerlisten

Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Anschließend können Sie diese Listen mit den unten beschriebenen Workflows für die Cookie-Abgleiche oder über den Bulk-Uploader-Dienst füllen.

Erste Schritte

Wenn Sie den Cookie-Abgleich verwenden möchten, müssen Sie sich an Ihren Technical Account Manager wenden, der bestimmte Workflows aktivieren und Sie bei der Konfiguration folgender Elemente unterstützen kann:

  • Netzwerk-ID des Cookie-Abgleichs (NID): Eine String-ID, mit der sich ein Bieterkonto bei der Cookie-Übereinstimmung und anderen ähnlichen Vorgängen eindeutig identifizieren lässt.
  • URL des Cookie-Abgleichs: Die Basis-URL eines Endpunkts, an dem eingehende Anfragen im Rahmen des Cookie-Abgleichsworkflows angenommen und verarbeitet werden. Bieter können Makros in diese URL einbetten, um die Reihenfolge der Parameter zu steuern, die in Cookie-Übereinstimmungsworkflows an sie übergeben werden.
  • Abgleich-Tag: Das Tag, das Sie im Browser eines Nutzers platzieren müssen, um den vom Bieter initiierten Cookie-Abgleich auszuführen. Sie können zusammen mit Anzeigen ausgeliefert oder außerhalb von Anzeigen auf Web-Properties platziert werden.
  • URL des Berichts zum Cookie-Abgleich (optional): Im einseitigen Cookie-Übereinstimmungsworkflow ist dies eine optionale URL, über die ein Endpunkt angegeben werden kann, an den Fehlerdetails gesendet werden, falls die Cookie-Übereinstimmung aufgrund einer HTTP-302-Weiterleitung fehlschlägt. Standardmäßig werden Antworten nur an diese URL gesendet, wenn beim Cookie-Abgleich ein Fehler aufgetreten ist. Bieter können jedoch anfordern, dass die Weiterleitung immer gesendet wird.
  • Cookie Match Assist-URL: Für Anzeigenplattformen, die den Cookie Match Assist-Workflow implementieren, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen reagieren soll.
  • Kontingent für den Cookie-Abgleich: Für Anzeigenplattformen, die den Workflow für den Cookie-Abgleich implementieren, ist dies die maximale Anzahl von Anfragen, die ihre Cookie-Abgleichs-URL pro Sekunde erhalten kann. So soll verhindert werden, dass die Server der Anzeigenplattform durch CMA-Anfragen überlastet werden.

Bei allen unterstützten Cookie-Abgleich-Workflows werden der Cookie-Abgleichs-URL eines Bieters in der Regel Parameter in einer nicht garantierten Reihenfolge angehängt. Bieter mit Integrationen, für die eine einheitliche Reihenfolge der Parameter erforderlich ist, können Makros in ihre Cookie-Abgleichs-URL einfügen, um die Platzierung zu gewährleisten.

Unterstützte Makros

Bieter können ihre Cookie-Abgleichs-URL optional so konfigurieren, dass sie ein oder mehrere Makros im Format %%GOOGLE_<PARAM_NAME>%% oder %%GOOGLE_<PARAM_NAME>_PAIR%% enthält. Folgende Makros und ihre erweiterten Werte werden unterstützt:

Macro Maximierter Wert
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID

Beispiel für ein Makro

Ein Bieter hat eine Cookie-Abgleichsintegration mit einem Endpunkt, der unter https://user.bidder.com.cookies gehostet wird. Für die Implementierung sind neben den Pixel-Abgleichsparametern vordefinierte Bieterparameter in der folgenden Reihenfolge erforderlich: google_push, google_gid, google_cver und google_error. Dazu kann der Bieter seine Cookie-Abgleich-URL so festlegen:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

Wenn Google später eine Abgleichsanfrage an diesen Bieter sendet, wird sie in etwa so erweitert:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Der Cookie-Abgleichsdienst von Google unterstützt derzeit drei Workflows für verschiedene Anwendungsfälle, die unten beschrieben werden.

Die beidseitige Cookie-Abgleichsfunktion bezieht sich auf einen vom Bieter initiierten Workflow, bei dem ein Abgleich-Tag im Browser des Nutzers platziert wird, das ihn an Google weiterleitet. Mit diesem Workflow können sowohl Google als auch der Bieter Abgleichstabellen erstellen. Im Folgenden finden Sie ein einfaches Beispiel für diesen Workflow.

Schritt 1: Abgleich-Tag platzieren

Um diesen Ablauf zu starten, muss der Bieter sein Match-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Ein einfaches Übereinstimmungs-Tag, das nur die Google Nutzer-ID an den Bieter zurückgibt, kann so strukturiert sein:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

Sie können dem Abgleichs-Tag zusätzliche Parameter hinzufügen, um verschiedene Anwendungsfälle zu erfüllen. Weitere Informationen zu diesen Parametern finden Sie unter URL-Parameter für Tags abgleichen.

Schritt 2: Google antwortet mit einer Weiterleitung, die Abgleichsdaten enthält

Das Übereinstimmungs-Tag führt dazu, dass der Cookie-Abgleichdienst von Google eine Anfrage vom Browser des Nutzers empfängt, wodurch eine HTTP 302-Weiterleitung an die Cookie-Abgleich-URL des Bieters gesendet wird. Die Weiterleitung enthält Abfrageparameter, die die Google Nutzer-ID und die Versionsnummer in der URL angeben. Außerdem erhält der Bieter sein Cookie, das in den Anfrageheadern enthalten ist. In der Praxis könnte die Weiterleitungs-URL für das einfache Abgleich-Tag mit der oben genannten Cookie-Abgleichs-URL https://ad.network.com/pixel so aussehen:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

Die mit dem Parameter google_gid übergebene Google Nutzer-ID ist ein websicherer, base64-codierter String ohne Padding. Bietern, die eine Abgleichtabelle hosten, wird empfohlen, den genauen String zu speichern, der vom Cookie-Abgleichsdienst zurückgegeben wird. In nachfolgenden Gebotsanfragen entspricht dies den Werten, die in OpenRTB über BidRequest.user.id oder im eingestellten Google RTB-Protokoll über BidRequest.google_user_id angegeben sind.

Die in google_cver angegebene Version ist die numerische Versionsnummer der Google-Nutzer-ID. Die Google Nutzer-ID eines bestimmten Nutzers ändert sich nur selten und wird anschließend erhöht.

Wenn Google bei der Verarbeitung Ihrer Abgleichsanfrage einen Fehler feststellt, wird stattdessen ein google_error-Parameter angegeben.

Schritt 3: Bieter verarbeitet Weiterleitung und antwortet mit Pixel

Der Bieter wird auf seine Cookie-Abgleichs-URL weitergeleitet. Diese enthält die Parameter, die er im ersten Schritt angegeben hat, sowie die von Google im zweiten Schritt bereitgestellten Parameter. Außerdem erhalten sie ihr Cookie an die HTTP-Header. Wenn der Vorgang erfolgreich war, kann ein Bieter, der eine eigene Abgleichtabelle hostet, sein Cookie mit der in der Antwort enthaltenen Google-Nutzer-ID abgleichen. Es wird empfohlen, den genauen String zu speichern, der vom Cookie-Abgleichsdienst zurückgegeben wird.

Wenn der Vorgang fehlgeschlagen ist, erhält der Bieter einen google_error-Parameter in der Weiterleitung. Dies ist ein numerischer Wert, der verschiedenen Fehlerstatus entspricht, die den aufgetretenen Fehler identifizieren. Weitere Informationen zu den möglichen Fehlerwerten Wenn Sie eine Fehlermeldung erhalten, können Sie versuchen, den Nutzer noch einmal abzugleichen, indem Sie ein neues Abgleich-Tag platzieren.

Der Bieter muss immer ein 1 × 1-Pixel-Bild mit unsichtbaren Pixeln ausliefern oder alternativ eine HTTP 204 Kein Inhalt-Antwort zurückgeben.

Dieser Workflow ist im folgenden Diagramm dargestellt. Dort werden Anfragen und Antworten durch einen Pfeil dargestellt und die zugehörigen Datenelemente in Klammern aufgeführt.

Übereinstimmung mit Tag-URL-Parametern

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bidders abgerufen werden.
google_cm Gibt dem Cookie-Abgleichsdienst von Google an, dass der Cookie-Abgleich durchgeführt werden soll. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_sc Dieser Parameter wurde eingestellt. Setzt das Google-Cookie für den Nutzer, falls noch keines vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist.
google_no_sc Dieser Parameter wurde eingestellt. Dies weist den Cookie-Abgleichsdienst von Google an, kein Cookie für den Nutzer festzulegen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_hm

Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.

Der Wert ist ein websicherer Base64-codierter String (mit optionalem Padding). Die Rohdaten dürfen maximal 40 Byte groß sein. Beispiel: Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.

google_redir Ein URL-codierter String, den ein Bieter angeben kann, wenn er Google anweisen möchte, die HTTP 302-Weiterleitung an die codierte URL für dieses Abgleich-Tag zu senden. So kann Google an erster Stelle in einer verketteten Aufrufabfolge an Partner gesetzt werden. Dies führt zu einem Fehler, wenn es ohne google_hm oder mit google_cm angegeben wird.
google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp]:
  • userlistid: eine einzelne numerische Nutzerlisten-ID.
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, der angibt, wann der Nutzer der Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen.

gdpr Gibt an, dass die Anfrage den Einschränkungen der DSGVO zur Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen an die Einwilligung der Nutzer in der EU und im Abschnitt Auswirkungen auf die Berechtigung für den Cookie-Abgleich in der Dokumentation zum IAB TCF 2.0 für Authorized Buyers.

Beispiel: gdpr=1

gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der Autorisierten Käufer – IAB TCF v2.0-Dokumentation unter Wie wird der TC-String übergeben?
process_consent Gibt an, dass der Bieter die Einwilligung der Endnutzer für die in der Richtlinie zur Einwilligung der Nutzer in der EU von Google angegebenen Datennutzungen eingeholt hat.

Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder andere Einwilligungsparameter in der Anfrage verfügbar sind (gdpr_consent), wird dieser Parameter ignoriert.

Beispiel: process_consent=T

Zusätzlich zu den oben genannten Parametern können Bieter eigene Parameter angeben, die der Weiterleitungs-URL als Parameter angehängt werden. Von Bietern definierte Parameter mit dem Präfix google_ werden ignoriert, da sie von Google für zukünftige Entwicklungen reserviert sind. Die Reihenfolge der Parameter kann nicht garantiert werden. Ein Übereinstimmungs-Tag mit von Bietern definierten Parametern kann so aussehen:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

Parameter für Weiterleitungs-URLs

Die Weiterleitungs-URL basiert auf der Basis-URL für den Cookie-Abgleich, die für das Konto eines Bieters konfiguriert wurde, einschließlich google_ und von Bietern definierter Parameter, je nachdem, welche Parameter im Übereinstimmungs-Tag angegeben sind. Die folgenden google_-Antwortparameter sind definiert:

Parameter Beschreibung
google_gid Google-Nutzer-ID Wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war.
google_cver Cookie-Version. Wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war.
google_error

Ein Ganzzahlwert, der den Gesamtfehler der Anfrage angibt. Nach dem Empfang bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen google_-Antwortparameter festgelegt werden. Zu den unterstützten Fehlerwerten gehören:

  • 1: Der Nutzer verfügt zwar über ein Google-Cookie, hat jedoch das Tracking anhand dieses Cookies deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Beispiel: Es wurde eine Anfrage ohne Aktion empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google speichert das Cookie nicht über den Cookie-Abgleichdienst.
  • 4: In Konflikt stehende Vorgänge angegeben. Sie dürfen nicht sowohl das google_push- als auch das google_cm-Flag in derselben Anfrage angeben, da sie unterschiedliche Zwecke haben.
  • 5: Ein ungültiger google_push-Parameter wurde in einer Weiterleitung an einen Google-Server als Teil einer bidirektionalen Pixelabgleich-Anfrage übergeben. Durch die Weiterleitung muss google_push auf denselben Wert festgelegt werden, der in der ursprünglichen Pixelanfrage an Sie übergeben wurde.
  • 6: Im Match-Tag wurde eine ungültige NID angegeben.
  • 7: Es wurde ein ungültiges Cookie erkannt.
  • 8: Eingestellt. Kein Cookie gefunden.
  • 9: Es wurde kein Cookie gefunden. Es wird versucht, ein Test-Cookie zu setzen.
  • 10: Der Parameter google_redir wurde verwendet, ohne dass google_hm angegeben wurde, oder zusätzlich zu google_cm.
  • 15: Die Anfrage stammt aus einer Region, in der Google verlangt, dass die Abgleichtabelle von Google gehostet wird. Daher enthält diese Antwort keine Google-Nutzer-ID. Diese Funktion ist derzeit nur für einen kleinen Prozentsatz des Traffics aktiviert, wird aber voraussichtlich im Juni 2020 vollständig aktiviert.
google_hm

Wird nur angezeigt, wenn der Versuch, in die von Google gehostete Match-Table zu schreiben, fehlschlägt. In diesem Fall ist der Wert einer der folgenden Statuscodes:

  • 1 – Verboten: Der Kunde ist noch nicht auf die Zulassungsliste für das Schreiben von Einträgen in der gehosteten Match-Table gesetzt.
  • 2 – Dekodierungsfehler: Der Parameterwert konnte nicht decodiert werden.
  • 3 – Nutzlast zu lang: Der Parameterwert wurde in mehr als 24 Byte Daten decodiert.
  • 4 – Interner Fehler: Beim Speichern der Daten ist ein interner Fehler aufgetreten.
  • 5 – Gedrosselt: Dieser Schreibvorgang wurde aufgrund einer Drosselung nicht verarbeitet.
google_ula

Status des Vorgangs zum Hinzufügen einer Nutzerliste. Dieser wird wiederholt, wenn in der Anfrage mehrere google_ula angegeben wurden. Das Format ist:
userlistid,status code

Beispiel: google_ula=1234567890,0

Der Vorgang google_ula kann einen der folgenden Statuscodes zurückgeben:

  • 0 – kein Fehler Der Nutzer wurde der Nutzerliste hinzugefügt.
  • 2 – Berechtigung verweigert. Sie sind nicht berechtigt, der angegebenen Nutzerliste Nutzer hinzuzufügen.
  • 5 – Ungültige Nutzerlisten-ID. Die angegebene Nutzerlisten-ID ist ungültig.
  • 6: ID des geschlossenen Attributs. Die angegebene Nutzerlisten-ID ist geschlossen.
  • 10 – Interner Fehler. Im Cookie-Abgleichdienst ist ein interner Fehler aufgetreten. Sie können noch einmal versuchen, den Nutzer zuzuordnen.

In den folgenden Szenarien wird beschrieben, wie die Cookie-Abgleichsfunktion für einen typischen Nutzer aussehen könnte, der eine Webseite besucht.

Szenario 1: Nutzer löscht seine Cookies und ruft eine Website auf

Jane löscht alle Cookies aus dem Cache. Er ruft dann die Startseite von BeispielNachrichten.de auf.

Folgendes passiert:

  1. ExampleNews.com wird gerendert und ruft Anzeigen über Google (Ad Manager) ab.
  2. Da der Anzeigenblock für die dynamische Zuordnung infrage kommt, sendet Google über den Echtzeitgebotsdienst Gebotsanfragen an FinestDSP und andere Bieter.
  3. Die Bieteranwendung von FinestDSP empfängt und verarbeitet die Gebotsanfrage und sendet die Gebotsantwort.
  4. Google erhält Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP, in der eine Anzeige mit einem Abgleich-Tag (Pixel) angegeben ist.
  5. FinestDSP gewinnt die Auktion. Google sendet Jane die Anzeige und das Abgleich-Tag von FinestDSP.
  6. Das Übereinstimmungs-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt die Parameter google_nid und google_cm an.
  7. Der Cookie-Abgleichsdienst liest das Google-Cookie von Jana und leitet ihren Browser mit den festgelegten Parametern google_gid und google_cver an die Cookie-Abgleichs-URL von FinestDSP weiter.
  8. Der Browser von Jana lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
  9. Der Cookie-Abgleichs-Endpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, die von Google festgelegte URL-Parameter und das Cookie für Jana in den HTTP-Headern enthält. FinestDSP kann jetzt die Zuordnung seines Cookies zur google_gid in seiner Abgleichstabelle speichern.
  10. FinestDSP antwortet auf die Weiterleitung mit einem unsichtbaren 1x1-Pixel.
Szenario 2: Nutzer mit vorhandener Zuordnung

Eine Woche nach Szenario 1 besucht Jane noch einmal beispielnachrichten.de. Jane hat jetzt sowohl Bidder- als auch Ad Manager-Cookies auf ihrem Computer. So funktioniert das Abgleichverfahren:

  1. Die Webseite wird gerendert, wodurch Google (Ad Manager) Anzeigen anfordert, die auf der Seite gerendert werden.
  2. Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die anwendbaren Bieter, einschließlich FinestDSP.
  3. FinestDSP erhält die Gebotsanfrage, einschließlich Signalen wie google_gid.
  4. FinestDSP sucht die google_gid in der Abgleichtabelle und findet das Cookie, das Jane zugeordnet ist und eine Woche zuvor (in Szenario 1) erstellt wurde.
  5. Basierend auf den Informationen, die mit dem Cookie verknüpft sind, gibt die Gebotslogik von FinestDSP ein Gebot für die Impression ab und gewinnt die Auktion.
  6. Jana sieht dann möglicherweise eine Anzeige, die auf ihren Interessen basiert und auf Informationen von FinestDSP beruht.

Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit der Ausnahme, dass er so geändert wird, dass nur Google eine Match-Table hostet und ausfüllt. Diese Option kann verwendet werden, wenn der Bieter keine Google-Nutzer-IDs in seiner eigenen Abgleichtabelle hosten darf. Um diesen Ablauf verwenden zu können, müssen Bieter Google das Hosten der Match-Table erlauben. Sie können google_cm nicht mehr in Anfragen an den Cookie-Abgleichdienst von Google angeben und erhalten folglich auch keine google_gid zum Ausfüllen ihrer eigenen Match-Table. Sobald Google eine Übereinstimmung für einen Nutzer festgestellt hat, können Bieter ihn mithilfe ihrer eigenen Cookiedaten zu Nutzerlisten hinzufügen. Ebenso werden Gebotsanfragen für diese Nutzer die Google-Nutzer-ID ausschließen, aber gehostete Abgleichsdaten enthalten. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.

Um diesen Ablauf zu starten, muss ein Bieter ein Match-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Im Gegensatz zum Workflow für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammen, muss das Abgleich-Tag den Browser des Nutzers auf Ihre Cookie-Abgleichs-URL weiterleiten. Wenn die URL für den Cookie-Abgleich beispielsweise als https://ad.network.com/pixel konfiguriert ist, würde sie so aussehen:

<img src="https://ad.network.com/pixel" />

Beim Laden im Browser des Nutzers wird ein Pixel von der Cookie-Abgleichs-URL des Bieters angefordert. Diese Anfrage enthält das Cookie im HTTP-Header, das für den nächsten Schritt extrahiert werden sollte.

Der Cookie-Abgleichs-Endpunkt des Bieters muss zum Cookie-Abgleichsdienst von Google weiterleiten. Er muss den Parameter google_hm enthalten, der mit den websicheren Base64-codierten Cookie-Daten des Bieters ausgefüllt ist. Die Weiterleitungs-URL könnte so aussehen:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung mit den von Ihnen angegebenen Parametern.

Schritt 4: Google liefert Pixel bei Erfolg oder Fehlerweiterleitung aus, falls Berichts-URL angegeben ist

Wenn die Cookie-Abgleichsoperation erfolgreich war oder für das Konto des Bieters keine URL für den Cookie-Abgleichsbericht angegeben wurde, wird von Google standardmäßig ein transparentes Pixel mit einer Größe von 1 × 1 Pixel ausgeliefert. Der Workflow endet hier. Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte Google RTB-Protokoll. Bieter können Nutzerlisten auch mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.

Andernfalls wird der Bieter über die URL des Berichts zur Cookie-Abgleichung auf eine Google-Weiterleitungsseite weitergeleitet. Die Ursache des Fehlers wird im Parameter google_error angegeben. Wenn die URL des Berichts zum Cookie-Abgleich des Bieters https://ad.network.com/report lautet, würde die Weiterleitungs-URL so aussehen:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

Der Browser des Nutzers wird zur Berichts-URL für die Cookie-Abgleiche des Bieters weitergeleitet. Dabei wird gegebenenfalls auch der von Google im Parameter google_error angegebene Fehlergrund angezeigt. Weitere Informationen zur Interpretation des Fehlercodes finden Sie in der Parameterbeschreibung.

Schritt 6: Bieter sendet transparentes 1x1-Pixel

Der Bieter muss antworten, indem er dem Browser des Nutzers ein transparentes 1x1-Pixel sendet.

Der Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen wird im Diagramm unten dargestellt. Anfragen und Antworten werden durch einen Pfeil dargestellt und die zugehörigen Datenelemente sind in Klammern aufgeführt.

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden.
google_sc Dieser Parameter wurde eingestellt. Setzt das Google-Cookie für den Nutzer, falls noch keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Wenn Sie den Parameter weglassen, wird ein Fehler ausgegeben, wenn kein Cookie vorhanden ist.
google_no_sc Dieser Parameter wurde eingestellt. Dies weist den Cookie-Abgleichsdienst von Google an, kein Cookie für den Nutzer festzulegen, falls kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_hm

Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.

google_redir Eine codierte URL, für die Google eine HTTP-302-Weiterleitung senden soll. Die angegebene URL erhält sowohl bei Fehlern als auch bei erfolgreichen Vorgängen Weiterleitungen mit dem Parameter google_error.
google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp]:
  • userlistid: eine einzelne numerische Nutzerlisten-ID.
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, der angibt, wann der Nutzer der Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen.

gdpr Gibt an, dass die Anfrage DSGVO-Einschränkungen für die Datennutzung unterliegt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der IAB TCF 2.0-Dokumentation für autorisierte Käufer unter Auswirkungen auf die Eignung für die Cookie-Abgleichsfunktion.

Beispiel: gdpr=1

gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der Autorisierten Käufern-Dokumentation zum IAB TCF 2.0 unter Wie wird der TC-String übergeben?
process_consent Gibt an, dass der Bieter die Einwilligung der Endnutzer für die in der Richtlinie zur Einwilligung der Nutzer in der EU von Google angegebenen Datennutzungen eingeholt hat.

Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder für die Anfrage andere Einwilligungsparameter verfügbar sind (gdpr_consent), wird dieser Parameter ignoriert.

Beispiel: process_consent=T

Parameter Beschreibung
google_error

Ein Ganzzahlwert, der den Gesamtfehler der Anfrage angibt. Wenn dieser Wert empfangen wird, wurden keine Vorgänge ausgeführt und es werden keine weiteren google_-Antwortparameter festgelegt. Zu den unterstützten Fehlerwerten gehören:

  • 1: Der Nutzer verfügt zwar über ein Google-Cookie, hat jedoch das Tracking anhand dieses Cookies deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Beispiel: Es wurde eine Anfrage ohne Aktion empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google speichert das Cookie nicht über den Cookie-Abgleichdienst.
  • 4: In Konflikt stehende Vorgänge angegeben. Die Flags google_push und google_cm dürfen nicht in derselben Anfrage angegeben werden, da sie widersprüchlichen Zwecken dienen.
  • 5: Ein ungültiger google_push-Parameter wurde in einer Weiterleitung an einen Google-Server als Teil einer bidirektionalen Pixelabgleich-Anfrage übergeben. Durch die Weiterleitung muss google_push auf denselben Wert festgelegt werden, der in der ursprünglichen Pixelanfrage an Sie übergeben wurde.
  • 6: Im Match-Tag wurde eine ungültige NID angegeben.
  • 7: Es wurde ein ungültiges Cookie erkannt.
  • 8: Eingestellt. Kein Cookie gefunden.
  • 9: Es wurde kein Cookie gefunden. Es wird versucht, ein Test-Cookie zu setzen.
  • 10: Der Parameter google_redir wurde verwendet, ohne dass google_hm angegeben wurde, oder zusätzlich zu google_cm.
  • 15: Die Anfrage stammt aus einer Region, in der Google verlangt, dass die Abgleichtabelle von Google gehostet wird. Daher enthält diese Antwort keine Google-Nutzer-ID. Diese Funktion ist derzeit nur für einen kleinen Prozentsatz des Traffics aktiviert, wird aber voraussichtlich im Juni 2020 vollständig aktiviert.

Von Google initiiert: Bidirektionaler Pixelabgleich

Der bidirektionale Pixelabgleich ist ein Workflow für den Cookie-Abgleichsdienst von Google. Dabei versucht Google, eine Google-Nutzer-ID mit einem algorithmisch ausgewählten Bieter abzugleichen, der nicht der Gewinner der Echtzeitgebotsauktion ist. Wenn eine Anzeige ausgeliefert wird, platziert Google ein Abgleich-Tag, das den Browser des Nutzers anweist, ein transparentes Pixel von der Cookie-Abgleich-URL des ausgewählten Bieters zu laden. So können sowohl Google als auch der Bieter eine Match-Table mit einem bestimmten Nutzer füllen. Unten finden Sie ein einfaches Beispiel für diesen Workflow.

Schritt 1: Google platziert ein Abgleich-Tag

Wenn die Seite eines teilnehmenden Publishers im Browser des Nutzers geladen wird und eine Anzeigenfläche auf dieser Seite von Google gefüllt wird, kann ein Übereinstimmungs-Tag platziert werden, das ein Pixel von einem algorithmisch ausgewählten Bieter anfordert. Das von Google platzierte Pixelabgleichs-Tag kombiniert die Cookie-Abgleichs-URL des Bieters mit zusätzlichen Parametern, mit denen der Bieter seine Match-Table füllen kann. Eine URL für den Cookie-Abgleich, die als https://ad.network.com/pixel angegeben ist, hat folgende Struktur:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

Bieter, die Anfragen zur Pixelabgleichsfunktion erhalten, müssen mit einer Weiterleitung zum Cookie-Abgleichsdienst von Google antworten. Diese Weiterleitung muss folgendermaßen strukturiert sein:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

Die oben angegebene Weiterleitungs-URL ähnelt der URL, die im Übereinstimmungs-Tag für den Workflow für den von der Gebotsfunktion initiierten Cookie-Abgleich verwendet wird. Bei der Pixelübereinstimmung wird der Parameter google_cm durch den Parameter google_push ersetzt. Der Wert dieses Parameters muss mit dem Wert übereinstimmen, den Google in der Anfrage angegeben hat. Ähnlich wie beim vom Bieter initiierten Workflow können zusätzliche Parameter angegeben werden, um zusätzliche Anwendungsfälle zu erfüllen.

Schritt 3: Google verarbeitet die Weiterleitung und antwortet mit dem Pixel

Google protokolliert, dass eine Übereinstimmung für den Nutzer erstellt wurde, und verarbeitet alle zusätzlichen Vorgänge, die über Abfrageparameter angefordert werden. Google antwortet mit einem transparenten 1x1-Pixel.

Workflow-Diagramm für den Pixelabgleich

Dieser Workflow wird durch das folgende Diagramm veranschaulicht, in dem Anfragen und Antworten durch einen Pfeil dargestellt werden und die zugehörigen Datenelemente in Klammern aufgeführt sind.

Anfrageparameter für das Google-Match-Tag

Parameter Beschreibung
google_gid Google Nutzer-ID. Für Nutzer aus anderen US-Bundesstaaten mit Datenschutzeinschränkungen wird dies immer im Übereinstimmungs-Tag von Google angegeben.
google_cver Die Cookie-Version. Dieser Wert wird immer im Match-Tag von Google angegeben.
google_push Gibt an, dass mit dieser Anfrage der Pixel-Matching-Workflow gestartet wird. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort des Bieters zurückgegeben werden.
gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten im Abschnitt [Anforderungen zur Einwilligung der Nutzer in der EU](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder unter **Wie wird der TC-String übergeben?** in der [Dokumentation zum Authorized Buyers IAB TCF 2.0](//support.google.com/authorizedbuyers/answer/9789378).

Parameter für Weiterleitungen bei der Pixel-Abgleichsfunktion für Bieter

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden.
google_push Gibt an, dass mit dieser Weiterleitung der Pixel-Abgleich abgeschlossen wird. Hier muss der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag angegeben werden.
google_hm

Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.

google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp]:
  • userlistid: eine einzelne numerische Nutzerlisten-ID.
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, der angibt, wann der Nutzer der Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen.

gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter [Anforderungen an die Nutzereinwilligung in der EU](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder in der [Authorized Buyers-Dokumentation zum IAB TCF v2.0](//support.google.com/authorizedbuyers/answer/9789378) unter „Wie wird der TC-String übergeben?“.

Von Google initiiert: Einseitiger Pixelabgleich

Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow dadurch, dass das Abgleich-Tag von Google keinen Parameter enthält, mit dem die Google-Nutzer-ID angegeben wird. Es wird jedoch weiterhin eine von Google gehostete Match-Table gefüllt. Diese Option kann verwendet werden, wenn der Bieter keine Google-Nutzer-IDs in seiner eigenen Abgleichtabelle hosten darf. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.

Schritt 1: Google platziert ein Abgleich-Tag

Google platziert ein Abgleich-Tag für einen algorithmisch ausgewählten Bieter. Das Match-Tag enthält den Parameter google_push. Beispiel:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

Schritt 2: Der Browser des Nutzers fordert Pixel von der Kochabgleich-URL des Bieters an

Der Browser des Nutzers fordert ein Pixel von der Cookie-Abgleich-URL des Bieters an, einschließlich des Cookies des Bieters in den HTTP-Headern.

Der Cookie-Abgleichendpunkt des Bieters muss an den Cookie-Abgleichdienst von Google weiterleiten, einschließlich des google_hm-Parameters, der mit seinen websicheren Base64-codierten Cookie-Daten ausgefüllt wird. Die Weiterleitungs-URL könnte so aussehen:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung mit den von Ihnen angegebenen Parametern. Wenn der Vorgang erfolgreich war, enthalten die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte Google RTB-Protokoll. Bieter können Nutzerlisten auch mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.

Schließlich gibt Google ein transparentes 1x1-Pixel an den Browser des Nutzers zurück.

Mit Open Bidding können Anzeigenplattformen vom Bieter initiierte und von Google initiierte Workflows für den Cookie-Abgleich verwenden, um eine Google-Nutzer-ID mit ihrem Cookie abzugleichen. Cookie Match Assist (CMA) ist eine zusätzliche Funktion für Anzeigenplattformen, mit der sie Match-Tables mit ihren eigenen Bietern erstellen können.

  1. Beim Platzieren einer Anzeige wählt Google algorithmisch eine teilnehmende Anzeigenplattform aus und platziert ein Cookie Match Assist-Tag mit der folgenden Struktur:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
  2. Durch das CMA-Abgleichs-Tag von Google wird die URL für den Cookie-Abgleich der Anzeigenplattform mit einer Pixelanfrage aufgerufen.

  3. Die Anfrage wird vom Cookie-Abgleichs-Endpunkt der Anzeigenplattform empfangen. Der Cookie-Abgleichsdienst der Anzeigenplattform ist für die Übereinstimmung der Nutzer-ID mit einem ihrer Bieter verantwortlich. Im folgenden Diagramm antwortet der Cookie-Abgleichsdienst der Anzeigenplattform dem Browser des Nutzers mit einer Weiterleitung zu einem der Endpunkte eines Bieters.
  4. Der Bieter erhält die Anfrage zusammen mit allen Parametern, die von der Anzeigenplattform angegeben wurden, um die Nutzer-ID mit dem Cookie abzugleichen.

Einschränkungen

Häufigkeit von Anfragen für neue Übereinstimmungen begrenzen

Bieter sind dafür verantwortlich, die Anzahl der Aufrufe des Cookie-Abgleichsdienstes für Nutzer zu begrenzen, die einen neuen Eintrag in der von Google gehosteten Abgleichstabelle haben. Ein Eintrag in der gehosteten Match-Table kann nach 14 Tagen als abgelaufen betrachtet werden. Danach kann er aktualisiert werden.

Auf alle Anfragen zur Pixelübereinstimmung antworten

Bieter, die den Pixel-Abgleich-Workflow verwenden, müssen auf alle eingehenden Pixel-Abgleich-Anfragen mit einer Antwort antworten, die den Parameter google_push enthält. So kann Google Richtlinien durch Überwachung der Nutzung erzwingen. Wenn die Antwortrate eines Bieters unter 90 % fällt, wird die Anzahl der Pixel-Abgleichsanfragen, die an sein Konto gesendet werden, von Google gedrosselt.

HTTPS-Endpunkte verwenden

Für Endpunkte, die in allen Cookie-Übereinstimmungs-Workflows verwendet werden, ist HTTPS erforderlich.

Wenn Sie auf eine Pixel-Übereinstimmungsanfrage antworten, die Sie über HTTPS erhalten, müssen Sie über HTTPS zum Cookie-Abgleichdienst weiterleiten. Ebenso muss für einen Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, HTTPS verwendet werden. Wenn Sie Anfragen an Google über HTTP häufiger als alle zwei Minuten senden, wird die Anzahl der Abgleichsanfragen, die an Ihr Konto gesendet werden, gedrosselt.

Bei Anfragen zum Cookie-Abgleich, die der Richtlinie zur Einwilligung der Nutzer in der EU von Google unterliegen, muss die Einwilligung des Endnutzers angegeben werden. Bei solchen Anfragen muss angegeben werden, dass die Einwilligung auf eine der folgenden Arten eingeholt wurde:

Beispiele

In den folgenden Beispielen wird veranschaulicht, wie Sie den Cookie-Abgleichsdienst verwenden können, um bestimmte Ziele zu erreichen. Sofern nicht anders angegeben, wird davon ausgegangen, dass der Nutzer, gegen den Maßnahmen ergriffen werden, nicht in einem US-Bundesstaat mit Datenschutzeinschränkungen ansässig ist.

Von Bietern gehostete Match-Table füllen

Bieter können den Cookie-Abgleich-Workflow verwenden, um eine eigene Abgleichtabelle zu erstellen. Dazu müssen sie nur die Parameter google_nid und google_cm in ihrem Abgleich-Tag angeben. Das könnte so aussehen:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

Wenn die Cookie-Abgleichs-URL des Bieters auf https://ad.network.com/pixel?id=1 festgelegt ist und der Cookie-Abgleich erfolgreich war, sieht die Weiterleitung, die Google als Antwort auf das Abgleich-Tag des Bieters sendet, möglicherweise so aus:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

Wenn der Cookie-Abgleich fehlschlägt, weil der Nutzer kein Google-Cookie hat, lautet die Antwort:

https://ad.network.com/pixel?id=1&google_error=3

Der Fehlercode hängt von der zugrunde liegenden Ursache des Fehlers ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie unter Weiterleitungs-URL-Parameter.

Zur Einzelnutzerliste hinzufügen

Der Parameter google_ula kann im Abgleichs-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn die von Google oder dem Bieter gehostete Abgleichstabelle einen neuen Eintrag für den Nutzer enthält, kann der Bieter ein Abgleich-Tag mit den Parametern google_nid und google_ula platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Cookie-Abgleichs-Workflow zu starten. Weitere Informationen finden Sie in den Einschränkungen für die Aufrufe des Cookie-Abgleichsdiensts. Das entsprechende Abgleich-Tag könnte so aussehen:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://ad.network.com/pixel ist, lautet die Weiterleitungs-URL von Google:

https://ad.network.com/pixel?google_ula=12345,0

Bei einem allgemeinen Fehler – zum Beispiel, wenn kein Google-Cookie für den Nutzer vorhanden ist – enthält die Weiterleitungs-URL den Parameter google_error:

  • https://ad.network.com/pixel?google_error=3

Wenn ein Fehler beim Hinzufügen des Nutzers zur Liste auftritt, wird google_ula in der Weiterleitung angezeigt. Im Gegensatz zum entsprechenden Parameter des Übereinstimmungs-Tags wird hier der Zeitstempel durch einen Statuscode ersetzt, der den Erfolg des Vorgangs anzeigt. Wenn die Anfrage beispielsweise fehlgeschlagen ist, weil das Bieterkonto keinen Zugriff auf die angegebene Nutzerliste hat, lautet die Weiterleitungs-URL:

https://ad.network.com/pixel?google_ula=12345,2

Mehreren Nutzerlisten hinzufügen

Bieter können angeben, dass ein Nutzer mehreren Nutzerlisten hinzugefügt werden soll, indem sie mehrere google_ula-Parameter in das Abgleich-Tag einfügen. In der Praxis kann das so aussehen:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

Der Status des Vorgangs wird für jede Nutzerliste auf ähnliche Weise über verschiedene google_ula-Parameter in der Weiterleitung gemeldet:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

In der Weiterleitung oben sehen Sie, dass der Vorgang für die Nutzerliste mit der ID 45678 erfolgreich war, für die Nutzerliste mit der ID 12345 jedoch fehlgeschlagen ist, da der Bieter keine Berechtigung zum Zugriff darauf hatte.

Wenn Sie die Cookie-Übereinstimmung durchführen und den Nutzer in einer einzigen Anfrage einer Nutzerliste hinzufügen möchten, muss das Abgleich-Tag eines Bieters google_cm und google_ula enthalten:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

Die von Google angegebene Weiterleitungs-URL würde google_gid, google_cver und google_ula enthalten. Das könnte so aussehen:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Speichern einer Übereinstimmung in einer von Google gehosteten Match-Table

Wenn ein Bieter seine Cookie-Daten in einer von Google gehosteten Abgleichstabelle speichern möchte und keine Übereinstimmung mit der Google-Nutzer-ID in seiner eigenen Abgleichstabelle speichern möchte, muss sein Abgleichs-Tag den Parameter google_hm enthalten. Der Wert dieses Parameters muss ein websicherer Base64-codierter String sein. Bei einem Nutzer, dessen uncodierte Cookie-Daten des Bieters Cookie number 1! lauten, würde der codierte Wert Q29va2llIG51bWJlciAxIQ== sein. Dieser Wert würde in einem Match-Tag wie dem folgenden verwendet:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://cookie-monster.com/pixel ist, lautet die Weiterleitungs-URL von Google:

https://cookie-monster.com/pixel

Der Parameter google_gid ist nicht in der Weiterleitung enthalten, da das Match-Tag google_cm nicht enthält und google_hm nicht in erfolgreichen Antworten enthalten ist. Bei zukünftigen Gebotsanfragen für Impressionen für diesen Nutzer erhält der Bieter die gehosteten Abgleichsdaten in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte RTB-Protokoll von Google.

Wenn der Bieter stattdessen ein Abgleich-Tag verwendet hat, bei dem der Wert von google_hm nicht base64-codiert war (z. B. chocolate_chunk!), könnte die Weiterleitungs-URL so aussehen:

https://cookie-monster.com/pixel?google_hm=2

Die obige Weiterleitungs-URL enthält den google_hm-Wert 2. Das bedeutet, dass der Vorgang fehlgeschlagen ist, weil der Wert nicht decodiert werden konnte.

Von Bietern und von Google gehostete Abgleichstabellen mit Nutzerlisten

Wenn ein Bieter neben einer von Google gehosteten Nutzerliste eine eigene Nutzungsliste hostet und ein einzelnes Übereinstimmungs-Tag für den Abgleich mit beiden Tabellen und zum Hinzufügen des Nutzers zu einer bestimmten Nutzerliste benötigt wird, muss das Übereinstimmungs-Tag die Parameter google_cm, google_hm und google_ula enthalten. Wenn die Cookie-Daten des Bieters Cookie number 1! sind, lautet der codierte Wert Q29va2llIG51bWJlciAxIQ==. Das würde zu einem Match-Tag wie dem folgenden führen:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://cookie-monster.com/pixel ist, würde die Weiterleitungs-URL von Google so aussehen:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

Nach Erhalt der Weiterleitung kann der Bieter die in google_gid angegebene Google Nutzer-ID mit den Cookiedaten in der Match-Table abgleichen. Außerdem kann er feststellen, ob die von Google gehosteten Match-Table- und Nutzerlistenvorgänge erfolgreich waren. Daher führt jedes Pre-Targeting, das der Bieter für die Ausrichtung auf die angegebene Nutzerlisten-ID konfiguriert hat, dazu, dass der Bieter Gebotsanfragen für Impressionen vom Nutzer erhält. In diesen Gebotsanfragen erhält der Bieter seine gehosteten Abgleichsdaten ebenfalls in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte Google RTB-Protokoll.