Conversion-Tracking

Abbildung 1. Conversion-Tracking – Übersicht

Übersicht

Beim Conversion-Tracking werden Conversions erfasst, die von Google über eine unserer Action Center-Integrationen initiiert wurden. So können Sie dafür sorgen, dass Ihre Integration einwandfrei funktioniert, da sie sich auf das Ranking auf bestimmten Seiten auswirken kann. Jedes Mal, wenn Google ein action_link generiert, wird die jeweilige URL so geändert, dass sie einen eindeutigen Suchparameter enthält: rwg_token. Sie können das Token speichern und die entsprechenden Werte zurückgeben, wenn ein Nutzer eine Buchung abschließt.

So schließen Sie die Integration ab:

1. Die rwg_token parsen und speichern.
2. Die Händlerinformationen werden analysiert und gespeichert.
3. Gibt die Werte für rwg_token und merchant_changed zurück.
4. Conversion-Tracking testen und überprüfen

Hinweis :Beim Standardintegrationsverfahren müssen Partner Conversion-Tracking zur Leistungsmessung implementieren. Die technischen Schritte werden im weiteren Verlauf dieses Dokuments beschrieben. Die Implementierung von Conversion-Tracking ist für Partner in der Gesundheitsbranche optional und richtet sich nach den Geschäftsanforderungen.

rwg_token parsen und speichern

Um die Integration abzuschließen, müssen Sie die rwg_token bis zu 30 Tage nach der ersten Google-Weiterleitung erfassen und speichern. Der Wert rwg_token ist ein codierter String, der Metadaten zum Link und die Händlerinformationen enthält, mit denen action_link generiert wurde.

Wichtig :Es werden keine personenidentifizierbaren Informationen gespeichert oder verschlüsselt.

Token parsen

Wenn ein Nutzer auf Ihre Buchungsseite weitergeleitet wird, wird der angegebenen URL ein neuer rwg_token angehängt. Auf Ihrer Buchungsseite müssen Sie den Tokenwert parsen.

Im folgenden Beispiel wird gezeigt, wie die rwg_token für das Tracking auf Geräteebene über einen Browser geparst wird.

const rwgToken = new URLSearchParams(location.search).get('rwg_token') || undefined;

Wichtig :Google empfiehlt, das Token als decodierten Wert in Ihrem Cookie zu speichern, da Browser-Cookies spezielle Verwendungszwecke für Sonderzeichen wie = haben. Achten Sie in jedem Fall darauf, dass die decodierte Version im Conversion-RPC gesendet wird und alle Sonderzeichen wie = enthält.

Token speichern

Wenn Sie die rwg_token speichern, können Sie das Conversion-Tracking auf zwei verschiedenen Ebenen implementieren:

• Geräteebene
• Nutzerebene

Sie können das Token auf jeder Ebene speichern, müssen es aber 30 Tage nach der ersten Empfehlung speichern.

Das folgende Beispiel zeigt das Conversion-Tracking auf Geräteebene. Sie können die Tokenwerte in einem Browser mit dem eigenen Cookie speichern. In diesem Beispiel wird davon ausgegangen, dass Sie den Tokenwert in eine Variable geparst haben. Ersetzen Sie rootdomain.com durch Ihre Domain.

if (rwgToken !== undefined) {
  document.cookie =
  "_rwgToken=" + rwgToken + "; max-age=2592000; domain=rootdomain.com; path=/";
}

Jedes Mal, wenn Google ein action_link generiert, das Sie über die Feeds angegeben haben, wird die URL so geändert, dass sie einen eindeutigen Suchparameter enthält: rwg_token. Sie müssen dieses Token speichern und als Teil des Conversion-Ereignisses zurückgeben.

Auf Geräteebene speichern

Auf Geräteebene werden Browser-Cookies, lokaler Speicher, lokaler App-Speicher oder andere Methoden verwendet, mit denen das Token für den 30-tägigen Attributionszeitraum gespeichert werden kann. Das Token wird lokal auf dem Gerät des Nutzers gespeichert. Das Conversion-Ereignis kann also nicht richtig zugeordnet werden, wenn der Nutzer:

• Das Gerät, das sie verwenden, wird geändert.
• Löscht den lokalen Speicher oder die Cookies.
• Sie verwenden einen privaten Browser oder den Inkognitomodus.

Wenn Sie das Conversion-Tracking auf Geräteebene verwenden, müssen Sie das Conversion-Ereignis auf allen unterstützten Geräten, einschließlich Mobilgeräten, neu implementieren.

Auf Nutzerebene speichern

Auf Nutzerebene wird das Token in Ihrer Anwendungsdatenbank, über ein serverseitiges Analysesystem oder andere serverseitige Systeme gespeichert. Das Token wird serverseitig gespeichert. Das Conversion-Ereignis wird also auch nach der erneuten Anmeldung des Nutzers richtig zugeordnet.

Wenn Sie das Conversion-Tracking auf Nutzerebene basierend auf Ihrer Systemarchitektur verwenden, können Sie das Conversion-Ereignis einmal serverseitig implementieren und auf allen unterstützten Geräten wiederverwenden.

Hinweis :Sie können den Speicherort für rwg_token entsprechend Ihren Anforderungen festlegen.

Token aktualisieren

Wenn Google einen Nutzer an denselben Händler verweist, wird das vorhandene, bereits gespeicherte Token durch das neue Token aus dem letzten Verweis ersetzt. Nach dem Ersetzen des Tokens wird der 30-Tage-Zuweisungszeitraum für die Tokenspeicherung zurückgesetzt und alle neuen Conversions für diesen Händler werden dem neuesten Token zugeordnet.

Weitere Informationen finden Sie unter Voraussetzungen für die Conversion-Zuordnung.

Händlerinformationen parsen und speichern

Wenn ein Nutzer zu Ihrer Buchungsseite weitergeleitet wird, müssen Sie die Logik implementieren, mit der die Händlerdetails gefunden und erfasst werden können. Partner fügen ihren Aktionslinks in der Regel Händlermetadaten oder merchant_id hinzu, um die Händlerinformationen zu identifizieren und zu speichern.

Wir empfehlen, die merchant_id oder die ausgewählte Kennung zusammen mit der rwg_token zu speichern. Wenn ein Nutzer eine Buchung bestätigt, können Sie sich an den Händler wenden, bevor Sie die vollständige Conversion-Anfrage senden. Ähnlich wie beim Speichern von Tokens müssen Sie die Händlerdetails zusammen mit dem Token für 30 Tage nach der ersten Weiterleitung speichern.

Im folgenden Beispiel wird die zuvor gespeicherte rwg_token geändert. Es wird davon ausgegangen, dass Sie die Händlerinformationen aus den Metadaten in der angegebenen URL geparst und entweder als merchant_id gespeichert oder mit einem vorhandenen merchant_id abgeglichen haben.

// Store the rwgToken and merchantId in your cookie and set the cookie
// expiration date to 30 days.
if (typeof rwgToken !== 'undefined') {
  document.cookie =
  "_rwgToken=" + rwgToken + "; _merchantId=" + merchantId + "; max-age=2592000;domain=rootdomain.com; path=/";
}

Gibt die rwg_token- und merchant_changed-Werte zurück.

Wenn ein Nutzer eine Buchung abschließt, die über eine action_link-Empfehlung erfolgt ist, müssen Sie eine HTTP-POST-Anfrage an den Conversion-Endpunkt senden. Es gibt zwei Endpunkte:

• Produktionsumgebung: https://www.google.com/maps/conversion/collect
• Sandbox-Umgebung: https://www.google.com/maps/conversion/debug/collect

Wenn Sie ein Conversion-Ereignis senden, müssen Sie die gespeicherte rwg_token und einen merchant_changed-Wert von 1 oder 2 angeben. Weitere Informationen zu merchant_changed finden Sie unter Return the Merchant Change Value.

Der POST-Text muss ein JSON-codiertes Objekt im folgenden Format sein:

{
  "conversion_partner_id": "<partnerId>",
  "rwg_token": "<rwg_token_val>",
  "merchant_changed": "1|2"
}

{
  "conversion_partner_id": "XXXXXXX",
  "rwg_token": "AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==",
  "merchant_changed": "2"
}

Im folgenden Beispiel wird das Conversion-Tracking auf Geräteebene mit einem Cookie auf dem Gerät des Nutzers in JavaScript beschrieben:

const partnerId = XXXXXXXXXX;
const endpoint = `https://www.google.com/maps/conversion/collect`;

// Retrieve the value of the rwgToken stored in the browser's cookie
const match = document.cookie.match(new RegExp('(?:^| )_rwgToken=([^;]+)'));
const storedRwgToken = match ? match[1] : undefined;

// Send Conversion event with decoded token, verify any special characters
// are sent properly.
if (storedRwgToken !== undefined) {
  fetch(endpoint, {
    method: "POST",
    body: JSON.stringify({
      conversion_partner_id: partnerId,
      rwg_token: decodeURIComponent(storedRwgToken),
      merchant_changed: merchantChanged
    })
  });
}

Achtung: Der einzige akzeptierte MIME Content-Type ist text/plain. Legen Sie keine anderen Content-Type im Header fest, da dies zu einem CORS-Fehler führt.

Warnung:Prüfen Sie, ob im Rahmen der Conversion-Daten keine personenbezogenen Daten an Google gesendet werden.

Hinweis:In der Produktion dürfen Sie keine Conversion-Ereignisse senden, die nicht dieser Integration zugeordnet sind. Es empfiehlt sich, vor dem Senden des Ereignisses zu prüfen, ob ein gültiger und nicht abgelaufener rwg_token-Wert vorhanden ist.

Händleränderungswert zurückgeben

Mit dem Wert merchant_changed wird ermittelt, ob sich der Händler vom ursprünglichen Weiterleitungshändler unterscheidet. Ein Händlerwechsel ist üblich, wenn sich Ihre Landingpage auf einer Plattform befindet, auf der auch andere Händler vertreten sind. Wenn ein Nutzer in diesem Fall von Google auf Ihre Plattform weitergeleitet wird und sich entscheidet, zu einem anderen Händler zu wechseln, um eine Buchung abzuschließen, müssen Sie wissen, dass eine Conversion bei einem anderen Händler stattgefunden hat. Sie können einen booleschen Wert verwenden, um die Händleränderung zu identifizieren, aber nicht die Händlerdetails.

Wenn Sie entscheiden, welchen Wert Sie merchant_changed zuweisen, müssen Sie den ursprünglichen Händler berücksichtigen, der in Parse and Store the Merchant Information gespeichert ist. Prüfen Sie, ob sich der Händler geändert hat, und weisen Sie den Wert entsprechend Ihren Anforderungen zu.

• Voraussetzung: Ein Nutzer verlässt die Website des ursprünglichen Händlers und schließt einen Kauf über Ihre Plattform bei einem anderen Händler ab.
  • Wert der Händleränderung: 1
• Voraussetzung: Der Nutzer schließt eine Transaktion über den ursprünglichen Händler ab.
  • Wert der Händleränderung: 2

Hinweis :Wenn sich Ihre Buchungsseite nicht auf einer Plattform befindet oder Nutzer nicht zu einem anderen Händler wechseln können, können Sie den Wert dieser Anfragen auf 2 fest codieren. Das ist häufig bei Partnern der Fall, die ihre Buchungsseiten in die Website des Händlers einbinden oder benutzerdefinierte Landingpages für die Verarbeitung einer Buchung haben.

Conversion-Tracking testen und überprüfen

In den folgenden Testläufen werden Test-Tokens verwendet, die im Abschnitt Test-Tokens bereitgestellt werden. Sie sollen Ihnen helfen, alle verschiedenen Szenarien durchzugehen, die zu einem Conversion-Ereignis führen können. So wird sichergestellt, dass das Token richtig gespeichert, der merchant_changed-Wert korrekt festgelegt und das Conversion-Ereignis bei Bedarf gesendet wird.

Verwenden Sie die in Ihren Feeds angegebenen Aktionslink- oder Buchungsseite-URLs und führen Sie jeden Testlauf aus, indem Sie die Test-Tokens an das Ende der URL anhängen. Verwenden Sie ein privates Browserfenster oder ein Inkognitofenster, um alle vorhandenen Tokens zu löschen, die mit dem aktuellen Nutzer verknüpft sind.

Testlauf	Testbeschreibung	User Flow	Erwartetes Ergebnis
1	Ein Nutzer schließt eine Buchung ab, die nicht über Google erfolgt ist.	Ein Nutzer ruft die Buchungsseite direkt auf, ohne von Google weitergeleitet zu werden oder ohne dass ein Verweis vorhanden ist. Dadurch sollte kein Conversion-Ereignis ausgelöst werden.	Kein Conversion-Ereignis, da der Nutzer die Buchungsseite nicht zuvor besucht hat oder nicht von Google weitergeleitet wurde.
2	Ein Nutzer schließt eine Buchung ab, die über Google initiiert wurde.	Ein Nutzer findet Ihren Händler über Google, wird auf Ihre Buchungsseite weitergeleitet und schließt eine Buchung ab.	Ein Conversion-Ereignis wird gesendet mit Token A und dem Wert 2 für merchant changed, da der Nutzer von Google zur Buchungsseite weitergeleitet wurde.
3	Ein Nutzer (von Google) beginnt den Buchungsvorgang, bricht die Sitzung jedoch ab, bevor eine Buchung abgeschlossen wird. Hinweis: Lassen Sie diese Sitzung für Test 4 und 5 geöffnet.	Ein Nutzer wird auf Ihre Reservierungsseite weitergeleitet, die Sitzung wird jedoch beendet, bevor er eine Reservierung abschließt.	Keine Conversion, da der Nutzer keine Buchung abgeschlossen hat, aber Token B sollte 30 Tage lang gespeichert werden.
4	Ein Nutzer kehrt zur Buchungsseite zurück, ohne von Google zu kommen, und schließt eine Buchung ab. Hinweis: Die URL des Buchungsvorgangs darf kein „rwg_token“ enthalten.	Ein Nutzer kehrt nach Test 4 zur Buchungsseite zurück. Token B sollte 30 Tage lang gespeichert werden. Bei jeder Conversion innerhalb dieser 30 Tage sollte ein Conversion-Ereignis zurückgegeben werden.	Ein Conversion-Ereignis wird gesendet mit Token B und dem Wert 2 für merchant changed, da der Nutzer nach einer früheren Weiterleitung von Google zur Buchungsseite zurückkehrt.
5	Ein Nutzer schließt nach Test 4 eine neue Buchung ab, die von Google stammt.	Wenn ein Nutzer nach einer vorherigen Google-Weiterleitung über eine Google-Weiterleitung zu Ihrer Buchungsseite zurückkehrt, wird der 30‑Tage-Speicherzeitraum zurückgesetzt und ein neues Token Token C ersetzt das alte Token Token B. Alle zukünftigen Conversions werden dann Token C zugeordnet.	Ein Conversion-Ereignis wird gesendet mit Token C und dem Wert 2 für merchant changed, da der Nutzer die Buchung abgeschlossen hat und das neue Token das zuvor gespeicherte Token ersetzt hat.

Wenn Sie eine Plattform haben, auf der Nutzer bei einem anderen Händler bezahlen können, testen Sie Folgendes.

Wichtig :Wie im Abschnitt Return the Merchant Change Value beschrieben, können Sie den Wert dieser Anfragen auf 2 fest codieren, wenn Ihre Buchungsseiten oder Aktionslinks keine Möglichkeit für Nutzer bieten, den Händler zu wechseln. Das ist häufig bei Partnern der Fall, die ihre Buchungsseiten in die Website des Händlers einbinden oder benutzerdefinierte Landingpages für die Verarbeitung einer Buchung haben. Wenn Sie einer dieser Partner sind, können Sie die folgenden Testläufe überspringen.

Testlauf	Testbeschreibung	User Flow	Erwartetes Ergebnis
6	Ein Nutzer wird von Google auf Ihre Buchungsseite weitergeleitet und schließt eine Buchung bei einem anderen Händler ab.	Ein Nutzer wird von Google auf Ihre Buchungsseite weitergeleitet. Dabei wird Token A verwendet. Bevor er eine Buchung abschließt, ruft er jedoch eine andere Seite auf und schließt die Buchung bei einem Händler ab, der sich von dem ursprünglichen Verweis unterscheidet.	Ein Conversion-Ereignis wird gesendet, weil der Nutzer eine Buchung abgeschlossen hat, die auf einer Empfehlung von Google mit Token A basiert, und der Wert merchant changed (Händler geändert) ist 1, weil der Nutzer die Buchung bei einem anderen Händler als dem der Empfehlung abgeschlossen hat.

Senden Sie während des Tests die HTTP-POST-Anfrage an den Conversion-Endpunkt. Es gibt zwei Endpunkte:

• Produktionsumgebung: https://www.google.com/maps/conversion/collect
• Sandbox-Umgebung: https://www.google.com/maps/conversion/debug/collect

Test-Tokens

Wenn Sie das Conversion-Tracking testen möchten, fügen Sie eines der folgenden Test-Tokens am Ende der Aktionslinks oder Buchungsseite-URLs hinzu, die Sie in Ihren Feeds angeben.

Token A:

rwg_token=AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ%3D%3D

Token B:

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

Token C:

rwg_token=AJKvS9VwInjZ_hGZPvBz0COVWJ5oFDzocFt9hGi7TMurlo2l71uiXP48PspPUMmRnqCUDE1mF_A5H_dMV78cBTF8jIfSQK6lEA%3D%3D

Wenn Sie die erfolgreichen Conversion-Ereignisse senden, werden sie im Action Center im Conversion-Tracking-Dashboard zusammengefasst.

Hinweis :Es kann bis zu einer Stunde dauern, bis Conversions im Dashboard angezeigt werden.

Anforderungen an die Conversion-Attribution

Der von Google geforderte Standard für die Conversion-Zuordnung ist ein 30-Tage-Attributionszeitraum für jede Interaktion mit einem Link für Ortsaktionen in einem beliebigen Geschäft.

Das bedeutet, dass Google in den folgenden Szenarien mit dem Senden eines Conversion-Ereignisses rechnen kann:

• Ein Nutzer folgt einem Link für eine Ortsaktion und gibt in derselben Sitzung eine Bestellung beim selben Händler auf. Händleränderungswert = 2.
• Ein Nutzer folgt einem Link für Ortsaktionen und kehrt dann innerhalb des 30-Tage-Attributionszeitraums über einen anderen Kanal zurück, um eine Bestellung für denselben Händler aufzugeben. Händleränderungswert = 2.
• Ein Nutzer folgt einem Link für eine Ortsaktion und gibt dann in einem anderen Geschäft eine Bestellung auf, entweder in derselben Sitzung oder in einer anderen Sitzung innerhalb eines 30-Tage-Attributionszeitraums. Händleränderungswert = 1.

Außerdem erwartet Google, dass Conversion-Ereignisse von jedem Gerät gesendet werden, auf das ein Nutzer über einen Place Actions-Link zugreifen kann. Dazu gehören:

• Webanwendungen für Computer oder Mobilgeräte.
• Mobile Apps über einen App-Deeplink oder einen registrierten App-Intent für Ihre Domain.

Wenn das Token auf Nutzerebene gespeichert wird, müssen Sie die geräteübergreifende Zuordnung bereitstellen. Weitere Informationen finden Sie unter Auf Nutzerebene speichern. In diesem Fall muss ein Nutzer, der einem Aktionslink auf dem Computer folgt und die Transaktion dann auf einem Mobilgerät mit demselben Nutzerkonto abschließt, ein Conversion-Ereignis auslösen.

Wenn das Token ausschließlich auf Geräteebene gespeichert wird, z. B. in Browser-Cookies, ist es nicht erforderlich, dass Sie die geräteübergreifende Zuordnung bereitstellen. In diesem Fall kann für jedes Gerät ein separates Token gespeichert werden, wenn der Nutzer auf diesem Gerät einem Aktionslink folgt. Außerdem können die Attributionsregeln für jedes Gerät separat angewendet werden.

Hinweis :Dieses Attributionsmodell kann sich von dem Ihres Analysesystems unterscheiden. Dieses System ist so konzipiert, dass es unabhängig von Ihrem Conversion-Tracking in Ihren Systemen funktioniert und Ihre internen Analysen nicht beeinträchtigen muss.