Cookie-Abgleich

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

Konzepte

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

Im Zusammenhang mit digitaler Werbung identifiziert Google Nutzer anhand von Cookies, die zur Domain doubleclick.net gehören. Bieter, die am Echtzeitgebotsverfahren teilnehmen, haben möglicherweise eine eigene Domain, in der sie Nutzer identifizieren, denen sie Anzeigen präsentieren möchten. Mit dem Cookie-Abgleich können Bieter ihre Cookies mit denen von Google abgleichen, um zu ermitteln, ob eine in einer Gebotsanfrage gesendete Impression mit einem der Nutzer verknüpft ist, auf den die Anzeigen ausgeliefert werden sollen. Sie erhalten dann entweder ihre 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 vereinfacht das Erstellen und Verwalten der Verknüpfung zwischen dem Cookie eines Bieters und der Google User-ID. Außerdem ermöglicht er das Ausfüllen von Nutzerlisten.

Match-Tables

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

Von Google gehostete Match-Tables

Für eine einfachere Wartung, geringere Latenz und Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen sollten Sie Google erlauben, Ihre Abgleichstabelle zu hosten. Sie können einen websicheren Base64-codierten String angeben, der der Google-Nutzer-ID eines bestimmten Nutzers zugeordnet wird. Dieser String wird nachfolgend als gehostete Abgleichsdaten bezeichnet. Nach der Zuordnung kann sie auf folgende Arten verwendet werden:

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

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

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

Nutzerlisten

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

Erste Schritte

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

  • Netzwerk-ID des Cookie-Abgleichs (NID): Eine String-ID, mit der sich ein Bieterkonto bei der Cookie-Übereinstimmung und anderen ähnlichen Vorgängen eindeutig identifizieren lässt.
  • URL des Cookie-Abgleichs: Die Basis-URL eines Endpunkts, an dem eingehende Anfragen im Rahmen des Cookie-Abgleichsworkflows angenommen und verarbeitet werden. Bieter können Makros in diese URL einbetten, um die Reihenfolge der Parameter zu steuern, die in Cookie-Übereinstimmungsworkflows an sie übergeben werden.
  • Übereinstimmungs-Tag: Das Tag, das Sie im Browser eines Nutzers für den vom Bieter initiierten Cookie-Abgleich-Workflow platzieren müssen. Sie können zusammen mit Anzeigen ausgeliefert oder außerhalb von Anzeigen auf Web-Properties platziert werden.
  • URL des Cookie-Abgleichberichts (optional): Im unidirektionalen Cookie-Abgleich-Workflow ist dies eine optionale URL, die bereitgestellt werden kann, um einen Endpunkt anzugeben, an den Fehlerdetails gesendet werden, falls 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. Bieter können jedoch anfordern, dass die Weiterleitung immer gesendet wird.
  • Cookie Match Assist-URL: Für Anzeigenplattformen, die den Cookie Match Assist-Workflow implementieren, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen reagieren soll.
  • Kontingent zur Cookie-Abgleich-Unterstützung: Auf Plattformen, die den Cookie Match Assist-Workflow implementieren, ist dies die maximale Anzahl von Anfragen, die ihre Cookie-Abgleich-URL pro Sekunde empfangen kann. So soll verhindert werden, dass die Server der Anzeigenplattform durch CMA-Anfragen überlastet werden.

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

Unterstützte Makros

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

Macro 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-Abgleichsintegration mit einem Endpunkt, der unter https://user.bidder.com.cookies gehostet wird. Für die Implementierung sind neben den Pixel-Abgleichsparametern vordefinierte Bieterparameter in der folgenden Reihenfolge erforderlich: google_push, google_gid, google_cver und google_error. Dazu muss der Bieter die URL für den Cookie-Abgleich so festlegen:

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

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

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

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

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

Schritt 1: Abgleich-Tag platzieren

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

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

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

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

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

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

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

Die in google_cver angegebene Version ist die numerische Versionsnummer der Google-Nutzer-ID. Die Google-Nutzer-ID für einen bestimmten Nutzer ändert sich nur selten und wird dann erhöht.

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

Schritt 3: Bieter verarbeitet Weiterleitung und antwortet mit Pixel

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

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

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

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

Übereinstimmung mit Tag-URL-Parametern

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

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

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

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen.
gdpr Gibt an, dass die Anfrage den Einschränkungen der DSGVO zur Datennutzung unterliegt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der IAB TCF 2.0-Dokumentation für autorisierte Käufer unter Auswirkungen auf die Eignung für die Cookie-Abgleichsfunktion.

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

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

Beispiel: process_consent=T

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

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

Parameter für Weiterleitungs-URLs

Die Weiterleitungs-URL wird aus der Basis-URL für die Cookie-Abgleichsfunktion erstellt, die für das Konto eines Bieters konfiguriert wurde. Dazu gehören google_ und vom Bieter definierte Parameter, die von den im Abgleichs-Tag angegebenen abhängen. Die folgenden google_-Antwortparameter sind definiert:

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

Ein Ganzzahlwert, der den Gesamtfehler der Anfrage angibt. Wenn dieser Wert empfangen wird, wurden keine Vorgänge ausgeführt und es werden keine weiteren google_-Antwortparameter festgelegt. Folgende Fehlerwerte werden unterstützt:

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

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

  • 1 – Verboten: Der Kunde ist noch nicht auf der Zulassungsliste, um Einträge in gehostete Abgleichtabellen zu schreiben.
  • 2 – Dekodierungsfehler: Der Parameterwert konnte nicht decodiert werden.
  • 3 – Nutzlast zu lang: Der Parameterwert wurde in mehr als 24 Byte Daten decodiert.
  • 4 – Interner Fehler: Beim Speichern der Daten ist ein interner Fehler aufgetreten.
  • 5 – gedrosselt: Dieser Schreibvorgang wurde aufgrund einer Drosselung nicht verarbeitet.
google_ula

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

Beispiel: google_ula=1234567890,0

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

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

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

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

Jane löscht alle Cookies aus dem Cache. Anschließend besucht er die Startseite von ExampleNews.com.

Folgendes passiert:

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

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

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

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

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

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

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

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

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

Google erhält eine Weiterleitung mit den von Ihnen angegebenen Parametern sowie das Google-Cookie in den HTTP-Headern.

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

Wenn der Cookie-Abgleich erfolgreich ist oder für das Konto des Bieters keine URL für den Cookie-Abgleichsbericht angegeben wurde, schaltet Google standardmäßig ein transparentes 1x1-Pixel. Der Workflow endet an dieser Stelle. Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die gehosteten Abgleichsdaten des Bieters in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte Google RTB-Protokoll. Bieter können Nutzerlisten auch mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.

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

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

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

Schritt 6: Bieter sendet transparentes 1x1-Pixel

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

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

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden.
google_sc Dieser Parameter wurde eingestellt. Setzt das Google-Cookie für den Nutzer, falls noch keines vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist.
google_no_sc Dieser Parameter wurde eingestellt. Damit wird dem Cookie-Abgleichdienst von Google mitgeteilt, dass er kein Cookie für den Nutzer setzen soll, wenn keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden.
google_hm

Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.
google_redir Eine codierte URL, für die Google eine HTTP-302-Weiterleitung senden soll. Die angegebene URL empfängt 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: Ein optionaler Zeitstempel im POSIX-Format, der angibt, wann der Nutzer der Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen.
gdpr Gibt an, dass die Anfrage DSGVO-Einschränkungen für die Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen an die Einwilligung der Nutzer in der EU und im Abschnitt Auswirkungen auf die Berechtigung für den Cookie-Abgleich in der Dokumentation zum IAB TCF 2.0 für Authorized Buyers.

Beispiel: gdpr=1
gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen zur Einwilligung der Nutzer in der EU und unter Wie wird der TC-String übergeben? in der Dokumentation zum IAB TCF 2.0 für Authorized Buyers.
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 Gesamtfehler der Anfrage angibt. Wenn dieser Wert empfangen wird, wurden keine Vorgänge ausgeführt und es werden keine weiteren google_-Antwortparameter festgelegt. Zu den unterstützten Fehlerwerten gehören:

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

Von Google initiiert: Bidirektionaler Pixelabgleich

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

Schritt 1: Google platziert ein Abgleich-Tag

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

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

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

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

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

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

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

Workflow-Diagramm für den Pixelabgleich

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

Anfrageparameter für das Google-Abgleichs-Tag

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

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

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

Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.
google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp]:
  • userlistid: eine einzelne numerische Nutzerlisten-ID
  • timestamp: Ein optionaler Zeitstempel im POSIX-Format, der angibt, wann der Nutzer der Nutzerliste hinzugefügt wurde.

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

Von Google initiiert: Einseitiger Pixelabgleich

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

Schritt 1: Google platziert ein Abgleich-Tag

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

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

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

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

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

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

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

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

  2. Durch das CMA-Abgleichs-Tag von Google wird die URL für den Cookie-Abgleich der Anzeigenplattform mit einer Pixelanfrage aufgerufen.

  3. Die Anfrage wird vom Cookie-Abgleichs-Endpunkt der Anzeigenplattform empfangen. Der Cookie-Abgleichsdienst der Anzeigenplattform ist für die Übereinstimmung der Nutzer-ID mit einem ihrer Bieter verantwortlich. Im folgenden Diagramm antwortet der Cookie-Abgleichdienst der Anzeigenplattform mit einer Weiterleitung an einen der Endpunkte des Bieters an 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 dem Cookie abzugleichen.

Einschränkungen

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

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

Auf alle Anfragen zur Pixelübereinstimmung antworten

Von Bietern, die den Pixel-Abgleich-Workflow verwenden, wird erwartet, dass sie auf alle eingehenden Pixel-Übereinstimmungsanfragen mit einer Antwort antworten, die den Parameter google_push enthält. So kann Google Richtlinien durch das Monitoring der Nutzung erzwingen. Wenn die Antwortrate eines Bieters unter 90 % fällt, wird die Anzahl der Pixel-Abgleichsanfragen, die an sein Konto gesendet werden, von Google gedrosselt.

HTTPS-Endpunkte verwenden

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

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

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

Beispiele

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

Von Bietern gehostete Match-Table füllen

Bieter können mit dem Cookie-Abgleich-Workflow ihre eigene Match-Table füllen, indem sie im entsprechenden Tag nur die Parameter google_nid und google_cm angeben. Dies könnte etwa 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 festgelegt ist und der Cookie-Abgleich erfolgreich ist, kann 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 zugrunde liegenden Ursache des Fehlers ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleichs-Workflow finden Sie unter Weiterleitungs-URL-Parameter.

Zur Liste mit einzelnen Nutzern hinzufügen

Der Parameter google_ula kann im Abgleichs-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn die von Google oder dem Bieter gehostete Abgleichstabelle einen neuen Eintrag für den Nutzer enthält, kann der Bieter ein Abgleich-Tag mit den Parametern google_nid und google_ula platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Cookie-Abgleichs-Workflow zu starten. Weitere Informationen finden Sie unter 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 https://ad.network.com/pixel erfolgreich ist, sieht die Weiterleitungs-URL von Google so aus:

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

Wenn ein allgemeiner Fehler auftritt, z. B. wenn für den Nutzer kein Google-Cookie vorhanden ist, enthält die Weiterleitungs-URL den Parameter google_error:

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

Wenn ein Fehler auftritt, der das Hinzufügen des Nutzers zur Liste betrifft, wird in der Weiterleitung google_ula zurückgegeben. Im Gegensatz zum entsprechenden Parameter für das Match-Tag wird hier der Zeitstempel 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, lautet die Weiterleitungs-URL:

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

Nutzer 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 kann das so aussehen:

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

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

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

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

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

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

Die von Google angegebene Weiterleitungs-URL enthält google_gid, google_cver und google_ula. Das könnte so aussehen:

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

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

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

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

Wenn die Cookie-Abgleich-URL des Bieters https://cookie-monster.com/pixel erfolgreich ist, sieht die Weiterleitungs-URL von Google so aus:

https://cookie-monster.com/pixel

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

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

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

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

Bieter und von Google gehostete Match-Tables mit Nutzerlisten

Wenn ein Bieter zusätzlich zu einer von Google gehosteten Nutzerliste eine eigene Nutzerliste hostet und mit einem einzigen Abgleich-Tag beide Tabellen abgleichen und den Nutzer einer bestimmten Nutzerliste hinzufügen möchte, muss sein Abgleich-Tag die Parameter google_cm, google_hm und google_ula enthalten. Wenn die Cookie-Daten des Bieters Cookie number 1! sind, lautet der codierte Wert Q29va2llIG51bWJlciAxIQ==. Das würde zu einem Match-Tag wie dem folgenden führen:

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

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

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

Nach Erhalt der Weiterleitung kann der Bieter die in google_gid angegebene Google Nutzer-ID mit den Cookiedaten in der Match-Table abgleichen. Außerdem kann er feststellen, ob die von Google gehosteten Match-Table- und Nutzerlistenvorgänge erfolgreich waren. Wenn der Bieter also ein Pretargeting auf die angegebene Nutzerlisten-ID konfiguriert hat, erhält er jetzt Gebotsanfragen für Impressionen vom Nutzer. Ebenso erhält der Bieter in diesen Gebotsanfragen seine gehosteten Abgleichsdaten in BidRequest.user.buyeruid für OpenRTB oder BidRequest.hosted_match_data für das eingestellte Google RTB-Protokoll.