Cookie-Abgleich

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 gebotsspezifische Google Nutzer-ID zu erstellen und Nutzerlisten zu erstellen, die Ihnen dabei helfen, effektivere Gebotseinstellungen. In diesem Leitfaden werden die in Cookies verwendeten Konzepte beschrieben. Abgleich sowie verschiedene Workflows für den Cookie-Abgleich und alle Varianten für bestimmte Anwendungsfälle haben.

<ph type="x-smartling-placeholder">

Konzepte

Domain-Inhaber legen den Inhalt von Cookies in der Regel für Nutzer fest, die die Website Ihrer Website, mit denen Nutzer innerhalb dieser Domain identifiziert werden. Selbst wenn zwei würden die Domaininhaber dem Austausch dieser Daten zustimmen, wird das Sicherheitsmodell der Internetbrowser verhindern das Lesen eines von einem anderen Browser gesetzten Cookies. .

Im Kontext digitaler Werbung identifiziert Google Nutzer mithilfe von Cookies die zur Domain doubleclick.net gehören, sowie Bieter die an Echtzeitgeboten teilnehmen, eine eigene Domain haben, um eine Gruppe von Nutzern zu identifizieren, für die Anzeigen ausgeliefert werden sollen. Cookie-Abgleich ermöglicht es dem Bieter, seine Cookies mit denen von Google abzugleichen, sodass er ermitteln, ob eine in einer Gebotsanfrage gesendete Impression mit einer der Zielnutzer erhalten diese entweder ihre eigenen Cookie-Daten oder eine bieterspezifische Google Nutzer-ID, bei der es sich um eine verschlüsselte Form der doubleclick.net-Cookie in der Gebotsanfrage.

Mit dem in diesem Leitfaden beschriebenen Cookie-Abgleichdienst können Sie und Pflege der Verknüpfung zwischen dem Cookie eines Bieters und dem User-ID und ermöglicht außerdem das Füllen von Nutzerlisten.

Match-Tables

Mithilfe einer Match-Table können IDs oder andere Daten einer Domain eine andere. Bieter können mit dem Cookie-Abgleichdienst ihre eigenen Match-Tables durch Zuordnung ihres Cookies für einen bestimmten Nutzer dem Google-Konto des Nutzers User-ID oder zum Ausfüllen einer von Google gehosteten Match-Table. Match-Tables sind erforderlich, damit die Gebotsanwendung eines Bieters auf Cookie-Daten des Nutzers zugreifen kann der Impression.

Von Google gehostete Match-Tables

Für eine einfachere Wartung, eine verbesserte Latenz und den Zugriff auf Datenabgleiche für in bestimmten Regionen nicht nutzen, wird empfohlen, Ihr Google-Konto Match-Table. So können Sie einen websicheren Base64-codierten String angeben: als gehostete Übereinstimmungsdaten bezeichnet. Diese Daten werden Google Nutzer-ID für einen bestimmten Nutzer. Sobald eine Übereinstimmung gefunden wurde, wie folgt verwendet werden:

  • Echtzeitgebote: in nachfolgenden Gebotsanfragen für Impressionen verknüpft sind, sendet Google Ihnen die gehosteten Übereinstimmungsdaten, die Sie die mit ihrer Google Nutzer-ID übereinstimmen. Wenn Ihr Gebotsendpunkt konfiguriert ist das RTB-Protokoll von Google verwenden, erhalten Sie diese als decodierte Bytes über Das Feld BidRequest.hosted_match_data. In OpenRTB von Google Implementierung, gibt BidRequest.user.buyeruid die folgende Abfrage zurück: als websicherer Base64-codierter String.

    <ph type="x-smartling-placeholder">
  • Nutzerlisten: Nutzerlisten können mit Daten gefüllt werden. mit Google Nutzer-IDs oder gehosteten Abgleichsdaten.

    <ph type="x-smartling-placeholder">
  • Pre-Targeting: Sie können das Pre-Targeting so konfigurieren, dass Sie nur Gebotsanfragen erhalten mit gehosteten Übereinstimmungsdaten. So lassen sich weniger relevante Anzeigen Impressionen für Nutzer außerhalb Ihres Cookie-Bereichs.

Nutzerlisten

Nutzerlisten können mit der Real-Time Bidding API erstellt und verwaltet werden. Nach der Erstellung können Sie diese Listen mithilfe der Workflows für den Cookie-Abgleich füllen. oder den Bulk-Uploader nutzen.

<ph type="x-smartling-placeholder">

Erste Schritte

Um mit dem Cookie-Abgleich zu beginnen, müssen Sie sich an Ihren Technischer Account Manager, der bestimmte Workflows aktivieren und Ihnen helfen kann, konfigurieren Sie Folgendes:

  • Cookie Matching Network ID (NID): Eine String-ID, die eindeutig identifiziert ein Bieterkonto für den Cookie-Abgleich und andere damit zusammenhängende Vorgänge.
  • Cookie-Abgleich-URL: Die Basis-URL für einen Endpunkt, der akzeptiert. und eingehende Anfragen im Rahmen des Cookie-Abgleich-Workflows zu verarbeiten. Bieter können in der URL Makros einbetten, die Reihenfolge der Parameter steuern, die in den Cookie-Abgleich-Workflows an sie übergeben werden.
  • Übereinstimmungs-Tag: Das Tag, das Sie im Browser eines Nutzers für den vom Bieter initiierter Cookie-Abgleich. Diese können neben Anzeigen, oder außerhalb von Anzeigen auf Web-Properties platziert werden.
  • URL des Cookie-Abgleichberichts (optional): In der unidirektionalen Cookie-Abgleich-Workflow. Hierbei handelt es sich um eine optionale URL, die einen Endpunkt angeben, an den Fehlerdetails gesendet werden, falls dieses Cookie der Abgleich durch eine HTTP 302-Weiterleitung fehlschlägt. Standardmäßig werden nur Antworten an diese URL gesendet, wenn beim Cookie-Abgleich ein Fehler aufgetreten ist, Die Bieter können aber verlangen, dass die Weiterleitung immer gesendet wird.
  • URL zur Unterstützung des Cookie-Abgleichs: Für Anzeigenplattformen, die die Workflow zur Unterstützung des Cookie-Abgleichs: Dies ist die Die Basis-URL des Endpunkts, der auf eingehende Anfragen antworten soll.
  • Kontingent zur Unterstützung für den Cookie-Abgleich: Für Anzeigenplattformen, die das Workflow zur Unterstützung des Cookie-Abgleichs: Dies ist die maximale Anzahl an Anfragen, die ihre Cookie-Abgleich-URL pro empfangen kann 2. Damit soll verhindert werden, dass CMA-Anfragen an die Server von Austausch mit Anfragen senden.

In einem der unterstützten Workflows für den Cookie-Abgleich der Cookie-Abgleich-URL eines Bieters werden in der Regel Parameter nicht garantierte Reihenfolge. Bieter mit Integrationen, die eine einheitliche Vorgehensweise erfordern der Parameteranordnung können Makros in ihrer Cookie-Abgleich-URL für ihr Placement garantieren können.

Unterstützte Makros

Bieter können ihre Cookie-Abgleich-URL optional so konfigurieren, dass sie eine oder weitere Makros in der Form %%GOOGLE_<PARAM_NAME>%% oder %%GOOGLE_<PARAM_NAME>_PAIR%%. Die unterstützten Makros und ihre erweiterte Werte sind:

Macro Erweiterter Wert
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &amp;google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &amp;cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &amp;google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &amp;google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&amp;cver=COOKIE_VERSION_NUMBER&amp;google_error=ERROR_ID

Beispiel für ein Makro

Ein Bieter hat eine Integration für den Cookie-Abgleich mit einem Endpunkt, der auf https://user.bidder.com.cookies, und ihre Implementierung erfordert voreingestellte Bieterparameter zusätzlich zum Pixel-Abgleich vor Parameter in der folgenden Reihenfolge: google_push, google_gid, google_cver und google_error Dazu legt der Bieter seine Cookie-Abgleich-URL zu:

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 diese erweitert in etwa so aussehen:

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

Der Cookie-Abgleichdienst von Google unterstützt derzeit drei Workflows zum verschiedene Anwendungsfälle, die im Folgenden beschrieben werden.

Der bidirektionale Cookie-Abgleich bezieht sich auf einen von einem Bieter initiierten Workflow, bei dem wird ein Übereinstimmungs-Tag im Browser platziert, über das der Nutzer an Google weitergeleitet wird. Dieses können sowohl Google als auch der Bieter Match-Tables mit Daten füllen. Unten sehen Sie eine Beispiel dieses Workflows.

Schritt 1: Übereinstimmungs-Tag platzieren

Um diesen Vorgang zu initiieren, muss der Bieter sein Übereinstimmungs-Tag so platzieren, die im Browser des Nutzers gerendert werden. Ein einfaches Übereinstimmungs-Tag, bei dem nur Die Google User-ID für den Bieter kann wie folgt strukturiert sein:

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

Es gibt zusätzliche Parameter, die Sie in das Übereinstimmungs-Tag aufnehmen können, um die verschiedenen Anwendungsfällen. Weitere Informationen zu diesen Parametern finden Sie unter Gleichen Sie die Tag-URL-Parameter an.

Schritt 2: Google antwortet mit einer Weiterleitung und enthält Übereinstimmungsdaten

Das Übereinstimmungs-Tag führt dazu, dass der Cookie-Abgleichdienst von Google Anfrage vom Browser des Nutzers, wodurch HTTP 302 ausgegeben wird Weiterleitung an die Cookie-Abgleich-URL des Bieters. Die Weiterleitung umfasst Parameter zur Angabe der Google Nutzer-ID und der Versionsnummer in der URL sowie erhält der Bieter auch sein Cookie, das in den Anfrageheadern enthalten ist. In für eine Cookie-Abgleich-URL, die als https://ad.network.com/pixel angegeben ist, gilt Folgendes: könnte die Weiterleitungs-URL für das einfache Übereinstimmungs-Tag wie oben Folgendes:

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

Die mit dem Parameter google_gid übergebene Google Nutzer-ID lautet eine websichere Base64-codierte ohne Padding . Bieter, die eine Match-Table hosten, sollten den genauen vom Cookie-Abgleichdienst zurückgegebenen String speichern In den folgenden Gebotsanfragen gesendet werden, entspricht dies den über BidRequest.google_user_id angegebenen Werten. im RTB-Protokoll von Google oder BidRequest.user.id im OpenRTB-Implementierung

Die in google_cver angegebene Version gibt die numerischen Versionsnummer für die Google Nutzer-ID ein. Die Google Nutzer-ID für einen bestimmten Nutzer selten geändert. Danach wird der Wert erhöht.

Sollte Google bei der Verarbeitung Ihrer Zuordnungsanfrage einen Fehler feststellen, Stattdessen wird der Parameter google_error angegeben.

Schritt 3: Die Gebotsfunktion verarbeitet die Weiterleitung und antwortet mit einem Pixel

Der Bieter erhält eine Weiterleitung zu seiner URL für den Cookie-Abgleich, die folgende Informationen enthält: Parameter, die sie im ersten Schritt angegeben haben, sowie diejenigen, die Google in den zweiten Schritt. Außerdem erhalten sie ihr Cookie im HTTP- Header. Wenn der Vorgang erfolgreich war, hostet ein Bieter seine eigene Match-Table. ihr Cookie der in der Antwort enthaltenen Google Nutzer-ID zuordnen. Es ist wird für Bieter empfohlen, den vom Cookie-Abgleich zurückgegebenen String genau zu speichern Dienst.

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

Der Bieter muss immer ein unsichtbares 1-x-1-Pixel-Image liefern oder oder die Antwort HTTP 204 No Content zurückgeben.

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

Übereinstimmung mit Tag-URL-Parametern

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann abgerufen werden auf der Seite Bieter .
google_cm Gibt dem Cookie-Abgleichdienst von Google an, dass die Ausführung Cookie-Abgleich. Der Wert des Parameters wird ignoriert und kann ausgelassen.
google_sc Dieser Parameter wurde eingestellt. Setzt das Cookie von Google für die wenn kein Nutzer vorhanden ist. Der Wert des Parameters wird ignoriert und kann ausgelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist existiert.
google_no_sc Dieser Parameter wurde eingestellt. Dies deutet darauf hin, Cookie-Abgleichdienst verwendet, dass er kein Cookie für den Nutzer setzen sollte, wenn Eine davon ist nicht vorhanden. Der Wert des Parameters wird ignoriert und kann ausgelassen.
google_hm

Daten, die der Bieter in einer von Google gehosteten Match-Table speichern möchte.

Der Wert ist ein websicherer Base64-codierter String (mit optionalem Padding). Die Rohdaten müssen 40 Byte oder weniger. Beispiel: Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.

google_redir Ein URL-codierter String, den ein Bieter angeben kann, wenn er weiterleiten möchte Google sendet die HTTP 302-Weiterleitung an die codierte URL für dieses Übereinstimmungs-Tag. So kann Google am Anfang einer verketteten an unsere Partner. Dies führt zu einem Fehler, wenn Sie ohne google_hm oder mit google_cm.
google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Der Wert erwartetes Format ist userlistid[,timestamp]: <ph type="x-smartling-placeholder">
    </ph>
  • userlistid: eine einzelne numerische Nutzerlisten-ID
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, gibt an, wann der Nutzer zur Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen.

gdpr Gibt an, dass die Anfrage DSGVO-Einschränkungen für Daten unterliegt Nutzung. Weitere Informationen finden Sie unter . Anforderungen an die Einwilligung der Nutzer in der EU unten oder Auswirkungen auf den Cookie-Abgleich in der <ph type="x-smartling-placeholder"></ph> Dokumentation zum IAB TCF 2.0 in Authorized Buyers

Beispiel: gdpr=1

gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen siehe Anforderungen an die Einwilligung der Nutzer in der EU oder Wie wird der TC-String übergeben? im <ph type="x-smartling-placeholder"></ph> Dokumentation zum IAB TCF 2.0 in Authorized Buyers
process_consent Gibt an, dass der Bieter die Einwilligung des Endnutzers für die in den <ph type="x-smartling-placeholder"></ph> Google-Richtlinie zur Einwilligung der Nutzer in der EU

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

Beispiel: process_consent=T

Zusätzlich zu den oben genannten Parametern können Bieter eigene Parameter angeben, die werden als Parameter an die Weiterleitungs-URL angehängt. Der vom Bieter definierte Parameter mit dem Präfix google_ werden ignoriert, weil Diese sind Google für die zukünftige Entwicklung und die Aufbewahrung der Parameter kann nicht garantiert werden. Ein Übereinstimmungs-Tag mit einem vom Bieter definierten Tag können wie folgt 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 Basis-URL für den Cookie-Abgleich erstellt, die für eines Bieterkontos, einschließlich google_ und von Bieter definierter Parameter abhängig von den im Übereinstimmungs-Tag angegebenen Werten. Folgende google_ Antwortparameter 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 ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wann? empfangen, bedeutet das, dass keine Vorgänge ausgeführt wurden und keine anderen google_ Antwortparameter werden festgelegt. Der unterstützte Fehler Folgende Werte sind möglich:

  • 1: Der Nutzer verfügt über ein Google-Cookie, hat jedoch eines deaktiviert. mithilfe dieses Cookies erfasst werden.
  • 2: Keine gültigen Vorgänge angegeben. zum Beispiel eine Nulloperation Anfrage ist eingegangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google wird keine Das Cookie wird über den Cookie-Abgleichdienst gespeichert.
  • 4: In Konflikt stehende Vorgänge angegeben. Sie sind nicht darf sowohl google_push als auch google_cm angeben Flags für dieselbe Anfrage, da sie widersprüchlichen Zwecken dienen.
  • 5: Ein ungültiger google_push-Parameter wurde Weiterleitung an einen Google-Server als Teil einer bidirektionalen Anfrage zum Pixel-Abgleich. Für deine Weiterleitung muss google_push festgelegt werden auf denselben Wert, der in der ursprünglichen Pixelanfrage an Sie übergeben wurde.
  • 6: Im Übereinstimmungs-Tag wurde eine ungültige NID angegeben.
  • 7: Es wurde ein ungültiges Cookie erkannt.
  • 8: Eingestellt. Kein Cookie gefunden.
  • 9: Kein Cookie gefunden. Es wird versucht, ein Testcookie zu setzen.
  • 10: Der Parameter google_redir wurde verwendet. ohne Angabe von google_hm oder wurde zusätzlich verwendet an google_cm.
  • 15: Die Anfrage stammt aus einer Region, in der Google setzt voraus, dass die Match-Table von Google gehostet wird. Dies hat zur Folge, Antwort keine Google Nutzer-ID enthält. Diese Option ist derzeit aktiviert für nur für einen kleinen Prozentsatz des Traffics, aber in Zukunft Juni 2020
google_hm

Wird nur angezeigt, wenn versucht wird, in die von Google gehostete Match-Table zu schreiben schlägt fehl. In diesem Fall ist der Wert einer der folgenden Statuscodes:

  • 1 – Verboten: Der Kunde ist noch nicht auf der weißen Liste für Gehostete Match-Table-Einträge schreiben.
  • 2 – Decodierungsfehler: Der Parameterwert konnte nicht decodiert werden.
  • 3 – Nutzlast zu lang: Der Parameterwert wurde in mehr als 24 Byte an Daten.
  • 4 – Interner Fehler: Beim Speichern ist ein interner Fehler aufgetreten. mit den Daten.
  • 5 – Gedrosselt: Dieser Schreibvorgang wurde aus folgendem Grund nicht verarbeitet: Drosselung.
google_ula

Status des Hinzufügungsvorgangs zur Nutzerliste, wird bei mehreren google_ula wiederholt die in der Anfrage angegeben sind. Das Format ist:
userlistid,status code

Beispiel: google_ula=1234567890,0

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

  • 0 – Kein Fehler. Der Nutzer wurde der Nutzerliste hinzugefügt.
  • 2 – Berechtigung verweigert. Sie sind nicht berechtigt, der angegebenen Nutzerliste Nutzer hinzuzufügen.
  • 5 – Ungültige Nutzerlisten-ID. Die angegebene Nutzerlisten-ID ist ungültig.
  • 6 – Geschlossene Attribut-ID. Die bereitgestellte Nutzerlisten-ID ist geschlossen.
  • 10: Interner Fehler. Der Cookie-Abgleichdienst Es ist ein interner Fehler aufgetreten. können Sie noch einmal versuchen, den Nutzer erneut zuzuordnen.

In den folgenden Szenarien wird beschrieben, wie der Cookie-Abgleich für eine wie ein typischer Nutzer beim Surfen auf einer Webseite ist.

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

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

Folgendes passiert:

  1. ExampleNews.com wird gerendert und ruft Anzeigen von Google (Ad Manager) ab.
  2. Da der Anzeigenblock für die dynamische Zuordnung infrage kommt, sendet Google Anfragen an FinestDSP und andere Bieter über den Echtzeitgebotsdienst.
  3. Die Gebotsanwendung von FinestDSP empfängt und verarbeitet die Gebotsanfrage, und sendet die zugehörige Gebotsantwort.
  4. Google erhält Gebotsantworten von Bietern, einschließlich der Antwort von FinestDSP , der eine Anzeige mit einem Übereinstimmungs-Tag (Pixel) angibt.
  5. FinestDSP gewinnt die Auktion. Google liefert die Anzeige und das Übereinstimmungs-Tag von FinestDSP an Jane.
  6. Das Übereinstimmungs-Tag ruft den Cookie-Abgleichdienst von Google auf und gibt dabei Folgendes an: google_nid- und google_cm-Parameter.
  7. Der Cookie-Abgleichdienst liest Susannes Google-Cookie und sendet eine Weiterleitung an die Cookie-Abgleich-URL von FinestDSP mit der Die Parameter google_user_id und google_cver wurden festgelegt.
  8. Janes Browser lädt die Weiterleitung zur Cookie-Abgleich-URL von FinestDSP.
  9. Der Cookie-Abgleich-Endpunkt von FinestDSP verarbeitet die Weiterleitungsanfrage, einschließlich der von Google festgelegten URL-Parameter und deren Cookie für Jane im HTTP-Header. FinestDSP kann jetzt die Zuordnung ihres Cookies zum google_user_id in der Match-Table.
  10. FinestDSP reagiert auf die Weiterleitung mit einem unsichtbaren 1x1-Pixel.
Szenario 2: Nutzer mit vorhandener Zuordnung

Eine Woche nach Szenario 1 besucht Susanne die Website ExampleNews.com erneut. Da Jane nun auf seinem Computer sowohl als auch Ad Manager-Cookies hat, funktioniert.

  1. Die Webseite wird gerendert, sodass Google (Ad Manager) Anzeigen anfordert, auf der Seite gerendert werden.
  2. Während der Anzeigenauktion sendet Google eine Gebotsanfrage an die infrage kommenden Bieter. einschließlich FinestDSP.
  3. FinestDSP empfängt die Gebotsanfrage, einschließlich Signalen wie dem google_user_id
  4. FinestDSP sucht in der Match-Table nach google_user_id. und findet das Cookie, das Jane zugeordnet ist, das eine Woche zuvor erstellt wurde. (in Szenario 1).
  5. Basierend auf den mit dem Cookie verknüpften Informationen ein Gebot für die Impression abgibt und die Auktion gewinnt.
  6. Jane sieht möglicherweise eine Anzeige, die auf ihren Interessen zugeschnitten ist, basierend auf den Informationen die FinestDSP besitzt.

Der unidirektionale Cookie-Abgleich ähnelt dem bidirektionalen Workflow. mit dem Unterschied, dass sie so geändert wurde, dass nur Google eine Übereinstimmung hostet und ausfüllt. . Dies kann in Fällen verwendet werden, in denen der Bieter nicht zum Hosten Google Nutzer-IDs in ihrer eigenen Match-Table aus. Um diesen Ablauf zu nutzen, muss Google erlauben, die Match-Table zu hosten, kann nicht mehr angeben google_cm in Anfragen an den Cookie-Abgleichdienst von Google und erhält folglich auch keine google_gid für ihre eigenen Match-Table. Sobald Google eine Übereinstimmung für einen Nutzer festgestellt hat, können Bieter mithilfe eigener Cookie-Daten zu Nutzerlisten. Auch Gebotsanfragen für Diese Nutzer schließen die Google Nutzer-ID aus, beinhalten aber gehostete Daten zum Abgleich. A Ein einfaches Beispiel des überarbeiteten Workflows ist in den folgenden Schritten zusammengefasst.

Um diesen Vorgang zu initiieren, muss ein Bieter ein Übereinstimmungs-Tag so platzieren, dass es die im Browser des Nutzers gerendert werden. Anders als beim Workflow für Nutzer*innen, die nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen kommen, muss der Browser des Nutzers über das Übereinstimmungs-Tag zu Ihrem Cookie weitergeleitet werden. Übereinstimmende URL. Beispiel: Wenn eine Cookie-Abgleich-URL wie folgt konfiguriert ist: https://ad.network.com/pixel sieht das so aus:

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

Beim Laden in den Browser des Nutzers wird ein Pixel vom URL für Cookie-Abgleich. Diese Anfrage enthält ihr Cookie im HTTP-Header, die für den nächsten Schritt extrahiert werden sollte.

Über den Cookie-Abgleichendpunkt des Bieters muss eine Weiterleitung zum Cookie von Google erfolgen Abgleichdienst, einschließlich des Parameters google_hm mit Werten für ihre websicheren Base64-codierten Cookie-Daten. Die Weiterleitungs-URL könnte wie folgt aussehen: Folgendes:

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

Google erhält eine Weiterleitung mit den Parametern, die Sie in Google-Cookie in den HTTP-Headern.

Schritt 4: Google liefert Pixel bei Erfolg oder Fehlerweiterleitung aus, falls Berichts-URL angegeben ist

Ob der Cookie-Abgleich erfolgreich ist oder wenn kein Cookie Die URL für den Abgleichsbericht wurde für das Konto des Bieters (Google) angegeben. liefert standardmäßig ein transparentes 1x1-Pixel und der Workflow endet hier. Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen enthalten den Wert gehostete Übereinstimmungsdaten in BidRequest.hosted_match_data für die Google Protokoll oder BidRequest.user.buyeruid für OpenRTB von Google Implementierung. Bieter können anhand der gehosteten Abgleichsdaten auch Nutzerlisten füllen die sie angegeben haben.

Andernfalls sendet Google im Falle eines Fehlers eine Weiterleitung an die URL des Cookie-Übereinstimmungsberichts mit der Fehlerursache im google_error-Parameter. Wenn die URL des Cookie-Abgleichberichts des Bieters https://ad.network.com/report lautet, sieht die Weiterleitungs-URL so aus: wie:

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

Der Browser des Nutzers leitet den Nutzer an die URL des Cookie-Abgleichberichts des Bieters weiter. einschließlich der Fehlerursache (falls vorhanden), die von Google in der google_error-Parameter. Weitere Informationen zum Interpretieren des Fehlers finden Sie in der Parameterbeschreibung.

Schritt 6: Der Bieter liefert ein transparentes 1 × 1-Pixel aus

Der Bieter muss als Antwort ein transparentes 1-x-1-Pixel an das Browser.

Das Diagramm zeigt den Standardworkflow für Nutzer in US-Bundesstaaten mit Datenschutzeinschränkungen wobei Anfragen und Antworten durch einen Pfeil dargestellt werden, und die Daten die zugehörigen Elemente in Klammern aufgeführt sind.

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann abgerufen werden auf der Seite Bieter .
google_sc Dieser Parameter wurde eingestellt. Setzt das Cookie von Google für die wenn kein Nutzer vorhanden ist. Der Wert des Parameters wird ignoriert und kann ausgelassen werden. Das Weglassen des Parameters führt zu einem Fehler, wenn kein Cookie vorhanden ist existiert.
google_no_sc Dieser Parameter wurde eingestellt. Dies deutet darauf hin, Cookie-Abgleichdienst verwendet, dass er kein Cookie für den Nutzer setzen sollte, wenn Eine davon ist nicht vorhanden. Der Wert des Parameters wird ignoriert und kann ausgelassen.
google_hm

Enthält Daten, die der Bieter in einer von Google gehosteten Übereinstimmung speichern möchte .

google_redir Eine codierte URL, an die Google eine HTTP 302-Weiterleitung senden soll. Die für die angegebene URL Weiterleitungen mit der google_error -Parameter für Fehler und erfolgreiche Vorgänge.
google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Der Wert erwartetes Format ist userlistid[,timestamp]: <ph type="x-smartling-placeholder">
    </ph>
  • userlistid: eine einzelne numerische Nutzerlisten-ID
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, gibt an, wann der Nutzer zur Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen.

gdpr Gibt an, dass die Anfrage DSGVO-Einschränkungen für Daten unterliegt Nutzung. Weitere Informationen finden Sie unter . Anforderungen an die Einwilligung der Nutzer in der EU unten oder Auswirkungen auf den Cookie-Abgleich in der <ph type="x-smartling-placeholder"></ph> Dokumentation zum IAB TCF 2.0 in Authorized Buyers

Beispiel: gdpr=1

gdpr_consent Ein TC-String, der die Einwilligung des Endnutzers darstellt. Weitere Informationen siehe Anforderungen an die Einwilligung der Nutzer in der EU oder Wie wird der TC-String übergeben? im <ph type="x-smartling-placeholder"></ph> Dokumentation zum IAB TCF 2.0 in Authorized Buyers
process_consent Gibt an, dass der Bieter die Einwilligung des Endnutzers für die in den <ph type="x-smartling-placeholder"></ph> Google-Richtlinie zur Einwilligung der Nutzer in der EU

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

Beispiel: process_consent=T

Parameter Beschreibung
google_error

Ein ganzzahliger Wert, der den gesamten Anfragefehler angibt. Wann? empfangen, bedeutet das, dass keine Vorgänge ausgeführt wurden und keine anderen google_ Antwortparameter werden festgelegt. Der unterstützte Fehler Folgende Werte sind möglich:

  • 1: Der Nutzer verfügt über ein Google-Cookie, hat jedoch eines deaktiviert. mithilfe dieses Cookies erfasst werden.
  • 2: Keine gültigen Vorgänge angegeben. zum Beispiel eine Nulloperation Anfrage ist eingegangen.
  • 3: Der Nutzer hat kein Google-Cookie. Google wird keine Das Cookie wird über den Cookie-Abgleichdienst gespeichert.
  • 4: In Konflikt stehende Vorgänge angegeben. Sie sind nicht darf sowohl google_push als auch google_cm angeben Flags für dieselbe Anfrage, da sie widersprüchlichen Zwecken dienen.
  • 5: Ein ungültiger google_push-Parameter wurde Weiterleitung an einen Google-Server als Teil einer bidirektionalen Anfrage zum Pixel-Abgleich. Für deine Weiterleitung muss google_push festgelegt werden auf denselben Wert, der in der ursprünglichen Pixelanfrage an Sie übergeben wurde.
  • 6: Im Übereinstimmungs-Tag wurde eine ungültige NID angegeben.
  • 7: Es wurde ein ungültiges Cookie erkannt.
  • 8: Eingestellt. Kein Cookie gefunden.
  • 9: Kein Cookie gefunden. Es wird versucht, ein Testcookie zu setzen.
  • 10: Der Parameter google_redir wurde verwendet. ohne Angabe von google_hm oder wurde zusätzlich verwendet an google_cm.
  • 15: Die Anfrage stammt aus einer Region, in der Google setzt voraus, dass die Match-Table von Google gehostet wird. Dies hat zur Folge, Antwort keine Google Nutzer-ID enthält. Diese Option ist derzeit aktiviert für nur für einen kleinen Prozentsatz des Traffics, aber in Zukunft Juni 2020

Von Google initiiert: Bidirektionaler Pixelabgleich

Der bidirektionale Pixel-Abgleich ist ein Workflow für den Cookie-Abgleich von Google. Dienst, bei dem Google versucht, eine Google Nutzer-ID einem Algorithmus zuzuordnen einen anderen Bieter als den Auktionsgewinner der Echtzeitgebotsfunktion ausgewählt hat. Wenn eine Anzeige platziert Google ein Übereinstimmungs-Tag, das den Browser des Nutzers auffordert, eine ein transparentes Pixel von der Cookie-Abgleich-URL des ausgewählten Bieters. Dadurch wird Folgendes aktiviert: und der Bieter, um eine Match-Table mit einem bestimmten Nutzer zu füllen. Unten sehen Sie ein einfaches Beispiel für diesen Workflow.

Schritt 1: Google platziert ein Übereinstimmungs-Tag

Wenn die Seite eines teilnehmenden Publishers im Browser des Nutzers geladen wird und ein auf dieser Seite von Google gefüllt wird, kann ein Übereinstimmungs-Tag platziert werden, fordert ein Pixel von einem algorithmisch ausgewählten Bieter an. Pixel-Abgleich von Google platzierte Tags kombiniert die Cookie-Abgleich-URL des Bieters mit zusätzliche Parameter für die die der Bieter verwenden kann, um seine Match-Table zu füllen. Für eine Cookie-Abgleich-URL als https://ad.network.com/pixel angegeben ist, ist sie so strukturiert: folgt:

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

Bieter, die Anfragen zum Pixelabgleich erhalten, müssen mit einer an den Cookie-Abgleichdienst von Google weiterleiten, der wie folgt aufgebaut ist:

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

Beachten Sie, dass die oben genannte Weiterleitungs-URL der URL ähnelt, die im für den vom Bieter initiierten Cookie-Abgleich-Workflow aus. Beim Pixelabgleich wird der Parameter google_cm durch den Parameter Parameter google_push. Sein Wert muss gleich dem Wert sein. in der Anfrage angegeben haben. Ähnlich wie die vom Bieter initiierte Workflow, zusätzliche Parameter kann angegeben werden, um zusätzliche Anwendungsfälle abzudecken.

<ph type="x-smartling-placeholder">

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

Google protokolliert, dass eine Übereinstimmung für den Nutzer erstellt wurde, und verarbeitet jegliche zusätzliche Vorgänge, die über Suchparameter angefordert werden. Google antwortet mit einem transparenten 1-x-1-Pixel.

Workflowdiagramm für den Pixelabgleich

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

Anfrageparameter für das Google-Match-Tag

Parameter Beschreibung
google_gid Google Nutzer-ID. Für Nutzer außerhalb der USA mit Datenschutzeinschränkungen gilt: im Übereinstimmungs-Tag von Google angegeben.
google_cver Die Cookie-Version. Dies wird immer in der Übereinstimmung mit Google angegeben. Tag.
google_push Gibt an, dass diese Anfrage den Pixel-Abgleich-Workflow initiiert. Der Wert muss über den entsprechenden Parameter in der Weiterleitungsantwort.

Weiterleitungsparameter für den Pixelabgleich des Bieters

Parameter Beschreibung
google_nid Netzwerk-ID (NID) für das Bieterkonto. Diese ID kann abgerufen werden auf der Seite Bieter .
google_push Gibt an, dass diese Weiterleitung den Pixel-Abgleich abschließt zu optimieren. Der Wert aus dem entsprechenden Google-Übereinstimmungs-Tag muss wie hier angegeben.
google_hm

Enthält Daten, die der Bieter in einer von Google gehosteten Übereinstimmung speichern möchte .

google_ula Ein String, mit dem der Nutzer einer vorhandenen Nutzerliste hinzugefügt wird. Der Wert erwartetes Format ist userlistid[,timestamp]: <ph type="x-smartling-placeholder">
    </ph>
  • userlistid: eine einzelne numerische Nutzerlisten-ID
  • timestamp: ein optionaler Zeitstempel im POSIX-Format, gibt an, wann der Nutzer zur Nutzerliste hinzugefügt wurde.

Dieser URL-Parameter kann wiederholt werden, um den Nutzer mehreren Listen.

Von Google initiiert: Unidirektionaler Pixelabgleich

Der unidirektionale Pixelabgleich unterscheidet sich vom bidirektionalen Workflow in dass das Übereinstimmungs-Tag von Google keinen Parameter enthält, der den Google-Nutzer ID, wird jedoch weiterhin in eine von Google gehostete Match-Table gefüllt. Dies kann verwendet werden, in Fällen, in denen der Bieter keine Google Nutzer-IDs in seinem Match-Table auswählen. Ein einfaches Beispiel des überarbeiteten Workflows finden Sie im die unten beschriebenen Schritte.

Schritt 1: Google platziert ein Übereinstimmungs-Tag

Google platziert ein Übereinstimmungs-Tag für einen algorithmisch ausgewählten Bieter. Das Übereinstimmungs-Tag enthält google_push-Parameter. 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. und das Cookie des Bieters in den HTTP-Headern enthalten.

Über den Cookie-Abgleichendpunkt des Bieters muss eine Weiterleitung zum Cookie von Google erfolgen Abgleichdienst, einschließlich des Parameters google_hm mit Werten für ihre websicheren Base64-codierten Cookie-Daten. Die Weiterleitungs-URL könnte wie folgt aussehen: Folgendes:

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

Google erhält eine Weiterleitung mit den Parametern, die Sie in Google-Cookie in den HTTP-Headern. Bisheriger Vorgang: Erfolg haben, enthalten die Impressionen für diesen Nutzer in nachfolgenden Gebotsanfragen gehostete Übereinstimmungsdaten des Bieters in BidRequest.hosted_match_data für das Google-Protokoll oder BidRequest.user.buyeruid für die OpenRTB-Implementierung Bieter können Nutzerlisten auch über die mit den angegebenen Daten übereinstimmen.

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

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

  1. Beim Platzieren einer Anzeige wählt Google mithilfe von Algorithmen ein teilnehmendes und platziert ein Tag zur Unterstützung bei der Cookie-Übereinstimmung, das Folgendes enthält: Struktur:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
  2. Das CMA-Übereinstimmungs-Tag von Google bewirkt, dass die Cookie-Abgleich-URL der Anzeigenplattform eine Pixel-Anfrage erhalten.

  3. Der Endpunkt für den Cookie-Abgleich der Anzeigenplattform empfängt die Anfrage, wobei ein eigener Cookie-Abgleichdienst für den Abgleich der Nutzer-ID mit einer seiner Bieter. Im folgenden Diagramm ist der Cookie-Abgleich der Plattform Der Dienst antwortet dem Browser des Nutzers mit einer Weiterleitung an eine der Endpunkten.
  4. Der Bieter erhält die Anfrage zusammen mit allen Parametern, die durch um die User-ID ihrem Cookie zuzuordnen.

Einschränkungen

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

Bieter sind dafür verantwortlich, die Anzahl der Aufrufe des Cookies zu begrenzen Abgleichdienst für Nutzer, für die ein neuer Eintrag in der von Google gehosteten Übereinstimmung vorhanden ist . Ein Eintrag in der gehosteten Match-Table gilt möglicherweise nach 14 Tagen als abgelaufen. und kann anschließend aktualisiert werden.

<ph type="x-smartling-placeholder">

Auf alle Anfragen mit Pixel-Übereinstimmung antworten

Bieter, die den Workflow für den Pixel-Abgleich verwenden, müssen alle eingehende Pixel Match-Anfragen mit einer Antwort, die google_push enthält . So kann Google Richtlinien durch das Monitoring der Nutzung erzwingen. Wenn ein die Antwortrate des Bieters unter 90 % fällt, drosselt Google die Anzahl der Pixel-Übereinstimmungsanfragen, die an das Konto gesendet wurden

HTTPS-Endpunkte verwenden

Endpunkte, die in allen Workflows für den Cookie-Abgleich verwendet werden, müssen HTTPS

Wenn Sie auf eine Pixel-Übereinstimmungsanfrage antworten, die Ihnen über HTTPS gesendet wurde, erforderlich, um über HTTPS zum Cookie-Abgleichdienst weiterzuleiten. Gleichermaßen muss ein Endpunkt für die Cookie-Übereinstimmung, 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 an Ihr Konto gesendeten Übereinstimmungsanfragen gedrosselt.

Cookie-Abgleichanfragen, die den Google-Nutzer in der EU Die Richtlinie zur Einwilligung der Nutzer in der EU sollte die Einwilligung des Endnutzers enthalten. Solche Anträge sind erforderlich, geben an, dass die Einwilligung auf eine der folgenden Arten eingeholt wurde:

  • TCF Version 2: Hierzu gehören gdpr und gdpr_consent Parameter. Weitere Informationen finden Sie in der <ph type="x-smartling-placeholder"></ph> Dokumentation zum IAB TCF 2.0 in Authorized Buyers
  • process_consent: eine Erklärung, die der Bieter erhalten hat der erforderlichen Einwilligung des Nutzers.

Beispiele

In den folgenden Beispielen wird veranschaulicht, wie Sie mit dem Cookie-Abgleichdienst um bestimmte Ziele zu erreichen. Sofern nicht anders angegeben, gilt Folgendes: dass die zu behandelnde Person nicht aus einem US-Bundesstaat mit Datenschutzbeschränkungen.

Vom Bieter gehostete Match-Table ausfüllen

Ein Bieter kann den Cookie-Abgleich verwenden, um seine eigene Übereinstimmung zu erfassen. indem Sie nur die google_nid und google_cm im Übereinstimmungs-Tag angegeben werden. Dies könnte etwa so aussehen:

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

Wenn die Cookie-Abgleich-URL des Bieters auf https://ad.network.com/pixel?id=1 festgelegt ist, und der Cookie-Abgleich erfolgreich ist, sendet Google kann die Antwort auf das Übereinstimmungs-Tag des Bieters so aussehen:

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

Wenn der Cookie-Abgleich fehlschlägt, weil der Nutzer keine Google-Cookie, lautet die Antwort:

https://ad.network.com/pixel?id=1&google_error=3

Der Fehlercode hängt von der zugrunde liegenden Fehlerursache ab. Weitere Informationen Weitere Informationen zu möglichen Fehlercodes für den Cookie-Abgleich-Workflow finden Sie in der Weiterleitungs-URL-Parameter.

Zur Einzelnutzerliste hinzufügen

Der Parameter google_ula kann in der Übereinstimmung eines Bieters angegeben werden -Tag, um den Nutzer einer Nutzerliste mit der angegebenen ID hinzuzufügen. Wenn die Google- oder der von einem Bieter gehosteten Match-Table einen neuen Eintrag für den Nutzer hat, kann der Bieter ein Übereinstimmungs-Tag mit google_nid und google_ula Parameter, um den Nutzer zur angegebenen Liste hinzuzufügen, ohne den vollständigen Workflow für den Cookie-Abgleich Einschränkungen zum Aufrufen des Cookie-Abgleichdiensts für weitere Details. Die entsprechenden kann wie folgt 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 wie folgt lautet: https://ad.network.com/pixel, würde die Weiterleitungs-URL von Google so aussehen:

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

Wenn ein allgemeiner Fehler vorliegt, zum Beispiel, wenn kein Google-Cookie vorhanden ist, für den Nutzer – die Weiterleitungs-URL enthält google_error-Parameter:

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

Wenn ein Fehler speziell beim Hinzufügen des Nutzers zur Liste auftritt, erhalten Sie google_ula in der Weiterleitung. Im Gegensatz zur Übereinstimmungs-Tag-Parameter entspricht, wird der Zeitstempel durch einen Status um den Erfolg des Vorgangs anzuzeigen. Wenn die Anfrage beispielsweise fehlgeschlagen ist da das Bieterkonto keinen Zugriff auf die angegebene Nutzerliste hatte, wäre die Weiterleitungs-URL:

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

Mehreren Nutzerlisten hinzufügen

Bieter können festlegen, dass ein Nutzer mehreren Nutzerlisten hinzugefügt werden soll, indem sie Mehrere google_ula-Parameter in das Übereinstimmungs-Tag aufgenommen werden In 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 über unterschiedliche google_ula-Parameter in der Weiterleitung:

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

In der Weiterleitung oben sehen wir, dass der Vorgang für den Nutzer erfolgreich war. Liste mit der ID 45678, aber Fehler für Nutzerlisten-ID 12345 da der Bieter keine Zugriffsberechtigung dafür hatte.

Um einen Cookie-Abgleich durchzuführen und den Nutzer einer Nutzerliste in einem -Anfrage muss das Übereinstimmungs-Tag eines Bieters die Werte google_cm und google_ula:

<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 Folgendes enthalten: google_gid, google_cver und google_ula. Dies könnte etwa so aussehen: Folgendes:

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 Match-Table speichern möchte, und beabsichtigt nicht, die Übereinstimmung mit der Google Nutzer-ID in ihrer eigenen Übereinstimmung zu speichern. muss das Übereinstimmungs-Tag den Parameter google_hm enthalten, wobei Der Wert muss ein websicherer Base64-codierter String sein. Für Nutzende, bei denen der Die nicht codierten Cookiedaten des Bieters sind „Cookie number 1!“, also die codierte wäre Q29va2llIG51bWJlciAxIQ==, der in einem wie in diesem Beispiel gezeigt:

<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 wie folgt lautet: https://cookie-monster.com/pixel würde die Weiterleitungs-URL von Google sein:

https://cookie-monster.com/pixel

Der google_gid-Parameter ist nicht in der Weiterleitung enthalten, da der Übereinstimmungs-Tag enthielt google_cm nicht und google_hm ist nicht in erfolgreichen Antworten enthalten. In zukünftigen Gebotsanfragen für Impressionen für diesen Nutzer erhält der Bieter die gehosteten Daten zum Abgleich in BidRequest.hosted_match_data für das RTB-Protokoll von Google oder BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google.

Wenn der Bieter stattdessen ein Übereinstimmungs-Tag verwendet hat, bei dem der Wert google_hm war nicht Base64-codiert, z. B. chocolate_chunk!: Die Weiterleitungs-URL könnte so aussehen: Folgendes:

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

Die obige Weiterleitungs-URL enthält den google_hm-Wert 2, was darauf hindeutet, dass der Vorgang fehlgeschlagen ist, weil der Wert nicht decodiert werden dürfen.

Bieter und von Google gehostete Match-Tables mit Nutzerlisten

Wenn ein Bieter neben einem von Google gehosteten Nutzer eine eigene Nutzungsliste hostet und möchte, dass mit einem einzigen Übereinstimmungs-Tag beide Tabellen abgeglichen und der Nutzer einem muss das Übereinstimmungs-Tag für jede Nutzerliste Folgendes enthalten: google_cm, google_hm- und google_ula-Parameter. Wenn der Bieter Cookie number 1! lautet, wäre der codierte Wert Q29va2llIG51bWJlciAxIQ==, wodurch ein Übereinstimmungs-Tag wie das folgende erzeugt wird: Folgendes:

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

Für eine erfolgreiche Antwort, wenn die Cookie-Abgleich-URL des Bieters wie folgt lautet: https://cookie-monster.com/pixel würde die Weiterleitungs-URL von Google so aussehen:

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

Beim Empfang der Weiterleitung kann der Bieter mit der angegebenen Google Nutzer-ID übereinstimmen in google_gid durch die Cookie-Daten in der Match-Table. In Außerdem können sie feststellen, ob die von Google gehostete Match-Table und Nutzerliste erfolgreich waren. Daraus folgt, dass jedes Pre-Targeting des Bieters die für die Ausrichtung auf die angegebene Nutzerlisten-ID konfiguriert ist, Gebotsanfragen für Impressionen vom Nutzer empfangen. Bei diesen Geboten erhält der Bieter die gehosteten Daten zum Abgleich in BidRequest.hosted_match_data für das RTB-Protokoll von Google oder BidRequest.user.buyeruid für die OpenRTB-Implementierung von Google.