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:
Inhalt
- 1 Was ist das Google Analytics Measurement Protocol?
- 2 Kaufmöglichkeiten im B2B-Bereich
- 3 Die vollständige Customer Journey: Das Konzept
- 4 Umsetzung: So funktioniert das Measurement Protocol
- 5 Ergebnisse: Analysen in Google Analytics 4
- 6 Ergebnisse in Google Ads
- 7 Zusammenfassung
- 8 FAQs
- 9 Deine Frage noch nicht beantwortet?
- 10 Folien SMX 2023
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
- 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.
❌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:
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:
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:
Screenshot: Die Hybride Customer Journey – online und offline
Damit wird zwar der Kauf in Google Analytics erfasst – wir haben allerdings zwei User Journeys:
- Die Online Journey mit der Information, dass Paid Search ein Formular-Submit ausgelöst hat.
- 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:
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:
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:
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:
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:
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:
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:
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?
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
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:
Screenshot: GA4 Event Builder
Hier können alle Event-Parameter entsprechend eingetragen und anschließend auf “Validate Event” geklickt werden:
Screenshot: Validate Measurement Protocol Request
Wichtig: Für die Validierung muss gtag.js (nicht firebase!) ausgewählt werden:
Screenshot: Auswahl gtag
Ist das Event gültig, erhältst du folgende Information:
Screenshot: Measurement Protocol Request is valid
Ist das Event ungültig, erhältst du folgende Information inkl. Empfehlung zur Optimierung:
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:
Screenshot: Google Analytics 4 Custom Report
Erstelle dazu einen neuen, leeren Bericht:
- Typ: Freies Format
- Dimension: affiliation
- Metrik: Transaktionen
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
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:
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:
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:
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:
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:
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:
- Mehr Daten in den Marketingtools – für Analyse; für Anzeigenoptimierung.
- 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:
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