Google Analytics 4-Tags haben mehrere Konfigurationsoptionen, die sich auf die Sitzungs- und Nutzeridentität auswirken können. Wenn sie nicht richtig konfiguriert sind, können Besucherquellen nicht identifiziert oder kategorisiert werden und es kann zu anderen Problemen in Berichten kommen. Diese Probleme führen zu nicht zugewiesenen Zeilen in Channelgruppen in Berichten, Werten vom Typ „(nicht festgelegt)“ und einem unerwartet großen Anteil an Zugriffen, die als „direkt“ kategorisiert werden.
In Google Analytics 4-Berichten wird die Zeile „Nicht zugewiesen“ angezeigt, wenn die Besucherquelle in Analytics nicht kategorisiert werden kann. In Analytics werden Besucherquellen anhand fester Regeln in Channels kategorisiert. Der Channel „Organische Suche“ umfasst beispielsweise Zugriffe über alle Suchmaschinen. Kanäle sind in Channelgruppen organisiert. Wenn Sie die Standard-Channelgruppen verwenden, können Sie die spezifische Logik, mit der Zugriffe kategorisiert werden, in den Standard-Channeldefinitionen prüfen. Channelgruppen können auf Nutzer-, Sitzungs- oder Ereignisebene betrachtet werden.
Wenn eine Besucherquelle nicht der Definition eines der Channels in einer Channelgruppe entspricht, die Sie in einem Bericht sehen, wird sie als nicht zugewiesen angezeigt. Es gibt möglicherweise keine vordefinierte Regel, um eine Besucherquelle zu kategorisieren, wenn Ihre Zugriffe aus einer benutzerdefinierten Quelle oder einem benutzerdefinierten Medium stammen oder als „(nicht festgelegt)“ angezeigt wird, weil Informationen zu Sitzungen oder Nutzeridentitäten fehlen.
Best Practices für die Reihenfolge von Tag-Codes
Beachten Sie die folgenden Best Practices für die Reihenfolge von Tag-Codes:
Tag-Typ | Anleitung | Best Practices |
---|---|---|
Google-Tag |
Initialisieren Sie das Google-Tag, bevor Sie eine Ereignismethode aufrufen, einschließlich Ereignissen mit Zielgruppentrigger. |
|
Google Tag Manager |
Folgen Sie der Anleitung in vier Schritten, um GTM einzurichten. |
|
Serverseitiges Tagging |
Diese speziellen Tag-Einstellungen dürfen nicht übersprungen werden. Sie sollten nicht sowohl eine serverseitige als auch eine eigenständige clientseitige Implementierung auf derselben Seite für dieselbe GA4-Property verwalten. Wenn Sie sGTM verwenden, müssen alle aktiven Tags so eingerichtet sein, dass Ereignisse über den serverseitigen Container gesendet werden. |
Wenn Sie die empfohlene Reihenfolge für Ereignisse nicht einhalten können, sollten Sie trotzdem diese beiden Empfehlungen beachten. Andernfalls kann es zu Problemen bei der Berichterstellung kommen.
- Geben Sie alle relevanten Konfigurationen für die Seite im Rahmen des Befehls
config
(für das Google-Tag) oder in den Google-Tag-Einstellungen (für Google Tag Manager) so früh wie möglich auf der Seite und vor etwaigen Ereignissen an. - Benutzerdefinierte Ereignisse dürfen nicht vor dem Befehl
config
ausgelöst werden, da sie sonst mit dem Ereignissession_start
zusammengefasst werden. Der Befehlconfig
kann sich auf die Nutzer- und Sitzungsidentität für den Rest der Seite auswirken. Das bedeutet, dass der Seitenaufruf und nachfolgende Ereignisse nicht mit dem früheren Sitzungsstart und dem benutzerdefinierten Ereignis verknüpft werden können.
Was passiert, wenn meine Ereignisse nicht richtig sortiert sind?
Wenn GA4-Tags zu unerwarteten Zeiten festgelegt werden, z. B. wenn der Konfigurationsbefehl oder das Google-Tag nach anderen Ereignissen auf der Seite ausgelöst wird, kann sich das auf die User-ID, die Sitzungs-ID oder beides auswirken. Das kann zu folgenden Problemen führen:
- Daten, die in Analytics als „(nicht festgelegt)“ angezeigt werden
- Falsche Anzahl von Nutzern und Sitzungen
- Nicht korrekt berechnete Messwerte auf Nutzer- und Sitzungsebene
- Falsche Messung von Nutzern und Sitzungen
Was kann dazu führen, dass Ereignisse falsch sortiert werden?
Zu den häufigsten Ursachen für unerwartetes Timing gehören:
Funktion | Ursache | Ergebnis | Best Practices |
---|---|---|---|
Serverseitiges Tagging Server-verwaltete Einstellung (server-verwaltete Client-ID) Client-verwaltete Einstellungen |
Im Feld für das serverseitige Tagging ist die Option „Server-verwaltet“ aktiviert. Wenn GA4-Ereignisse über ein Server-Tag verarbeitet werden, haben Nutzer verschiedene Möglichkeiten, eine andere Nutzeridentität als die Client-ID zu verwenden, die vom Web-Tag verwendet wird. |
Wenn Sie im Drop-down-Menü oben „Server-verwaltet“ auswählen, wird über das serverseitige Tagging eine separate Client-ID verwaltet und für die Verarbeitung von Messungen verwendet. Außerdem gibt es mehrere Optionen für das Schreiben dieses Cookies und eine Option für die schrittweise Migration für Kunden, die bereits direkte GA4-Zugriffe haben und keine abrupte Unterbrechung von Zielgruppen und Berichten durch eine plötzliche Änderung aller Besucher-IDs wünschen. |
Wenn Sie diese Option verwenden, müssen Sie dafür sorgen, dass alle Messungen für Ihren Stream über Ihr Server-Tag laufen und keine direkt an die Google-Server gesendet werden. Am einfachsten ist es, dafür zu sorgen, dass Google Tag Manager oder der Befehl „config“ (Google-Tag) für das Web-Tag, das Daten an Ihren Servercontainer sendet, immer das erste Tag oder der erste Befehl für diesen Container ist. |
Anpassen des Cookie-Namens |
Dadurch wird der Name des eigenen Cookies geändert, das sowohl für die Client-ID als auch für den Sitzungsstatus verwendet wird. |
Nutzer können nicht über Sitzungen hinweg verknüpft werden und Ereignisse können nicht in Sitzungen eingeschlossen werden. Ereignismesswerte werden in der Analyse mit Sitzungs- oder Nutzerdimensionen als „(nicht festgelegt)“ angezeigt. |
Verwenden Sie auf Ihrer Website ein einheitliches Cookie-Präfix. Das Cookie-Präfix in Analytics sollte dazu verwendet werden, einen benutzerdefinierten Cookie-Namen zu erstellen, nicht mehrere Cookie-Silos. Das ist der Fall, wenn Sie unterschiedliche oder inkonsistente Präfixe verwenden. |
Automatische domainübergreifende Verknüpfung |
Mit dieser Einstellung wird das Tag angewiesen, Client- und Sitzungsdaten der vorherigen Seite zu verarbeiten und zu verwenden, sofern verfügbar. Beim Annehmen der verknüpften Daten geht das Tag davon aus, dass die Sitzung bereits auf der vorherigen Seite gestartet wurde. |
Wenn die Verknüpfung erst spät initialisiert wird und erst durch einen späten Konfigurationsbefehl von einem domainübergreifend verknüpften Nutzer erfährt, ändert sich die Nutzeridentität an diesem Punkt plötzlich. Späte Konfigurationsbefehle führen mindestens zu kurzen Sitzungen, die verworfen werden, wenn die Werte der Linkparameter übernommen werden. Alle zu diesem Zeitpunkt bereits gesendeten Sitzungs- oder Nutzerattribute können nicht mehr mit der tatsächlichen Sitzung oder dem tatsächlichen Nutzer verknüpft werden. |
Passen Sie die Client- oder Sitzungs-ID nicht an, da dies zu falschen Annahmen sowohl in den Tags als auch bei der Verarbeitung darüber führt, wie Sitzungen strukturiert werden. Dies kann auch zu Problemen führen. |
Manuelle domainübergreifende Verknüpfung |
Damit Kunden die domainübergreifende Messung manuell implementieren können, enthält das GA4-Tag APIs, mit denen sowohl Client- als auch Sitzungs-IDs abgerufen und festgelegt werden können. Wenn Sie |
Bei Ereignissen, die von ihren ursprünglichen Client- und Sitzungs-IDs getrennt sind, fehlen möglicherweise wichtige Informationen und es kann zu unerwarteten Attributionsproblemen kommen. |
Verwenden Sie Verwenden Sie diese APIs nicht, um benutzerdefinierte Client- oder Sitzungs-IDs zu ändern oder bereitzustellen. Diese IDs sollten nur in seltenen Fällen manuell festgelegt werden, wenn eine manuelle domainübergreifende Einrichtung erforderlich ist. |
1 linker ist der Parameter für die automatische domainübergreifende Verknüpfung. Sie können die Client-ID und die Sitzungs-ID manuell festlegen, wenn die automatische domainübergreifende Verknüpfung für Ihre Website nicht funktioniert. Passen Sie diese Werte niemals an. In GA4 werden Werte in einem bestimmten Format erwartet. Unerwartete Werte können zu Fehlern führen. Weitere Informationen zum linker-Parameter