Praxishandbuch Measurement Protocol: Offline-Käufe für Analysen (GA4) und Targeting (Google Ads) nutzen26 min Lesezeit

Michaela Linhart 2 Comments

Speziell im B2B-Bereich erfolgen die wenigsten Käufe online über den Onlineshop – häufig sogar weniger als 30%.

Gekauft wird offline – via Email, Telefon oder Anfrage-Formular auf der Website. Hauptsache persönlich.

Der Nachteil: 70% des Umsatzes landen nicht in den Marketing-Tools wie Google Ads und Facebook – und auch nicht in Google Analytics.

Man kann zwar Google Ads schalten – aber ob die Anzeigen konvertieren, weiß man nicht, weil es sind nur 30% der Daten verfügbar.

Mit 30% an Daten macht es auch wenig Sinn auf Kauf oder ROAS zu optimieren.

Und mit den neuen Performance MAX Kampagnen ist die geringe Datenmenge nochmal dramatischer geworden, weil der Algorithmus braucht viele Daten um „gscheit“ arbeiten zu können. Wir haben aber nur 30%.

So oder oder so ähnlich geht es vermutlich jedem B2B-Unternehmen – egal ob die Verteilung 30:70, 20:80 oder 50:50 ist.

Der Gap ist eklatant.

Es benötigt also eine Möglichkeit, auch offline Daten in Google Analytics zu erfassen, um ein genaueres Abbild der Realität zu bekommen und sinnvolle Marketingmaßnahmen abzuleiten.

Genau dafür bietet Google Analytics das Measurement Protocol:

Was ist das Google Analytics Measurement Protocol?

Das Measurement Protocol wurde 2011 und mit dem Start von Universal Analytics (GA3) eingeführt.

Die Idee: Measure everything!

Tatsächlich können mit dem Measurement Protocol, Daten aus j-e-d-e-m erdenklichen System an Google Analytics gesendet werden:

  • Käufe vom Point of Sale
  • Kundendaten aus dem CRM, ERP, DWH und jeder anderen Datenbank
  • Käufe aus dem Backend System

Mit dem Measurement Protocol kann sogar die Kaffeemaschine vertrackt werden, um den Kaffeekonsum☕ messbar zu machen. Das ist vielleicht nicht die sinnvollste Anwendung, aber eine lustige Fingerübung, die wir 2014 auf Agentur-Seite gemacht haben, um uns in das Measurement Protocol einzuarbeiten. >> Use Case: Coffee Tracker.

Ein anderer Use Case ist das Tracking eines Messebesuchs um folgende Fragen messbar zu machen:

  • Wie viele Verkaufsgespräche wurden geführt?
  • Wie viele kalte Leads wurden generiert z.B. via Glücksrad?
  • Wie viele warme Leads wurden generiert z.B. via Email Adresse?

>> Details im Blogartikel: Google Analytics – Offline Tracking mit Amazon Dash-Buttons

Weitere Möglichkeiten sind das Tracking via WLAN-Sensoren, via NFC, Bilderkennung oder einfachen Lichtschranken…

Die Ideen sind (fast) grenzenlos.

Mit Universal Analytics hat Google das reine Web- und App-Tracking hinter sich gelassen und hat mit dem Measurement Protocol seine Plattform für jegliche Formen von Informations-Tracking und Analyse geöffnet.

Das Ziel: Den User oder Kunden an ALLEN Touchpoints der Customer Journey zu erfassen – auch und ganz speziell offline.

Zurück zu unserem B2B Use-Case: Welche Touchpoints gibt es hier eigentlich?

Kaufmöglichkeiten im B2B-Bereich

Die Kaufmöglichkeiten im B2B-Bereich sind vielfältig: Email, Telefon, Ladengeschäfte, Händler, Onlineshop…

All diese Touchpoints lassen sich auf drei (!) Kaufmöglichkeiten zusammenfassen:

  • online
    • Onlineshop
  • offline
    • Email
    • Telefon
    • PoS
  • hybrid: online gestartet, offline beendet

Der Klassiker: Online-Käufe

Online ist der Klassiker im B2C-Bereich.

Es gibt einen Onlineshop und in diesem können Produkte gemütlich durchbrowst und gekauft werden – ähnlich wie bei Zalando, Amazon & Co.

Für das Tracking im Onlineshops wird im besten Fall der Google Tag Manager und spezielle Ecommerce dataLayer-Codes eingesetzt.

>>Alle Details für das Tracking im Onlineshop findest du hier: Ecommerce in GA4: Alles was Marketer wissen müssen um mega Insights zu generieren.

Google Tag Manager - Das umfassende Handbuch

❌Offline Käufe

Offline ist der Klassiker im B2B-Bereich: Ein User bestellt per Email oder Telefon.

Das interessiert uns im Marketing allerdings am Wenigsten.

User, die bspw. über Telefon bestellen, können wir KEINE online Sitzung zuordnen. Wir wissen nicht, ob sie davor auf der Website waren oder den Kontakt über Empfehlungen bekommen haben.

Wir haben keinen online Touchpoint, den wir zuordnen könnten – somit können wir im Marketing auch nichts mit diesen Usern anfangen. Wir können sie in Google Analytics nicht sinnvoll analysieren. Wir können sie in Google Ads & Co nicht retargeten.

Wir können maximal die Emailadresse und Telefonnummer für Enhanced Conversions in Google Ads bzw. Advanced Matching in Facebook hochladen, um ein genaueres Performance-Bild in den jeweiligen Marketingkanälen zu erhalten – natürlich nur mit Consent🍪.

Mehr geht jedoch leider nicht.

Hybrid – das große Potential

Bleiben noch die “hybriden User”: Jene die ihren Kaufprozess online starten und offline beenden.

Diese User interessieren uns im Marketing ganz besonders.

Im folgenden erkläre ich warum:

Die vollständige Customer Journey: Das Konzept

Ein User kommt über einen externen Kanal (Google Ads, Google Organic, Email, etc.) auf deinen Webshop.

Er macht, was auch immer dein B2B-Shop bietet bzw. eine Produktkonfiguration.

Anstatt jedoch online zu kaufen, schickt der User eine Anfrage über das Customer Support Formular, weil er bspw. spezifische Rückfragen zu seiner Produktkonfiguration hat.

Das Formular ist abgeschickt – die Online-Journey des Users beendet:

Online Journey

Screenshot: Online Journey

Das Formular-Submit wird im besten Fall noch als Conversion in Google Ads und Google Analytics getrackt ABER nicht jede Anfrage wird zur Bestellung.

Das Formular-Submit ist tatsächlich super ungenau. Es ist maximal eine MICRO-Conversion.

Wie geht es offline weiter?

Die Anfrage kommt in das interne Backend-System bspw. das CRM.

Ein Mitarbeiter empfängt die Anfrage und bearbeitet diese offline, erstellt ein Angebot, klärt Rückfragen per Email und Telefon.

Schließlich kauft der Kunde und der Mitarbeiter markiert die Anfrage im Backend-System als “gekauft”. Das bekommen wir online allerdings NICHT mit:

Offline Journey

Screenshot: Offline Journey

Zumindest nicht einfach so.

Aber es gibt ja Googles Measurement Protocol mit dem exakt an dieser Stelle – beim Kauf – die offline Conversion an Google Analytics übermittelt werden kann:

Die Hybride Customer Journey - online und offline

Screenshot: Die Hybride Customer Journey – online und offline

Damit wird zwar der Kauf in Google Analytics erfasst – wir haben allerdings zwei User Journeys:

  1. Die Online Journey mit der Information, dass Paid Search ein Formular-Submit ausgelöst hat.
  2. Die Offline Journey mit dem Kauf.

Das Ziel ist jedoch EINE User Journey, d.h. offline und online miteinander zu verknüpfen, sodass die Customer Journey vollständig in Google Analytics abgebildet wird.

Auch das geht mit dem Measurement Protocol, indem zum Formular die Identifier des Online-Users gespeichert werden:

Vollständige Customer Journey in Google Analytics

Screenshot: Vollständige Customer Journey in Google Analytics

Die Online-Identifier des Users sind:

  • Client ID = Google Analytics Cookie
  • Google Click ID = Google Ads Cookie
  • (optional) UserID

Hinweis: Eine UserID ist nicht erforderlich aber empfehlenswert, da wenn aus irgendwelchen Gründen die Google Cookies nicht mehr verfügbar sind, die offline Bestellung immer noch dem User und somit seinem initialen Kanal zugeordnet werden kann.

Was ist eine UserID? Eine eindeutige Identifizierung des Users bspw. die Email-Adresse, die jedoch nur verhasht an Google Analytics übermittelt werden darf. Achtung: PII!

Nur mit diesen IDs, die mit der Formularanfrage im CRM gespeichert UND mit der offline Bestellung an die Google Tools gesendet wird, kann online und offline zusammengeführt und DAMIT die Customer Journey vervollständigt werden.

Das ist das Szenario.

Das ist das Konzept.

Hinweis: Natürlich funktioniert jedes B2B-Unternehmen ein wenig anders. Möglicherweise gibt es bei dir zwei oder mehr Backend-Systeme. Möglicherweise gibt es mehrere relevante Informationen als nur den Kauf wie bspw. Änderungen der Transaktion, Stornos, Refunds, etc.

Ich empfehle die Erstellung eines spezifischen Konzeptes für deinen spezifischen Anwendungsfall.

Mit dem Konzept in der Hand, geht es direkt in die Umsetzung:

Umsetzung: So funktioniert das Measurement Protocol

Im Kern funktioniert das Measurement Protocol über eine simple HTTP-Anfrage, welche direkt an Google Analytics gesendet wird.

Welche Daten wir schicken, bleibt uns überlassen.

Wir wollen den offline Kauf an Google Analytics senden und dazu bietet Google Analytics das Ecommerce-Feature.

Das Ecommerce-Feature ist speziell für das Tracking im Onlineshop gedacht. Es bietet viele vordefinierte Ereignisse und Parameter, wie beispielsweise das purchase-Event:

Ecommerce Feature in GA4

Screenshot: Ecommerce Feature in GA4

Für das Tracking des Kaufs bzw. der Transaktion, wird im Onlineshop bei der Bestellung ein spezielles purchase-Event via dataLayer-Push an Google Analytics gesendet.

Exakt das selbe Event kann (bzw. soll!) auch für das offline Conversion Tracking genutzt werden – statt einem dataLayer-Push benötigt es allerdings einen HTTP-Request. Das purchase-Event ist dabei immer das Gleiche:

purchase online vs offline

Screenshot: purchase online vs offline

Wichtig: Das Measurement Protocol ergänzt das Web- und App-Tracking mit dem gtag. Das Ziel ist, dass ALLE Daten eines Unternehmens in den selben Datentopf getrackt werden. Erst dadurch kann das volle Potential ausgeschöpft werden.

Schauen wir uns den HTTP-Request im Detail an:

Der HTTP-Request

Für einen gültigen HTTP-Request verlangt das Measurement Protocol zwei Arten von Parametern:

  • URL-Parameter
  • JSON-Text

URL-Parameter

Die URL-Parameter beschreiben, wohin die Daten gesendet werden, d.h. an welche Google Analytics Property.

Erforderlich sind zwei URL-Parameter:

  • api_secret
  • measurement_id

api_secret

Das API Secret ist ein Sicherheitsmechanismus, den Google mit GA4 eingeführt hat und welches vor Spam schützen soll.

In Universal Analytics gab es kein API Secret: Jeder kann mit dem Measurement Protocol Daten an jede Google Analytics Property senden.

Das Problem: Spam-Traffic – und Spam-Traffic gab es tatsächlich zu Hauf im alten Universal.

Mit GA4 ist Google gescheiter geworden und hat einen API-Key eingeführt. Nur wer über diesen verfügt, darf Daten an die entsprechende Property senden.

Das API Secret findest du in der GA4 Verwaltung -> Datenstream → WEB Datenstrom → Ereignisse: Measurement Protocol – API-Secrets:

Hier kannst du rechts oben auf “Erstellen” klicken um ein neues API-Secret zu erstellen:

Google Analytics Measurement Protocol API Secret

Screenshto: Google Analytics Measurement Protocol API Secret

Wähle einen Alias z.B. Offline Conversions und klicke auf erstellen.

Du erhältst automatisch deinen Secret-Wert: sHKZa50vR-u2A_U2vkaOTg

Hinweis: Mein Secret-Wert ist nur ein Dummy, der zur Veranschaulichung dient.

Der zweite URL-Parameter ist die measurement_id:

measurement_id

Die Measurement ID bzw. Mess-ID oder G-ID ist deine GA4 Tracking-ID.

Sie ist deinem GA4 Datenstrom eindeutig zugeordnet.

Hinweis: In Universal Analytics war die Property-ID (UA-123123-1) die Mess-ID. In GA4 ist die Property-ID irrelevant. Stattdessen benötigst du die G-ID für das Tracking.

Du findest deine G-ID in der GA4 Verwaltung → Datenstreams → WEB Datenstrom:

GA4 Mess-ID

Screenshot: GA4 Mess-ID

Meine Mess-ID ist: G-94FGWQGFG0

Zusammengefasst

  • api_secret: sHKZa50vR-u2A_U2vkaOTg
  • measurement_id: G-94FGWQGFG0

JSON-Text

Der JSON-Text enthält die Daten, die an Google Analytics gesendet werden – in diesem Beispiel die Daten zum Kauf.

Hier sind ebenfalls zwei Parameter erforderlich:

  • client_id
  • events

Optional können beliebig weitere Parameter bzw. Informationen an Google Analytics übermittelt werden. Unbedingt empfehlenswert sind folgende:

  • user_id
  • gclid – für die Verknüpfung mit einer Google Anzeige
  • fbclid – für die Verknüpfung mit einer Facebook Anzeige

client_id

Um den Online-User mit der Offline-Conversion zu verknüpfen, benötigst du die client_id.

Die client_id ist das Google Analytics Cookie (_ga-Cookie), welche Google automatisch bei jeder Browser-basierten Sitzung in den Browser deines Users schreibt und für die Identifikation nutzt.

Besucht ein User bspw. heute deine Website mit dem Chrome-Browser und kommt morgen über denselben Browser wieder, erfasst Google Analytics den User als Wiederkehrer, da die client_id dieselbe ist.

Du kannst deine client_id auf deiner Website ansehen, indem du die Developer-Console öffnest und im Network-Stream „collect“ eingibst. Die client_id wird mit cid abgekürtz:

client_id Check in Google Chrome

Screenshot: client_id Check in Google Chrome

client_id-Beispiel: 1640099657.1629443530

Diese ID muss über die Website abgegriffen und zusätzlich zur bspw. Formular-Anfrage in deiner Datenbank gespeichert werden.

Nur dadurch kann der Offline-Kauf der Online-Sitzung zugeordnet und die Customer Journey vervollständigt werden – hier erfolgt die Magie.

events

Der events-Parameter im JSON-Body ist ein Array von Ereigniselementen.

GA4 nutzt ein Event-basiertes Datenmodell.

Somit können auch nur Events an Google Analytics 4 übermittelt werden, d.h. die relevanten Daten in Form eines Event-Namen wie bspw. purchase und verschiedener Event-Parameter wie bspw. der Artikelname, die Transaktions-ID usw.

Hinweis: Eine vollständige Liste aller verfügbaren Parameter findest du im Google Developer Guide.

Wir wollen das purchase-Event an Google Analytics senden, deswegen schauen wir uns im nächsten Schritt die Parameter dazu an.

Folgende Transaktionsparameter stehen zur Verfügung: 

  • currency (Pflicht!)
  • transaction_id (Pflicht!)
  • value = Umsatz
  • coupon
  • shipping
  • tax
  • affiliation
  • items (Array)

Diese sind dir vermutlich aus dem Onlineshop-Tracking bekannt – exakt dieselben Parameter stehen auch für das Offline-Conversion-Tracking zur Verfügung. Das Ecommerce-Feature ist das selbe.

Folgende Produktparameter stehen zur Verfügung:

  • item_id (Pflicht!)
  • item_name
  • affiliation
  • coupon
  • discount
  • item_brand
  • item_category
  • item_category2
  • item_category3
  • item_category4
  • item_category5
  • item_variant
  • location_id
  • price
  • currency (Pflicht!)
  • quantity

Diese sind dir vermutlich aus dem Onlineshop-Tracking bekannt – exakt dieselben Parameter stehen auch für das Offline-Conversion-Tracking zur Verfügung. Das Ecommerce-Feature ist das selbe.

Wichtig: Um in Google Analytics zwischen online- und offline-Conversion zu unterscheiden, empfehle ich die entsprechende Information in den affiliation-Parameter zu schreiben:

  • affiliation = offline
  • affiliation = online

Diese Parameter sollten von dir überprüft und nicht gebrauchte Parameter entfernt werden. Wenn du bspw. keine 5 Produktekategorien nutzt – weg damit. Die meisten Parameter sind optional einsetzbar und es ist empfehlenswert, nur jene zu befüllen, die es tatsächlich bei dir gibt.

Meine Empfehlung sind mindestens folgende Parameter: 

  • currency (Pflicht!)
  • transaction_id (Pflicht!)
  • value = Umsatz
  • coupon, falls verfügbar
  • discount, falls verfügbar
  • affiliation
  • item_id (Pflicht!)
  • item_name
  • item_brand
  • item_category
  • item_variant
  • price
  • quantity

user_id (optional aber empfohlen)

Optional kann auch eine user_id im Measurement Protokoll mitgeschickt werden.

Die UserID ist eine für jeden User eindeutige Nummer, welche den User eindeutig identifiziert.

In der Webanalyse hat sich durchgesetzt, dass dafür die SHA256-verhashte Email-Adresse des Users genutzt wird.

Wichtig: Es dürfen KEINE Personal Identifiable Information (PII) in Google Analytics gespeichert werden. Die Email Adresse ist eine PII und darf daher NUR verhasht an Google Analytics übermittelt werden.

>> Details zur UserID siehe Google Support Center.

Hinweis: Die user_id darf nur utf-8 Zeichen enthalten und maximal 256 Zeichen lang sein.

Das UserID-Feature in Google Analytics ist übrigens das Pendant zu den Enhanced Conversions in Google Ads bzw. Advanced Matching in Facebook.

gclid (optional)

Um die offline Transaktion einer Google Ads Anzeige zuordnen zu können, benötigt es die gclid = Google Klick ID.

Die gclid ist ein URL-Parameter, der mit dem Klick auf eine Google-Anzeige mitgeben wird, um den Klick und die Conversion der Kampagne zuzuordnen.

Die gclid steht im Google Ads Cookie (_gac-Cookie) und sieht wie folgt aus:

1.1638348242.CjwKCAiAv_KMBhAzEiwAs-rX1BJADZ4IH6jXiMxJmb_slJF8NeMZGwsCnOsu

Für uns ist nur die zufällig generierte ID nach 1.1638348242. wichtig: CjwKCAiAv_…

Kommt der User über eine Google Anzeige, soll diese ID von der Website abgegriffen und zusätzlich zur bspw. Formular-Anfrage in deiner Datenbank gespeichert werden. Nur dadurch kann der Offline-Kauf der Google Anzeige zugeordnet werden.

Wichtig: Die gclid sind nur verfügbar, wenn der User über eine Google-Anzeige auf die Website kommt.

Das selbe gilt auch für Facebook:

fbclid (optional)

Um die offline Transaktion einer Facebook Anzeige zuordnen zu können, benötigt es zwei Cookie-Informationen:

  • _fbp-Cookie = Facebook Pixel Client ID
  • _fbc-Cookie = Facebook Ad Click ID

Kommt der User über eine Facebook Anzeige, sollen diese Cookie-Informationen von der Website abgegriffen und zusätzlich zur bspw. Formular-Anfrage in deiner Datenbank gespeichert werden. Nur dadurch kann der Offline-Kauf der Facebook Anzeige zugeordnet werden.

Wichtig: Die Cookies sind nur verfügbar, wenn der User über eine Facebook-Anzeige auf die Website kommt.

Zusammengefasst

  • client_id: 1640099657.1629443530
  • events: […]
  • user_id: 7650ee89b55969a7b987f50b6203a96466359c62ac34db5775bae8b555bd0a61
  • gclid: CjwKCAiAv_KMBhAzEiwAs-rX1BJADZ4IH6jXiMxJmb_slJF8NeMZGwsCnOsu
  • fbp: 1596403881668.1116446470
  • fbc: 1554763741205.AbCdEfGhIjKlMnOpQrStUvWxYz1234567890

Aufbau des HTTP-Requests

Mit all diesen Informationen kann jetzt der Measurement Protocol HTTP-Request zusammengestellt werden.

Der Endpunkt enthält die Information, WOHIN die Daten gesendet werden.

Der JSON-Text ist der Payload des Requests.

Endpunkt

Das Measurement Protocol für GA4 unterstützt nur HTTP POST-Requests.

Der HTTP-POST Request muss an folgenden Endpunkt gesendet werden:

POST /mp/collect HTTP/1.1
HOST: www.google-analytics.com
Content-Type: application/json
<payload_data>

Im besten Fall wird der Request nicht direkt an Google Analytics übermittelt – sondern an den eigenen Tracking-Server. Dieser entscheidet wohin die Daten gesendet werden:

purchase offline via serverside tagging

Screenshot: purchase offline via serverside tagging

Der Host ist in dem Fall die eigene Tracking-Subdomain:

HOST: data.analyticskiste.blog

Eigener Tracking Server? 🤔 Alle Details dazu findest du hier:

>> Die Zukunft der Webanalyse trackt serverseitig – aber wie?

>> Serverseitiges Tracking Teil 2: Google’s Lösung

Die Vorteile des serverseitigen Tracking sind vielfältig: 

  • maximale Kontrolle
  • Vermeidung von Duplicate-Transactions
  • natives Google Ads Conversion Tracking der offline Transaktionen
  • Facebook Conversion Tracking der offline Transaktionen

Der für mich wichtigste Vorteil ist die Garantie für ein sauberes Tracking.

Eine Transaktion darf nur einmal – entweder offline oder online in den jeweiligen Tools landen, andernfalls wird eine höhere Anzahl an Transaktionen und mehr Umsatz erfasst, als in der Realität stattgefunden hat. Das verfälscht die Daten und ruiniert somit die Datenqualität.

Paypload

Der Payload sind die Daten die gesendet werden bestehend aus:

  • URL-Parameter und
  • JSON-Text

Beispiel Request

Der fertige Measurement Protocol Request um ein Transaktions-Ereignis zu senden, sieht beispielsweise wie folgt aus:

Wichtig: Das Beispiel ist in Javascript erstellt – es muss jedoch kein Javascript verwendet werden.

const measurementId = `G-94FGWQGFG0`;
const apiSecret = `sHKZa50vR-u2A_U2vkaOTg`;

fetch(`https://data.analyticskiste.blog/mp/collect?measurement_id=${measurementId}&api_secret=${apiSecret}`, {
method: "POST",
body: JSON.stringify({
 "client_id": "1640099657.1629443530",
 "user_id":
 "7650ee89b55969a7b987f50b6203a96466359c62ac34db5775bae8b555bd0a61",
 "events": [{
   "name": "purchase",
   "params": {
    "gclid": "CjwKCAiAv_KMBhAzEiwAs-rX1BJADZ4IH6jXiMxJmb_slJF8NeMZGwsCnOsu",
    "currency": "EUR",
    "transaction_id": "51225",
    "value": 677.59,
    "affiliation": "Offline",
    "coupon": "SUMMER08",
    "discount": 10.00",
    "items": [{
      "item_id": "34",
      "item_name": "Produkt Name",
      "item_brand": "Marke",
      "item_category": "Hauptkategorie",
      "price": 677.59,
      "quantity": 10000
   }]
  }
}]
})
});

Achtung: Beschränkungen

  • Requests dürfen max. 25 Ereignisse haben.
  • Ereignisse dürfen max. 25 Event-Parameter haben.
  • Ereignisse dürfen max. 25 User-Scoped Parameter haben.
  • Namen von User-Scoped Parameter dürfen max. 24 Zeichen lang sein.
  • Werte von User-Scoped Parameter dürfen max. 36 Zeichen umfassen.
  • Ereignisnamen dürfen max. 40 Zeichen lang sein und nur alphanumerische Zeichen und Unterstriche enthalten. Außerdem müssen sie mit einem Buchstaben beginnen.
  • Parameternamen (einschließlich „item“-Parameter) dürfen max. 40 Zeichen lang sein, dürfen nur alphanumerische Zeichen und Unterstriche enthalten und müssen mit einem Buchstaben beginnen.
  • Parameterwerte (einschließlich „item“-Parameter) dürfen max. 100 Zeichen lang sein.
  • Für „item“-Parameter sind max. zehn benutzerdefinierte Parameter zulässig.
  • Der Post-Text muss kleiner als 130 KB sein.

Wichtig – Stand März 2023: Da der affiliation-Parameter im Standard von GA4 noch nicht verfügbar ist, muss dieser zuerst in der Verwaltung → Benutzerdefinierte Definitionen → Benutzerdefinierte Dimensionen als Parameter registriert werden:

Custom Dimension affiliation in GA4

Custom Dimension affiliation in GA4

Noch wichtiger: Sobald der affiliation-Parameter im GA4-Standard zur Verfügung steht, muss dieser nicht extra registriert werden. Am Besten prüfst du vor dem Setup nach, ob der Parameter bereits verfügbar ist. Auf Deutsch heißt dieser vermutlich: Händler, Partner oder ähnliches.

Testing mit dem GA4 Event Validator

Vor dem Einbau des Measurement Protocols sollte der Request auf Gültigkeit getestet werden.

Dazu bietet Google Analytics den GA4 Event Validator:

GA4 Event Builder

Screenshot: GA4 Event Builder

Hier können alle Event-Parameter entsprechend eingetragen und anschließend auf “Validate Event” geklickt werden:

Validate Measurement Protocol Request

Screenshot: Validate Measurement Protocol Request

Wichtig: Für die Validierung muss gtag.js (nicht firebase!) ausgewählt werden:

Auswahl gtag

Screenshot: Auswahl gtag

Ist das Event gültig, erhältst du folgende Information:

Measurement Protocol Request is valid

Screenshot: Measurement Protocol Request is valid

Ist das Event ungültig, erhältst du folgende Information inkl. Empfehlung zur Optimierung:

Measurement Protocol Request is invalid

Screenshot: Measurement Protocol Request is invalid

Für ein noch einfacheres Debugging empfehle ich jedoch folgendes:

Testing mit dem Debug-Endpoint

Verwende https://www.google-analytics.com/debug/mp/collect?measurement_id… um deine URL zu testen.

Du erhältst eine noch detailliertere Fehlerbeschreibung als Antwort, welche dir mehr Informationen zur Fehlerbehebung liefert als der GA4 Event Validator.

>> Alle Details dazu findest du im Google Developer Guide.

Fertig getestet ist der Request bereit, an der entsprechenden Stelle im Backend-System implementiert zu werden. Anschließend fließen die Daten auch schon in Google Analytics ein: 🥁

Ergebnisse: Analysen in Google Analytics 4

Im ersten Schritt ist interessant, wie viele Transaktionen denn nun tatsächlich offline generiert wurden:

Anteil Online vs. Offline Käufe

Am Einfachsten erfolgt diese Analyse über einen Custom Report in der explorativen Datenanalyse von GA4:

Google Analytics 4 Custom Report

Screenshot: Google Analytics 4 Custom Report

Erstelle dazu einen neuen, leeren Bericht:

  • Typ: Freies Format
  • Dimension: affiliation
  • Metrik: Transaktionen
Analyse der offline Käufe in Google Analytics 4

Screenshot: Analyse der offline Käufe in Google Analytics 4

Wichtig – Stand März 2023: Da der affiliation-Parameter im Standard von GA4 noch nicht verfügbar ist, muss dieser zuerst in der Verwaltung → Benutzerdefinierte Definitionen → Benutzerdefinierte Dimensionen als Parameter registriert werden:

Custom Dimension affiliation in GA4

Custom Dimension affiliation in GA4

Noch wichtiger: Sobald der affiliation-Parameter im GA4-Standard zur Verfügung steht, muss dieser nicht extra registriert werden. Am Besten prüfst du vor dem Setup nach, ob der Parameter bereits verfügbar ist. Auf Deutsch heißt dieser vermutlich: Händler, Partner oder ähnliches.

Da der Prozentuale-Anteil derzeit noch nicht angezeigt wird, habe ich diesen händisch🧮 errechnet und dazu geschrieben…

Schauen wir auf die Daten:

  • 164 Transaktionen OFFLINE = 69%
  • 75 Transaktionen ONLINE = 31%
  • 239 in Summe

Und tatsächlich: Nur rund 30% der Käufe passiert online im Onlinshop. Mehr als 70% der User konvertieren offline – via Email, Telefon & Co. 😱
Kanal-Analysen

Dank der offline Conversions stehen uns somit DREIMAL mehr Daten zum Kauf zur Verfügung – das ist extrem viel.

Kanal-Analyse offline Conversions

Die reine Anzahl an offline Conversions ist zwar schon interessant aber das Ziel ist ja, offline und online zu verknüpfen und zu sehen, über welche Online-Kanäle diese 164 offline Käufe zustande gekommen sind.

Hole dir dazu die Dimension „Sitzung – Standard-Channelgruppierung“ in den Custom Report und filtere auf affiliation = offline:

Kanalanalyse der offline Transaktionen

Screenshot: Kanalanalyse der offline Transaktionen

Der Direct-Anteil ist mit 55% am Höchsten.

Direct, dass können direkte Zugriffe sein, bspw. wenn sich Bestandskunden die Website bookmarken um schneller nachbestellen zu können.

Im Direct-Kanal verstecken sich aber derzeit auch die REINEN offline Käufer. Jene Käufer, die angerufen oder eine Email versendet – jedenfalls keine Online-Interaktion hatten.

Erst mit der Online-Interaktion, wenn zum Formular-Submit die client_id des Users gespeichert und mit der offline Bestellung die client_id wieder an Google Analytics gesendet wird, erfolgt die Kanal-Zuordnung.

Ohne Formularanfrage, keine Kanal-Zuordnung.

Ohne Kanal-Zuordnung, weißt Google die Transaktion dem direkten Kanal zu.

Tipp: Später, wenn in GA4 wieder eigene Kanäle definiert werden können – das geht aktuell leider noch nicht – dann würde ich einen eigenen OFFLINE-KANAL erstellen, dann sieht man den Anteil “echte directs” und “offline” nochmal besser…

Der Paid-Search-Anteil ist mit 25% am zweit Höchsten.

Das ist ein beachtlicher Anteil, vor allem weil Google Analytics ALLE Känel in die Analyse einschließt, d.h. Multi-Channel attribuiert.

Exkurs: >> Multi-Channel: Kanalübergreifende Analysen und Budget-Ooptimierungen in Google Analytics

Betrachtet man den Google Ads-Kanal für sich, ist der Anteil vermutlich deutlich höher… to be analyzied

Gehen wir hier noch tiefer und vergleichen Paid Search online mit Paid Search offline:

Gegenüberstellung Paid Search online vs offline

Screenshot: Gegenüberstellung Paid Search online vs offline

Auf der linken Seite befinden sich die online Transaktionen: 27 Käufe

Auf der rechten Seite befinden sich die offline Transaktionen: 41 Käufe

Das sind mehr als DOPPELT so viele Transaktionen, die dem Paid Search Kanal zur Verfügung stehen – ein Plus von 60%.

Denn damit können die Google Ads Kampagnen endlich von CPC auf Kauf oder ROAS optimiert werden.

Die neuen Performance Max Kampagnen werden mit so viel mehr Daten durch die Decke gehen…

Das ist der Hammer! 🔨

Es kann aber sogar noch tiefer analysiert werden:

Welche Kampagnen waren die Conversion-Treiber?

Im nächsten Schritt kannst du dir die Dimension „Sitzung – Kampagne“ in den Custom Report dazu holen und analysieren, welche Kampagnen die Conversion-Treiber waren:

Conversion Treiber in Google Ads

Screenshot: Conversion Treiber in Google Ads für offline

Das Ergebnis ist eventuell nicht mega hübsch… hier musste ich ein paar Daten ausgrauen.

Es geht mehr darum die Analyse-Möglichkeiten und Insights, die offline Conversions generieren, herzuzeigen – sogar bis tief runter auf Kampagnen-Ebene.

Und das waren nur die Custom Reports…

Offline-Käufe in GA4 Standardreports analysieren

Google Analytics bietet auch jede Menge Standardreports:

Standardreports in GA4

Screenshot: Standardreports in GA4

Das Geniale: Mit dem affiliation-Parameter kannst du nun ALLE diese Standardreports auf Offline-Käufer einschränken und somit noch tiefer in die Analyse einsteigen:

  • Welche Micro-Conversions lösen Offline-Käufer aus?
  • Was sind die demografischen Daten von Offline-Käufern?
  • Was sind die technischen Daten – Browser, Betriebssystem…
  • Welche Ereignisse lösen sie aus?
  • Welche PDFs werden runter geladen?
  • Welche Suchbe

Erstelle dazu einfach einen Vergleich bzw. einen Filter (Segment) und wende ihn auf deine Daten an.

Einen Vergleich kannst du in jedem GA4-Standardbericht über der Überschrift hinzufügen:

Vergleich in GA4 Standardreports erstellen

Screenshot: Vergleich in GA4 Standardreports erstellen

Als Dimension wähle den speziellen affiliation-Parameter.

Als Dimensionswert kannst du „offline“ oder „online“ auswählen.

Klick auf „ok“.

Der Vergleich wird angewendet und du kannst ALLE Standardreports durchklicken und analysieren, wie sich offline Käufer online verhalten.

Mega! 🤓

Ergebnisse in Google Ads

Da kann ich leider noch nicht so viel herzeigen. 😪

Die neuen Conversions sind aktuell noch auf sekundär eingestellt und haben keine Auswirkung auf die Anzeigenperformance. Wir sind einfach noch in der Testphase.

Im nächsten Schritt stellen wir die Conversions auf primär um und schauen was es tatsächlich bringt.

Wir erwarten uns aber eigentlich schon einen großen Erfolg.

Wir haben es ja in den Analysen gesehen: Die offline Conversions machen einen RIESEN Unterschied; da sind einfach viel, viel mehr Daten verfügbar als rein über Online und das wird sich sehr positiv auf die Anzeigenperformance auswirken – davon bin ich überzeugt.

Ergebnisse folgen (hoffentlich) bald.

Zusammenfassung

Speziell, wenn Käufe NICHT rein online stattfinden, wie bspw. im B2B-Bereich, macht es Sinn auch offline Conversions in Google Ads und Google Analytics zu erfassen, um die Realität richtiger abzubilden.

Google bietet dazu das grenzgeniale Google Analytics Measurement Protocol für eine Server-to-Server-Kommunikation.

Das Ergebnis:

  1. Mehr Daten in den Marketingtools – für Analyse; für Anzeigenoptimierung.
  2. Eine VOLLSTÄNDIGE Customer Journey – offline-to-online Verknüpfung.

In den offline Daten steckt also unheimlich viel Potential.

Die Conversions aber erst der Anfang.

Was sind die nächsten Schritte?

Zur offline Transaktion können viele weitere spannende Daten an die Google Tools gesendet werden.

Beispielsweise:

  • die Anzahl der Bestellungen
  • der Customer Lifetime Value
  • der Kundentyp z.B. Großkunde vs Reseller

Auch diese Daten schlummern im Backend und können über das Google Analytics Measurement Protocol in den Marketing-Tools verfügbar gemacht werden – für Analysen in Google Analytics 4; für Targeting in Google Ads.

> Beispiel: Praxishandbuch – Personalisierung auf Basis von Kundensegmenten mit Google Optimize (free)

Die Ideen sind auch hier (fast) grenzenlos. 🧡

FAQs

Ist das legal?

Genauso wie es im Onlineshop die Zustimmung für das Tracking benötigt, benötigst du auch die Zustimmung für das Offline-Conversion-Tracking.

Der User muss transparent über das Tracking und die Nutzung der Daten aufgeklärt werden und aktiv Zustimmung dafür geben.

Im besten Fall klärst du diese Frage aber direkt mit deinem Datenschutzbeauftragten.

Wie kompliziert ist das Setup?

Ich bezeichne das Offline-Conversion-Tracking gerne als Königsdisziplin in der Webanalyse.

Es ist nicht einfach – mit einem Konzept in der Hand allerdings machbar.

Vorab sollte jedoch geklärt werden, ob das Backend-System grundsätzlich Daten an andere Systeme senden kann (technische Machbarkeit) und darf (Datenschutz).

In große Systeme wie bspw. Salesforce können mit hoher Wahrscheinlichkeit keine Tracking Codes eingebaut werden. Man scheitert an der technischen Machbarkeit.

Ist jedoch die technische Machbarkeit gegeben und man stellt den Entwicklern ein gut durchdachtes Konzept inkl. Tracking-Codes zur Verfügung, geht der Einbau in der Regel relativ schnell.

Deine Frage noch nicht beantwortet?

Du hast eine Frage zum Offline-Conversion Tracking?

👉 Schreibe sie einfach in die Kommentare. Ich helfe, wo ich kann.

Happy Analyzing

Deine Michaela

Folien SMX 2023

Diesen Use Case habe ich auf der SMX München 2023 vorgestellt.

▶ Hier findest du die Folien meiner Präsentation:

  • Andreas sagt:

    Hi Michaela,

    danke für den tollen Beitrag. Eine Frage dazu: Du liest ja die client_id aus dem „_ga“-Cookie aus, oder? Habe ich da nicht wieder das Problem mit den Tracking-Preventions (7 Tage Laufzeit)? Gibt es wie bei der „gclid“ auch ein serverseitiges Pendant zum _ga-Cookie, welches die client-id enthält?

    Lg

    • Hallo Andreas,

      vielen Dank für deine spannende Frage.

      Wenn du eine serverseitige Implementierung für Google Analytics hast, wird das _ga-Cookie serverseitig gesetzt und profitiert von der verlängerten Cookielaufzeit. Für Google Analytics kannst du also auch bei einer serverseitigen Implementierung das _ga-Cookie auslesen.

      Wenn du Google Ads Conversions serverseitig trackst, heißt das Cookie FPGCLAW (und nicht mehr _gcl_aw). In dem Fall musst du dieses auslesen um von der verlängerten Cookielaufzeit zu profitieren.

      Ganz liebe Grüße
      Michaela