Der Cookie-Abgleich ist eine Funktion, mit der Sie Ihr Cookie (z. B. die ID eines Nutzers, der Ihre Website besucht hat) mit einer entsprechenden Bieter-spezifischen Google Nutzer-ID abgleichen und Nutzerlisten erstellen können, mit denen Sie effektivere Gebotsentscheidungen treffen können. In diesem Leitfaden werden Konzepte, die beim Cookie-Abgleich verwendet werden, verschiedene Workflows für den Cookie-Abgleich sowie mögliche Varianten für bestimmte Anwendungsfälle beschrieben.
Konzepte
Was ist der Cookie-Abgleich?
Domaininhaber setzen die Inhalte von Cookies normalerweise für Nutzer, die ihre Website besuchen. Dadurch werden Nutzer innerhalb dieser Domain identifiziert. Auch wenn zwei Domaininhaber anderen Domains zustimmen würden, dass diese Daten ausgetauscht werden, schränkt das Sicherheitsmodell von Internetbrowsern einen davon ein, ein von einer anderen Domain gesetztes Cookie zu lesen.
Im Zusammenhang mit digitaler Werbung identifiziert Google Nutzer anhand von Cookies, die zur Domain doubleclick.net
gehören. Bieter, die an Echtzeitgeboten teilnehmen, haben möglicherweise eine eigene Domain, auf der sie bestimmte Nutzer angeben, für die sie Anzeigen präsentieren möchten. Durch den Cookie-Abgleich kann der Bieter seine Cookies mit denen von Google abgleichen, sodass er feststellen kann, ob eine in einer Gebotsanfrage gesendete Impression mit einem der Zielnutzer verknüpft ist. Er erhält entweder seine eigenen Cookiedaten oder eine bieterspezifische Google Nutzer-ID, die eine verschlüsselte Form des doubleclick.net
-Cookies in der Gebotsanfrage ist.
Der in diesem Leitfaden beschriebene Dienst für den Cookie-Abgleich erleichtert das Erstellen und Verwalten der Verknüpfung zwischen dem Cookie eines Bieters und der Google Nutzer-ID und ermöglicht es, Nutzerlisten zu füllen.
Match-Tables
Eine Match-Table kann verwendet werden, um eine ID oder andere Daten einer Domain einer anderen zuzuordnen. Bieter können mit dem Cookie-Abgleichdienst eigene Match-Tables füllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google User-ID des Nutzers zuordnen oder eine von Google gehostete Match-Table ausfüllen. Match-Tables sind erforderlich, damit die Bieteranwendung eines Bieters auf Cookie-Daten für den Nutzer zugreift, dem die Impression präsentiert wird.
Von Google gehostete Match-Tables
Zur einfacheren Wartung, zu Latenzverbesserungen und zum Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen empfiehlt es sich, Google das Hosten Ihrer Match-Table zu erlauben. So können Sie einen websicheren, mit Base64 codierten String angeben. Dieser wird im Folgenden als gehostete Abgleichsdaten bezeichnet und der Google Nutzer-ID für einen bestimmten Nutzer zugeordnet. Sobald eine Übereinstimmung hergestellt wurde, kann sie folgendermaßen verwendet werden:
Echtzeitgebote: Bei nachfolgenden Gebotsanfragen für Impressionen, die mit dem Nutzer verknüpft sind, sendet Google Ihnen die gehosteten Abgleichsdaten, die Sie mit seiner Google Nutzer-ID abgeglichen haben. Wenn der Gebotsendpunkt für die Verwendung des EZG-Protokolls von Google konfiguriert ist, erhalten Sie diese als decodierte Byte über das Feld
BidRequest.hosted_match_data
. In der OpenRTB-Implementierung von Google gibtBidRequest.user.buyeruid
diese Daten als websicheren, mit Base64 codierten String zurück.Nutzerlisten: Nutzerlisten können entweder mit Google Nutzer-IDs oder gehosteten Abgleichsdaten gefüllt werden.
- Pre-Targeting: Sie können das Pre-Targeting so konfigurieren, dass Sie nur Gebotsanfragen mit gehosteten Abgleichsdaten erhalten. So können weniger relevante Impressionen für Nutzer außerhalb Ihres Cookie-Bereichs eliminiert werden.
Nutzerlisten
Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Nach der Erstellung können Sie diese Listen mit den unten beschriebenen Workflows für den Cookie-Abgleich oder über den Bulk-Uploader-Dienst füllen.
Erste Schritte
Wenn Sie den Cookie-Abgleich einrichten möchten, müssen Sie sich an Ihren Technical Account Manager wenden. Er kann bestimmte Workflows aktivieren und Ihnen bei der Konfiguration folgender Elemente helfen:
- Netzwerk-ID des Cookie-Abgleichs (NID): Eine String-ID, mit der ein Bieterkonto für den Cookie-Abgleich und andere zugehörige Vorgänge eindeutig identifiziert wird.
- URL des Cookie-Abgleichs: Die Basis-URL eines Endpunkts, der eingehende Anfragen als Teil des Cookie-Abgleich-Workflows akzeptiert und verarbeitet. Bieter können Makros in diese URL einbetten, um die Reihenfolge der Parameter zu steuern, die in den Cookie-Abgleich-Workflows an sie übergeben werden.
- Übereinstimmungs-Tag: Das Tag, das Sie für den vom Bieter initiierten Cookie-Abgleich-Workflow im Browser eines Nutzers einfügen müssen. Diese können zusammen mit Anzeigen oder auf Web-Properties außerhalb von Anzeigen platziert werden.
- URL des Cookie-Abgleichberichts (optional): Im unidirektionalen Cookie-Abgleich-Workflow kann diese optionale URL bereitgestellt werden, um einen Endpunkt anzugeben, an den Fehlerdetails gesendet werden, wenn der Cookie-Abgleich über eine HTTP 302-Weiterleitung fehlschlägt. Standardmäßig werden Antworten nur an diese URL gesendet, wenn beim Cookie-Abgleich ein Fehler aufgetreten ist. Der Bieter kann jedoch verlangen, dass die Weiterleitung immer gesendet wird.
- URL des Cookie Match Assist: Bei Anzeigenplattformen, bei denen der Workflow für den Cookie Match Assist implementiert ist, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen antworten soll.
- Kontingent für die Cookie-Abgleichunterstützung: Bei Anzeigenplattformen, die den Workflow „Cookie Match Assist“ implementieren, ist dies die maximale Anzahl von Anfragen, die die Cookie-Abgleich-URL pro Sekunde empfangen kann. So soll verhindert werden, dass CMA-Anfragen die Server der Anzeigenplattform mit Anfragen überlasten.
Makros für den Cookie-Abgleich
In jedem der unterstützten Workflows für den Cookie-Abgleich sind Parameter in der Regel in einer nicht garantierten Reihenfolge an die Cookie-Abgleich-URL eines Bieters angehängt. Bieter mit Integrationen, die eine einheitliche Reihenfolge der Parameter erfordern, können Makros in ihre Cookie-Abgleich-URL einfügen, um das Placement zu gewährleisten.
Supported macros
Bieter können ihre Cookie-Abgleich-URL so konfigurieren, dass sie ein oder mehrere Makros in Form von %%GOOGLE_<PARAM_NAME>%%
oder %%GOOGLE_<PARAM_NAME>_PAIR%%
enthält. Folgende Makros und ihre erweiterten Werte werden unterstützt:
Macro | Erweiterter Wert |
---|---|
GOOGLE_GID | GOOGLE_USER_ID |
GOOGLE_GID_PAIR | &google_gid=GOOGLE_USER_ID |
GOOGLE_CVER | COOKIE_VERSION_NUMBER |
GOOGLE_CVER_PAIR | &cver=COOKIE_VERSION_NUMBER |
GOOGLE_ERROR | ERROR_ID |
GOOGLE_ERROR_PAIR | &google_error=ERROR_ID |
GOOGLE_PUSH | PIXEL_MATCH_DATA |
GOOGLE_PUSH_PAIR | &google_push=PIXEL_MATCH_DATA |
GOOGLE_ALL_PARAMS | google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID |
Beispiel für Makro
Ein Bieter hat einen Cookie-Abgleich mit einem Endpunkt, der unter https://user.bidder.com.cookies
gehostet wird, und seine Implementierung erfordert zusätzlich zu den Pixel-Abgleichparametern vordefinierte Bieter-definierte Parameter in der folgenden Reihenfolge: google_push
, google_gid
, google_cver
und google_error
. Dazu legt er seine Cookie-Abgleich-URL auf eine der folgenden Optionen fest:
https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%
Wenn Google später eine Übereinstimmungsanfrage an diesen Bieter sendet, wird diese folgendermaßen erweitert:
https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3
Workflows des Cookie-Abgleichdienstes
Der Cookie-Abgleichdienst von Google unterstützt derzeit drei Workflows für verschiedene Anwendungsfälle, die unten beschrieben werden.
Vom Bieter initiiert: Bidirektionaler Cookie-Abgleich
Der bidirektionale Cookie-Abgleich bezieht sich auf einen vom Bieter initiierten Workflow, bei dem ein Übereinstimmungs-Tag im Browser des Nutzers platziert wird, das den Nutzer an Google weiterleitet. Mit diesem Workflow können sowohl Google als auch der Bieter Match-Tables füllen. Unten sehen Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Übereinstimmungs-Tag einfügen
Um diesen Vorgang zu starten, muss der Bieter sein Übereinstimmungs-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Ein einfaches Übereinstimmungs-Tag, das nur die Google Nutzer-ID an den Bieter zurückgibt, kann so strukturiert sein:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
Sie können zusätzliche Parameter für verschiedene Anwendungsfälle in das Übereinstimmungs-Tag einfügen. Weitere Informationen zu diesen Parametern finden Sie unter URL-Parameter für Übereinstimmungs-Tags.
Schritt 2: Google antwortet mit einer Weiterleitung und den Abgleichsdaten
Das Übereinstimmungs-Tag führt dazu, dass der Cookie-Abgleichdienst von Google eine Anfrage vom Browser des Nutzers empfängt, wodurch eine HTTP 302
-Weiterleitung an die Cookie-Abgleich-URL des Bieters ausgegeben wird. Die Weiterleitung enthält Suchparameter, die die Google Nutzer-ID und die Versionsnummer in der URL angeben. Der Bieter erhält ebenfalls sein Cookie in den Anfrageheadern. In der Praxis könnte die Weiterleitungs-URL für das einfache Übereinstimmungs-Tag für eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel
angegeben ist, so aussehen:
https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
Die mit dem Parameter google_gid
übergebene Google Nutzer-ID ist ein websicherer, base64-codierter String ohne Padding. Bieter, die eine Match-Table hosten möchten, sollten genau den vom Cookie-Abgleichdienst zurückgegebenen String speichern. Bei nachfolgenden Gebotsanfragen entspricht dies den Werten, die im RTB-Protokoll von Google über BidRequest.google_user_id
oder in der OpenRTB-Implementierung von Google über BidRequest.user.id
angegeben werden.
Die in google_cver
angegebene Version gibt die numerische Versionsnummer für die Google Nutzer-ID an. Die Google Nutzer-ID für einen bestimmten Nutzer ändert sich selten. Danach wird sie erhöht.
Wenn Google bei der Verarbeitung Ihrer Abgleichsanfrage auf einen Fehler stößt, wird stattdessen ein google_error
-Parameter angegeben.
Schritt 3: Die Gebotsfunktion verarbeitet die Weiterleitung und antwortet mit einem Pixel
Der Bieter erhält eine Weiterleitung zu seiner URL zum Cookie-Abgleich, einschließlich der Parameter, die er im ersten Schritt und die von Google im zweiten Schritt angegeben hat. Zusätzlich erhalten sie ihr Cookie auch in den HTTP-Headern. Wenn der Vorgang erfolgreich war, kann ein Bieter, der eine eigene Match-Table hostet, sein Cookie der Google Nutzer-ID zuordnen, die in der Antwort enthalten ist. Es wird empfohlen, dass Bieter genau den vom Cookie-Abgleichdienst zurückgegebenen String speichern.
Ist der Vorgang fehlgeschlagen, erhält der Bieter einen google_error
-Parameter in der Weiterleitung. Dabei handelt es sich um einen numerischen Wert, der verschiedenen Fehlerstatus entspricht, die den jeweiligen aufgetretenen Fehler identifizieren. Weitere Informationen zu möglichen Fehlerwerten finden Sie hier.
Wenn Sie eine Fehlermeldung erhalten, können Sie versuchen, einen neuen Abgleich für diesen Nutzer durchzuführen, indem Sie ein neues Übereinstimmungs-Tag einfügen.
Der Bieter muss immer mit einem unsichtbaren 1 × 1-Pixelbild antworten oder alternativ die HTTP 204
-Antwort Kein Inhalt zurückgeben.
Workflowdiagramm für den Cookie-Abgleich
Dieser Workflow wird im folgenden Diagramm veranschaulicht. Anfragen und Antworten werden durch einen Pfeil dargestellt und die zugehörigen Datenelemente in Klammern aufgeführt.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching.png?authuser=6&hl=de)
URL-Parameter für Übereinstimmungs-Tag
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_cm |
Gibt dem Cookie-Abgleichdienst von Google an, dass der Cookie-Abgleich durchgeführt werden soll. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_sc |
Dieser Parameter wurde eingestellt. Legt das Cookie von Google für den Nutzer fest, falls keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde eingestellt. Hierdurch wird der Cookie-Abgleichdienst von Google angewiesen, kein Cookie für den Nutzer zu setzen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_hm |
Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table speichern möchte.
Der Wert ist ein websicherer, mit Base64 codierter String (mit optionalem Padding). Die Rohdaten dürfen maximal 40 Byte groß sein. Beispiel: |
google_redir |
Ein URL-codierter String, den ein Bieter angeben kann, wenn er Google anweisen soll, die HTTP 302 -Weiterleitung an die codierte URL für dieses Übereinstimmungs-Tag zu senden. Dadurch kann Google in einem verketteten Aufruf an Partner ganz vorne platziert werden. Dies führt zu einem Fehler, wenn die Angabe ohne google_hm oder mit google_cm angegeben wird. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
gdpr |
Gibt an, dass die Anfrage den DSGVO-Einschränkungen in Bezug auf die Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt
Anforderungen der EU-Nutzereinwilligung oder Auswirkungen auf die Berechtigung zum Cookie-Abgleich in der
Dokumentation zu Version 2.0 des IAB TCF von Authorized Buyers.
Beispiel: |
gdpr_consent |
Ein TC-String, der die Endnutzereinwilligung darstellt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Wie wird der TC-String übergeben? in der Dokumentation zu Version 2.0 des IAB TCF 2.0 von Authorized Buyers. |
process_consent |
Gibt an, dass der Bieter die Endnutzereinwilligung für die Datenverwendung eingeholt hat, die in der
Google-Richtlinie zur Einwilligung der Nutzer in der EU angegeben ist.
Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder wenn für die Anfrage andere Einwilligungsparameter verfügbar sind ( Beispiel: |
Zusätzlich zu den oben genannten Parametern können Bieter eigene Parameter angeben, die dann als Parameter an die Weiterleitungs-URL angehängt werden. Vom Bieter definierte Parameter, die mit dem Präfix google_
benannt sind, werden ignoriert, da sie von Google für die zukünftige Entwicklung reserviert sind und die Reihenfolge der Parameter nicht garantiert ist. Ein Übereinstimmungs-Tag mit vom Bieter definierten Parametern kann so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />
Weiterleitungs-URL-Parameter
Die Weiterleitungs-URL wird aus der Cookie-Abgleich-Basis-URL erstellt, die für das Konto eines Bieters konfiguriert wurde. Sie umfasst google_
und vom Bieter definierte Parameter, je nachdem, welche im Übereinstimmungs-Tag angegeben sind. Die folgenden google_
-Antwortparameter sind definiert:
Parameter | Beschreibung |
---|---|
google_gid |
Google Nutzer-ID Dieser Wert wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_cver |
Cookie-Version Dieser Wert wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_error |
Ein ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wenn es empfangen wird, bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen
|
google_hm |
Wird nur angezeigt, wenn der Versuch, in die von Google gehostete Match-Table zu schreiben, fehlschlägt. In diesem Fall ist der Wert einer der folgenden Statuscodes:
|
google_ula |
Status des Hinzufügungsvorgangs zur Nutzerliste. Dieser wird wiederholt, wenn in der Anfrage mehrere Beispiel: Der
|
Beispielszenarien für den Cookie-Abgleich-Workflow
In den folgenden Szenarien wird beschrieben, wie der Cookie-Abgleich für einen typischen Nutzer aussehen könnte, der eine Webseite besucht.
Szenario 1: Der Nutzer löscht seine Cookies und surft auf einer Website.
Jane löscht alle Cookies im Cache. Anschließend besuchen sie die Startseite von ExampleNews.com.
Folgendes geschieht:
- BeispielNews.com wird gerendert und ruft Anzeigen von Google (Ad Manager) ab.
- Da der Anzeigenblock für die dynamische Zuordnung infrage kommt, sendet Google über den Echtzeitgebotsdienst Gebotsanfragen an FinestDSP und andere Bieter.
- Die Gebotsanwendung von FinestDSP empfängt und verarbeitet die Gebotsanfrage und sendet ihre Gebotsantwort.
- Google erhält Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP, die eine Anzeige mit einem Übereinstimmungs-Tag (Pixel) angibt.
- FinestDSP gewinnt die Auktion. Google liefert Jane die Anzeige und das Übereinstimmungs-Tag von FinestDSP.
- Das Übereinstimmungs-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt die Parameter
google_nid
undgoogle_cm
an. - Der Cookie-Abgleichdienst liest Susannes Google-Cookie und sendet Erikas Browser eine Weiterleitung an die Cookie-Abgleich-URL von FinestDSP mit den festgelegten Parametern
google_user_id
undgoogle_cver
. - Janas Browser lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
- Der Cookie-Abgleich-Endpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, die von Google festgelegte URL-Parameter und ihr Cookie für Jane in den HTTP-Headern enthält. FinestDSP kann jetzt die Zuordnung ihres Cookies zur
google_user_id
in der Match-Table speichern. - FinestDSP reagiert mit einem unsichtbaren 1x1-Pixel auf die Weiterleitung.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie-matching-schematic.png?authuser=6&hl=de)
Szenario 2: Nutzer mit vorhandener Zuordnung
Eine Woche nach Szenario 1 besucht Jane noch einmal ExampleNews.com. Nachdem Jane sowohl das Bieter- als auch das Ad Manager-Cookie auf ihrem Computer hat, funktioniert der Abgleich so.
- Die Webseite wird gerendert, sodass Google (Ad Manager) Anzeigen anfordert, die auf der Seite gerendert werden.
- Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die entsprechenden Bieter, einschließlich FinestDSP.
- FinestDSP empfängt die Gebotsanfrage, einschließlich Signalen wie dem
google_user_id
. - FinestDSP sucht nach der
google_user_id
in ihrer Match-Table und findet das mit Jane verknüpfte Cookie, das eine Woche zuvor erstellt wurde (in Szenario 1). - Basierend auf den mit dem Cookie verknüpften Informationen gibt die Gebotslogik von FinestDSP ein Gebot für die Impression ab und gewinnt die Auktion.
- Jane sieht möglicherweise eine auf ihre Interessen zugeschnittene Anzeige, basierend auf den Informationen, die FinestDSP besitzt.
Vom Bieter initiiert: Unidirektionaler Cookie-Abgleich
Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit der Ausnahme, dass nur Google eine Match-Table hostet und füllt. Dies kann in Fällen verwendet werden, in denen die Gebotsfunktion keine Google Nutzer-IDs in einer eigenen Match-Table hosten darf. Zur Verwendung dieses Ablaufs müssen Bieter Google erlauben, die Match-Table zu hosten. Außerdem können sie google_cm
in Anfragen an den Cookie-Abgleichdienst von Google nicht mehr angeben und erhalten daher keine google_gid
zum Ausfüllen der eigenen Match-Table. Sobald Google eine Übereinstimmung für einen Nutzer ermittelt hat, können Bieter ihn anhand ihrer eigenen Cookie-Daten zu Nutzerlisten hinzufügen. Analog dazu schließen Gebotsanfragen für diese Nutzer die Google Nutzer-ID aus, enthalten aber gehostete Daten zum Abgleich. Ein einfaches Beispiel für den überarbeiteten Workflow finden Sie in den folgenden Schritten.
Schritt 1: Übereinstimmungs-Tag platzieren, das an die Cookie-Abgleich-URL des Bieters weitergeleitet wird
Um diesen Vorgang zu starten, muss eine Gebotsfunktion ein Übereinstimmungs-Tag platzieren, damit es im Browser des Nutzers gerendert wird. Im Gegensatz zum Workflow für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammen, muss der Browser des Nutzers über das Übereinstimmungs-Tag zu Ihrer Cookie-Abgleich-URL weitergeleitet werden. Wenn eine Cookie-Abgleich-URL beispielsweise als https://ad.network.com/pixel
konfiguriert ist, sieht sie so aus:
<img src="https://ad.network.com/pixel" />
Beim Laden in den Browser des Nutzers wird ein Pixel von der Cookie-Abgleich-URL des Bieters angefordert. Diese Anfrage enthält ihr Cookie im HTTP-Header, das für den nächsten Schritt extrahiert werden sollte.
Schritt 2: Zum Cookie-Abgleichdienst von Google weiterleiten
Vom Endpunkt des Cookie-Abgleichs des Bieters muss eine Weiterleitung zum Cookie-Abgleichdienst von Google erfolgen. Dabei muss der Parameter google_hm
mit seinen websicheren base64-codierten Cookie-Daten gefüllt werden. Die Weiterleitungs-URL könnte so aussehen:
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA
Schritt 3: Der Browser des Nutzers wird zum Cookie-Abgleichdienst von Google weitergeleitet
Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung, die die von Ihnen angegebenen Parameter enthält.
Schritt 4: Google liefert Pixel bei Erfolg oder Fehlerweiterleitung, wenn eine Berichts-URL angegeben wurde
Wenn der Cookie-Abgleich erfolgreich ist oder wenn für das Konto des Bieters keine URL für den Cookie-Abgleichbericht angegeben wurde, liefert Google standardmäßig ein transparentes 1x1-Pixel aus und der Workflow endet hier.
Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die gehosteten Übereinstimmungsdaten des Bieters in BidRequest.hosted_match_data
für das Google-Protokoll oder BidRequest.user.buyeruid
für die OpenRTB-Implementierung von Google. Bieter können Nutzerlisten auch anhand der von ihnen angegebenen gehosteten Abgleichsdaten füllen.
Sollte ein Fehler auftreten, sendet Google eine Weiterleitung an die URL des Cookie-Abgleichberichts des Bieters. Dabei wird die Ursache des im google_error
-Parameter angegebenen Fehlers verursacht. Wenn die URL des Cookie-Abgleichberichts des Bieters https://ad.network.com/report
lautet, sieht die Weiterleitungs-URL so aus:
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
Schritt 5: Browser des Nutzers leitet zur URL des Cookie-Abgleichberichts des Bieters weiter
Der Browser des Nutzers leitet den Nutzer zur URL des Cookie-Abgleichberichts des Bieters weiter, einschließlich des Fehlergrunds (falls vorhanden), der von Google im Parameter google_error
angegeben wurde. Weitere Informationen zur Interpretation des Fehlercodes finden Sie in der Parameterbeschreibung.
Schritt 6: Der Bieter liefert ein transparentes 1x1-Pixel aus.
Der Bieter muss daraufhin ein transparentes 1 × 1-Pixel an den Browser des Nutzers senden.
Workflowdiagramm zum Cookie-Abgleich für Nutzer aus US-Bundesstaaten mit Datenschutzeinschränkungen
Der Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen wird im folgenden Diagramm veranschaulicht. Anfragen und Antworten werden durch einen Pfeil dargestellt und die Datenelemente, die sie begleiten, sind in Klammern aufgeführt.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching_ca.png?authuser=6&hl=de)
URL-Parameter für Bieter, die an den Cookie-Abgleichdienst von Google weiterleiten
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_sc |
Dieser Parameter wurde eingestellt. Legt das Cookie von Google für den Nutzer fest, falls keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde eingestellt. Hierdurch wird der Cookie-Abgleichdienst von Google angewiesen, kein Cookie für den Nutzer zu setzen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_hm |
Enthält Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table speichern möchte. |
google_redir |
Eine codierte URL, an die Google eine HTTP 302-Weiterleitung senden soll. Die angegebene URL erhält Weiterleitungen mit dem Parameter google_error sowohl für Fehler als auch für erfolgreiche Vorgänge. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
gdpr |
Gibt an, dass die Anfrage den DSGVO-Einschränkungen in Bezug auf die Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt
Anforderungen der EU-Nutzereinwilligung oder Auswirkungen auf die Berechtigung zum Cookie-Abgleich in der
Dokumentation zu Version 2.0 des IAB TCF von Authorized Buyers.
Beispiel: |
gdpr_consent |
Ein TC-String, der die Endnutzereinwilligung darstellt. Weitere Informationen finden Sie unten im Abschnitt Anforderungen der EU-Nutzereinwilligung oder Wie wird der TC-String übergeben? in der Dokumentation zu Version 2.0 des IAB TCF 2.0 von Authorized Buyers. |
process_consent |
Gibt an, dass der Bieter die Endnutzereinwilligung für die Datenverwendung eingeholt hat, die in der
Google-Richtlinie zur Einwilligung der Nutzer in der EU angegeben ist.
Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder wenn für die Anfrage andere Einwilligungsparameter verfügbar sind ( Beispiel: |
URL-Parameter für Google leiten an die URL des Cookie-Abgleichberichts des Bieters weiter
Parameter | Beschreibung |
---|---|
google_error |
Ein ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wenn es empfangen wird, bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen
|
Von Google initiiert: Bidirektionaler Pixel-Abgleich
Der bidirektionale Pixel-Abgleich ist ein Workflow für den Cookie-Abgleichdienst von Google, bei dem Google versucht, eine Google Nutzer-ID einem algorithmisch ausgewählten Bieter, nicht dem Gewinner der Echtzeitgebotsauktion, zuzuordnen. Wenn eine Anzeige platziert wird, fügt Google ein Übereinstimmungs-Tag ein, das den Browser des Nutzers anweist, ein transparentes Pixel aus der Cookie-Abgleich-URL des ausgewählten Bieters zu laden. So können sowohl Google als auch der Bieter eine Match-Table mit einem bestimmten Nutzer füllen. Unten finden Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Google fügt ein Übereinstimmungs-Tag ein
Wenn die Seite eines teilnehmenden Publishers im Browser des Nutzers geladen wird und eine Anzeigenfläche auf dieser Seite von Google gefüllt wird, kann ein Übereinstimmungs-Tag platziert werden, das ein Pixel von einem algorithmisch ausgewählten Bieter anfordert. Das von Google platzierte Pixel-Abgleich-Tag kombiniert die Cookie-Abgleich-URL des Bieters mit zusätzlichen Parametern, die der Bieter zum Ausfüllen der Match-Table verwenden kann. Für eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel
angegeben ist, ist sie so strukturiert:
<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />
Schritt 2: Der Bieter muss mit einer Weiterleitung an die URL des Cookie-Abgleichdiensts von Google antworten
Bieter, die Anfragen zum Pixelabgleich erhalten, müssen mit einer Weiterleitung zum Cookie-Abgleichdienst von Google antworten. Diese ist so aufgebaut:
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
Beachten Sie, dass die obige Weiterleitungs-URL der URL der URL ähnelt, die im Übereinstimmungs-Tag für den durch den Bieter initiierten Cookie-Abgleich-Workflow verwendet wird.
Beim Pixel-Abgleich wird der Parameter google_cm
durch den Parameter google_push
ersetzt. Sein Wert muss dem Wert entsprechen, der von Google in der Anfrage angegeben wurde. Ähnlich wie beim vom Bieter initiierten Workflow können zusätzliche Parameter für zusätzliche Anwendungsfälle festgelegt werden.
Schritt 3: Google verarbeitet die Weiterleitung und antwortet mit einem Pixel
Google protokolliert, dass eine Übereinstimmung für den Nutzer erstellt wurde, und verarbeitet alle zusätzlichen Vorgänge, die über Abfrageparameter angefordert werden. Schließlich antwortet Google mit einem transparenten 1x1-Pixel.
Workflowdiagramm: Pixel-Abgleich
Dieser Workflow wird im folgenden Diagramm veranschaulicht. Anfragen und Antworten werden durch einen Pfeil dargestellt und die zugehörigen Datenelemente in Klammern aufgeführt.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/pixel_matching.png?authuser=6&hl=de)
Anfrageparameter für Übereinstimmungs-Tags von Google
Parameter | Beschreibung |
---|---|
google_gid |
Google Nutzer-ID Für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammen, wird dies immer im Übereinstimmungs-Tag von Google angegeben. |
google_cver |
Die Cookie-Version. Dieser wird immer im Übereinstimmungs-Tag von Google angegeben. |
google_push |
Gibt an, dass diese Anfrage den Pixel-Abgleich-Workflow initiiert. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort des Bieters zurückgegeben werden. |
Weiterleitungsparameter für den Bieter-Pixel-Abgleich
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_push |
Gibt an, dass diese Weiterleitung den Pixel-Abgleich-Workflow abschließt. Hier muss der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag angegeben werden. |
google_hm |
Enthält Daten, die die Gebotsfunktion in einer von Google gehosteten Match-Table speichern möchte. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
Von Google initiiert: Unidirektionaler Pixel-Abgleich
Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow darin, dass das Übereinstimmungs-Tag von Google keinen Parameter enthält, der die Google User-ID angibt. Es wird jedoch weiterhin eine von Google gehostete Match-Table gefüllt. Dies kann in Fällen verwendet werden, in denen der Bieter nicht berechtigt ist, Google Nutzer-IDs in einer eigenen Match-Table zu hosten. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.
Schritt 1: Google fügt ein Übereinstimmungs-Tag ein
Google platziert ein Übereinstimmungs-Tag für einen algorithmisch ausgewählten Bieter. Das Übereinstimmungs-Tag enthält den Parameter google_push
. Beispiel:
<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />
Schritt 2: Der Browser des Nutzers fordert Pixel von der Kochabgleich-URL des Bieters an
Der Browser des Nutzers fordert von der Cookie-Abgleich-URL des Bieters ein Pixel an, einschließlich des Cookies des Bieters in den HTTP-Headern.
Schritt 3: Zum Cookie-Abgleichdienst von Google weiterleiten
Vom Endpunkt des Cookie-Abgleichs des Bieters muss eine Weiterleitung zum Cookie-Abgleichdienst von Google erfolgen. Dabei muss der Parameter google_hm
mit seinen websicheren base64-codierten Cookie-Daten gefüllt werden. Die Weiterleitungs-URL könnte so aussehen:
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA
Schritt 4: Der Browser des Nutzers wird zum Cookie-Abgleichdienst von Google weitergeleitet
Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung, die die von Ihnen angegebenen Parameter enthält. Wenn der Vorgang erfolgreich war, enthalten die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die gehosteten Abgleichsdaten des Bieters in BidRequest.hosted_match_data
für das Google-Protokoll oder BidRequest.user.buyeruid
für die OpenRTB-Implementierung von Google. Bieter können auch Nutzerlisten mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.
Schließlich gibt Google ein transparentes 1x1-Pixel an den Browser des Nutzers zurück.
Vorbereitung zum Cookie-Abgleich
Mit Open Bidding können Anzeigenplattformen vom Bieter initiierte und von Google initiierte Cookie-Abgleich-Workflows verwenden, um eine Google Nutzer-ID mit ihrem Cookie abzugleichen. Cookie Match Assist (CMA) ist eine zusätzliche Funktion für Anzeigenplattformen, mit der sie Match-Tables mit ihren eigenen Bietern erstellen können.
Funktionsweise des Cookie-Abgleichassistenten
Beim Platzieren einer Anzeige wählt Google mithilfe von Algorithmen eine teilnehmende Anzeigenplattform aus und platziert ein Assist-Tag für den Cookie-Abgleich, das folgende Struktur hat:
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
Das CMA-Übereinstimmungs-Tag von Google führt dazu, dass die Cookie-Abgleich-URL der Anzeigenplattform eine Pixelanfrage empfängt.
- Die Anfrage wird an den Endpunkt des Cookie-Abgleichs der Anzeigenplattform gesendet, bei dem der Cookie-Abgleichdienst für den Abgleich der Nutzer-ID mit einem Bieter zuständig ist. Im folgenden Diagramm antwortet der Cookie-Abgleichdienst der Anzeigenplattform dem Browser des Nutzers mit einer Weiterleitung an einen der Endpunkte seiner Bieter.
- Der Bieter empfängt die Anfrage zusammen mit allen von der Anzeigenplattform festgelegten Parametern, um die User-ID mit seinem Cookie abzugleichen.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_match_assist_diagram.png?authuser=6&hl=de)
Einschränkungen
Häufigkeit der Anfragen für neue Übereinstimmungen begrenzen
Bieter sind dafür verantwortlich, die Anzahl der Aufrufe an den Cookie-Abgleichdienst für Nutzer zu beschränken, für die in der von Google gehosteten Match-Table ein neuer Eintrag vorhanden ist. Ein Eintrag in der gehosteten Match-Table kann nach 14 Tagen als abgelaufen angesehen werden. Danach kann er aktualisiert werden.
Auf alle Pixel-Abgleichanfragen antworten
Bieter, die den Workflow für den Pixel-Abgleich verwenden, müssen auf alle eingehenden Pixel-Abgleichanfragen mit einer Antwort antworten, die den Parameter google_push
enthält. So kann Google durch die Überwachung der Nutzung Richtlinien durchsetzen. Wenn die Antwortrate eines Bieters unter 90 % fällt, drosselt Google die Anzahl der Pixel-Abgleichanfragen, die an sein Konto gesendet werden.
HTTPS-Endpunkte verwenden
Endpunkte, die in allen Cookie-Abgleich-Workflows verwendet werden, müssen HTTPS verwenden.
Wenn Sie auf eine Pixel-Abgleichanfrage antworten, die Sie über HTTPS erhalten haben, müssen Sie Ihre Nutzer über HTTPS zum Cookie-Abgleichdienst weiterleiten. Ebenso muss ein Endpunkt für den Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, ebenfalls HTTPS verwenden. Wenn Sie häufiger als alle zwei Minuten Anfragen über HTTP an Google senden, wird die Anzahl der Übereinstimmungsanfragen, die an Ihr Konto gesendet werden, gedrosselt.
Anforderungen an die Einwilligung der Nutzer in der EU
Anfragen zum Cookie-Abgleich, die der Google-Richtlinie zur Einwilligung der Nutzer in der EU unterliegen, sollten die Einwilligung des Endnutzers enthalten. Solche Anfragen müssen darauf hinweisen, dass eine Einwilligung auf eine der folgenden Arten eingeholt wurde:
- TCF v2: Dazu gehören die Parameter
gdpr
undgdpr_consent
. Weitere Informationen finden Sie in der Dokumentation zu Version 2.0 des IAB TCF 2.0 von Authorized Buyers. process_consent
: eine Erklärung, dass der Bieter die erforderliche Nutzereinwilligung eingeholt hat
Beispiele
Die folgenden Beispiele veranschaulichen, wie der Cookie-Abgleichdienst zum Erreichen bestimmter Ziele verwendet wird. Sofern nicht anders angegeben, wird angenommen, dass der Nutzer, für den eine Aktion ausgeführt wird, nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen stammt.
Eine vom Bieter gehostete Match-Table ausfüllen
Eine Gebotsfunktion kann den Cookie-Abgleich-Workflow verwenden, um ihre eigene Match-Table zu füllen, indem nur die Parameter google_nid
und google_cm
im Übereinstimmungs-Tag angegeben werden. Das könnte so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />
Wenn die Cookie-Abgleich-URL des Bieters auf https://ad.network.com/pixel?id=1
gesetzt ist und der Cookie-Abgleich erfolgreich ist, könnte die Weiterleitung, die Google als Antwort auf das Übereinstimmungs-Tag des Bieters sendet, so aussehen:
https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
Wenn der Cookie-Abgleich fehlschlägt, weil der Nutzer kein Google-Cookie hat, lautet die Antwort:
https://ad.network.com/pixel?id=1&google_error=3
Der Fehlercode hängt von der Fehlerursache ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie unter Parameter für die Weiterleitungs-URL.
Zur Liste mit einzelnen Nutzern hinzufügen
Der google_ula
-Parameter kann im Übereinstimmungs-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn in der von Google oder der vom Bieter gehosteten Match-Table ein neuer Eintrag für den Nutzer vorhanden ist, kann die Gebotsfunktion ein Übereinstimmungs-Tag mit den Parametern google_nid
und google_ula
platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Cookie-Abgleich-Workflow zu starten. Weitere Informationen finden Sie in den Einschränkungen zum Aufrufen des Cookie-Abgleichdiensts. Das entsprechende Übereinstimmungs-Tag könnte so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />
Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://ad.network.com/pixel
lautet, lautet die Weiterleitungs-URL von Google:
https://ad.network.com/pixel?google_ula=12345,0
Bei einem allgemeinen Fehler – beispielsweise, wenn kein Google-Cookie für den Nutzer vorhanden ist – enthält die Weiterleitungs-URL den Parameter google_error
:
https://ad.network.com/pixel?google_error=3
Wenn ein Fehler speziell beim Hinzufügen des Nutzers zur Liste auftritt, wird google_ula
in der Weiterleitung zurückgegeben. Im Gegensatz zum entsprechenden Übereinstimmungs-Tag-Parameter wird hier der Zeitstempel durch einen Statuscode ersetzt, der den Erfolg des Vorgangs anzeigt. Wenn die Anfrage beispielsweise fehlgeschlagen ist, weil das Bieterkonto keinen Zugriff auf die angegebene Nutzerliste hatte, lautet die Weiterleitungs-URL:
https://ad.network.com/pixel?google_ula=12345,2
Zu mehreren Nutzerlisten hinzufügen
Bieter können festlegen, dass ein Nutzer mehreren Nutzerlisten hinzugefügt werden soll, indem sie mehrere google_ula
-Parameter in das Übereinstimmungs-Tag aufnehmen. In der Praxis könnte das so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
Der Status des Vorgangs wird für jede Nutzerliste in ähnlicher Weise über verschiedene google_ula
-Parameter in der Weiterleitung gemeldet:
https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0
In der obigen Weiterleitung sehen wir, dass der Vorgang für die Nutzerliste mit der ID 45678
erfolgreich war, für die Nutzerlisten-ID 12345
jedoch fehlgeschlagen ist, da der Bieter keine Zugriffsberechtigung hatte.
Workflow für den Cookie-Abgleich durchlaufen und zur Nutzerliste hinzufügen
Damit der Cookie-Abgleich durchgeführt und der Nutzer in einer Einzelanfrage einer Nutzerliste hinzugefügt werden kann, sollte das Übereinstimmungs-Tag eines Bieters google_cm
und google_ula
enthalten:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />
Die von Google angegebene Weiterleitungs-URL würde google_gid
, google_cver
und google_ula
enthalten. Dies könnte so aussehen:
https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0
Übereinstimmung in einer von Google gehosteten Match-Table speichern
Wenn eine Gebotsfunktion ihre Cookiedaten in einer von Google gehosteten Match-Table speichern und nicht die Übereinstimmung mit der Google Nutzer-ID in ihrer eigenen Match-Table speichern möchte, muss das Übereinstimmungs-Tag den Parameter google_hm
enthalten. Der Wert muss ein websicherer base64-codierter String sein. Für einen Nutzer, bei dem die nicht codierten Cookiedaten des Bieters Cookie number 1!
sind, lautet der codierte Wert Q29va2llIG51bWJlciAxIQ==
, der in einem Übereinstimmungs-Tag wie dem folgenden verwendet wird:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://cookie-monster.com/pixel
lautet, lautet die Weiterleitungs-URL von Google:
https://cookie-monster.com/pixel
Der google_gid
-Parameter ist nicht in der Weiterleitung enthalten, da google_cm
nicht im Übereinstimmungs-Tag enthalten ist und google_hm
nicht in erfolgreichen Antworten enthalten ist. Bei zukünftigen Gebotsanfragen für Impressionen für diesen Nutzer erhält der Bieter seine gehosteten Abgleichsdaten in BidRequest.hosted_match_data
(für das RTB-Protokoll von Google) oder in BidRequest.user.buyeruid
(für die OpenRTB-Implementierung von Google).
Wenn der Bieter stattdessen ein Übereinstimmungs-Tag verwendet, bei dem der Wert von google_hm
nicht base64-codiert war (z. B. chocolate_chunk!
), könnte die Weiterleitungs-URL so aussehen:
https://cookie-monster.com/pixel?google_hm=2
Die obige Weiterleitungs-URL enthält den google_hm
-Wert 2
. Dies deutet darauf hin, dass der Vorgang fehlgeschlagen ist, da der Wert nicht decodiert werden konnte.
Bieter und von Google gehostete Match-Tables mit Nutzerlisten
Wenn eine Gebotsfunktion neben einer von Google gehosteten Nutzerliste auch eine eigene Nutzungsliste hostet und ein einzelnes Übereinstimmungs-Tag mit beiden Tabellen verknüpfen und den Nutzer einer bestimmten Nutzerliste hinzufügen möchte, muss das Übereinstimmungs-Tag die Parameter google_cm
, google_hm
und google_ula
enthalten. Wenn die Cookiedaten des Bieters Cookie number 1!
sind, ist der codierte Wert Q29va2llIG51bWJlciAxIQ==
, wodurch ein Übereinstimmungs-Tag wie das folgende erzeugt wird:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />
Wenn die Cookie-Abgleich-URL des Bieters bei einer erfolgreichen Antwort https://cookie-monster.com/pixel
lautet, sieht die Weiterleitungs-URL von Google so aus:
https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0
Beim Empfang der Weiterleitung kann der Bieter die in google_gid
angegebene Google Nutzer-ID mit seinen Cookiedaten in der Match-Table abgleichen. Außerdem kann er feststellen, ob die von Google gehosteten Match-Table- und Nutzerlistenvorgänge erfolgreich waren. Infolgedessen erhält der Bieter bei jedem Pre-Targeting, das für die Ausrichtung auf die angegebene Nutzerlisten-ID konfiguriert ist, Gebotsanfragen für Impressionen des Nutzers. Bei diesen Gebotsanfragen erhält der Bieter seine gehosteten Daten zum Abgleich in BidRequest.hosted_match_data
(für das RTB-Protokoll von Google) oder in BidRequest.user.buyeruid
(für die OpenRTB-Implementierung von Google).