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
Was ist der Cookie-Abgleich?
Domaininhaber legen in der Regel den Inhalt von Cookies für Nutzer fest, die ihre Website besuchen. Diese Cookies werden verwendet, um Nutzer innerhalb dieser Domain zu identifizieren. Selbst wenn zwei Domaininhaber dem Austausch dieser Daten zustimmen würden, verhindert das Sicherheitsmodell von Internetbrowsern, dass ein Cookie einer anderen Domain gelesen wird.
Im Zusammenhang mit digitaler Werbung identifiziert Google Nutzer anhand von Cookies, die zur Domain doubleclick.net
gehören. Bieter, die am Echtzeitgebotsverfahren teilnehmen, haben möglicherweise eine eigene Domain, in der sie Nutzer identifizieren, denen sie Anzeigen präsentieren möchten. Beim Cookie-Abgleich kann der Bieter seine Cookies mit denen von Google abgleichen, um festzustellen, ob eine in einer Gebotsanfrage gesendete Impression mit einem der Nutzer verknüpft ist, auf die das Targeting erfolgt. Er erhält entweder seine eigenen Cookiedaten oder eine bieterspezifische Google Nutzer-ID, die eine verschlüsselte Form des doubleclick.net
-Cookies in der Gebotsanfrage ist.
Der in diesem Leitfaden beschriebene Cookie-Abgleichsdienst erleichtert das Erstellen und Pflegen der Verknüpfung zwischen dem Cookie eines Bieters und der Google-Nutzer-ID. Außerdem können damit Nutzerlisten erstellt werden.
Match-Tables
Mit einer Abgleichtabelle können Sie eine ID oder andere Daten aus einer Domain einer anderen zuordnen. Bieter können mit dem Cookie-Abgleichdienst ihre eigenen Match-Tables ausfüllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google Nutzer-ID des Nutzers zuordnen oder eine von Google gehostete Match-Table ausfüllen. Abgleichstabellen sind erforderlich, damit die Bieteranwendung eines Bieters auf Cookie-Daten für den Nutzer zugreifen kann, dem die Impression präsentiert wird.
Von Google gehostete Match-Tables
Für eine einfachere Wartung, geringere Latenz und Zugriff auf Abgleichsdaten für Nutzer in bestimmten Regionen sollten Sie Google erlauben, Ihre Abgleichstabelle zu hosten. So kannst du einen websicheren base64-codierten String angeben, der der Google Nutzer-ID für einen bestimmten Nutzer zugeordnet wird. Der String wird im Folgenden als gehostete Abgleichsdaten bezeichnet. Sobald eine Übereinstimmung festgestellt wurde, kann sie auf folgende Arten verwendet werden:
Echtzeitgebote: Bei nachfolgenden Gebotsanfragen für Impressionen, die mit dem Nutzer verknüpft sind, sendet Google Ihnen die gehosteten Abgleichsdaten, die Sie mit der Google-Nutzer-ID abgeglichen haben. In der OpenRTB-Implementierung von Google wird
BidRequest.user.buyeruid
als websicherer Base64-codierter String angegeben. Wenn Ihr Gebotsendepunkt für die Verwendung des eingestellten Google RTB-Protokolls konfiguriert ist, erhalten Sie diese als decodierte Bytes über das FeldBidRequest.hosted_match_data
.Nutzerlisten: Nutzerlisten können entweder mit Google-Nutzer-IDs oder gehosteten Abgleichsdaten ausgefüllt werden.
- Pre-Targeting: Sie können das Pre-Targeting so konfigurieren, dass Sie nur Gebotsanfragen mit gehosteten Abgleichsdaten erhalten. So lassen sich weniger relevante Impressionen für Nutzer außerhalb Ihres Cookie-Speichers ausschließen.
Nutzerlisten
Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Anschließend können Sie diese Listen mit den unten beschriebenen Workflows für die Cookie-Abgleiche oder über den Bulk-Uploader-Dienst füllen.
Erste Schritte
Wenn Sie den Cookie-Abgleich verwenden möchten, müssen Sie sich an Ihren Technical Account Manager wenden, der bestimmte Workflows aktivieren und Sie bei der Konfiguration folgender Elemente unterstützen kann:
- Netzwerk-ID des Cookie-Abgleichs (NID): Eine String-ID, mit der sich ein Bieterkonto bei der Cookie-Übereinstimmung und anderen ähnlichen Vorgängen eindeutig identifizieren lässt.
- URL des Cookie-Abgleichs: Die Basis-URL eines Endpunkts, an dem eingehende Anfragen im Rahmen des Cookie-Abgleichsworkflows angenommen und verarbeitet werden. Bieter können Makros in diese URL einbetten, um die Reihenfolge der Parameter zu steuern, die in Cookie-Übereinstimmungsworkflows an sie übergeben werden.
- Abgleich-Tag: Das Tag, das Sie im Browser eines Nutzers platzieren müssen, um den vom Bieter initiierten Cookie-Abgleich auszuführen. Sie können zusammen mit Anzeigen ausgeliefert oder außerhalb von Anzeigen auf Web-Properties platziert werden.
- URL des Berichts zum Cookie-Abgleich (optional): Im einseitigen Cookie-Übereinstimmungsworkflow ist dies eine optionale URL, über die ein Endpunkt angegeben werden kann, an den Fehlerdetails gesendet werden, falls die Cookie-Übereinstimmung aufgrund einer HTTP-302-Weiterleitung fehlschlägt. Standardmäßig werden Antworten nur an diese URL gesendet, wenn beim Cookie-Abgleich ein Fehler aufgetreten ist. Bieter können jedoch anfordern, dass die Weiterleitung immer gesendet wird.
- Cookie Match Assist-URL: Für Anzeigenplattformen, die den Cookie Match Assist-Workflow implementieren, ist dies die Basis-URL des Endpunkts, der auf eingehende Anfragen reagieren soll.
- Kontingent für den Cookie-Abgleich: Für Anzeigenplattformen, die den Workflow für den Cookie-Abgleich implementieren, ist dies die maximale Anzahl von Anfragen, die ihre Cookie-Abgleichs-URL pro Sekunde erhalten kann. So soll verhindert werden, dass die Server der Anzeigenplattform durch CMA-Anfragen überlastet werden.
Makros für den Cookie-Abgleich
Bei allen unterstützten Cookie-Abgleich-Workflows werden der Cookie-Abgleichs-URL eines Bieters in der Regel Parameter in einer nicht garantierten Reihenfolge angehängt. Bieter mit Integrationen, für die eine einheitliche Reihenfolge der Parameter erforderlich ist, können Makros in ihre Cookie-Abgleichs-URL einfügen, um die Platzierung zu gewährleisten.
Unterstützte Makros
Bieter können ihre Cookie-Abgleichs-URL optional so konfigurieren, dass sie ein oder mehrere Makros im Format %%GOOGLE_<PARAM_NAME>%%
oder %%GOOGLE_<PARAM_NAME>_PAIR%%
enthält. Folgende Makros und ihre erweiterten Werte werden unterstützt:
Macro | Maximierter Wert |
---|---|
GOOGLE_GID | GOOGLE_USER_ID |
GOOGLE_GID_PAIR | &google_gid=GOOGLE_USER_ID |
GOOGLE_CVER | COOKIE_VERSION_NUMBER |
GOOGLE_CVER_PAIR | &cver=COOKIE_VERSION_NUMBER |
GOOGLE_ERROR | ERROR_ID |
GOOGLE_ERROR_PAIR | &google_error=ERROR_ID |
GOOGLE_PUSH | PIXEL_MATCH_DATA |
GOOGLE_PUSH_PAIR | &google_push=PIXEL_MATCH_DATA |
GOOGLE_ALL_PARAMS | google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID |
Beispiel für ein Makro
Ein Bieter hat eine Cookie-Abgleichsintegration mit einem Endpunkt, der unter https://user.bidder.com.cookies
gehostet wird. Für die Implementierung sind neben den Pixel-Abgleichsparametern vordefinierte Bieterparameter in der folgenden Reihenfolge erforderlich: google_push
, google_gid
, google_cver
und google_error
. Dazu kann der Bieter seine Cookie-Abgleich-URL so festlegen:
https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%
Wenn Google später eine Abgleichsanfrage an diesen Bieter sendet, wird sie in etwa so erweitert:
https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3
Workflows für den Cookie-Abgleichdienst
Der Cookie-Abgleichsdienst von Google unterstützt derzeit drei Workflows für verschiedene Anwendungsfälle, die unten beschrieben werden.
Vom Bieter initiiert: Zweiseitiger Cookie-Abgleich
Die beidseitige Cookie-Abgleichsfunktion bezieht sich auf einen vom Bieter initiierten Workflow, bei dem ein Abgleich-Tag im Browser des Nutzers platziert wird, das ihn an Google weiterleitet. Mit diesem Workflow können sowohl Google als auch der Bieter Abgleichstabellen erstellen. Im Folgenden finden Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Abgleich-Tag platzieren
Um diesen Ablauf zu starten, muss der Bieter sein Match-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Ein einfaches Übereinstimmungs-Tag, das nur die Google Nutzer-ID an den Bieter zurückgibt, kann so strukturiert sein:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
Sie können dem Abgleichs-Tag zusätzliche Parameter hinzufügen, um verschiedene Anwendungsfälle zu erfüllen. Weitere Informationen zu diesen Parametern finden Sie unter URL-Parameter für Tags abgleichen.
Schritt 2: Google antwortet mit einer Weiterleitung, die Abgleichsdaten enthält
Das Übereinstimmungs-Tag führt dazu, dass der Cookie-Abgleichdienst von Google eine Anfrage vom Browser des Nutzers empfängt, wodurch eine HTTP 302
-Weiterleitung an die Cookie-Abgleich-URL des Bieters gesendet wird. Die Weiterleitung enthält Abfrageparameter, die die Google Nutzer-ID und die Versionsnummer in der URL angeben. Außerdem erhält der Bieter sein Cookie, das in den Anfrageheadern enthalten ist. In der Praxis könnte die Weiterleitungs-URL für das einfache Abgleich-Tag mit der oben genannten Cookie-Abgleichs-URL https://ad.network.com/pixel
so aussehen:
https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
Die mit dem Parameter google_gid
übergebene Google Nutzer-ID ist ein websicherer, base64-codierter String ohne Padding. Bietern, die eine Abgleichtabelle hosten, wird empfohlen, den genauen String zu speichern, der vom Cookie-Abgleichsdienst zurückgegeben wird. In nachfolgenden Gebotsanfragen entspricht dies den Werten, die in OpenRTB über BidRequest.user.id
oder im eingestellten Google RTB-Protokoll über BidRequest.google_user_id
angegeben sind.
Die in google_cver
angegebene Version ist die numerische Versionsnummer der Google-Nutzer-ID. Die Google Nutzer-ID eines bestimmten Nutzers ändert sich nur selten und wird anschließend erhöht.
Wenn Google bei der Verarbeitung Ihrer Abgleichsanfrage einen Fehler feststellt, wird stattdessen ein google_error
-Parameter angegeben.
Schritt 3: Bieter verarbeitet Weiterleitung und antwortet mit Pixel
Der Bieter wird auf seine Cookie-Abgleichs-URL weitergeleitet. Diese enthält die Parameter, die er im ersten Schritt angegeben hat, sowie die von Google im zweiten Schritt bereitgestellten Parameter. Außerdem erhalten sie ihr Cookie an die HTTP-Header. Wenn der Vorgang erfolgreich war, kann ein Bieter, der eine eigene Abgleichtabelle hostet, sein Cookie mit der in der Antwort enthaltenen Google-Nutzer-ID abgleichen. Es wird empfohlen, den genauen String zu speichern, der vom Cookie-Abgleichsdienst zurückgegeben wird.
Wenn der Vorgang fehlgeschlagen ist, erhält der Bieter einen google_error
-Parameter in der Weiterleitung. Dies ist ein numerischer Wert, der verschiedenen Fehlerstatus entspricht, die den aufgetretenen Fehler identifizieren. Weitere Informationen zu den möglichen Fehlerwerten
Wenn Sie eine Fehlermeldung erhalten, können Sie versuchen, den Nutzer noch einmal abzugleichen, indem Sie ein neues Abgleich-Tag platzieren.
Der Bieter muss immer ein 1 × 1-Pixel-Bild mit unsichtbaren Pixeln ausliefern oder alternativ eine HTTP 204
Kein Inhalt-Antwort zurückgeben.
Workflowdiagramm für den Cookie-Abgleich
Dieser Workflow ist im folgenden Diagramm dargestellt. Dort werden Anfragen und Antworten durch einen Pfeil dargestellt und die zugehörigen Datenelemente in Klammern aufgeführt.
Übereinstimmung mit Tag-URL-Parametern
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bidders abgerufen werden. |
google_cm |
Gibt dem Cookie-Abgleichsdienst von Google an, dass der Cookie-Abgleich durchgeführt werden soll. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_sc |
Dieser Parameter wurde eingestellt. Setzt das Google-Cookie für den Nutzer, falls noch keines vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde eingestellt. Dies weist den Cookie-Abgleichsdienst von Google an, kein Cookie für den Nutzer festzulegen, wenn kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_hm |
Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte.
Der Wert ist ein websicherer Base64-codierter String (mit optionalem Padding). Die Rohdaten dürfen maximal 40 Byte groß sein. Beispiel: |
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] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
gdpr |
Gibt an, dass die Anfrage den Einschränkungen der DSGVO zur Datennutzung unterliegt. Weitere Informationen finden Sie unten im Abschnitt
Anforderungen an die Einwilligung der Nutzer in der EU und im Abschnitt Auswirkungen auf die Berechtigung für den Cookie-Abgleich in der
Dokumentation zum IAB TCF 2.0 für Authorized Buyers.
Beispiel: |
gdpr_consent |
Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der Autorisierten Käufer – IAB TCF v2.0-Dokumentation unter Wie wird der TC-String übergeben? |
process_consent |
Gibt an, dass der Bieter die Einwilligung der Endnutzer für die in der
Richtlinie zur Einwilligung der Nutzer in der EU von Google angegebenen Datennutzungen eingeholt hat.
Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder andere Einwilligungsparameter in der Anfrage verfügbar sind ( Beispiel: |
Zusätzlich zu den oben genannten Parametern können Bieter eigene Parameter angeben, die der Weiterleitungs-URL als Parameter angehängt werden. Von Bietern definierte Parameter mit dem Präfix google_
werden ignoriert, da sie von Google für zukünftige Entwicklungen reserviert sind. Die Reihenfolge der Parameter kann nicht garantiert werden. Ein Übereinstimmungs-Tag mit von Bietern definierten Parametern kann so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />
Parameter für Weiterleitungs-URLs
Die Weiterleitungs-URL basiert auf der Basis-URL für den Cookie-Abgleich, die für das Konto eines Bieters konfiguriert wurde, einschließlich google_
und von Bietern definierter Parameter, je nachdem, welche Parameter im Übereinstimmungs-Tag angegeben sind. Die folgenden google_
-Antwortparameter sind definiert:
Parameter | Beschreibung |
---|---|
google_gid |
Google-Nutzer-ID Wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_cver |
Cookie-Version. Wird festgelegt, wenn google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_error |
Ein Ganzzahlwert, der den Gesamtfehler der Anfrage angibt. Nach dem Empfang bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen
|
google_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 Vorgangs zum Hinzufügen einer Nutzerliste. Dieser wird wiederholt, wenn in der Anfrage mehrere Beispiel: Der Vorgang
|
Beispielszenarien für den Cookie-Abgleich-Workflow
In den folgenden Szenarien wird beschrieben, wie die Cookie-Abgleichsfunktion für einen typischen Nutzer aussehen könnte, der eine Webseite besucht.
Szenario 1: Nutzer löscht seine Cookies und ruft eine Website auf
Jane löscht alle Cookies aus dem Cache. Er ruft dann die Startseite von BeispielNachrichten.de auf.
Folgendes passiert:
- ExampleNews.com wird gerendert und ruft Anzeigen über 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 Bieteranwendung von FinestDSP empfängt und verarbeitet die Gebotsanfrage und sendet die Gebotsantwort.
- Google erhält Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP, in der eine Anzeige mit einem Abgleich-Tag (Pixel) angegeben ist.
- FinestDSP gewinnt die Auktion. Google sendet Jane die Anzeige und das Abgleich-Tag von FinestDSP.
- Das Übereinstimmungs-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt die Parameter
google_nid
undgoogle_cm
an. - Der Cookie-Abgleichsdienst liest das Google-Cookie von Jana und leitet ihren Browser mit den festgelegten Parametern
google_gid
undgoogle_cver
an die Cookie-Abgleichs-URL von FinestDSP weiter. - Der Browser von Jana lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
- 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. - FinestDSP antwortet auf die Weiterleitung mit einem unsichtbaren 1x1-Pixel.
Szenario 2: Nutzer mit vorhandener Zuordnung
Eine Woche nach Szenario 1 besucht Jane noch einmal beispielnachrichten.de. Jane hat jetzt sowohl Bidder- als auch Ad Manager-Cookies auf ihrem Computer. So funktioniert das Abgleichverfahren:
- Die Webseite wird gerendert, wodurch Google (Ad Manager) Anzeigen anfordert, die auf der Seite gerendert werden.
- Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die anwendbaren Bieter, einschließlich FinestDSP.
- FinestDSP erhält die Gebotsanfrage, einschließlich Signalen wie
google_gid
. - 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. - 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.
- Jana sieht dann möglicherweise eine Anzeige, die auf ihren Interessen basiert und auf Informationen von FinestDSP beruht.
Vom Bieter initiiert: Unidirektionaler Cookie-Abgleich
Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit der Ausnahme, dass er so geändert wird, dass nur Google eine Match-Table hostet und ausfüllt. Diese Option kann verwendet werden, wenn der Bieter keine Google-Nutzer-IDs in seiner eigenen Abgleichtabelle hosten darf. Um diesen Ablauf verwenden zu können, müssen Bieter Google das Hosten der Match-Table erlauben. Sie können google_cm
nicht mehr in Anfragen an den Cookie-Abgleichdienst von Google angeben und erhalten folglich auch keine google_gid
zum Ausfüllen ihrer eigenen Match-Table. Sobald Google eine Übereinstimmung für einen Nutzer festgestellt hat, können Bieter ihn mithilfe ihrer eigenen Cookiedaten zu Nutzerlisten hinzufügen. Ebenso werden Gebotsanfragen für diese Nutzer die Google-Nutzer-ID ausschließen, aber gehostete Abgleichsdaten enthalten. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.
Schritt 1: Abgleich-Tag auf die Cookie-Übereinstimmungs-URL des Bieters einfügen
Um diesen Ablauf zu starten, muss ein Bieter ein Match-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Im Gegensatz zum Workflow für Nutzer, die nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammen, muss das Abgleich-Tag den Browser des Nutzers auf Ihre Cookie-Abgleichs-URL weiterleiten. Wenn die URL für den Cookie-Abgleich beispielsweise als https://ad.network.com/pixel
konfiguriert ist, würde sie so aussehen:
<img src="https://ad.network.com/pixel" />
Beim Laden im Browser des Nutzers wird ein Pixel von der Cookie-Abgleichs-URL des Bieters angefordert. Diese Anfrage enthält das Cookie im HTTP-Header, das für den nächsten Schritt extrahiert werden sollte.
Schritt 2: Weiterleitung zum Cookie-Abgleichsdienst von Google
Der Cookie-Abgleichs-Endpunkt des Bieters muss zum Cookie-Abgleichsdienst von Google weiterleiten. Er muss den Parameter google_hm
enthalten, der mit den websicheren Base64-codierten Cookie-Daten des Bieters ausgefüllt ist. Die Weiterleitungs-URL könnte so aussehen:
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA
Schritt 3: Der Browser des Nutzers wird an den Cookie-Abgleichsdienst von Google weitergeleitet
Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung mit den von Ihnen angegebenen Parametern.
Schritt 4: Google liefert Pixel bei Erfolg oder Fehlerweiterleitung aus, falls Berichts-URL angegeben ist
Wenn die Cookie-Abgleichsoperation erfolgreich war oder für das Konto des Bieters keine URL für den Cookie-Abgleichsbericht angegeben wurde, wird von Google standardmäßig ein transparentes Pixel mit einer Größe von 1 × 1 Pixel ausgeliefert. Der Workflow endet hier.
Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid
für OpenRTB oder BidRequest.hosted_match_data
für das eingestellte Google RTB-Protokoll. Bieter können Nutzerlisten auch mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.
Andernfalls wird der Bieter über die URL des Berichts zur Cookie-Abgleichung auf eine Google-Weiterleitungsseite weitergeleitet. Die Ursache des Fehlers wird im Parameter google_error
angegeben. Wenn die URL des Berichts zum Cookie-Abgleich des Bieters https://ad.network.com/report
lautet, würde die Weiterleitungs-URL so aussehen:
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
Schritt 5: Der Browser des Nutzers leitet zur URL des Cookie-Abgleichberichts des Bieters weiter
Der Browser des Nutzers wird zur Berichts-URL für die Cookie-Abgleiche des Bieters weitergeleitet. Dabei wird gegebenenfalls auch der von Google im Parameter google_error
angegebene Fehlergrund angezeigt. Weitere Informationen zur Interpretation des Fehlercodes finden Sie in der Parameterbeschreibung.
Schritt 6: Bieter sendet transparentes 1x1-Pixel
Der Bieter muss antworten, indem er dem Browser des Nutzers ein transparentes 1x1-Pixel sendet.
Workflow-Diagramm für die Cookie-Abgleichsfunktion für Nutzer aus US-Bundesstaaten mit Datenschutzeinschränkungen
Der Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen wird im Diagramm unten dargestellt. Anfragen und Antworten werden durch einen Pfeil dargestellt und die zugehörigen Datenelemente sind in Klammern aufgeführt.
URL-Parameter für Bieter leiten an den Cookie-Abgleichdienst von Google weiter
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_sc |
Dieser Parameter wurde eingestellt. Setzt das Google-Cookie für den Nutzer, falls noch keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Wenn Sie den Parameter weglassen, wird ein Fehler ausgegeben, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde eingestellt. Dies weist den Cookie-Abgleichsdienst von Google an, kein Cookie für den Nutzer festzulegen, falls kein Cookie vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_hm |
Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte. |
google_redir |
Eine codierte URL, für die Google eine HTTP-302-Weiterleitung senden soll. Die angegebene URL erhält sowohl bei Fehlern als auch bei erfolgreichen Vorgängen Weiterleitungen mit dem Parameter google_error . |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
gdpr |
Gibt an, dass die Anfrage DSGVO-Einschränkungen für die Datennutzung unterliegt. Weitere Informationen finden Sie unten unter
Anforderungen an die Nutzereinwilligung in der EU oder in der
IAB TCF 2.0-Dokumentation für autorisierte Käufer unter Auswirkungen auf die Eignung für die Cookie-Abgleichsfunktion.
Beispiel: |
gdpr_consent |
Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter Anforderungen an die Nutzereinwilligung in der EU oder in der Autorisierten Käufern-Dokumentation zum IAB TCF 2.0 unter Wie wird der TC-String übergeben? |
process_consent |
Gibt an, dass der Bieter die Einwilligung der Endnutzer für die in der
Richtlinie zur Einwilligung der Nutzer in der EU von Google angegebenen Datennutzungen eingeholt hat.
Wenn die Anfrage nicht der Richtlinie zur Einwilligung der Nutzer in der EU unterliegt oder für die Anfrage andere Einwilligungsparameter verfügbar sind ( Beispiel: |
URL-Parameter für die Google-Weiterleitung zur URL des Berichts zum Cookie-Abgleich des Bieters
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
|
Von Google initiiert: Bidirektionaler Pixelabgleich
Der bidirektionale Pixelabgleich ist ein Workflow für den Cookie-Abgleichsdienst von Google. Dabei versucht Google, eine Google-Nutzer-ID mit einem algorithmisch ausgewählten Bieter abzugleichen, der nicht der Gewinner der Echtzeitgebotsauktion ist. Wenn eine Anzeige ausgeliefert wird, platziert Google ein Abgleich-Tag, das den Browser des Nutzers anweist, ein transparentes Pixel von der Cookie-Abgleich-URL des ausgewählten Bieters zu laden. So können sowohl Google als auch der Bieter eine Match-Table mit einem bestimmten Nutzer füllen. Unten finden Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Google platziert ein Abgleich-Tag
Wenn die Seite eines teilnehmenden Publishers im Browser des Nutzers geladen wird und eine Anzeigenfläche auf dieser Seite von Google gefüllt wird, kann ein Übereinstimmungs-Tag platziert werden, das ein Pixel von einem algorithmisch ausgewählten Bieter anfordert. Das von Google platzierte Pixelabgleichs-Tag kombiniert die Cookie-Abgleichs-URL des Bieters mit zusätzlichen Parametern, mit denen der Bieter seine Match-Table füllen kann. Eine URL für den Cookie-Abgleich, die als https://ad.network.com/pixel
angegeben ist, hat folgende Struktur:
<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />
Schritt 2: Bieter muss mit einer Weiterleitung zur URL des Cookie-Abgleichsdiensts von Google antworten
Bieter, die Anfragen zur Pixelabgleichsfunktion erhalten, müssen mit einer Weiterleitung zum Cookie-Abgleichsdienst von Google antworten. Diese Weiterleitung muss folgendermaßen strukturiert sein:
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
Die oben angegebene Weiterleitungs-URL ähnelt der URL, die im Übereinstimmungs-Tag für den Workflow für den von der Gebotsfunktion initiierten Cookie-Abgleich verwendet wird.
Bei der Pixelübereinstimmung wird der Parameter google_cm
durch den Parameter google_push
ersetzt. Der Wert dieses Parameters muss mit dem Wert übereinstimmen, den Google in der Anfrage angegeben hat. Ähnlich wie beim vom Bieter initiierten Workflow können zusätzliche Parameter angegeben werden, um zusätzliche Anwendungsfälle zu erfüllen.
Schritt 3: Google verarbeitet die Weiterleitung und antwortet mit dem Pixel
Google protokolliert, dass eine Übereinstimmung für den Nutzer erstellt wurde, und verarbeitet alle zusätzlichen Vorgänge, die über Abfrageparameter angefordert werden. Google antwortet mit einem transparenten 1x1-Pixel.
Workflow-Diagramm für den Pixelabgleich
Dieser Workflow wird durch das folgende Diagramm veranschaulicht, in dem Anfragen und Antworten durch einen Pfeil dargestellt werden und die zugehörigen Datenelemente in Klammern aufgeführt sind.
Anfrageparameter für das Google-Match-Tag
Parameter | Beschreibung |
---|---|
google_gid |
Google Nutzer-ID. Für Nutzer aus anderen US-Bundesstaaten mit Datenschutzeinschränkungen wird dies immer im Übereinstimmungs-Tag von Google angegeben. |
google_cver |
Die Cookie-Version. Dieser Wert wird immer im Match-Tag von Google angegeben. |
google_push |
Gibt an, dass mit dieser Anfrage der Pixel-Matching-Workflow gestartet wird. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort des Bieters zurückgegeben werden. |
gdpr_consent |
Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten im Abschnitt [Anforderungen zur Einwilligung der Nutzer in der EU](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder unter **Wie wird der TC-String übergeben?** in der [Dokumentation zum Authorized Buyers IAB TCF 2.0](//support.google.com/authorizedbuyers/answer/9789378). |
Parameter für Weiterleitungen bei der Pixel-Abgleichsfunktion für Bieter
Parameter | Beschreibung |
---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_push |
Gibt an, dass mit dieser Weiterleitung der Pixel-Abgleich abgeschlossen wird. Hier muss der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag angegeben werden. |
google_hm |
Enthält Daten, die der Bieter in einer von Google gehosteten Abgleichstabelle speichern möchte. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format des Werts ist userlistid[,timestamp] :
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
gdpr_consent |
Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen finden Sie unten unter [Anforderungen an die Nutzereinwilligung in der EU](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) oder in der [Authorized Buyers-Dokumentation zum IAB TCF v2.0](//support.google.com/authorizedbuyers/answer/9789378) unter „Wie wird der TC-String übergeben?“. |
Von Google initiiert: Einseitiger Pixelabgleich
Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow dadurch, dass das Abgleich-Tag von Google keinen Parameter enthält, mit dem die Google-Nutzer-ID angegeben wird. Es wird jedoch weiterhin eine von Google gehostete Match-Table gefüllt. Diese Option kann verwendet werden, wenn der Bieter keine Google-Nutzer-IDs in seiner eigenen Abgleichtabelle hosten darf. Ein einfaches Beispiel für den überarbeiteten Workflow ist in den folgenden Schritten zusammengefasst.
Schritt 1: Google platziert ein Abgleich-Tag
Google platziert ein Abgleich-Tag für einen algorithmisch ausgewählten Bieter. Das Match-Tag enthält den Parameter google_push
. Beispiel:
<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />
Schritt 2: Der Browser des Nutzers fordert Pixel von der Kochabgleich-URL des Bieters an
Der Browser des Nutzers fordert ein Pixel von der Cookie-Abgleich-URL des Bieters an, einschließlich des Cookies des Bieters in den HTTP-Headern.
Schritt 3: Weiterleitung zum Cookie-Abgleichsdienst von Google
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
Schritt 4: Der Browser des Nutzers wird an den Cookie-Abgleichsdienst von Google weitergeleitet
Google erhält zusätzlich zum Google-Cookie in den HTTP-Headern eine Weiterleitung mit den von Ihnen angegebenen Parametern. Wenn der Vorgang erfolgreich war, enthalten die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die vom Bieter gehosteten Abgleichsdaten in BidRequest.user.buyeruid
für OpenRTB oder BidRequest.hosted_match_data
für das eingestellte Google RTB-Protokoll. Bieter können Nutzerlisten auch mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.
Schließlich gibt Google ein transparentes 1x1-Pixel an den Browser des Nutzers zurück.
Cookie-Abgleich-Assistent
Mit Open Bidding können Anzeigenplattformen vom Bieter initiierte und von Google initiierte Workflows für den Cookie-Abgleich verwenden, um eine Google-Nutzer-ID mit ihrem Cookie abzugleichen. Cookie Match Assist (CMA) ist eine zusätzliche Funktion für Anzeigenplattformen, mit der sie Match-Tables mit ihren eigenen Bietern erstellen können.
Funktionsweise des Cookie-Abgleichs
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"/>
Durch das CMA-Abgleichs-Tag von Google wird die URL für den Cookie-Abgleich der Anzeigenplattform mit einer Pixelanfrage aufgerufen.
- Die Anfrage wird vom Cookie-Abgleichs-Endpunkt der Anzeigenplattform empfangen. Der Cookie-Abgleichsdienst der Anzeigenplattform ist für die Übereinstimmung der Nutzer-ID mit einem ihrer Bieter verantwortlich. Im folgenden Diagramm antwortet der Cookie-Abgleichsdienst der Anzeigenplattform dem Browser des Nutzers mit einer Weiterleitung zu einem der Endpunkte eines Bieters.
- Der Bieter erhält die Anfrage zusammen mit allen Parametern, die von der Anzeigenplattform angegeben wurden, um die Nutzer-ID mit dem Cookie abzugleichen.
Einschränkungen
Häufigkeit von Anfragen für neue Übereinstimmungen begrenzen
Bieter sind dafür verantwortlich, die Anzahl der Aufrufe des Cookie-Abgleichsdienstes für Nutzer zu begrenzen, die einen neuen Eintrag in der von Google gehosteten Abgleichstabelle haben. Ein Eintrag in der gehosteten Match-Table kann nach 14 Tagen als abgelaufen betrachtet werden. Danach kann er aktualisiert werden.
Auf alle Anfragen zur Pixelübereinstimmung antworten
Bieter, die den Pixel-Abgleich-Workflow verwenden, müssen auf alle eingehenden Pixel-Abgleich-Anfragen mit einer Antwort antworten, die den Parameter google_push
enthält. So kann Google Richtlinien durch Überwachung der Nutzung erzwingen. Wenn die Antwortrate eines Bieters unter 90 % fällt, wird die Anzahl der Pixel-Abgleichsanfragen, die an sein Konto gesendet werden, von Google gedrosselt.
HTTPS-Endpunkte verwenden
Für Endpunkte, die in allen Cookie-Übereinstimmungs-Workflows verwendet werden, ist HTTPS erforderlich.
Wenn Sie auf eine Pixel-Übereinstimmungsanfrage antworten, die Sie über HTTPS erhalten, müssen Sie über HTTPS zum Cookie-Abgleichdienst weiterleiten. Ebenso muss für einen Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, HTTPS verwendet werden. Wenn Sie Anfragen an Google über HTTP häufiger als alle zwei Minuten senden, wird die Anzahl der Abgleichsanfragen, die an Ihr Konto gesendet werden, gedrosselt.
Anforderungen an die Einwilligung der Nutzer in der EU
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:
- TCFv2: Dazu gehören die Parameter
gdpr
undgdpr_consent
. Weitere Informationen finden Sie in der Dokumentation zum IAB TCF v2.0 für Authorized Buyers. process_consent
: Eine Erklärung, dass der Bieter die erforderliche Nutzereinwilligung eingeholt hat.
Beispiele
In den folgenden Beispielen wird veranschaulicht, wie Sie den Cookie-Abgleichsdienst verwenden können, um bestimmte Ziele zu erreichen. Sofern nicht anders angegeben, wird davon ausgegangen, dass der Nutzer, gegen den Maßnahmen ergriffen werden, nicht in einem US-Bundesstaat mit Datenschutzeinschränkungen ansässig ist.
Von Bietern gehostete Match-Table füllen
Bieter können den Cookie-Abgleich-Workflow verwenden, um eine eigene Abgleichtabelle zu erstellen. Dazu müssen sie nur die Parameter google_nid
und google_cm
in ihrem Abgleich-Tag angeben. Das könnte so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />
Wenn die Cookie-Abgleichs-URL des Bieters auf https://ad.network.com/pixel?id=1
festgelegt ist und der Cookie-Abgleich erfolgreich war, sieht die Weiterleitung, die Google als Antwort auf das Abgleich-Tag des Bieters sendet, möglicherweise so aus:
https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
Wenn der Cookie-Abgleich fehlschlägt, weil der Nutzer kein Google-Cookie hat, lautet die Antwort:
https://ad.network.com/pixel?id=1&google_error=3
Der Fehlercode hängt von der zugrunde liegenden Ursache des Fehlers ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie unter Weiterleitungs-URL-Parameter.
Zur Einzelnutzerliste hinzufügen
Der Parameter google_ula
kann im Abgleichs-Tag eines Bieters angegeben werden, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn die von Google oder dem Bieter gehostete Abgleichstabelle einen neuen Eintrag für den Nutzer enthält, kann der Bieter ein Abgleich-Tag mit den Parametern google_nid
und google_ula
platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Cookie-Abgleichs-Workflow zu starten. Weitere Informationen finden Sie in den Einschränkungen für die Aufrufe des Cookie-Abgleichsdiensts. Das entsprechende Abgleich-Tag könnte so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />
Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://ad.network.com/pixel
ist, lautet die Weiterleitungs-URL von Google:
https://ad.network.com/pixel?google_ula=12345,0
Bei einem allgemeinen Fehler – zum Beispiel, wenn kein Google-Cookie für den Nutzer vorhanden ist – enthält die Weiterleitungs-URL den Parameter google_error
:
https://ad.network.com/pixel?google_error=3
Wenn ein Fehler beim Hinzufügen des Nutzers zur Liste auftritt, wird google_ula
in der Weiterleitung angezeigt. Im Gegensatz zum entsprechenden Parameter des Übereinstimmungs-Tags wird hier der Zeitstempel durch einen Statuscode ersetzt, der den Erfolg des Vorgangs anzeigt. Wenn die Anfrage beispielsweise fehlgeschlagen ist, weil das Bieterkonto keinen Zugriff auf die angegebene Nutzerliste hat, lautet die Weiterleitungs-URL:
https://ad.network.com/pixel?google_ula=12345,2
Mehreren Nutzerlisten hinzufügen
Bieter können angeben, dass ein Nutzer mehreren Nutzerlisten hinzugefügt werden soll, indem sie mehrere google_ula
-Parameter in das Abgleich-Tag einfügen. In der Praxis kann das so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
Der Status des Vorgangs wird für jede Nutzerliste auf ähnliche Weise über verschiedene google_ula
-Parameter in der Weiterleitung gemeldet:
https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0
In der Weiterleitung oben sehen Sie, dass der Vorgang für die Nutzerliste mit der ID 45678
erfolgreich war, für die Nutzerliste mit der ID 12345
jedoch fehlgeschlagen ist, da der Bieter keine Berechtigung zum Zugriff darauf hatte.
Den Cookie-Abgleich-Workflow durchgehen und der Nutzerliste hinzufügen
Wenn Sie die Cookie-Übereinstimmung durchführen und den Nutzer in einer einzigen Anfrage einer Nutzerliste hinzufügen möchten, muss das Abgleich-Tag eines Bieters google_cm
und google_ula
enthalten:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />
Die von Google angegebene Weiterleitungs-URL würde google_gid
, google_cver
und google_ula
enthalten. Das könnte so aussehen:
https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0
Speichern einer Übereinstimmung in einer von Google gehosteten Match-Table
Wenn ein Bieter seine Cookie-Daten in einer von Google gehosteten Abgleichstabelle speichern möchte und keine Übereinstimmung mit der Google-Nutzer-ID in seiner eigenen Abgleichstabelle speichern möchte, muss sein Abgleichs-Tag den Parameter google_hm
enthalten. Der Wert dieses Parameters muss ein websicherer Base64-codierter String sein. Bei einem Nutzer, dessen uncodierte Cookie-Daten des Bieters Cookie number 1!
lauten, würde der codierte Wert Q29va2llIG51bWJlciAxIQ==
sein. Dieser Wert würde in einem Match-Tag wie dem folgenden verwendet:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://cookie-monster.com/pixel
ist, lautet die Weiterleitungs-URL von Google:
https://cookie-monster.com/pixel
Der Parameter google_gid
ist nicht in der Weiterleitung enthalten, da das Match-Tag google_cm
nicht enthält und google_hm
nicht in erfolgreichen Antworten enthalten ist. Bei zukünftigen Gebotsanfragen für Impressionen für diesen Nutzer erhält der Bieter die gehosteten Abgleichsdaten in BidRequest.user.buyeruid
für OpenRTB oder BidRequest.hosted_match_data
für das eingestellte RTB-Protokoll von Google.
Wenn der Bieter stattdessen ein Abgleich-Tag verwendet hat, bei dem der Wert von google_hm
nicht base64-codiert war (z. B. chocolate_chunk!
), könnte die Weiterleitungs-URL so aussehen:
https://cookie-monster.com/pixel?google_hm=2
Die obige Weiterleitungs-URL enthält den google_hm
-Wert 2
. Das bedeutet, dass der Vorgang fehlgeschlagen ist, weil der Wert nicht decodiert werden konnte.
Von Bietern und von Google gehostete Abgleichstabellen mit Nutzerlisten
Wenn ein Bieter neben einer von Google gehosteten Nutzerliste eine eigene Nutzungsliste hostet und ein einzelnes Übereinstimmungs-Tag für den Abgleich mit beiden Tabellen und zum Hinzufügen des Nutzers zu einer bestimmten Nutzerliste benötigt wird, muss das Übereinstimmungs-Tag die Parameter google_cm
, google_hm
und google_ula
enthalten. Wenn die Cookie-Daten des Bieters Cookie number 1!
sind, lautet der codierte Wert Q29va2llIG51bWJlciAxIQ==
. Das würde zu einem Match-Tag wie dem folgenden führen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />
Bei einer erfolgreichen Antwort, bei der die Cookie-Abgleichs-URL des Bieters https://cookie-monster.com/pixel
ist, würde die Weiterleitungs-URL von Google so aussehen:
https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0
Nach Erhalt der Weiterleitung kann der Bieter die in google_gid
angegebene Google Nutzer-ID mit den Cookiedaten in der Match-Table abgleichen. Außerdem kann er feststellen, ob die von Google gehosteten Match-Table- und Nutzerlistenvorgänge erfolgreich waren. Daher führt jedes Pre-Targeting, das der Bieter für die Ausrichtung auf die angegebene Nutzerlisten-ID konfiguriert hat, dazu, dass der Bieter Gebotsanfragen für Impressionen vom Nutzer erhält. In diesen Gebotsanfragen erhält der Bieter seine gehosteten Abgleichsdaten ebenfalls in BidRequest.user.buyeruid
für OpenRTB oder BidRequest.hosted_match_data
für das eingestellte Google RTB-Protokoll.