Tutorial: page_location, URL-Fragmente und Serveranfragen

Browseradresse, HTTP-Seitenanfrage und GA4-Ereignis sind unterschiedliche Darstellungen. Das Fragment hinter # fehlt beim Abruf der Seite. JavaScript kann das Fragment trotzdem lesen und den Wert mit einer separaten Anfrage übertragen.

GA4 übernimmt das Fragment standardmäßig nicht. Googles Dokumentation für Seitenaufrufe nennt diese Ausnahme zu location.href ausdrücklich. Eine eigene Vorgabe für page_location kann den übertragenen Wert verändern. Die Browserzeile allein belegt daher nicht den Eingang bei Analytics.

Von der Browseradresse zur Anfrage

Bei https://shop.example/checkout?page=2#payment lautet das Schema https, der Host shop.example, der Pfad /checkout, die Abfrage page=2 und das Fragment payment. Allgemein können URLs zusätzlich einen Port oder Benutzerinformationen enthalten.

Die Seitenanfrage richtet sich an /checkout?page=2. HTTP/1.1 übermittelt die Serveradresse normalerweise im Host-Header und das Ziel in der Anfragezeile; HTTP/2 und HTTP/3 verwenden entsprechende Pseudo-Header. Eine Anfrage für /#/catalog verrät dem Seitenserver deshalb nicht die ausgewählte Hash-Route. Wechsel zwischen Hash-Routen benötigen häufig keinen weiteren Dokumentabruf. Aus Dokumentanfragen allein lassen sich solche Wechsel nicht zählen.

Was die GA4-Dimensionen beschreiben

Das folgende Beispiel setzt den dokumentierten Standard, eine gültige URL und keine eigene Umschreibung oder Datenbereinigung voraus. Die Dimensionen sind Ansichten erfasster Ereignisdaten, keine vier eigenständigen Erfassungssysteme.

Eine eigene Vorgabe mit Fragment erfordert eine gesonderte Kontrolle des ausgehenden Ereignisses und des verwendeten Berichts oder Exports. Die Standardtabelle garantiert keine einheitliche Behandlung beliebiger Fragmente in sämtlichen Auswertungen. Ein stabiler, nicht personenbezogener Routenname oder ein freigegebener virtueller Pfad ist für Hash-Routing häufig verständlicher.

Abfragewerte können ansonsten identische Seiten auf mehrere Zeilen verteilen. Das tatsächliche Ergebnis hängt auch von Bereinigung, Umschreibung und Bericht ab. Eine pfadbasierte Dimension ermöglicht die Gruppierung ohne Entfernen der Kampagnenangaben bei der Erfassung. Ein eigenes route_name benötigt für gewöhnliche GA4-Berichte eine benutzerdefinierte Dimension mit Ereignisbezug.

Länge und Datenschutz vor der Übertragung

Google nennt maximal 1.000 Zeichen für page_location. Ein längerer Wert überschreitet diese Grenze; eine stille, verlässliche Kürzung ist keine belastbare Planungsgrundlage. Kurze, gültige und aussagekräftige URLs sind einem beliebigen Abschneiden vorzuziehen: Dabei können Routen oder Parameter ihre Bedeutung verlieren.

Das Entfernen bestimmter Parameternamen ist kein vollständiger Datenschutzfilter. Auch Pfade, erlaubte Parameterwerte, Fragmente und Titel können personenbezogene Angaben enthalten. Googles Datenbereinigung bietet eine zusätzliche Kontrolle, aber keine Erkennungsgarantie für sämtliche persönlichen Angaben. Eine lokale Längenprüfung kann auf die reine Zeichenanzahl beschränkt bleiben; bereits die Ausgabe der ersten 120 URL-Zeichen kann sensible Inhalte offenlegen.

Das Entfernen von UTM-Parametern oder Klickkennungen vor der Kampagnenverarbeitung kann die Herkunftsauswertung verändern. Ein erstes Tag mit der unveränderten Adresse löst das Problem nicht allgemein, wenn diese Adresse personenbezogene Angaben enthält. Freigegebene Kampagnenverarbeitung und datensparsame Seitenkennungen benötigen ein abgestimmtes Konzept samt Tests. Explizite Kampagnenfelder ersetzen nicht beliebig die Klickkennungen automatischer Tag-Kennzeichnung.

Einzelseitenanwendungen (SPAs): Messung nach abgeschlossenem Seitenwechsel

Einzelseitenanwendungen wechseln den sichtbaren Inhalt, ohne für jede Ansicht ein vollständiges neues Dokument zu laden. Automatische Messung auf Grundlage des Browserverlaufs existiert bereits. Eine eigene Hülle um die History API ist daher weder grundsätzlich erforderlich noch ein Nachweis für den fertigen neuen Seitentitel. pushState() löst kein hashchange aus; eine geänderte URL belegt außerdem keinen abgeschlossenen asynchronen Seitenaufbau.

Eine zweckmäßige Regel für die Anwendung lautet: genau eine Meldung route_ready nach einem vollständig abgeschlossenen Wechsel zu einer anderen Ansicht. Das folgende Beispiel gehört in den Anwendungscode, mit einem Aufruf, sobald die neue Ansicht und der zugehörige Titel fertig sind. Die zwei freigegebenen Routenschlüssel und englischen Anzeigetitel dienen als Beispiel und benötigen eine Anpassung an den tatsächlichen Routenkatalog. Unbekannte Routen sowie eine fehlende oder falsche Freigabe werden abgewiesen.

function reportRouteReady(routeKey, measurementAllowed) {
  var routes = {
    catalog: { path: "/catalog", title: "Catalog" },
    checkout: { path: "/checkout", title: "Checkout" }
  };
  if (measurementAllowed !== true ||
      !Object.prototype.hasOwnProperty.call(routes, routeKey)) {
    return false;
  }
  var route = routes[routeKey];
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "route_ready",
    route_name: routeKey,
    page_location: new URL(route.path, location.origin).href,
    page_title: route.title
  });
  return true;
}

Diese Hilfsfunktion versendet selbst keine Anfrage. Die Einbindung muss die aktuelle Messfreigabe übergeben und Aufrufe bei Widerruf stoppen; der Wahrheitswert ersetzt keine Einwilligungssteuerung anderer Tags. In GTM kann ein Auslöser für das benutzerdefinierte Ereignis route_ready ein GA4-Tag mit Ereignisname page_view starten. Data-Layer-Variablen liefern die drei übergebenen Felder. Auch nachfolgende Ereignisse benötigen dazu passende Werte. Die Funktion liest bewusst keine unveränderten URLs oder Seitentitel. Die zugeordneten URLs enthalten weder Abfrage noch Fragment; das Beispiel ist keine vollständige Umsetzung der Herkunftsmessung.

Der Router muss genau einen Aufruf je gezähltem Wechsel liefern, einschließlich der vereinbarten Behandlung der ersten Ansicht. Ein Sprung im Inhaltsverzeichnis ist nicht automatisch ein Seitenaufruf. Eine identische Route kann trotzdem einen bewussten erneuten Besuch darstellen; URL-Gleichheit ist deshalb keine universelle Regel gegen Doppelzählung. Für die Navigationsanalyse ist außerdem die vorherige freigegebene virtuelle URL als page_referrer zu berücksichtigen.

Bei vollständig manuellen Seitenaufrufen benötigen der erste automatische Aufruf und die History-Aufrufe der optimierten Analysen jeweils eine eigene Deaktivierung. send_page_view: false allein deaktiviert keine History-Aufrufe. Zur Abnahme gehören erster Seitenaufbau, Vor-/Zurücknavigation, Anker, wiederholte Routen, Einwilligungswechsel und genau ein vorgesehenes Ereignis je Wechsel. Tag-Vorschau, ausgehende Anfrage und DebugView beantworten unterschiedliche Fragen.

Fragen und Antworten

Kann ein serverseitiger Container ein Fragment entfernen?

Ja, wenn ein Client das Fragment ausdrücklich als Ereignisdaten übertragen hat. Der Container kann den Wert vor der Weitergabe verändern oder ausschließen. Der bereits erfolgte Empfang am Endpunkt und eine Protokollierung vor der Transformation bleiben dadurch bestehen. Angaben, die auf dem Gerät bleiben müssen, benötigen eine Entfernung vor der ausgehenden Anfrage.

Kann eine Serverweiterleitung eine Hash-Route in einen Pfad übersetzen?

Nicht anhand der Seitenanfrage allein. Eine Weiterleitung von / nach /app/ ohne eigenes Fragment erhält nach HTTP-Regeln normalerweise das ursprüngliche Fragment. Eine Zuordnung im Browser kann freigegebene alte Routen in neue Pfade übersetzen. Nach einer Änderung über die History API muss der Server den neuen Pfad auch bei erneutem Laden ausliefern können; eine Änderung über Location löst Navigation aus. Die Messung sollte nach der vorgesehenen Zuordnung beginnen, mit einer ausdrücklichen Vergleichsregel für Berichte über den Umstellungszeitpunkt hinweg.

Schützt ein Fragment personenbezogene Angaben?

Nein. Skripte können Fragmente lesen und übertragen. Das fehlende Fragment in der Dokumentanfrage ist eine begrenzte Protokolleigenschaft, keine Datenschutzgarantie.

Quellen

• RFC 3986: Allgemeine URI-Syntax, Abschnitt 3.5
• RFC 9110: Bedeutung von HTTP, Location
• Google Analytics: Seitenaufrufe messen
• Google Analytics: Einzelseitenanwendungen messen
• Google Analytics Data API: Dimensionen und Messwerte
• Google Analytics: Automatisch erfasste Ereignisse
• Google Analytics: Grenzen der Ereigniserfassung
• Google Analytics: Datenbereinigung
• Google Analytics: Übertragung personenbezogener Angaben vermeiden
• MDN: History.pushState()
• Google Tag Manager: Serverseitige Transformationen
• Google Analytics: Eigene Kampagnendaten festlegen
• Google-Tag: Einwilligungsmodus für Websites einrichten
• Google Analytics: Benutzerdefinierte Dimensionen mit Ereignisbezug erstellen