Der Cookie-Abgleich ist eine Funktion, mit der Sie Ihr Cookie (z. B. eine ID für einen Nutzer, der Ihre Website besucht hat) mit einer entsprechenden gebotsspezifischen Google-Nutzer-ID abgleichen und Nutzerlisten erstellen können, um effektivere Gebotsentscheidungen zu treffen. In diesem Leitfaden werden Konzepte für den Cookie-Abgleich und verschiedene Workflows für den Cookie-Abgleich beschrieben. Außerdem erfahren Sie, welche Variationen es für bestimmte Anwendungsfälle gibt.
Konzepte
Was ist der Cookie-Abgleich?
Domaininhaber legen in der Regel den Inhalt von Cookies für Nutzer fest, die ihre Website besuchen. Diese werden verwendet, um die Nutzer in dieser Domain zu identifizieren. Selbst wenn zwei Domainnamen ansonsten dem Austausch dieser Daten zustimmen würden, schränkt das Sicherheitsmodell von Internetbrowsern das Vorhandensein eines Cookies ein, das von einer anderen Domain gesetzt wurde.
Im Kontext der digitalen Werbung identifiziert Google Nutzer mit Cookies, die zur Domain doubleclick.net gehören. Bieter, die an Echtzeitgeboten teilnehmen, haben dann möglicherweise eine eigene Domain, in der sie die Nutzer identifizieren, für die sie Anzeigen schalten möchten. Durch den Cookie-Abgleich können die Bieter ihre Cookies mit denen von Google abgleichen und so feststellen, ob eine in einer Gebotsanfrage gesendete Impression dem gewünschten Nutzer zugeordnet ist. In diesem Fall erhält der Bieter entweder seine eigenen Cookie-Daten oder eine gebotsspezifische Google-Nutzer-ID, die in verschlüsselter Form für das doubleclick.net-Cookie in der Gebotsanfrage verwendet wird.
Der in diesem Leitfaden beschriebene Cookie-Abgleichdienst vereinfacht das Erstellen und Verwalten des Verknüpfens von Cookie eines Bieters mit der Google-Nutzer-ID und ermöglicht es Ihnen auch, Nutzerlisten zu füllen.
Match-Tables
Mit einer Match-Table können Sie eine ID oder andere Daten einer Domain einer anderen Tabelle zuordnen. Bieter können mit dem Cookie-Abgleichdienst ihre eigenen Match-Tables füllen, indem sie ihr Cookie für einen bestimmten Nutzer der Google-Nutzer-ID des Nutzers zuordnen oder eine von Google gehostete Match-Table füllen. Match-Tables 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, Latenzverbesserungen und 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 base64-codierten String angeben, der der Google-Nutzer-ID für einen bestimmten Nutzer zugeordnet wird. Nachdem eine Übereinstimmung gefunden wurde, kann sie so verwendet werden:
Echtzeitgebote: In nachfolgenden Gebotsanfragen für Impressionen, die dem Nutzer zugeordnet sind, sendet Google Ihnen die Daten zu den gehosteten Übereinstimmungen, die Sie mit der zugehörigen Google-Nutzer-ID abgeglichen haben. Wenn Ihr Gebotsendpunkt für die Verwendung des RTB-Protokolls von Google konfiguriert ist, erhalten Sie die Nachricht über das Feld
BidRequest.hosted_match_dataals decodierte Byte. In der OpenRTB-Implementierung von Google gebenBidRequest.user.buyeruiddiese Daten als websicheren base64-codierten String zurück.Nutzerlisten: Nutzerlisten können entweder mit Google-Nutzer-IDs oder mit gehosteten Abgleichsdaten gefüllt werden.
- Pre-Targeting: Sie können das Pre-Targeting so konfigurieren, dass Sie nur Gebotsanfragen mit gehosteten Abgleichsdaten erhalten. Dadurch lassen sich weniger relevante Impressionen für Nutzer außerhalb des Cookie-Bereichs vermeiden.
Nutzerlisten
Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Nach dem Erstellen können Sie diese Listen mit den unten beschriebenen Workflows zum Cookie-Abgleich füllen oder über den Bulk-Upload-Dienst.
Erste Schritte
Wenn Sie den Cookie-Abgleich einrichten möchten, müssen Sie sich an Ihren Technical Account Manager wenden, der bestimmte Workflows aktivieren und Sie bei der Konfiguration der folgenden Schritte unterstützen kann:
- 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.
- Cookie-Abgleich-URL: Die Basis-URL für einen Endpunkt, der eingehende Anfragen im Rahmen des Cookie-Abgleich-Workflows akzeptiert und verarbeitet. Bieter können in dieser URL Makros einbetten, um die Reihenfolge der in den Workflows zum Cookie-Abgleich übergebenen Parameter zu steuern.
- Übereinstimmungs-Tag: Das Tag, das Sie im Browser eines Nutzers für den vom Bieter initiierten Workflow für den Cookie-Abgleich platzieren müssen. Diese Anzeigen können neben Anzeigen oder in Web-Properties außerhalb von Anzeigen platziert werden.
- URL für den Cookie-Abgleich (optional): Im Rahmen des einseitigen Cookie-Abgleich-Workflows ist dies eine optionale URL, die angegeben werden kann, um einen Endpunkt anzugeben, der Fehlerdetails empfängt, falls die Cookie-Übereinstimmung über eine HTTP 302-Weiterleitung fehlschlägt. Antworten werden standardmäßig nur an diese URL gesendet, wenn ein Fehler beim Cookie-Abgleich vorliegt. Der Bieter kann aber festlegen, dass die Weiterleitung immer gesendet werden soll.
- Cookie Match Assist-URL: Bei Anzeigenplattformen, in denen der Cookie Match Assist-Workflow implementiert wird, ist dies die Basis-URL des Endpunkts, der für die Beantwortung eingehender Anfragen vorgesehen ist.
- Kontingent für Cookie-Übereinstimmungen: Für Anzeigenplattformen, die den Workflow für den Cookie-Abgleich Damit soll verhindert werden, dass CMA-Anfragen die Server der Anzeigenplattform mit Anfragen überlasten.
Makros für den Cookie-Abgleich
In allen unterstützten Cookie-Abgleich-Workflows sind der URL für den Cookie-Abgleich einer Gebotsfunktion in der Regel Parameter in einer nicht garantierten Reihenfolge angehängt. Bieter mit Integrationen, die eine einheitliche Reihenfolge der Parameter erfordern, können Makros in ihre Cookie-Abgleichs-URL einfügen, um ihre Platzierung zu garantieren.
Supported macros
Bieter können optional ihre URL für den Cookie-Abgleich so konfigurieren, dass ein oder mehrere Makros in Form von %%GOOGLE_<PARAM_NAME>%% oder %%GOOGLE_<PARAM_NAME>_PAIR%% enthalten sind. Unterstützte Makros und ihre erweiterten Werte sind:
| Macro | Erweiterter Wert |
|---|---|
| GOOGLE_GID | GOOGLE_USER_ID |
| GOOGLE_GID_PAIR | &google_gid=GOOGLE_USER_ID |
| GOOGLE_CVER | COOKIE_VERSION_NUMBER |
| GOOGLE_CVER_PAIR | &cver=COOKIE_VERSION_NUMBER |
| GOOGLE_FEHLER | ERROR_ID |
| GOOGLE_ERROR_PAIR (GOOGLE_ERROR_PAIR) | &google_error=ERROR_ID |
| GOOGLE_PUSH | PIXEL_MATCH_DATA |
| GOOGLE_PUSH_PAIR | &google_push=PIXEL_MATCH_DATA |
| GOOGLE_ALL_PARAMS- | google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID |
Makrobeispiel
Ein Bieter hat eine Cookie-Abgleichintegration mit einem auf https://user.bidder.com.cookies gehosteten Endpunkt. Seine Implementierung erfordert neben den Pixelabgleich-Parametern die folgenden Standardeinstellungen: google_push, google_gid, google_cver und google_error. Die Gebotsfunktion kann dazu die folgende URL 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 Zuordnungsanfrage 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-Abgleichdienst von Google unterstützt derzeit drei Workflows für verschiedene unten beschriebene Anwendungsfälle.
Vom Bieter initiiert: Bidirektionaler Cookie-Abgleich
Der bidirektionale Cookie-Abgleich bezieht sich auf den vom Bieter initiierten Workflow, bei dem ein Übereinstimmungs-Tag im Browser des Nutzers platziert wird, der es an Google weiterleitet. So können sowohl Google als auch der Bieter Match-Tables ausfüllen. Unten sehen Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Übereinstimmungs-Tag einfügen
Damit der Vorgang initiiert werden kann, muss der Bieter sein Match-Tag so platzieren, dass er im Browser des Nutzers gerendert wird. Ein einfaches Übereinstimmungs-Tag, das nur die Google-Nutzer-ID an den Bieter zurückgibt, kann so strukturiert werden:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
Sie können zusätzliche Parameter in das Übereinstimmungs-Tag einfügen, um unterschiedliche Anwendungsfälle zu erfüllen. Weitere Informationen zu diesen Parametern finden Sie unter Tag-URL-Parameter zuordnen.
Schritt 2: Google antwortet mit einer Weiterleitung, einschließlich Abgleichsdaten
Das Übereinstimmungs-Tag führt dazu, dass der Cookie-Abgleichdienst von Google eine Anfrage vom Browser des Nutzers empfängt. Dadurch wird eine HTTP 302-Weiterleitung zur URL für den Cookie-Abgleich des Bieters ausgegeben. Die Weiterleitung enthält Suchparameter, die die Google-Nutzer-ID und ihre Versionsnummer in der URL angeben. Der Bieter erhält außerdem sein Cookie, das in den Anfrageheadern enthalten ist. Bei einer Cookie-Abgleich-URL, die als https://ad.network.com/pixel angegeben ist, kann die Weiterleitungs-URL für das einfache Übereinstimmungs-Tag in der Praxis 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 aufgefüllter, websicherer base64-codierter String. Bietern, die eine Match-Table hosten möchten, wird empfohlen, genau den String zu speichern, der vom Cookie-Abgleichdienst zurückgegeben wird. In nachfolgenden Gebotsanfragen entspricht das den Werten, die über BidRequest.google_user_id im RTB-Protokoll von Google oder BidRequest.user.id in der OpenRTB-Implementierung von Google angegeben sind.
Die in google_cver angegebene Version enthält die numerische Versionsnummer für die Google-Nutzer-ID. Die Google-Nutzer-ID für einen bestimmten Nutzer ändert sich nur selten. Danach wird die Nummer erhöht.
Wenn Google bei der Verarbeitung Ihrer Zuordnungsanfrage auf einen Fehler stößt, wird stattdessen der Parameter google_error angegeben.
Schritt 3: Bieter verarbeitet die Weiterleitung und antwortet mit Pixel
Die Gebotsfunktion erhält eine Weiterleitung zu der URL, die mit dem Cookie übereinstimmt, einschließlich der im ersten Schritt angegebenen Parameter und der im zweiten Schritt angegebenen Google. Außerdem erhalten sie ihr Cookie in den HTTP-Headern. Wenn der Vorgang erfolgreich war, konnte ein Bieter, der seine eigene Match-Table hostet, sein Cookie mit der in der Antwort enthaltenen Google-Nutzer-ID abgleichen. Es wird empfohlen, dass Bieter den genauen String speichern, der vom Cookie-Abgleichdienst 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, durch die der aufgetretene Fehler identifiziert wird. Weitere Informationen zu den möglichen Fehlerwerten finden Sie hier.
Wenn Sie eine Fehlermeldung erhalten, können Sie noch einmal versuchen, die Zuordnung für diesen Nutzer vorzunehmen, indem Sie ein neues Übereinstimmungs-Tag ersetzen.
Der Bieter muss immer antworten, indem er ein nicht sichtbares 1x1-Pixel-Bild bereitstellt, oder alternativ die Antwort HTTP 204 Kein Inhalt zurückgeben.
Workflow-Diagramm zum Cookie-Abgleich
Dieser Workflow ist im folgenden Diagramm dargestellt, in dem Anfragen und Antworten durch einen Pfeil dargestellt sind und die zugehörigen Datenelemente in Klammern aufgeführt sind.
Übereinstimmungs-Tag-URL-Parameter
| Parameter | Beschreibung |
|---|---|
google_nid |
Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann über die Ressource Bieter abgerufen werden. |
google_cm |
Weist auf den Cookie-Abgleichdienst von Google hin, dass der Cookie-Abgleich ausgeführt werden soll. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_sc |
Dieser Parameter wurde verworfen. Legt das Google-Cookie für den Nutzer fest, wenn keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Bei Weglassen des Parameters wird ein Fehler ausgegeben, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde verworfen. Dies signalisiert dem Cookie-Abgleichdienst von Google, dass für den Nutzer kein Cookie gesetzt werden sollte, wenn kein Cookie-Abgleichdienst vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. |
google_hm |
Daten, die der Bieter in einer von Google gehosteten Match-Table speichern möchte
Der Wert ist ein websicherer Base64-codierter String (Abstand optional). Die Rohdaten dürfen maximal 40 Byte umfassen. Beispiel: |
google_redir |
Ein URL-codierter String, den ein Bieter angeben kann, wenn er Google weiterleiten soll, um die HTTP 302Weiterleitung an die codierte URL für dieses Übereinstimmungs-Tag zu senden. So kann Google in einem Kettenaufruf an Partnerunternehmen ganz oben platziert werden. Wenn Sie ohne google_hm oder mit google_cm angegeben werden, tritt ein Fehler auf. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format für den Wert ist userlistid[,timestamp]:
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
Zusätzlich zu den oben genannten Parametern können Bieter ihren eigenen Parameter angeben, der als Parameter an die Weiterleitungs-URL angehängt wird. Beachten Sie, dass vom Bieter definierte Parameter, die mit dem Präfix google_ benannt sind, ignoriert werden, da sie für die zukünftige Entwicklung von Google reserviert sind. Die Beibehaltung der Reihenfolge der Parameter kann nicht garantiert werden. Ein Übereinstimmungs-Tag mit gebotsdefinierten 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 basiert auf der Cookie-Basis-URL, die für das Konto eines Bieters konfiguriert wurde, einschließlich google_ und von Bietern definierten Parametern, je nachdem, welche im Match-Tag angegeben sind. Die folgenden google_-Antwortparameter sind definiert:
| Parameter | Beschreibung |
|---|---|
google_gid |
Google-Nutzer-ID. Legen Sie fest, ob google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_cver |
Cookie-Version. Legen Sie fest, ob google_cm in der Anfrage angegeben ist und die Anfrage erfolgreich war. |
google_error |
Ein Ganzzahlwert, der den Gesamtanfragefehler angibt. Wenn dies 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 hat er einen der folgenden Statuscodes:
|
google_ula |
Status des Hinzufügens der Nutzerliste, der wiederholt wird, wenn in der Anfrage mehrere Beispiel: Beim
|
Beispielszenarien für den Workflow für den Cookie-Abgleich
In den folgenden Szenarien wird der Cookie-Abgleich für einen typischen Nutzer beschrieben, der eine Webseite besucht.
Szenario 1: Der Nutzer löscht seine Cookies und besucht eine Website
Jane löscht alle Cookies im Cache. Anschließend besucht er die Startseite von beispielnews.de.
Folgendes geschieht:
- Das Beispiel wird auf NewsNews.com gerendert und es werden Anzeigen von Google (Ad Manager) aufgerufen.
- 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 die Gebotsantwort.
- Google empfängt Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP, die eine Anzeige mit einem Übereinstimmungs-Tag (Pixel) angibt.
- FinestDSP gewinnt die Auktion. Google sendet die Anzeige und das Übereinstimmungs-Tag von FinestDSP an Jane.
- Das Übereinstimmungs-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt die Parameter
google_nidundgoogle_cman. - Der Cookie-Abgleichdienst liest Janes Google-Cookie und sendet Janes Browser an die FinestDSP-URL für den Cookie-Abgleich mit den festgelegten Parametern
google_user_idundgoogle_cver. - Janes Browser lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
- Der Cookie-Abgleichendpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, die von Google festgelegte URL-Parameter enthält, sowie das Cookie für Jane in den HTTP-Headern. FinestDSP kann jetzt die Zuordnung von Cookies zu
google_user_idin der Match-Table speichern. - FinestDSP antwortet mit einem unsichtbaren 1x1-Pixel auf die Weiterleitung.
Szenario 2: Nutzer mit bestehender Zuordnung
Eine Woche nach Szenario 1 besucht Jane noch einmal NewsNews.com. Nun hat Jane sowohl Bieter- als auch Ad Manager-Cookies auf ihrem Computer. So funktioniert der Abgleich.
- 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 alle Bieter, einschließlich FinestDSP,
- FinestDSP empfängt die Gebotsanfrage, einschließlich Signalen wie
google_user_id. - FinestDSP sucht das
google_user_idin seiner Match-Table und findet das mit Jane verknüpfte Cookie, das eine Woche früher erstellt wurde (in Szenario 1). - Die Gebotslogik von FinestDSP basiert auf den mit dem Cookie verknüpften Informationen und gibt ein Gebot für die Impression ab und gewinnt die Auktion.
- Eine Anzeige könnte basierend auf Informationen, die ihr FinestDSP gehören, auf ihre Interessen zugeschnitten sein.
Vom Bieter initiiert: Cookie-Abgleich in eine Richtung
Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow, mit der Ausnahme, dass nur Google eine Match-Table hostet und ausfüllt. Er kann in Fällen verwendet werden, in denen der Bieter keine Google-Nutzer-IDs in einer eigenen Match-Table hosten darf. Bieter müssen es Google erlauben, die Match-Table zu hosten, dürfen google_cm in Anfragen an den Cookie-Abgleichdienst von Google nicht mehr angeben und erhalten daher google_gid nicht, um eine eigene Match-Table zu füllen. Sobald Google eine Übereinstimmung für einen Nutzer festgestellt hat, können Bieter ihn anhand von eigenen Cookiedaten zu Nutzerlisten hinzufügen. Die Gebotsanfragen für diese Nutzer schließen die Google-Nutzer-ID ebenfalls aus, enthalten aber gehostete Daten zum Abgleich. Ein einfaches Beispiel für den überarbeiteten Workflow wird in den folgenden Schritten zusammengefasst.
Schritt 1: Übereinstimmungs-Tag platzieren, das an die Cookie-Abgleich-URL des Bieters weitergeleitet wird
Damit der Vorgang gestartet werden kann, muss ein Bieter ein Übereinstimmungs-Tag so platzieren, dass es im Browser des Nutzers gerendert wird. Im Gegensatz zum Workflow für Nutzer außerhalb der USA mit Datenschutzeinschränkungen muss das Übereinstimmungs-Tag den Browser des Nutzers an Ihre Cookie-Abgleich-URL weiterleiten. Mit einer Cookie-Abgleich-URL, die als https://ad.network.com/pixel konfiguriert ist, sieht sie beispielsweise so aus:
<img src="https://ad.network.com/pixel" />
Beim Laden im Browser des Nutzers wird ein Pixel von der Cookie-Abgleich-URL des Bieters angefordert. Diese Anfrage enthält ihr Cookie im HTTP-Header, der für den nächsten Schritt extrahiert werden soll.
Schritt 2: Zum Cookie-Abgleichdienst von Google weiterleiten
Der Endpunkt für den Cookie-Abgleich des Bieters muss zum Google-Dienst für den Cookie-Abgleich weitergeleitet werden, einschließlich des google_hm-Parameters mit seinen websicheren base64-codierten Cookiedaten. Die Weiterleitungs-URL kann 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 eine Weiterleitung mit den von dir angegebenen Parametern zusätzlich zum Google-Cookie in den HTTP-Headern.
Schritt 4: Google stellt Pixel bei Erfolgsmeldung oder Fehlerweiterleitung bereit, wenn die Berichts-URL angegeben wird
Wenn der Cookie-Abgleichvorgang erfolgreich ist oder wenn für das Konto des Bieters keine URL für den Cookie-Abgleichsbericht angegeben wurde, stellt Google standardmäßig ein transparentes 1 × 1-Pixel bereit und der Workflow endet hier.
Die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten die für den Bieter gehosteten Daten zum Abgleich 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.
Wenn ein Fehler auftritt, sendet Google eine Weiterleitung an die URL des Berichts zum Cookie-Abgleich des Bieters mit der Ursache des im Parameter google_error angegebenen Fehlers. Wenn die URL des Bieterberichts zum Cookie-Abgleich https://ad.network.com/report lautete, würde die Weiterleitungs-URL so aussehen:
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
Schritt 5: Der Browser des Nutzers wird zur URL des Berichts zum Cookie-Abgleich des Bieters weitergeleitet.
Der Browser des Nutzers leitet den Nutzer nach der URL des Berichts zum Cookie-Abgleich des Bieters weiter, einschließlich der Fehlermeldung (falls vorhanden), die von Google im Parameter google_error angegeben wurde. Weitere Informationen zum Interpretieren des Fehlercodes finden Sie in der Parameterbeschreibung.
Schritt 6: Der Bieter stellt ein transparentes 1x1-Pixel bereit
Der Bieter muss antworten, indem er ein transparentes 1 × 1-Pixel im Browser des Nutzers bereitstellt.
Workflow-Cookie-Abgleich-Workflow für Nutzer aus US-Bundesstaaten mit Datenschutzeinschränkungen
Der Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen ist in der folgenden Grafik dargestellt, in der Anfragen und Antworten durch einen Pfeil dargestellt sind und die zugehörigen Datenelemente in Klammern aufgeführt sind.
URL-Parameter für die Gebotsfunktion leiten zum 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 verworfen. Legt das Google-Cookie für den Nutzer fest, wenn keins vorhanden ist. Der Wert des Parameters wird ignoriert und kann weggelassen werden. Bei Weglassen des Parameters wird ein Fehler ausgegeben, wenn kein Cookie vorhanden ist. |
google_no_sc |
Dieser Parameter wurde verworfen. Dies signalisiert dem Cookie-Abgleichdienst von Google, dass für den Nutzer kein Cookie gesetzt werden sollte, wenn kein Cookie-Abgleichdienst 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 Match-Table speichern möchte. |
google_redir |
Eine codierte URL, an die Google eine HTTP 302-Weiterleitung senden soll. Die angegebene URL empfängt Weiterleitungen mit dem Parameter google_error für Fehler und erfolgreiche Vorgänge. |
google_ula |
Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Das erwartete Format für den Wert ist userlistid[,timestamp]:
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
URL-Parameter für Google leiten zur URL des Berichts zum Cookie-Abgleich des Bieters weiter
| Parameter | Beschreibung |
|---|---|
google_error |
Ein Ganzzahlwert, der den Gesamtanfragefehler angibt. Wenn dies empfangen wird, bedeutet dies, dass keine Vorgänge ausgeführt wurden und keine anderen
|
Von Google initiiert: Bidirektionaler Pixelabgleich
Der bidirektionale Pixelabgleich ist ein Workflow für den Cookie-Abgleichdienst von Google. Dabei versucht Google, eine Google-Nutzer-ID mit einem anderen Algorithmus zu ermitteln, bei dem es sich nicht um den Gewinner der Echtzeitauktion handelt. 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 sehen Sie ein einfaches Beispiel für diesen Workflow.
Schritt 1: Google platziert ein Übereinstimmungs-Tag
Wird die Seite eines teilnehmenden Publishers im Browser des Nutzers geladen und von Google eine Anzeigenfläche auf dieser Seite gefüllt, kann ein Übereinstimmungs-Tag platziert werden, das ein Pixel von einem durch Algorithmen 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 in die Match-Table aufnehmen kann. Eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel angegeben ist, ist folgendermaßen 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 auf die URL des Cookie-Abgleichdienstes von Google antworten.
Bieter, die Pixel-Abgleichanfragen erhalten, müssen mit einer Weiterleitung an den Cookie-Abgleichdienst von Google antworten, die so strukturiert ist:
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
Die obige Weiterleitungs-URL ähnelt der URL, die im Übereinstimmungs-Tag für den Bieter-initiierten Workflow für den Cookie-Abgleich verwendet wird.
Beim Pixelabgleich 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 bei dem vom Bieter initiierten Workflow können zusätzliche Parameter angegeben werden, um zusätzliche Anwendungsfälle zu erfüllen.
Schritt 3: Google verarbeitet Weiterleitungen und antwortet mit Pixel
Google protokolliert, dass eine Übereinstimmung für den Nutzer erstellt wurde, und verarbeitet alle zusätzlichen Vorgänge, die über Suchparameter angefordert werden. Google antwortet mit einem transparenten 1x1-Pixel.
Diagramm zum Workflow für den Pixel-Abgleich
Dieser Workflow ist im folgenden Diagramm dargestellt, in dem Anfragen und Antworten durch einen Pfeil dargestellt sind und die zugehörigen Datenelemente in Klammern aufgeführt sind.
Google Match-Tag-Anfrageparameter
| Parameter | Beschreibung |
|---|---|
google_gid |
Google-Nutzer-ID. Für Nutzer außerhalb der USA mit Datenschutzeinschränkungen wird dies immer im Übereinstimmungs-Tag von Google angegeben. |
google_cver |
Cookie-Version Dies wird immer im Match-Tag von Google angegeben. |
google_push |
Gibt an, dass diese Anfrage den Workflow für den Pixel-Abgleich initiiert. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort des Bieters zurückgegeben werden. |
Weiterleitungsparameter für den Pixel-Abgleich von Bietern
| 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. Der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag muss hier angegeben werden. |
google_hm |
Enthält Daten, die der Bieter 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 für den Wert ist userlistid[,timestamp]:
Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen hinzuzufügen. |
Von Google initiiert: Unidirektionaler 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. Stattdessen wird jedoch eine von Google gehostete Match-Table ausgefüllt. Er kann in Fällen verwendet werden, in denen der Bieter keine Google-Nutzer-IDs in seiner eigenen Match-Table hosten darf. In den folgenden Schritten wird ein einfaches Beispiel für den überarbeiteten Workflow zusammengefasst.
Schritt 1: Google platziert ein Übereinstimmungs-Tag
Google platziert ein Übereinstimmungs-Tag für einen vom Algorithmus 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 Koch-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: Weiterleitung zum Cookie-Abgleichdienst von Google
Der Endpunkt für den Cookie-Abgleich des Bieters muss zum Google-Dienst für den Cookie-Abgleich weitergeleitet werden, einschließlich des google_hm-Parameters mit seinen websicheren base64-codierten Cookiedaten. Die Weiterleitungs-URL kann 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 Google-Dienst für den Cookie-Abgleich weitergeleitet
Google erhält eine Weiterleitung mit den von dir angegebenen Parametern zusätzlich zum Google-Cookie in den HTTP-Headern. Wenn der Vorgang erfolgreich war, enthalten Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen die vom Bieter gehosteten Daten 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 mit den von ihnen angegebenen gehosteten Abgleichsdaten füllen.
Schließlich gibt Google ein transparentes 1 × 1-Pixel an den Browser des Nutzers zurück.
Cookie-Abgleichsassistent
Bei Open Bidding können Anzeigenplattformen die Cookie-Abgleich-Workflows von Bietern initiiert und von Google initiiert 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 eigenen Bietern erstellen können.
Funktionsweise des Cookie-Abgleichs
Beim Präsentieren einer Anzeige wählt Google per Algorithmus eine teilnehmende Anzeigenplattform aus und platziert ein Tag mit vorbereitenden Cookies, 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.
- Der Cookie-Abgleich-Endpunkt der Anzeigenplattform empfängt die Anfrage. Dabei ist der eigene Cookie-Abgleichdienst dafür verantwortlich, die User-ID einem seiner Bieter zuzuordnen. Im folgenden Diagramm antwortet der Cookie-Abgleichdienst der Anzeigenplattform an den Browser des Nutzers und leitet ihn zu einem Endpunkt des Bieters weiter.
- Der Bieter erhält die Anfrage zusammen mit allen Parametern, die von der Anzeigenplattform angegeben wurden, um die User-ID mit dem Cookie abzugleichen.
Einschränkungen
Häufigkeit der Anfragen für neue Übereinstimmungen begrenzen
Bieter müssen die Anzahl der Aufrufe für den Cookie-Abgleichdienst für Nutzer beschränken, die einen neuen Eintrag in der von Google gehosteten Match-Table haben. Ein Eintrag in der gehosteten Match-Table kann nach 14 Tagen als abgelaufen gelten. Danach kann er aktualisiert werden.
Auf alle Pixel-Abgleichanfragen antworten
Bieter, die den Pixel-Abgleich-Workflow verwenden, müssen auf alle eingehenden Pixel Match-Anfragen mit einer Antwort, einschließlich des Parameters google_push, antworten. Dadurch kann Google Richtlinien durch Überwachen der Nutzung erzwingen. Wenn die Antwortrate eines Bieters unter 90 % sinkt, drosselt Google die Anzahl der an sein Konto gesendeten Pixel Match-Anfragen.
HTTPS-Endpunkte verwenden
Endpunkte, die in allen Cookie-Abgleich-Workflows verwendet werden, müssen HTTPS verwenden.
Wenn Sie auf eine Pixel Match-Anfrage antworten, die Sie über HTTPS gesendet haben, müssen Sie über HTTPS zum Cookie-Abgleichdienst weiterleiten. Ebenso muss ein Cookie Match Assist-Endpunkt, der zu Bietern weiterleitet, ebenfalls HTTPS verwenden. Wenn Sie Anfragen über HTTP häufiger als alle zwei Minuten an Google senden, wird die Anzahl der an Ihr Konto gesendeten Zuordnungsanfragen gedrosselt.
Beispiele
Die folgenden Beispiele veranschaulichen, wie der Cookie-Abgleichdienst zum Erreichen bestimmter Ziele verwendet wird. Sofern nicht anders angegeben, wird davon ausgegangen, dass die Person, aus der Maßnahmen ergriffen werden, nicht aus einem US-Bundesstaat mit Datenschutzeinschränkungen stammt.
Von Bietern gehostete Match-Table ausfüllen
Eine Gebotsfunktion kann den Workflow für den Cookie-Abgleich nutzen, um eine eigene Match-Table zu füllen. Dazu muss im Match-Tag nur die Parameter google_nid und google_cm 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 festgelegt ist und der Vorgang für den 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 Fehlerursache ab. Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie unter Weiterleitungs-URL-Parameter.
Einer einzelnen Nutzerliste hinzufügen
Der Parameter google_ula kann im Übereinstimmungs-Tag eines Bieters angegeben werden, um den Nutzer mit einer bestimmten ID in eine Nutzerliste aufzunehmen. Wenn die Match-Table von Google oder der Gebotsfunktion einen neuen Eintrag für den Nutzer enthält, kann der Bieter ein Übereinstimmungs-Tag mit den Parametern google_nid und google_ula platzieren, um den Nutzer der angegebenen Liste hinzuzufügen, ohne den vollständigen Workflow für den Cookie-Abgleich zu initiieren. Weitere Informationen finden Sie in den Einschränkungen für den Aufruf 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" />
Für eine erfolgreiche Antwort, wenn die Cookie-Abgleich-URL des Bieters https://ad.network.com/pixel ist, würde die Weiterleitungs-URL von Google so aussehen:
https://ad.network.com/pixel?google_ula=12345,0
Liegt ein Fehler vor, etwa 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 beim Hinzufügen des Nutzers zur Liste ein Fehler auftritt, wird in der Weiterleitung google_ula zurückgegeben. Im Gegensatz zum entsprechenden Übereinstimmungs-Tag-Parameter ersetzt dies den Zeitstempel durch einen Statuscode, 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 so:
https://ad.network.com/pixel?google_ula=12345,2
Mehreren Nutzerlisten hinzufügen
Bieter können angeben, dass ein Nutzer zu mehreren Nutzerlisten hinzugefügt werden soll, indem mehrere google_ula-Parameter in das Übereinstimmungs-Tag aufgenommen werden. In der Praxis kann das so aussehen:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
Der Status des Vorgangs für jede Nutzerliste wird auf ähnliche Weise über 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 ist zu sehen, dass der Vorgang für die Nutzerliste mit der ID 45678 erfolgreich war, aber bei der Nutzerliste-ID 12345 fehlgeschlagen, weil der Bieter keine Berechtigung für den Zugriff hatte.
Workflow für den Cookie-Abgleich durchlaufen und der Nutzerliste hinzufügen
Für einen Cookie-Abgleich und das Hinzufügen des Nutzers zu einer Nutzerliste in einer einzelnen Anfrage 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 umfasst google_gid, google_cver und google_ula. Das kann so aussehen:
https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0
Übereinstimmungen in einer von Google gehosteten Match-Table speichern
Wenn ein Bieter seine Cookie-Daten in einer von Google gehosteten Match-Table speichern und keine Übereinstimmung mit der Google-Nutzer-ID in einer eigenen Match-Table speichern möchte, muss das Match-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, ist der codierte Wert Q29va2llIG51bWJlciAxIQ==. Er wird in einem Übereinstimmungs-Tag wie im folgenden Beispiel verwendet:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
Für eine erfolgreiche Antwort, wenn die Cookie-Abgleich-URL des Bieters https://cookie-monster.com/pixel ist, würde die Weiterleitungs-URL von Google so aussehen:
https://cookie-monster.com/pixel
Der Parameter google_gid ist nicht in der Weiterleitung enthalten, weil das Übereinstimmungs-Tag nicht google_cm 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.hosted_match_data für das RTB-Protokoll von Google und in BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google.
Wenn der Bieter ein Übereinstimmungs-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. Dies deutet darauf hin, dass der Vorgang fehlgeschlagen ist, weil der Wert nicht decodiert werden konnte.
Von Bietern und von Google gehostete Match-Tables mit Nutzerlisten
Wenn ein Bieter neben einer von Google gehosteten Nutzerliste eine eigene Nutzungsliste hostet und möchte, dass ein einzelnes Übereinstimmungs-Tag mit beiden Tabellen abgeglichen und der Nutzer einer bestimmten Nutzerliste hinzugefügt wird, muss das Übereinstimmungs-Tag die Parameter google_cm, google_hm und google_ula enthalten. Wenn die Cookiedaten des Bieters Cookie number 1! lauten, wäre der codierte Wert Q29va2llIG51bWJlciAxIQ== und würde ein Übereinstimmungs-Tag wie dieses ergeben:
<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-Abgleich-URL des Bieters 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 den Cookiedaten in seiner Match-Table abgleichen. Außerdem können sie feststellen, ob die von Google gehosteten Match-Tables- und Nutzerlistenvorgänge erfolgreich waren. Daher führt jedes Pre-Targeting des Bieters, das für das Targeting der angegebenen Nutzerliste-ID konfiguriert ist, dazu, dass der Bieter Gebotsanfragen für Impressionen vom Nutzer empfängt. Außerdem erhält der Bieter in diesen Gebotsanfragen die gehosteten Daten zum Abgleich in BidRequest.hosted_match_data für das RTB-Protokoll von Google und in BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google.