Die unterschiedlichen Reporting-Identity-Optionen in GA4: Vor- und Nachteile im Überblick

Erfahren Sie, welche Reporting-Identity-Option in Google Analytics 4 die richtige für Ihr Unternehmen ist. Blended, Observed oder Device-Based? Verstehen Sie die Vor- und Nachteile jeder Option und optimieren Sie das Verhaltens-Tracking Ihrer Nutzer:innen.

Reporting Identity in GA4

Die Reporting Identity basiert auf verschiedenen IDs und Signalen wie User ID, Google Signals und Device ID oder auch auf modellierten Daten. In GA4 stehen drei verschiedene Reporting-Identity-Optionen zur Verfügung: Blended, Observed und Device-Based. Jede Option hat ihre Vor- und Nachteile, die wir im Folgenden genauer betrachten.

Reporting Identity in GA4 Show All, Quelle: Google

Klicke auf ‘Show all’/’Alle anzeigen’, um alle Reporting Identity Optionen angezeigt zu bekommen.

Reporting Identity Blended, Quelle: Google

Blended Reporting Identity

Die Blended-Reporting-Identity versucht, die verschiedenen IDs zu verknüpfen, um eine umfassende Ansicht des Nutzer:innenverhaltens über Geräte und Plattformen hinweg zu erstellen. Dabei werden mehrere Identifizierungsmerkmale wie User ID, Google Signals, Device ID und Modeled Data verwendet.

Blended Reporting Identity, Quelle: Google

Als Basis ermöglicht die Verwendung der User ID eine eindeutige Identifizierung von Nutzer:innen, beispielsweise durch eine verhashte Kund:innennummer beim Login. Kann die User ID nicht genutzt werden oder ist nicht implementiert, erkennt Google Signals Nutzer:innen, die mit ihrem Google-Konto eingeloggt sind und personalisierte Werbung aktiviert haben, solange die Property genügend Aktivität von angemeldeten Nutzer:innen aufweist. Ergänzend ist die Device ID eine anonyme ID, die das Gerät und den benutzten Browser eindeutig identifiziert, wenn User-ID und Google Signals bei den Nutzer:innen nicht angewandt werden können. Letztendlich bei fehlender Zustimmung (Consent) und nicht möglicher Kennung der Nutzer:innen greift GA4 auf Machine Learning mittels der Holdback-Validierung zurück, um das Nutzer:innenverhalten zu ermitteln.

Die Holdback-Validierung vergleicht geschätzte Nutzer:innendaten mit einem Teil der erfassten Daten, die beim Trainieren der Modelle nicht berücksichtigt wurden. Dadurch werden die Modelle optimiert und die Datenpräzision verbessert. Verhaltensmodellierung wird jedoch nur mit ausreichend qualitativen Daten von Nutzer:innen durchgeführt, die ihre Einwilligung erteilt haben, und braucht daher den implementierten Consent Mode.

Vor- und Nachteile der Blended Reporting Identity

Die Blended-Reporting-Identity bietet eine umfassende Sicht auf das Verhalten der Nutzer:innen über Geräte und Plattformen hinweg. Dies ermöglicht eine genauere Identifikation von Trends und Mustern sowie ein besseres Verständnis der User Journeys.

Jedoch erfordert diese Option die Aktivierung der User-ID. Dabei sollte darauf geachtet werden, dass keine persönlich identifizierbaren Informationen (PII), wie zum Beispiel Name, Telefonnummer oder Adresse, getrackt wird. Zusätzlich muss die Nutzung dieser Identifizierung auf der Webseite für die Nutzer:innen transparent kommuniziert werden.

Google Signals, benötigt den Google Login und die Zustimmung zur personalisierten Werbung, um optimal angewandt werden zu können. Hierbei kann es zu Problemen mit der Datenpräzision kommen; beispielsweise werden Alter und Geschlecht der Nutzer:innen, die personalisiertem Advertising nicht zugestimmt haben, die nicht in ihren Google Konten eingeloggt sind oder auch gar kein Google Konto haben, nicht getrackt und stattdessen als ‘unknown’ übergeben. Außerdem werden Daten von weniger als ca. 50 Nutzer:innen nicht im Report angezeigt, um die Anonymität der Nutzer:innen zu wahren, auch bekannt als Thresholding.

Ein weiterer Nachteil ist, dass bei der Blended-Reporting-Identity modellierte Daten erst herangezogen werden, wenn Consent Mode implementiert ist. Außerdem muss das Minimum von 1000 Nutzer:innen erreicht werden, die das Event anayltics_storage = ‘granted’ in mindestens 7 von den letzten 28 Tagen ausgelöst haben.

Observed Reporting Identity

Die Observed-Reporting-Identity verwendet ebenfalls verschiedene Signale wie User ID, Google Signals und Device ID, jedoch ohne Modeled Data. Demnach wird hierbei auf tatsächliche Nutzer:innendaten mit Zustimmung (Consent) zurückgegriffen, ohne jegliche Modellierung.

Observed Reporting Identity, Quelle: Google

Wie bereits bei der Blended Reporting Identity erläutert, ermöglicht die Verwendung der User ID eine eindeutige Identifizierung von Nutzer:innen, während Google Signals Nutzer:innen erkennt, die mit ihrem Google-Konto eingeloggt sind und personalisierte Werbung aktiviert haben. Die Device ID identifiziert das Gerät und den benutzten Browser.

Vor- und Nachteile der Observed Reporting Identity

Die Observed-Reporting-Identity bietet einen genaueren Blick auf das Nutzer:innenverhalten im Vergleich zum Blended Reporting. Durch die Verwendung tatsächlicher Daten der Nutzer:innen mit Zustimmung wird ein klareres Verständnis von Customer Journeys und Touchpoints ermöglicht. Jedoch erfordert diese Option auch die Aktivierung von Google Signals, Google Login und die Zustimmung zur personalisierten Werbung.

Es ist wichtig zu beachten, dass nicht alle Nutzer:innen personalisierten Anzeigen zustimmen, was die Genauigkeit des beobachteten Reportings einschränkt. Modellierte Daten werden bei dieser Option nicht berücksichtigt. Auch hier muss die Property genügend Aktivität von angemeldeten Nutzer:innen aufweisen, um ihre Identität angemessen zu anonymisieren.

Device-Based Reporting Identity

Die Device-Based-Reporting-Identity verwendet eine einzelne Device-ID zur Verfolgung des Nutzer:innenverhaltens. Wenn ein:e Nutzer:in eine Website oder App auf einem Gerät besucht, weist Google Analytics diesem/dieser Nutzer:in eine Client-ID zu. Diese Client-ID bleibt gleich, solange der/die Nutzer:in dasselbe Gerät und denselben Browser verwendet. Damit gleichen die Daten der User:innen bei der Auswahl der Device-Based Reporting Identity am ehesten den Daten in Universal Analytics.

Device Based Reporting Identity, Quelle: Google

Vor- und Nachteiler der Device-Based Reporting Identity

Diese Option ist nützlich, um das Nutzer:innenverhalten auf einem einzelnen Gerät zu verfolgen. Sie bietet jedoch keine vollständige Ansicht des Verhaltens über Geräte und Plattformen hinweg. Es wird 1:1 das reportet, was auch getrackt wird, ohne Deduplizierung und Thresholding. Thresholding kommt hier nicht zum Einsatz, es werden immer alle Daten angezeigt. Die Identität der Nutzer:innen ist geschützt, da Cross-Device Tracking nicht möglich ist.

Allerdings ist die Device-Based Reporting Identity beschränkt auf ein einziges Gerät, was zu einer unvollständigen Sicht auf das Nutzer:innenverhalten und Touchpoints führen kann. Auch die Genauigkeit der Attribution über Geräte hinweg ist eingeschränkt. Nutzer:innen werden nicht mit Google Signals oder User ID erkannt, was zu unpräzisen Nutzer:innenzahlen führen kann. Zudem wird die Identität der Nutzer:innen nicht dedupliziert.

Fazit:

Abschließend kann gesagt werden, dass die Wahl der richtigen Reporting-Identity-Option in GA4 von verschiedenen Faktoren abhängt. Es ist wichtig, die Vor- und Nachteile jeder Option sowie die spezifischen Voraussetzungen zu berücksichtigen. Nur so kann eine optimale Analyse des Verhaltens der Nutzer:innen und eine genaue Attribution gewährleistet werden.

Die unterschiedlichen Reporting-Identity-Optionen in GA4: Vor- und Nachteile im Überblick

Management Summary

Reporting Identity in GA4

Blended Reporting Identity

Vor- und Nachteile der Blended Reporting Identity

Observed Reporting Identity

Vor- und Nachteile der Observed Reporting Identity

Device-Based Reporting Identity

Vor- und Nachteiler der Device-Based Reporting Identity

Fazit:

Haben Sie noch Fragen oder wollen Sie selbst mit der Implementierung beginnen? Wir stehen Ihnen jederzeit zur Verfügung unter: kontakt@e-dialog.at

Weitere Themen

Key Events – neue Nomenklatur in Google Analytics 4

sGTM & Telefontracking – Übergabe der First Person ID (FPID) an Matelso

Bot Traffic in GA4

Scheduled Emails – Jetzt auch für GA4 Reports

Realtime Reports: Mit dem Echtzeit-Bericht Analytics Interesse wecken

Attribution: Tipps für den Model Comparison Report in GA4

Visualisierung von benutzerdefinierten Events: Ein Leitfaden für aussagekräftige Reports

Debugging Server Side Google Tag Manager

UA zu GA4: So gelingt die Migration in Looker Studio Dashboards

Überprüfung des Consent Mode in Google Analytics 4

GA4 Predictive Metrics: Erfolg durch den Blick in die Zukunft

Conversion Zählmethoden in GA4 – was ändert sich für Reportings?

Consent Mode für Google Ads, Google Marketing Platform & GA4 – was ist zu tun?

Sunset von Google Universal Analytics ab Juli 2023