Cookie-Abgleich

Der Cookie-Abgleich ist eine Funktion, mit der Sie Ihr Cookie (z. B. die ID eines Nutzers, der Ihre Website besucht hat) mit einer entsprechenden Bieter-spezifischen Google Nutzer-ID abgleichen und Nutzerlisten erstellen können, mit denen Sie effektivere Gebotsentscheidungen treffen können. In diesem Leitfaden werden Konzepte, die beim Cookie-Abgleich verwendet werden, verschiedene Workflows für den Cookie-Abgleich sowie mögliche Varianten für bestimmte Anwendungsfälle beschrieben.

Konzepte

Domaininhaber setzen die Inhalte von Cookies normalerweise für Nutzer, die ihre Website besuchen. Dadurch werden Nutzer innerhalb dieser Domain identifiziert. Auch wenn zwei Domaininhaber anderen Domains zustimmen würden, dass diese Daten ausgetauscht werden, schränkt das Sicherheitsmodell von Internetbrowsern einen davon ein, ein von einer anderen Domain gesetztes Cookie zu lesen.

Im Zusammenhang mit digitaler Werbung identifiziert Google Nutzer anhand von Cookies, die zur Domain doubleclick.net gehören. Bieter, die an Echtzeitgeboten teilnehmen, haben möglicherweise eine eigene Domain, auf der sie bestimmte Nutzer angeben, für die sie Anzeigen präsentieren möchten. Durch den Cookie-Abgleich kann der Bieter seine Cookies mit denen von Google abgleichen, sodass er feststellen kann, ob eine in einer Gebotsanfrage gesendete Impression mit einem der Zielnutzer verknüpft ist. 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 Dienst für den Cookie-Abgleich erleichtert das Erstellen und Verwalten der Verknüpfung zwischen dem Cookie eines Bieters und der Google Nutzer-ID und ermöglicht es, Nutzerlisten zu füllen.

Match-Tables

Eine Match-Table kann verwendet werden, um eine ID oder andere Daten einer Domain einer anderen zuzuordnen. Bieter können mit dem Cookie-Abgleichdienst eigene Match-Tables füllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google User-ID des Nutzers zuordnen oder eine von Google gehostete Match-Table ausfüllen. Match-Tables sind erforderlich, damit die Bieteranwendung eines Bieters auf Cookie-Daten für den Nutzer zugreift, dem die Impression präsentiert wird.

Von Google gehostete Match-Tables

Zur einfacheren Wartung, zu Latenzverbesserungen und zum Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen empfiehlt es sich, Google das Hosten Ihrer Match-Table zu erlauben. So können Sie einen websicheren, mit Base64 codierten String angeben. Dieser wird im Folgenden als gehostete Abgleichsdaten bezeichnet und der Google Nutzer-ID für einen bestimmten Nutzer zugeordnet. Sobald eine Übereinstimmung hergestellt wurde, kann sie folgendermaßen 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 seiner Google Nutzer-ID abgeglichen haben. Wenn der Gebotsendpunkt für die Verwendung des EZG-Protokolls von Google konfiguriert ist, erhalten Sie diese als decodierte Byte über das Feld BidRequest.hosted_match_data. In der OpenRTB-Implementierung von Google gibt BidRequest.user.buyeruid diese Daten als websicheren, mit Base64 codierten String zurück.

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

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

Nutzerlisten

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

Erste Schritte

Wenn Sie den Cookie-Abgleich einrichten möchten, müssen Sie sich an Ihren Technical Account Manager wenden. Er kann bestimmte Workflows aktivieren und Ihnen bei der Konfiguration folgender Elemente helfen:

  • Netzwerk-ID des Cookie-Abgleichs (NID): Eine String-ID, mit der ein Bieterkonto für den Cookie-Abgleich und andere zugehörige Vorgänge eindeutig identifiziert wird.
  • URL des Cookie-Abgleichs: Die Basis-URL eines Endpunkts, der eingehende Anfragen als Teil des Cookie-Abgleich-Workflows akzeptiert und verarbeitet. Bieter können Makros in diese URL einbetten, um die Reihenfolge der Parameter zu steuern, die in den Cookie-Abgleich-Workflows an sie übergeben werden.
  • Übereinstimmungs-Tag: Das Tag, das Sie für den vom Bieter initiierten Cookie-Abgleich-Workflow im Browser eines Nutzers einfügen müssen. Diese können zusammen mit Anzeigen oder auf Web-Properties außerhalb von Anzeigen platziert werden.
  • URL des Cookie-Abgleichberichts (optional): Im unidirektionalen Cookie-Abgleich-Workflow kann diese optionale URL bereitgestellt werden, um einen Endpunkt anzugeben, an den Fehlerdetails gesendet werden, wenn der Cookie-Abgleich über eine HTTP 302-Weiterleitung fehlschlägt. Standardmäßig werden Antworten nur an diese URL gesendet, wenn beim Cookie-Abgleich ein Fehler aufgetreten ist. Der Bieter kann jedoch verlangen, dass die Weiterleitung immer gesendet wird.
  • URL des Cookie Match Assist: Bei Anzeigenplattformen, bei denen der Workflow für den Cookie Match Assist implementiert ist, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen antworten soll.
  • Kontingent für die Cookie-Abgleichunterstützung: Bei Anzeigenplattformen, die den Workflow „Cookie Match Assist“ implementieren, ist dies die maximale Anzahl von Anfragen, die die Cookie-Abgleich-URL pro Sekunde empfangen kann. So soll verhindert werden, dass CMA-Anfragen die Server der Anzeigenplattform mit Anfragen überlasten.

In jedem der unterstützten Workflows für den Cookie-Abgleich sind Parameter in der Regel in einer nicht garantierten Reihenfolge an die Cookie-Abgleich-URL eines Bieters angehängt. Bieter mit Integrationen, die eine einheitliche Reihenfolge der Parameter erfordern, können Makros in ihre Cookie-Abgleich-URL einfügen, um das Placement zu gewährleisten.

Supported macros

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

Macro Erweiterter 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 Makro

Ein Bieter hat einen Cookie-Abgleich mit einem Endpunkt, der unter https://user.bidder.com.cookies gehostet wird, und seine Implementierung erfordert zusätzlich zu den Pixel-Abgleichparametern vordefinierte Bieter-definierte Parameter in der folgenden Reihenfolge: google_push, google_gid, google_cver und google_error. Dazu legt er seine Cookie-Abgleich-URL auf eine der folgenden Optionen fest:

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 Übereinstimmungsanfrage an diesen Bieter sendet, wird diese folgendermaßen 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-Abgleichdienst von Google unterstützt derzeit drei Workflows für verschiedene Anwendungsfälle, die unten beschrieben werden.

Der bidirektionale Cookie-Abgleich bezieht sich auf einen vom Bieter initiierten Workflow, bei dem ein Übereinstimmungs-Tag im Browser des Nutzers platziert wird, das den Nutzer an Google weiterleitet. Mit diesem Workflow können sowohl Google als auch der Bieter Match-Tables füllen. Unten sehen Sie ein einfaches Beispiel für diesen Workflow.

Schritt 1: Übereinstimmungs-Tag einfügen

Um diesen Vorgang zu starten, muss der Bieter sein Übereinstimmungs-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 zusätzliche Parameter für verschiedene Anwendungsfälle in das Übereinstimmungs-Tag einfügen. Weitere Informationen zu diesen Parametern finden Sie unter URL-Parameter für Übereinstimmungs-Tags.

Schritt 2: Google antwortet mit einer Weiterleitung und den Abgleichsdaten

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 ausgegeben wird. Die Weiterleitung enthält Suchparameter, die die Google Nutzer-ID und die Versionsnummer in der URL angeben. Der Bieter erhält ebenfalls sein Cookie in den Anfrageheadern. In der Praxis könnte die Weiterleitungs-URL für das einfache Übereinstimmungs-Tag für eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel angegeben ist, 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. Bieter, die eine Match-Table hosten möchten, sollten genau den vom Cookie-Abgleichdienst zurückgegebenen String speichern. Bei nachfolgenden Gebotsanfragen entspricht dies den Werten, die im RTB-Protokoll von Google über BidRequest.google_user_id oder in der OpenRTB-Implementierung von Google über BidRequest.user.id angegeben werden.

Die in google_cver angegebene Version gibt die numerische Versionsnummer für die Google Nutzer-ID an. Die Google Nutzer-ID für einen bestimmten Nutzer ändert sich selten. Danach wird sie erhöht.

Wenn Google bei der Verarbeitung Ihrer Abgleichsanfrage auf einen Fehler stößt, wird stattdessen ein google_error-Parameter angegeben.

Schritt 3: Die Gebotsfunktion verarbeitet die Weiterleitung und antwortet mit einem Pixel

Der Bieter erhält eine Weiterleitung zu seiner URL zum Cookie-Abgleich, einschließlich der Parameter, die er im ersten Schritt und die von Google im zweiten Schritt angegeben hat. Zusätzlich erhalten sie ihr Cookie auch in den HTTP-Headern. Wenn der Vorgang erfolgreich war, kann ein Bieter, der eine eigene Match-Table hostet, sein Cookie der Google Nutzer-ID zuordnen, die in der Antwort enthalten ist. Es wird empfohlen, dass Bieter genau den vom Cookie-Abgleichdienst zurückgegebenen String speichern.

Ist der Vorgang fehlgeschlagen, erhält der Bieter einen google_error-Parameter in der Weiterleitung. Dabei handelt es sich um einen numerischen Wert, der verschiedenen Fehlerstatus entspricht, die den jeweiligen aufgetretenen Fehler identifizieren. Weitere Informationen zu möglichen Fehlerwerten finden Sie hier. Wenn Sie eine Fehlermeldung erhalten, können Sie versuchen, einen neuen Abgleich für diesen Nutzer durchzuführen, indem Sie ein neues Übereinstimmungs-Tag einfügen.

Der Bieter muss immer mit einem unsichtbaren 1 × 1-Pixelbild antworten oder alternativ die HTTP 204-Antwort Kein Inhalt zurückgeben.

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

URL-Parameter für Übereinstimmungs-Tag

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden.
google_cm Gibt dem Cookie-Abgleichdienst 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. Legt das Cookie von Google für den Nutzer fest, falls keins 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. Hierdurch wird der Cookie-Abgleichdienst von Google angewiesen, kein Cookie für den Nutzer zu setzen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_hm

Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table speichern möchte.

Der Wert ist ein websicherer, mit 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 soll, die HTTP 302-Weiterleitung an die codierte URL für dieses Übereinstimmungs-Tag zu senden. Dadurch kann Google in einem verketteten Aufruf an Partner ganz vorne platziert werden. Dies führt zu einem Fehler, wenn die Angabe 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 ist 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 DSGVO-Einschränkungen in Bezug auf die Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Auswirkungen auf die Berechtigung zum Cookie-Abgleich in der Dokumentation zu Version 2.0 des IAB TCF von Authorized Buyers.

Beispiel: gdpr=1
gdpr_consent Ein TC-String, der die Endnutzereinwilligung darstellt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Wie wird der TC-String übergeben? in der Dokumentation zu Version 2.0 des IAB TCF 2.0 von Authorized Buyers.
process_consent Gibt an, dass der Bieter die Endnutzereinwilligung für die Datenverwendung eingeholt hat, die in der Google-Richtlinie zur Einwilligung der Nutzer in der EU angegeben ist.

Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder wenn für die Anfrage andere Einwilligungsparameter 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 dann als Parameter an die Weiterleitungs-URL angehängt werden. Vom Bieter definierte Parameter, die mit dem Präfix google_ benannt sind, werden ignoriert, da sie von Google für die zukünftige Entwicklung reserviert sind und die Reihenfolge der Parameter nicht garantiert ist. Ein Übereinstimmungs-Tag mit vom Bieter definierten Parametern kann so aussehen:

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

Weiterleitungs-URL-Parameter

Die Weiterleitungs-URL wird aus der Cookie-Abgleich-Basis-URL erstellt, die für das Konto eines Bieters konfiguriert wurde. Sie umfasst google_ und vom Bieter definierte Parameter, je nachdem, welche im Übereinstimmungs-Tag angegeben sind. Die folgenden google_-Antwortparameter sind definiert:

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

Ein ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wenn es empfangen wird, bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen google_-Antwortparameter festgelegt werden. Folgende Fehlerwerte werden unterstützt:

  • 1: Der Nutzer hat ein Google-Cookie, hat jedoch das Tracking mithilfe dieses Cookies deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Beispielsweise wurde eine No-Op-Anfrage empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google speichert das Cookie nicht über den Cookie-Abgleichdienst.
  • 4: Es wurden widersprüchliche 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: In einer Weiterleitung an einen Google-Server als Teil einer bidirektionalen Anfrage zum Pixel-Abgleich wurde ein ungültiger google_push-Parameter übergeben. Bei der Weiterleitung muss google_push auf den Wert festgelegt werden, der in der ersten Pixelanfrage an Sie übergeben wurde.
  • 6: Im Übereinstimmungs-Tag wurde eine ungültige NID angegeben.
  • 7: Ein ungültiges Cookie wurde erkannt.
  • 8: eingestellt. Kein Cookie gefunden.
  • 9: Kein Cookie gefunden. Es wird versucht, ein Testcookie zu setzen.
  • 10: Der Parameter google_redir wurde ohne Angabe von google_hm oder zusätzlich zu google_cm verwendet.
  • 15: Die Anfrage stammt aus einer Region, in der Google verlangt, dass die Match-Table 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 der Zulassungsliste für das Schreiben von Einträgen in die gehostete Match-Table.
  • 2 – Decodierungsfehler: Der Parameterwert konnte nicht decodiert werden.
  • 3 – Nutzlast zu lang: Der Parameterwert wurde in Daten von mehr als 24 Byte 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 Hinzufügungsvorgangs zur 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 google_ula-Vorgang kann einen der folgenden Statuscodes zurückgeben:

  • 0: Kein Fehler. Der Nutzer wurde der Nutzerliste hinzugefügt.
  • 2 – Zugriff verweigert. Sie sind nicht berechtigt, Nutzer zur angegebenen Nutzerliste hinzuzufügen.
  • 5: Ungültige Nutzerlisten-ID. Die angegebene Nutzerlisten-ID ist ungültig.
  • 6: Geschlossene Attribut-ID. Die bereitgestellte Nutzerlisten-ID ist geschlossen.
  • 10: Interner Fehler. Beim Cookie-Abgleichdienst ist ein interner Fehler aufgetreten. Sie können den Nutzer noch einmal zuordnen.

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

Szenario 1: Der Nutzer löscht seine Cookies und surft auf einer Website.

Jane löscht alle Cookies im Cache. Anschließend besuchen sie die Startseite von ExampleNews.com.

Folgendes geschieht:

  1. BeispielNews.com wird gerendert und ruft Anzeigen von 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 Gebotsanwendung von FinestDSP empfängt und verarbeitet die Gebotsanfrage und sendet ihre Gebotsantwort.
  4. Google erhält Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP, die eine Anzeige mit einem Übereinstimmungs-Tag (Pixel) angibt.
  5. FinestDSP gewinnt die Auktion. Google liefert Jane die Anzeige und das Übereinstimmungs-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-Abgleichdienst liest Susannes Google-Cookie und sendet Erikas Browser eine Weiterleitung an die Cookie-Abgleich-URL von FinestDSP mit den festgelegten Parametern google_user_id und google_cver.
  8. Janas Browser lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
  9. Der Cookie-Abgleich-Endpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, die von Google festgelegte URL-Parameter und ihr Cookie für Jane in den HTTP-Headern enthält. FinestDSP kann jetzt die Zuordnung ihres Cookies zur google_user_id in der Match-Table speichern.
  10. FinestDSP reagiert mit einem unsichtbaren 1x1-Pixel auf die Weiterleitung.
Szenario 2: Nutzer mit vorhandener Zuordnung

Eine Woche nach Szenario 1 besucht Jane noch einmal ExampleNews.com. Nachdem Jane sowohl das Bieter- als auch das Ad Manager-Cookie auf ihrem Computer hat, funktioniert der Abgleich so.

  1. Die Webseite wird gerendert, sodass Google (Ad Manager) Anzeigen anfordert, die auf der Seite gerendert werden.
  2. Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die entsprechenden Bieter, einschließlich FinestDSP.
  3. FinestDSP empfängt die Gebotsanfrage, einschließlich Signalen wie dem google_user_id.
  4. FinestDSP sucht nach der google_user_id in ihrer Match-Table und findet das mit Jane verknüpfte Cookie, das eine Woche zuvor erstellt wurde (in Szenario 1).
  5. Basierend auf den mit dem Cookie verknüpften Informationen gibt die Gebotslogik von FinestDSP ein Gebot für die Impression ab und gewinnt die Auktion.
  6. Jane sieht möglicherweise eine auf ihre Interessen zugeschnittene Anzeige, basierend auf den Informationen, die FinestDSP besitzt.

Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit der Ausnahme, dass nur Google eine Match-Table hostet und füllt. Dies kann in Fällen verwendet werden, in denen die Gebotsfunktion keine Google Nutzer-IDs in einer eigenen Match-Table hosten darf. Zur Verwendung dieses Ablaufs müssen Bieter Google erlauben, die Match-Table zu hosten. Außerdem können sie google_cm in Anfragen an den Cookie-Abgleichdienst von Google nicht mehr angeben und erhalten daher keine google_gid zum Ausfüllen der eigenen Match-Table. Sobald Google eine Übereinstimmung für einen Nutzer ermittelt hat, können Bieter ihn anhand ihrer eigenen Cookie-Daten zu Nutzerlisten hinzufügen. Analog dazu schließen Gebotsanfragen für diese Nutzer die Google Nutzer-ID aus, enthalten aber gehostete Daten zum Abgleich. Ein einfaches Beispiel für den überarbeiteten Workflow finden Sie in den folgenden Schritten.

Um diesen Vorgang zu starten, muss eine Gebotsfunktion ein Übereinstimmungs-Tag platzieren, damit 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 der Browser des Nutzers über das Übereinstimmungs-Tag zu Ihrer Cookie-Abgleich-URL weitergeleitet werden. Wenn eine Cookie-Abgleich-URL beispielsweise als https://ad.network.com/pixel konfiguriert ist, sieht sie so aus:

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

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

Vom Endpunkt des Cookie-Abgleichs des Bieters muss eine Weiterleitung zum Cookie-Abgleichdienst von Google erfolgen. Dabei muss der Parameter google_hm mit seinen websicheren base64-codierten Cookie-Daten gefüllt werden. 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, die die von Ihnen angegebenen Parameter enthält.

Schritt 4: Google liefert Pixel bei Erfolg oder Fehlerweiterleitung, wenn eine Berichts-URL angegeben wurde

Wenn der Cookie-Abgleich erfolgreich ist oder wenn für das Konto des Bieters keine URL für den Cookie-Abgleichbericht angegeben wurde, liefert Google standardmäßig ein transparentes 1x1-Pixel aus und der Workflow endet hier. Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die gehosteten Übereinstimmungsdaten des Bieters in BidRequest.hosted_match_data für das Google-Protokoll oder BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google. Bieter können Nutzerlisten auch anhand der von ihnen angegebenen gehosteten Abgleichsdaten füllen.

Sollte ein Fehler auftreten, sendet Google eine Weiterleitung an die URL des Cookie-Abgleichberichts des Bieters. Dabei wird die Ursache des im google_error-Parameter angegebenen Fehlers verursacht. Wenn die URL des Cookie-Abgleichberichts des Bieters https://ad.network.com/report lautet, sieht die Weiterleitungs-URL so aus:

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

Der Browser des Nutzers leitet den Nutzer zur URL des Cookie-Abgleichberichts des Bieters weiter, einschließlich des Fehlergrunds (falls vorhanden), der von Google im Parameter google_error angegeben wurde. Weitere Informationen zur Interpretation des Fehlercodes finden Sie in der Parameterbeschreibung.

Schritt 6: Der Bieter liefert ein transparentes 1x1-Pixel aus.

Der Bieter muss daraufhin ein transparentes 1 × 1-Pixel an den Browser des Nutzers senden.

Der Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen wird im folgenden Diagramm veranschaulicht. Anfragen und Antworten werden durch einen Pfeil dargestellt und die Datenelemente, die sie begleiten, 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. Legt das Cookie von Google für den Nutzer fest, falls keins 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. Hierdurch wird der Cookie-Abgleichdienst von Google angewiesen, kein Cookie für den Nutzer zu setzen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_hm

Enthält Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table speichern möchte.
google_redir Eine codierte URL, an die Google eine HTTP 302-Weiterleitung senden soll. Die angegebene URL erhält Weiterleitungen mit dem Parameter google_error sowohl für Fehler als auch für erfolgreiche Vorgänge.
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 ist 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 DSGVO-Einschränkungen in Bezug auf die Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Auswirkungen auf die Berechtigung zum Cookie-Abgleich in der Dokumentation zu Version 2.0 des IAB TCF von Authorized Buyers.

Beispiel: gdpr=1
gdpr_consent Ein TC-String, der die Endnutzereinwilligung darstellt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Wie wird der TC-String übergeben? in der Dokumentation zu Version 2.0 des IAB TCF 2.0 von Authorized Buyers.
process_consent Gibt an, dass der Bieter die Endnutzereinwilligung für die Datenverwendung eingeholt hat, die in der Google-Richtlinie zur Einwilligung der Nutzer in der EU angegeben ist.

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

Beispiel: process_consent=T
Parameter Beschreibung
google_error

Ein ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wenn es empfangen wird, bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen google_-Antwortparameter festgelegt werden. Folgende Fehlerwerte werden unterstützt:

  • 1: Der Nutzer hat ein Google-Cookie, hat jedoch das Tracking mithilfe dieses Cookies deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Beispielsweise wurde eine No-Op-Anfrage empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google speichert das Cookie nicht über den Cookie-Abgleichdienst.
  • 4: Es wurden widersprüchliche 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: In einer Weiterleitung an einen Google-Server als Teil einer bidirektionalen Anfrage zum Pixel-Abgleich wurde ein ungültiger google_push-Parameter übergeben. Bei der Weiterleitung muss google_push auf den Wert festgelegt werden, der in der ersten Pixelanfrage an Sie übergeben wurde.
  • 6: Im Übereinstimmungs-Tag wurde eine ungültige NID angegeben.
  • 7: Ein ungültiges Cookie wurde erkannt.
  • 8: eingestellt. Kein Cookie gefunden.
  • 9: Kein Cookie gefunden. Es wird versucht, ein Testcookie zu setzen.
  • 10: Der Parameter google_redir wurde ohne Angabe von google_hm oder zusätzlich zu google_cm verwendet.
  • 15: Die Anfrage stammt aus einer Region, in der Google verlangt, dass die Match-Table 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 Pixel-Abgleich

Der bidirektionale Pixel-Abgleich ist ein Workflow für den Cookie-Abgleichdienst von Google, bei dem Google versucht, eine Google Nutzer-ID einem algorithmisch ausgewählten Bieter, nicht dem Gewinner der Echtzeitgebotsauktion, zuzuordnen. Wenn eine Anzeige platziert wird, fügt Google ein Übereinstimmungs-Tag ein, das den Browser des Nutzers anweist, ein transparentes Pixel aus 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 fügt ein Übereinstimmungs-Tag ein

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 Pixel-Abgleich-Tag kombiniert die Cookie-Abgleich-URL des Bieters mit zusätzlichen Parametern, die der Bieter zum Ausfüllen der Match-Table verwenden kann. Für eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel angegeben ist, ist sie so strukturiert:

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

Bieter, die Anfragen zum Pixelabgleich erhalten, müssen mit einer Weiterleitung zum Cookie-Abgleichdienst von Google antworten. Diese ist so aufgebaut:

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

Beachten Sie, dass die obige Weiterleitungs-URL der URL der URL ähnelt, die im Übereinstimmungs-Tag für den durch den Bieter initiierten Cookie-Abgleich-Workflow verwendet wird. Beim Pixel-Abgleich wird der Parameter google_cm durch den Parameter google_push ersetzt. Sein Wert muss dem Wert entsprechen, der von Google in der Anfrage angegeben wurde. Ähnlich wie beim vom Bieter initiierten Workflow können zusätzliche Parameter für zusätzliche Anwendungsfälle festgelegt werden.

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

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

Workflowdiagramm: Pixel-Abgleich

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

Anfrageparameter für Übereinstimmungs-Tags von Google

Parameter Beschreibung
google_gid Google Nutzer-ID Für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammen, wird dies immer im Übereinstimmungs-Tag von Google angegeben.
google_cver Die Cookie-Version. Dieser wird immer im Übereinstimmungs-Tag von Google angegeben.
google_push Gibt an, dass diese Anfrage den Pixel-Abgleich-Workflow initiiert. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort des Bieters zurückgegeben werden.

Weiterleitungsparameter für den Bieter-Pixel-Abgleich

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 diese Weiterleitung den Pixel-Abgleich-Workflow abschließt. Hier muss der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag angegeben werden.
google_hm

Enthält Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table 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 ist 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.

Von Google initiiert: Unidirektionaler Pixel-Abgleich

Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow darin, dass das Übereinstimmungs-Tag von Google keinen Parameter enthält, der die Google User-ID angibt. Es wird jedoch weiterhin eine von Google gehostete Match-Table gefüllt. Dies kann in Fällen verwendet werden, in denen der Bieter nicht berechtigt ist, Google Nutzer-IDs in einer eigenen Match-Table zu hosten. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.

Schritt 1: Google fügt ein Übereinstimmungs-Tag ein

Google platziert ein Übereinstimmungs-Tag für einen algorithmisch ausgewählten Bieter. Das Übereinstimmungs-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 von der Cookie-Abgleich-URL des Bieters ein Pixel an, einschließlich des Cookies des Bieters in den HTTP-Headern.

Vom Endpunkt des Cookie-Abgleichs des Bieters muss eine Weiterleitung zum Cookie-Abgleichdienst von Google erfolgen. Dabei muss der Parameter google_hm mit seinen websicheren base64-codierten Cookie-Daten gefüllt werden. 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, die die von Ihnen angegebenen Parameter enthält. Wenn der Vorgang erfolgreich war, enthalten die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die gehosteten Abgleichsdaten des Bieters in BidRequest.hosted_match_data für das Google-Protokoll oder BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google. Bieter können auch Nutzerlisten 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 Cookie-Abgleich-Workflows 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 mithilfe von Algorithmen eine teilnehmende Anzeigenplattform aus und platziert ein Assist-Tag für den Cookie-Abgleich, das folgende Struktur hat:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

  2. Das CMA-Übereinstimmungs-Tag von Google führt dazu, dass die Cookie-Abgleich-URL der Anzeigenplattform eine Pixelanfrage empfängt.

  3. Die Anfrage wird an den Endpunkt des Cookie-Abgleichs der Anzeigenplattform gesendet, bei dem der Cookie-Abgleichdienst für den Abgleich der Nutzer-ID mit einem Bieter zuständig ist. Im folgenden Diagramm antwortet der Cookie-Abgleichdienst der Anzeigenplattform dem Browser des Nutzers mit einer Weiterleitung an einen der Endpunkte seiner Bieter.
  4. Der Bieter empfängt die Anfrage zusammen mit allen von der Anzeigenplattform festgelegten Parametern, um die User-ID mit seinem Cookie abzugleichen.

Einschränkungen

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

Bieter sind dafür verantwortlich, die Anzahl der Aufrufe an den Cookie-Abgleichdienst für Nutzer zu beschränken, für die in der von Google gehosteten Match-Table ein neuer Eintrag vorhanden ist. Ein Eintrag in der gehosteten Match-Table kann nach 14 Tagen als abgelaufen angesehen werden. Danach kann er aktualisiert werden.

Auf alle Pixel-Abgleichanfragen antworten

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

HTTPS-Endpunkte verwenden

Endpunkte, die in allen Cookie-Abgleich-Workflows verwendet werden, müssen HTTPS verwenden.

Wenn Sie auf eine Pixel-Abgleichanfrage antworten, die Sie über HTTPS erhalten haben, müssen Sie Ihre Nutzer über HTTPS zum Cookie-Abgleichdienst weiterleiten. Ebenso muss ein Endpunkt für den Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, ebenfalls HTTPS verwenden. Wenn Sie häufiger als alle zwei Minuten Anfragen über HTTP an Google senden, wird die Anzahl der Übereinstimmungsanfragen, die an Ihr Konto gesendet werden, gedrosselt.

Anfragen zum Cookie-Abgleich, die der Google-Richtlinie zur Einwilligung der Nutzer in der EU unterliegen, sollten die Einwilligung des Endnutzers enthalten. Solche Anfragen müssen darauf hinweisen, dass eine Einwilligung auf eine der folgenden Arten eingeholt wurde:

Beispiele

Die folgenden Beispiele veranschaulichen, wie der Cookie-Abgleichdienst zum Erreichen bestimmter Ziele verwendet wird. Sofern nicht anders angegeben, wird angenommen, dass der Nutzer, für den eine Aktion ausgeführt wird, nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen stammt.

Eine vom Bieter gehostete Match-Table ausfüllen

Eine Gebotsfunktion kann den Cookie-Abgleich-Workflow verwenden, um ihre eigene Match-Table zu füllen, indem nur die Parameter google_nid und google_cm im Übereinstimmungs-Tag angegeben werden. Das könnte so aussehen:

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

Wenn die Cookie-Abgleich-URL des Bieters auf https://ad.network.com/pixel?id=1 gesetzt ist und der Cookie-Abgleich erfolgreich ist, könnte die Weiterleitung, die Google als Antwort auf das Übereinstimmungs-Tag des Bieters sendet, so aussehen:

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 Fehlerursache ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie unter Parameter für die Weiterleitungs-URL.

Zur Liste mit einzelnen Nutzern hinzufügen

Der google_ula-Parameter kann im Übereinstimmungs-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn in der von Google oder der vom Bieter gehosteten Match-Table ein neuer Eintrag für den Nutzer vorhanden ist, kann die Gebotsfunktion ein Übereinstimmungs-Tag mit den Parametern google_nid und google_ula platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Cookie-Abgleich-Workflow zu starten. Weitere Informationen finden Sie in den Einschränkungen zum Aufrufen des Cookie-Abgleichdiensts. Das entsprechende Übereinstimmungs-Tag könnte so aussehen:

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

Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://ad.network.com/pixel lautet, lautet die Weiterleitungs-URL von Google:

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

Bei einem allgemeinen Fehler – beispielsweise, 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 speziell beim Hinzufügen des Nutzers zur Liste auftritt, wird google_ula in der Weiterleitung zurückgegeben. Im Gegensatz zum entsprechenden Übereinstimmungs-Tag-Parameter 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 hatte, lautet die Weiterleitungs-URL:

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

Zu mehreren Nutzerlisten hinzufügen

Bieter können festlegen, dass ein Nutzer mehreren Nutzerlisten hinzugefügt werden soll, indem sie mehrere google_ula-Parameter in das Übereinstimmungs-Tag aufnehmen. In der Praxis könnte 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 in ähnlicher 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 obigen Weiterleitung sehen wir, dass der Vorgang für die Nutzerliste mit der ID 45678 erfolgreich war, für die Nutzerlisten-ID 12345 jedoch fehlgeschlagen ist, da der Bieter keine Zugriffsberechtigung hatte.

Damit der Cookie-Abgleich durchgeführt und der Nutzer in einer Einzelanfrage einer Nutzerliste hinzugefügt werden kann, sollte das Übereinstimmungs-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. Dies könnte so aussehen:

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

Übereinstimmung in einer von Google gehosteten Match-Table speichern

Wenn eine Gebotsfunktion ihre Cookiedaten in einer von Google gehosteten Match-Table speichern und nicht die Übereinstimmung mit der Google Nutzer-ID in ihrer eigenen Match-Table speichern möchte, muss das Übereinstimmungs-Tag den Parameter google_hm enthalten. Der Wert muss ein websicherer base64-codierter String sein. Für einen Nutzer, bei dem die nicht codierten Cookiedaten des Bieters Cookie number 1! sind, lautet der codierte Wert Q29va2llIG51bWJlciAxIQ==, der in einem Übereinstimmungs-Tag wie dem folgenden verwendet wird:

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

Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://cookie-monster.com/pixel lautet, lautet die Weiterleitungs-URL von Google:

https://cookie-monster.com/pixel

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

Wenn der Bieter stattdessen ein Übereinstimmungs-Tag verwendet, 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. Dies deutet darauf hin, dass der Vorgang fehlgeschlagen ist, da der Wert nicht decodiert werden konnte.

Bieter und von Google gehostete Match-Tables mit Nutzerlisten

Wenn eine Gebotsfunktion neben einer von Google gehosteten Nutzerliste auch eine eigene Nutzungsliste hostet und ein einzelnes Übereinstimmungs-Tag mit beiden Tabellen verknüpfen und den Nutzer einer bestimmten Nutzerliste hinzufügen möchte, muss das Übereinstimmungs-Tag die Parameter google_cm, google_hm und google_ula enthalten. Wenn die Cookiedaten des Bieters Cookie number 1! sind, ist der codierte Wert Q29va2llIG51bWJlciAxIQ==, wodurch ein Übereinstimmungs-Tag wie das folgende erzeugt wird:

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

Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://cookie-monster.com/pixel lautet, sieht die Weiterleitungs-URL von Google so aus:

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

Beim Empfang der Weiterleitung kann der Bieter die in google_gid angegebene Google Nutzer-ID mit seinen Cookiedaten in der Match-Table abgleichen. Außerdem kann er feststellen, ob die von Google gehosteten Match-Table- und Nutzerlistenvorgänge erfolgreich waren. Infolgedessen erhält der Bieter bei jedem Pre-Targeting, das für die Ausrichtung auf die angegebene Nutzerlisten-ID konfiguriert ist, Gebotsanfragen für Impressionen des Nutzers. Bei diesen Gebotsanfragen erhält der Bieter seine gehosteten Daten zum Abgleich in BidRequest.hosted_match_data (für das RTB-Protokoll von Google) oder in BidRequest.user.buyeruid (für die OpenRTB-Implementierung von Google).