Cookie-Abgleich

Beim Cookie-Abgleich wird Ihr Cookie, z. B. eine ID für einen Nutzer, der Ihre Website besucht hat, mit einer entsprechenden bieterspezifischen Google-Nutzer-ID abgeglichen. Daraufhin lassen sich Nutzerlisten erstellen, die es Ihnen ermöglichen, effektivere Gebote abzugeben. In diesem Leitfaden werden die Konzepte beschrieben, die beim Cookie-Abgleich verwendet werden, sowie verschiedene Cookie-Abgleich-Workflows und alle Variationen, die sie für bestimmte Anwendungsfälle haben können.

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 sich darauf einigen, diese Daten auszutauschen, wird durch das Sicherheitsmodell von Internetbrowsern verhindert, dass eine Domain einen von einer anderen Domain gesetzten Cookie liest.

Im Kontext digitaler Werbung identifiziert Google Nutzer mit Cookies, die zur Domain doubleclick.net gehören. Bieter, die an Echtzeitgeboten teilnehmen, haben möglicherweise eine eigene Domain, in der sie eine Reihe von Nutzern identifizieren, denen sie Anzeigen präsentieren möchten. Beim Cookie-Abgleich kann der Bieter seine Cookies mit denen von Google abgleichen. So kann er feststellen, ob eine Impression, die in einer Gebotsanfrage gesendet wird, mit einem der Nutzer verknüpft ist, auf die er ausgerichtet ist. Er erhält entweder seine eigenen Cookie-Daten 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-Abgleichdienst erleichtert das Erstellen und Verwalten 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 Abgleichstabelle können Sie eine ID oder andere Daten aus einer Domain einer anderen zuordnen. Bieter können den Cookie Matching Service verwenden, um ihre eigenen Match-Tabellen zu füllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google-Nutzer-ID des Nutzers zuordnen, oder um eine von Google gehostete Match-Tabelle zu füllen. Abgleichstabellen sind für die Gebotsanwendung eines Bieters erforderlich, um auf Cookie-Daten für den Nutzer zuzugreifen, dem die Impression präsentiert wird.

Von Google gehostete Match-Tables

Für eine einfachere Wartung, eine geringere Latenz und den Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen wird empfohlen, Google die Möglichkeit zu geben, Ihre Abgleichstabelle zu hosten. So können Sie einen websicheren Base64-codierten String (im Folgenden als gehostete Abgleichsdaten bezeichnet) angeben, der der Google-Nutzer-ID für einen bestimmten Nutzer zugeordnet wird. Sobald eine Übereinstimmung gefunden wurde, kann sie auf folgende Weise 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 des Nutzers abgeglichen haben. Google gibt BidRequest.user.buyeruid als websicheren Base64-codierten String an.

  • Nutzerlisten: Nutzerlisten können entweder mit Google-Nutzer-IDs oder mit 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 Sie weniger relevante Impressionen für Nutzer außerhalb Ihres Cookie-Bereichs ausschließen.

Nutzerlisten

Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Nachdem Sie diese Listen erstellt haben, können Sie sie mit den folgenden Cookie-Abgleich-Workflows oder über den Bulk Uploader Service füllen.

Erste Schritte

Wenn Sie Cookie Matching verwenden möchten, müssen Sie sich an Ihren Technical Account Manager wenden. Er kann bestimmte Arbeitsabläufe aktivieren und Ihnen bei der Konfiguration der folgenden Elemente helfen:

  • 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 im Rahmen von Cookie-Übereinstimmungsworkflows an sie übergeben werden.
  • Abgleichs-Tag: Das Tag, das Sie im Browser eines Nutzers für den vom Bieter initiierten Cookie-Abgleichs-Workflow platzieren müssen. Sie können zusammen mit Anzeigen ausgeliefert oder auf Web-Properties außerhalb von Anzeigen platziert werden.
  • URL des Berichts zum Cookie-Abgleich (optional): Im einseitigen Cookie-Abgleichsworkflow ist dies eine optionale URL, über die ein Endpunkt angegeben werden kann, an den Fehlerdetails gesendet werden, falls der Cookie-Abgleich aufgrund einer HTTP-302-Weiterleitung fehlschlägt. Standardmäßig werden Antworten nur dann an diese URL gesendet, wenn ein Fehler beim Cookie-Abgleich aufgetreten ist. Bieter können jedoch anfordern, dass die Weiterleitung immer gesendet wird.
  • URL zur Unterstützung des Cookie-Abgleichs: Für Börsen, die den Workflow zur Unterstützung des Cookie-Abgleichs implementieren, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen reagieren soll.
  • Kontingent für Cookie Match Assist: Für Exchanges, die den Cookie Match Assist-Workflow implementieren, ist dies die maximale Anzahl von Anfragen, die ihre Cookie-Abgleichs-URL pro Sekunde empfangen kann. So soll verhindert werden, dass die Server der Börse durch CMA-Anfragen überlastet werden.

Bei allen unterstützten Cookie-Abgleichsworkflows werden an die Cookie-Abgleichs-URL eines Bieters in der Regel Parameter in einer nicht garantierten Reihenfolge angehängt. Bieter mit Integrationen, die eine konsistente Reihenfolge der Parameter erfordern, können Makros in ihre Cookie-Abgleichs-URL einfügen, um deren Platzierung anzugeben.

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. Die unterstützten Makros und ihre erweiterten Werte sind:

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

Makrobeispiel

Ein Bieter hat eine Cookie-Abgleichintegration mit einem Endpunkt, der unter https://user.bidder.com/cookies gehostet wird. Für die Implementierung sind neben den Pixel Matching-Parametern auch voreingestellte, vom Bieter definierte Parameter in der folgenden Reihenfolge erforderlich: google_push, google_gid, google_cver und google_error. Der Bieter kann dies erreichen, indem er die URL für den Cookie-Abgleich auf Folgendes festlegt:

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 Matching Service von Google unterstützt die folgenden drei Workflows.

Beim bidirektionalen Cookie-Abgleich wird ein vom Bieter initiierter Workflow verwendet. Dabei wird ein Abgleichs-Tag im Browser des Nutzers platziert, das ihn zu Google weiterleitet. In diesem Workflow können sowohl Google als auch der Bieter Abgleichstabellen erstellen. Im Folgenden finden Sie ein Beispiel für diesen Workflow.

Schritt 1: Abgleichs-Tag platzieren

Damit dieser Ablauf gestartet werden kann, muss der Bieter sein Abgleich-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Ein Abgleichs-Tag, das dem Bieter nur die Google-Nutzer-ID zurückgibt, kann so strukturiert sein:

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

Es gibt zusätzliche Parameter, die Sie in das Abgleichs-Tag einfügen können, um verschiedene Anwendungsfälle zu erfüllen. Weitere Informationen zu diesen Parametern finden Sie unter URL-Parameter für Abgleichs-Tags.

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

Das Abgleich-Tag bewirkt, dass der Cookie Matching Service von Google eine Anfrage vom Browser des Nutzers erhält, die eine HTTP 302-Weiterleitung an die Cookie-Abgleich-URL des Bieters auslöst. Die Weiterleitung enthält Suchparameter, die die Google-Nutzer-ID und ihre Versionsnummer in der URL angeben. Der Bieter erhält außerdem sein Cookie in den Anfrageheadern. In der Praxis könnte die Weiterleitungs-URL für das vorherige Abgleich-Tag für eine Cookie-Abgleichs-URL, die als https://ad.network.com/pixel angegeben ist, so aussehen:

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

Die über den Parameter google_gid übergebene Google-Nutzer-ID ist ein String ohne Padding, der websicher mit Base64 codiert ist. Bietern, die eine Abgleichstabelle hosten, wird empfohlen, den genauen String zu speichern, der vom Cookie Matching Service zurückgegeben wird. In nachfolgenden Gebotsanfragen entspricht dies den Werten, die über BidRequest.user.id angegeben werden.

Die in google_cver angegebene Version ist die numerische Versionsnummer für die Google-Nutzer-ID. Die Google-Nutzer-ID für einen bestimmten Nutzer ändert sich nur selten. Danach wird sie inkrementiert.

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

Schritt 3: Der Bieter verarbeitet die Weiterleitung und antwortet mit einem Pixel.

Der Bieter erhält eine Weiterleitung zu seiner Cookie-Abgleichs-URL, die die Parameter enthält, die er im ersten Schritt angegeben hat, sowie die Parameter, die Google im zweiten Schritt bereitgestellt hat. Außerdem erhalten sie ihr Cookie in den HTTP-Headern. Wenn der Vorgang erfolgreich war, kann ein Bieter, der seine eigene Abgleichstabelle hostet, seinen Cookie mit der in der Antwort enthaltenen Google-Nutzer-ID abgleichen. Es wird empfohlen, dass Bieter den genauen String speichern, der vom Cookie Matching Service zurückgegeben wird.

Wenn der Vorgang nicht erfolgreich war, erhält der Bieter im Redirect den Parameter google_error. Dies ist ein numerischer Wert, der verschiedenen Fehlerstatus entspricht und den aufgetretenen Fehler angibt. Weitere Informationen zu den möglichen Fehlerwerten finden Sie in der Beschreibung des URL-Parameters google_error. Wenn Sie eine Fehlermeldung erhalten, können Sie versuchen, den Nutzer noch einmal zuzuordnen, indem Sie ein neues Abgleich-Tag platzieren.

Der Bieter muss immer mit einem unsichtbaren 1 × 1-Pixelbild antworten oder alternativ eine HTTP 204-Antwort mit dem Status No Content zurückgeben.

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

URL-Parameter für Tag-Abgleich

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Bidders-Ressource abgerufen werden.
google_cm Gibt dem Cookie-Abgleichsdienst von Google an, dass ein 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. Wenn der Parameter weggelassen wird, führt das zu einem Fehler, wenn kein Cookie vorhanden ist.
google_no_sc Dieser Parameter wurde eingestellt. Dies weist den Cookie Matching Service von Google darauf hin, dass kein Cookie für den Nutzer gesetzt werden soll, wenn noch keines 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 (Auffüllung optional). Die Rohdaten dürfen maximal 40 Byte groß sein. Beispiel: Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.
google_redir Ein URL-codierter String, den ein Bieter angeben kann, wenn er möchte, dass Google die HTTP 302-Weiterleitung an die codierte URL für dieses Abgleichs-Tag sendet. So kann Google bei einem verketteten Aufruf an Partner an erster Stelle stehen. Das 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 DSGVO-Beschränkungen für die Datennutzung unterliegt. Weitere Informationen finden Sie in der Dokumentation zum IAB TCF 2.0 für Authorized Buyers unter Anforderungen an die Einwilligung der Nutzer in der EU oder Auswirkungen auf die Eignung für den Cookie-Abgleich.

Beispiel: gdpr=1
gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unter Anforderungen an die Nutzereinwilligung in der EU oder in der Dokumentation zu Authorized Buyers IAB TCF 2.0 im Abschnitt 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 als Parameter an die Weiterleitungs-URL angehängt werden. Hinweis: Bieterdefinierte Parameter mit dem Präfix google_ werden ignoriert, da sie von Google für zukünftige Entwicklungen reserviert sind. Außerdem wird die Reihenfolge der Parameter nicht garantiert. Ein Abgleichs-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 für das Konto eines Bieters konfigurierten Cookie-Abgleichs-Basis-URL erstellt, einschließlich google_ und bieterdefinierten Parametern, je nachdem, welche im Abgleichs-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 allgemeinen Anforderungsfehler angibt. Wenn diese Meldung empfangen wird, bedeutet das, 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 aber die Verwendung dieses Cookies für das Tracking deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Es wurde beispielsweise eine No-Op-Anfrage empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google legt das Cookie nicht über den Cookie Matching Service fest.
  • 4: Es wurden widersprüchliche Vorgänge angegeben. Sie dürfen nicht sowohl das Flag google_push als auch das Flag google_cm in derselben Anfrage angeben, da sie sich widersprechen.
  • 5: Ein ungültiger google_push-Parameter wurde in einer Weiterleitung an einen Google-Server im Rahmen einer bidirektionalen Pixel-Matching-Anfrage übergeben. In Ihrer Weiterleitung muss google_push auf denselben Wert festgelegt werden, der Ihnen in der ursprünglichen Pixelanfrage übergeben wurde.
  • 6: Im Abgleich-Tag wurde eine ungültige NID angegeben.
  • 7: Ein ungültiges Cookie wurde 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 ohne Angabe von google_hm oder zusätzlich zu google_cm verwendet.
  • 15: Die Anfrage stammt aus einer Region, in der Google die Match-Tabelle hosten muss. Daher enthält diese Antwort keine Google-Nutzer-ID.
google_hm

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

  • 1 – Forbidden: Der Kunde hat keinen Zugriff, um Einträge in die gehostete Match-Table zu schreiben.
  • 2 – Decodierungsfehler: Der Parameterwert konnte nicht decodiert werden.
  • 3 – Nutzlast zu lang: Der Parameterwert wurde in mehr als 40 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 der Nutzerliste. 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: Geschlossene Attribut-ID. Die angegebene Nutzerlisten-ID ist geschlossen.
  • 10 – Interner Fehler. Beim Dienst zur Suche nach Cookie-Übereinstimmungen ist ein interner Fehler aufgetreten. Sie können versuchen, die Nutzerzuordnung noch einmal durchzuführen.

In den folgenden Szenarien wird beschrieben, wie der Cookie-Abgleich für einen typischen Nutzer aussehen kann, der eine Webseite aufruft.

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

Jane löscht den Cache aller Cookies. Anschließend besucht er die Startseite von BeispielNachrichten.de.

Folgendes passiert:

  1. ExampleNews.com rendert und ruft Anzeigen von Google (Ad Manager) auf.
  2. Da der Anzeigenblock für die dynamische Zuordnung infrage kommt, sendet Google Gebotsanfragen über den Echtzeitgebotsdienst 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 Abgleichs-Tag (Pixel) angegeben ist.
  5. FinestDSP gewinnt die Auktion. Google liefert das Anzeigen- und das Abgleichs-Tag von FinestDSP an Jane aus.
  6. Das Abgleich-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt die Parameter google_nid und google_cm an.
  7. Der Cookie Match Service liest Janes Google-Cookie und sendet Janes Browser eine Weiterleitung zur Cookie-Abgleichs-URL von FinestDSP mit den Parametern google_gid und google_cver.
  8. Der Browser von Jane lädt die Weiterleitung zur Cookie-Übereinstimmungs-URL von FinestDSP.
  9. Der Cookie-Abgleichsendpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, die von Google festgelegte URL-Parameter und das Cookie für Jane in den HTTP-Headern enthält. FinestDSP kann jetzt die Zuordnung des Cookies zur google_gid in der 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 ExampleNews.com noch einmal. Jane hat jetzt sowohl Bieter- als auch Ad Manager-Cookies auf ihrem Computer. So funktioniert der Abgleich:

  1. Die Webseite wird gerendert. Dadurch werden Anzeigen von Google (Ad Manager) angefordert, die auf der Seite gerendert werden.
  2. Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die entsprechenden Bieter, einschließlich FinestDSP.
  3. FinestDSP erhält die Gebotsanfrage mit Signalen wie google_gid.
  4. FinestDSP sucht in seiner Abgleichstabelle nach der google_gid und findet den Cookie, der vor einer Woche (in Szenario 1) für Jane erstellt wurde.
  5. Anhand der mit dem Cookie verknüpften Informationen gibt die Gebotslogik von FinestDSP ein Gebot für die Impression ab und gewinnt die Auktion.
  6. Jana sieht möglicherweise eine Anzeige, die auf ihre Interessen zugeschnitten ist und auf Informationen basiert, die FinestDSP besitzt.

Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit dem Unterschied, dass nur Google eine Abgleichstabelle hostet und mit Daten füllt. Dies kann in Fällen verwendet werden, in denen der Bieter keine Google-Nutzer-IDs in seiner eigenen Abgleichstabelle hosten darf. Damit Bieter diesen Ablauf nutzen können, müssen sie Google erlauben, die Abgleichstabelle zu hosten. Sie können google_cm nicht mehr in Anfragen an den Cookie Matching Service von Google angeben und erhalten daher auch keine google_gid, um ihre eigene Abgleichstabelle zu füllen. Sobald Google eine Übereinstimmung für einen Nutzer gefunden hat, können Bieter ihn mithilfe ihrer eigenen Cookie-Daten zu Nutzerlisten hinzufügen. Entsprechend enthalten Gebotsanfragen für diese Nutzer nicht die Google-Nutzer-ID, aber gehostete Abgleichsdaten. Ein Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.

Schritt 1: Match-Tag auf die Cookie-Abgleichs-URL des Bieters verweisen

Damit dieser Ablauf gestartet werden kann, muss ein Bieter ein Abgleich-Tag platzieren, das im Browser des Nutzers gerendert wird. Anders als beim Workflow für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen stammen, muss das Abgleichs-Tag den Browser des Nutzers zu Ihrer Cookie-Abgleichs-URL weiterleiten. Wenn Sie beispielsweise eine Cookie-Abgleichs-URL als https://ad.network.com/pixel konfiguriert haben, sieht sie so aus:

<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 muss.

Der Cookie-Abgleichsendpunkt des Bieters muss zum Cookie-Abgleichsdienst von Google weiterleiten. Dabei muss der Parameter google_hm mit den websicheren Base64-codierten Cookie-Daten des Bieters gefüllt sein. 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 eine Weiterleitung mit den von Ihnen angegebenen Parametern sowie dem Google-Cookie in den HTTP-Headern.

Schritt 4: Google stellt Pixel bei Erfolg oder Fehlerweiterleitung bereit, wenn eine Berichts-URL angegeben ist

Wenn der Cookie-Abgleich erfolgreich ist oder keine Cookie-Abgleichsbericht-URL für das Konto des Bieters angegeben wurde, wird von Google standardmäßig ein transparentes 1‑×‑1-Pixel ausgeliefert und der Workflow endet hier. Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid. Bieter können auch Nutzerlisten mit den von ihnen angegebenen gehosteten Abgleichsdaten erstellen.

Andernfalls, wenn ein Fehler aufgetreten ist, sendet Google eine Weiterleitung an die URL des Cookie-Abgleichberichts des Bieters. 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 wäre, sähe die Weiterleitungs-URL so aus:

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

Der Browser des Nutzers wird zur URL des Cookie-Abgleichberichts des Bieters weitergeleitet. Diese enthält den von Google im Parameter google_error angegebenen Fehlergrund (falls vorhanden). Weitere Informationen zum Interpretieren des Fehlercodes finden Sie in der Parameterbeschreibung.

Schritt 6: Der Bieter stellt ein transparentes 1x1-Pixel bereit

Der Bieter muss mit der Bereitstellung eines transparenten 1x1-Pixels für den Browser des Nutzers antworten.

Der Standard-Workflow für Nutzer in US-Bundesstaaten mit Datenschutzbeschränkungen ist im folgenden Diagramm 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 Bidders-Ressource abgerufen 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. Wenn der Parameter weggelassen wird, führt das zu einem Fehler, wenn kein Cookie vorhanden ist.
google_no_sc Dieser Parameter wurde eingestellt. Dies weist den Cookie Matching Service von Google darauf hin, dass kein Cookie für den Nutzer gesetzt werden soll, wenn noch keines 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, an die Google eine HTTP-302-Weiterleitung senden soll. Die angegebene URL wird sowohl bei Fehlern als auch bei erfolgreichen Vorgängen mit dem Parameter google_error weitergeleitet.
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 DSGVO-Beschränkungen für die Datennutzung unterliegt. Weitere Informationen finden Sie in der Dokumentation zum IAB TCF 2.0 für Authorized Buyers unter Anforderungen an die Einwilligung der Nutzer in der EU oder Auswirkungen auf die Eignung für den Cookie-Abgleich.

Beispiel: gdpr=1
gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unter Anforderungen an die Nutzereinwilligung in der EU oder in der Dokumentation zu Authorized Buyers IAB TCF 2.0 im Abschnitt 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
Parameter Beschreibung
google_error

Ein Ganzzahlwert, der den allgemeinen Anforderungsfehler angibt. Wenn diese Meldung empfangen wird, bedeutet das, 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 aber die Verwendung dieses Cookies für das Tracking deaktiviert.
  • 2: Es wurden keine gültigen Vorgänge angegeben. Es wurde beispielsweise eine No-Op-Anfrage empfangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google legt das Cookie nicht über den Cookie Matching Service fest.
  • 4: Es wurden widersprüchliche Vorgänge angegeben. Sie dürfen nicht sowohl das Flag google_push als auch das Flag google_cm in derselben Anfrage angeben, da sie sich widersprechen.
  • 5: Ein ungültiger google_push-Parameter wurde in einer Weiterleitung an einen Google-Server im Rahmen einer bidirektionalen Pixel-Matching-Anfrage übergeben. In Ihrer Weiterleitung muss google_push auf denselben Wert festgelegt werden, der Ihnen in der ursprünglichen Pixelanfrage übergeben wurde.
  • 6: Im Abgleich-Tag wurde eine ungültige NID angegeben.
  • 7: Ein ungültiges Cookie wurde 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 ohne Angabe von google_hm oder zusätzlich zu google_cm verwendet.
  • 15: Die Anfrage stammt aus einer Region, in der Google die Match-Tabelle hosten muss. Daher enthält diese Antwort keine Google-Nutzer-ID.

Von Google initiiert: Bidirektionaler Pixelabgleich

Der bidirektionale Pixel-Abgleich ist ein Workflow für den Cookie-Abgleichsdienst von Google, bei dem Google versucht, 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 Abgleichs-Tag, das den Browser des Nutzers anweist, ein transparentes Pixel von der Cookie-Abgleichs-URL des ausgewählten Bieters zu laden. So können sowohl Google als auch der Bieter eine Match-Tabelle mit einem bestimmten Nutzer füllen. Im Folgenden finden Sie ein Beispiel für diesen Workflow.

Schritt 1: Google platziert ein Abgleichs-Tag

Wenn die Seite eines teilnehmenden Verlags und Webpublishers im Browser des Nutzers geladen wird und ein Anzeigen-Slot auf dieser Seite von Google gefüllt wird, kann ein Abgleich-Tag platziert werden, mit dem ein Pixel von einem algorithmisch ausgewählten Bieter angefordert wird. Das von Google platzierte Pixelabgleichs-Tag kombiniert die Cookie-Abgleichs-URL des Bieters mit zusätzlichen Parametern, die der Bieter zum Füllen seiner Match-Table verwenden kann. Eine Cookie-Abgleichs-URL, die als https://ad.network.com/pixel angegeben ist, ist so aufgebaut:

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

Bieter, die Anfragen zum Pixel-Abgleich erhalten, müssen mit einer Weiterleitung an den Cookie Matching Service von Google antworten. Diese Weiterleitung muss so strukturiert sein:

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

Die Weiterleitungs-URL ähnelt der URL, die im Abgleichstag für den vom Bieter initiierten Cookie-Abgleichworkflow 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 wird. Ähnlich wie beim vom Bieter initiierten Workflow können zusätzliche Parameter angegeben werden, um weitere Anwendungsfälle zu berücksichtigen.

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

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

Diagramm zum Workflow für den Pixelabgleich

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

Google-Tag-Anfrageparameter für den Abgleich

Parameter Beschreibung
google_gid Google-Nutzer-ID Bei Nutzern, die nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen stammen, wird dies immer im Google-Abgleichstag angegeben.
google_cver Die Cookie-Version. Das wird immer im Google-Abgleich-Tag angegeben.
google_push Gibt an, dass mit dieser Anfrage der Workflow für den Pixelabgleich 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 unter [EU-Nutzereinwilligung](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder im Abschnitt **How will the TC string be passed?** in der [IAB TCF v2.0-Dokumentation für Authorized Buyers](//support.google.com/authorizedbuyers/answer/9789378).

Weiterleitungsparameter für den Abgleich von Gebots-Pixeln

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Bidders-Ressource abgerufen werden.
google_push Gibt an, dass mit dieser Weiterleitung der Workflow für den Pixel-Abgleich abgeschlossen wird. Hier muss der Wert aus dem entsprechenden Google-Abgleichstag 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 unter [Anforderungen an die Einwilligung der Nutzer in der EU](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder im Abschnitt **Wie wird der TC-String übergeben?** in der [IAB TCF v2.0-Dokumentation für Authorized Buyers](//support.google.com/authorizedbuyers/answer/9789378).

Von Google initiiert: Unidirektionaler Pixelabgleich

Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow dadurch, dass das Google-Abgleichstag keinen Parameter mit der Google-Nutzer-ID enthält. Es wird aber weiterhin eine von Google gehostete Abgleichstabelle gefüllt. Dies kann in Fällen verwendet werden, in denen der Bieter Google-Nutzer-IDs nicht in seiner eigenen Abgleichstabelle hosten darf. Ein Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.

Schritt 1: Google platziert ein Abgleichs-Tag

Google platziert ein Abgleichs-Tag für einen algorithmisch ausgewählten Bieter. Das Abgleichs-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 das Pixel von der Cookie-Abgleichs-URL des Bieters an.

Der Browser des Nutzers fordert ein Pixel von der Cookie-Abgleichs-URL des Bieters an und sendet das Cookie des Bieters in den HTTP-Headern.

Der Cookie-Abgleichsendpunkt des Bieters muss zum Cookie-Abgleichsdienst von Google weiterleiten. Dabei muss der Parameter google_hm mit den websicheren Base64-codierten Cookie-Daten des Bieters gefüllt sein. 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 eine Weiterleitung mit den von Ihnen angegebenen Parametern sowie dem Google-Cookie in den HTTP-Headern. Wenn der Vorgang erfolgreich war, enthalten Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid. Bieter können auch Nutzerlisten mit den von ihnen angegebenen gehosteten Abgleichsdaten erstellen.

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

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

  1. Wenn eine Anzeige ausgeliefert wird, wählt der Google-Algorithmus einen teilnehmenden Exchange 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. Das CMA-Match-Tag von Google bewirkt, dass die URL für den Cookie-Abgleich der Exchange eine Pixelanfrage erhält.

  3. Der Cookie-Abgleichsendpunkt der Exchange-Plattform empfängt die Anfrage. Der eigene Cookie-Abgleichsdienst der Exchange-Plattform ist dafür verantwortlich, die Nutzer-ID mit einem der Bieter abzugleichen. Im folgenden Diagramm antwortet der Cookie-Abgleichsdienst der Exchange mit einer Weiterleitung an einen der Bieterendpunkte auf den Browser des Nutzers.
  4. Der Bieter erhält die Anfrage zusammen mit allen Parametern, die von der Anzeigenplattform angegeben wurden, um die Nutzer-ID mit seinem Cookie abzugleichen.

Einschränkungen

Häufigkeit von Anfragen für neue Abgleiche begrenzen

Bieter sind dafür verantwortlich, die Anzahl der Aufrufe des Cookie-Abgleichdienstes für Nutzer mit einem neuen Eintrag in der von Google gehosteten Abgleichtabelle zu begrenzen. Ein Eintrag in der gehosteten Match-Tabelle kann nach 14 Tagen als abgelaufen betrachtet und aktualisiert werden.

Auf alle Anfragen zu Pixel-Abgleich reagieren

Bieter, die den Pixel-Abgleich-Workflow verwenden, müssen auf alle eingehenden Pixel-Abgleich-Anfragen mit einer Antwort reagieren, die den Parameter google_push enthält. So kann Google Richtlinien durchsetzen, indem die Nutzung überwacht wird. Wenn die Reaktionsrate eines Bieters unter 90 % liegt, drosselt Google die Anzahl der Pixel-Abgleichsanfragen, die an sein Konto gesendet werden.

HTTPS-Endpunkte verwenden

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

Wenn Sie auf eine Pixel Match-Anfrage antworten, die Ihnen über HTTPS gesendet wurde, müssen Sie über HTTPS an den Cookie Matching Service weiterleiten. Ebenso muss für einen Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, HTTPS verwendet werden. Wenn Sie häufiger als alle zwei Minuten Anfragen über HTTP an Google senden, wird die Anzahl der an Ihr Konto gesendeten Abgleichsanfragen 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

Die folgenden Beispiele veranschaulichen, wie Sie den Cookie Matching-Dienst verwenden können, um bestimmte Ziele zu erreichen. Sofern nicht anders angegeben, wird davon ausgegangen, dass der Nutzer, auf den sich die Aktion bezieht, nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen stammt.

Vom Bieter gehostete Match-Tabelle ausfüllen

Ein Bieter kann seine eigene Abgleichstabelle mit dem Cookie-Abgleichsverfahren füllen, indem er in seinem Abgleichstag nur die Parameter google_nid und google_cm angibt. 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 gesetzt ist und der Cookie-Abgleich erfolgreich ist, sieht die Weiterleitung, die Google als Reaktion auf das Match-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, sieht die Antwort so aus:

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-Abgleichsworkflow finden Sie unter Parameter für Weiterleitungs-URLs.

Einer einzelnen Nutzerliste hinzufügen

Der Parameter google_ula kann im Match-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn die von Google oder vom Bieter gehostete Abgleichstabelle einen neuen Eintrag für den Nutzer enthält, kann der Bieter ein Abgleichs-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 unter Einschränkungen für den Aufruf des Cookie Matching Service. Das entsprechende Abgleichs-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, wäre die Weiterleitungs-URL von Google:

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

Wenn ein allgemeiner Fehler auftritt, z. B. 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, erhalten Sie google_ula in der Weiterleitung. Im Gegensatz zum entsprechenden Parameter für das Abgleich-Tag wird der Zeitstempel hier durch einen Statuscode ersetzt, der den Erfolg des Vorgangs angibt. Wenn die Anfrage beispielsweise fehlgeschlagen ist, weil das Bieterkonto keinen Zugriff auf die angegebene Nutzerliste hatte, wäre 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 Abgleichs-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 für jede Nutzerliste wird auf ähnliche Weise über separate google_ula-Parameter im Redirect gemeldet:

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

Im vorherigen Redirect sehen wir, 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 für den Zugriff darauf hatte.

Wenn Sie die Cookie-Übereinstimmung ausführen und den Nutzer in einer einzigen Anfrage einer Nutzerliste hinzufügen möchten, muss das Match-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

Match in einer von Google gehosteten Match-Tabelle speichern

Wenn ein Bieter seine Cookie-Daten in einer von Google gehosteten Abgleichstabelle speichern möchte und nicht beabsichtigt, den Abgleich mit der Google-Nutzer-ID in seiner eigenen Abgleichstabelle zu speichern, muss sein Abgleichs-Tag den Parameter google_hm enthalten. Der Wert muss ein websicherer Base64-codierter String sein. Für einen Nutzer, dessen uncodierte Cookie-Daten des Bieters Cookie number 1! sind, wäre der codierte Wert Q29va2llIG51bWJlciAxIQ==, der in einem Abgleich-Tag wie dem folgenden verwendet würde:

<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 nicht google_cm enthielt und google_hm nicht in erfolgreichen Antworten enthalten ist. In zukünftigen Gebotsanfragen für Impressionen für diesen Nutzer erhält der Bieter seine gehosteten Abgleichsdaten in BidRequest.user.buyeruid.

Wenn der Bieter stattdessen ein Abgleichs-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 vorangehende Weiterleitungs-URL enthält den google_hm-Wert 2. Das deutet darauf hin, dass der Vorgang fehlgeschlagen ist, weil der Wert nicht decodiert werden konnte.

Gebotsabgabe- und von Google gehostete Abgleichstabellen mit Nutzerlisten

Wenn ein Bieter zusätzlich zu einer von Google gehosteten Nutzerliste eine eigene Nutzungsliste hostet und ein einzelnes Abgleichs-Tag verwenden möchte, um beide Tabellen abzugleichen und den Nutzer einer bestimmten Nutzerliste hinzuzufügen, muss das Abgleichs-Tag die Parameter google_cm, google_hm und google_ula enthalten. Wenn die Cookie-Daten des Bieters Cookie number 1! sind, wäre 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, sieht die Weiterleitungs-URL von Google so aus:

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 seinen Cookie-Daten in seiner Abgleichstabelle abgleichen. Außerdem können sie feststellen, ob die Vorgänge für die von Google gehostete Abgleichstabelle und Nutzerliste erfolgreich waren. Infolge dessen erhält der Bieter nun Gebotsanfragen für Impressionen des Nutzers, wenn er Pretargeting konfiguriert hat, das auf die angegebene Nutzerlisten-ID ausgerichtet ist. Ebenso erhält der Bieter in diesen Gebotsanfragen seine gehosteten Abgleichsdaten in BidRequest.user.buyeruid.