{"id":13205,"date":"2026-09-29T12:45:00","date_gmt":"2026-09-29T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13205"},"modified":"2026-09-25T15:07:51","modified_gmt":"2026-09-25T13:07:51","slug":"tutorial-was-in-page_location-ankommt-und-warum-das-fragment-nie-beim","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/tutorials-de\/tutorial-was-in-page_location-ankommt-und-warum-das-fragment-nie-beim\/","title":{"rendered":"Tutorial: Was in page_location ankommt und warum das Fragment nie beim Server landet"},"content":{"rendered":"

Eine Adresse in der Browserzeile sieht aus wie eine einzige Zeichenkette. Auf ihrem Weg in einen Bericht durchl\u00e4uft sie vier Systeme, und jedes davon beh\u00e4lt einen anderen Teil.<\/p>\n

Das meiste daran ist erwartbar. Ein Teil nicht: Alles hinter der Raute erreicht den Webserver \u00fcberhaupt nie und erreicht die Analyse-Property vollst\u00e4ndig – das Gegenteil dessen, was die meisten annehmen, und es entscheidet, wo die Routen einer Einzelseitenanwendung landen.<\/p>\n

\n\"Eine
Vier Systeme, vier verschiedene Auswahlen. Die Fragmentzeile ist die, die anders l\u00e4uft als alle anderen.<\/figcaption><\/figure>\n

Die Teile einer Adresse und wer welchen sieht<\/h2>\n

Eine Adresse setzt sich aus f\u00fcnf St\u00fccken zusammen, und die Trennzeichen dazwischen sind das, wonach ein Parser sucht.<\/p>\n

https:\/\/shop.example\/kasse\/schritt-2?utm_source=newsletter&gclid=Cj0KEQ#zahlung\n\u2514\u2500\u252c\u2500\u2518   \u2514\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2518\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\u2514\u2500\u2500\u2500\u252c\u2500\u2500\u2518\nSchema     Host          Pfad                  Abfrage                Fragment<\/code><\/pre>\n
Der Webserver bekommt den Host in einem Header und Pfad und Abfrage in der Anfragezeile. Das Fragment bekommt er nie, denn der Browser sendet es nicht – dieser Teil ist als clientseitig festgelegt und bleibt dort. Kein Zugriffsprotokoll, kein vorgelagerter Server und keine serverseitige Regel sieht ihn.<\/p>\n
Das Analyse-Tag l\u00e4uft im Browser, liest document.location.href<\/code>, und diese Zeichenkette enth\u00e4lt alles einschlie\u00dflich des Fragments. Der Wert in page_location<\/code> ist damit vollst\u00e4ndiger als alles, was der Server hat.<\/p>\n
Das Fragment und wo es landet<\/h2>\n
Am meisten z\u00e4hlt das f\u00fcr Anwendungen, die ihre Wegf\u00fchrung in das Fragment legen. Ein Pfad der Form \/#\/produkt\/42<\/code> ist f\u00fcr den Server eine einzige Seite – er sieht immer nur \/<\/code> -, w\u00e4hrend die Analyse-Property f\u00fcr jede Route ein eigenes page_location<\/code> erh\u00e4lt.<\/p>\n
Daraus folgen drei Dinge, und sie ziehen in verschiedene Richtungen.<\/p>\n
Eine serverseitige Messung einer solchen Anwendung ist ohne Hilfe unm\u00f6glich: Eine Protokollauswertung sieht eine Seite und hunderttausend Aufrufe. Das ist das Argument f\u00fcr clientseitige Messung, das nichts anderes ersetzt.<\/p>\n
Ein serverseitiges Schw\u00e4rzen einer solchen Anwendung ist ebenso unm\u00f6glich. Ein Fragment mit einer Bestellnummer oder einer Mailadresse l\u00e4sst sich von keinem vorgelagerten Server entfernen, denn dieser bekommt es nie – die einzige Stelle zum Entfernen ist der Browser, bevor das Tag liest.<\/p>\n
Und die Berichtsdimensionen behandeln es uneinheitlich, was der praktische Teil ist.<\/p>\n
Was jede Dimension tats\u00e4chlich enth\u00e4lt<\/h2>\n
GA4 speichert einen Parameter und leitet daraus mehrere Dimensionen ab – und jede Ableitung l\u00e4sst etwas weg.<\/p>\n\n\n\n\n\n\n\n\n
Dimension<\/th>\nInhalt f\u00fcr das Beispiel oben<\/th>\n<\/tr>\n<\/thead>\n
Seitenadresse<\/td>\nhttps:\/\/shop.example\/kasse\/schritt-2?utm_source=\u2026&gclid=\u2026#zahlung<\/td>\n<\/tr>\n
Hostname<\/td>\nshop.example<\/td>\n<\/tr>\n
Seitenpfad und Abfragezeichenfolge<\/td>\n\/kasse\/schritt-2?utm_source=newsletter&gclid=Cj0KEQ<\/td>\n<\/tr>\n
Seitenpfad<\/td>\n\/kasse\/schritt-2<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Das Fragment erscheint nur in der ersten Zeile. Das hei\u00dft: Ein nach Seitenpfad gruppierter Bericht zeigt f\u00fcr eine rautengef\u00fchrte Anwendung eine Zeile, und derselbe Bericht nach Seitenadresse gruppiert zeigt hundert – und beides sind dieselben Daten.<\/p>\n
Die Abfragezeichenfolge ist das Zweite, worauf zu achten ist. Sie steht in zwei der vier Dimensionen, und jeder Parameter darin wird Teil des Werts: Eine Seite, die mit einem gclid<\/code> erreicht wurde, und dieselbe Seite ohne sind zwei verschiedene Zeilen. Auf einem Auftritt mit Kampagnenverkehr zerlegt das allein eine einzelne Seite in Dutzende.<\/p>\n
Die L\u00e4ngenbegrenzung<\/h2>\n
Die meisten Ereignisparameter in GA4 nehmen hundert Zeichen an. Die Seitenadresse ist ein Sonderfall und nimmt tausend – gro\u00dfz\u00fcgig und nicht unbegrenzt.<\/p>\n
Eine l\u00e4ngere Adresse wird gek\u00fcrzt, und die K\u00fcrzung ist still. Wehtun tut sie genau dort, wo Adressen lang werden: eine gefilterte Kategorieseite mit acht Merkmalen, ein Suchergebnis mit der Anfrage in der Adresse und eine rautengef\u00fchrte Anwendung, deren Route einen Zustand tr\u00e4gt.<\/p>\n
\/\/ vor dem Tag pruefen, wie lang die Adresse tatsaechlich ist\nconsole.log(document.location.href.length,\n            document.location.href.slice(0, 120));<\/code><\/pre>\n
Wo die Grenze ein echtes Risiko ist, lautet die Antwort: absichtlich k\u00fcrzen, statt die Plattform schneiden zu lassen. Ein page_location<\/code>-Ersatz, der den Pfad und nur die wichtigen Parameter beh\u00e4lt, ist zugleich k\u00fcrzer und n\u00fctzlicher, denn er entfernt auch die Kampagnenparameter, die die Seite in Dutzende Zeilen zerlegt haben.<\/p>\n
function () {\n  var behalten = [\"seite\", \"sortierung\", \"filter\"];\n  var u = new URL(document.location.href);\n  var neu = new URL(u.origin + u.pathname);\n\n  behalten.forEach(function (name) {\n    if (u.searchParams.has(name)) {\n      neu.searchParams.set(name, u.searchParams.get(name));\n    }\n  });\n  return neu.href;          \/\/ ohne Fragment, ohne Kampagnenparameter\n}<\/code><\/pre>\n
Eine Warnung zu dieser Variablen: N\u00f6tig ist sie am Seitenaufruf-Tag und an jedem Ereignis-Tag, sonst f\u00fchrt die Property zwei verschiedene Vorstellungen derselben Seite. Und die Kampagnenparameter m\u00fcssen gelesen werden, bevor sie entfernt werden – das Konfigurationstag braucht die urspr\u00fcngliche Adresse, sonst verschwindet die Zuordnung mit ihnen.<\/p>\n
Einzelseitenanwendungen: im richtigen Augenblick lesen<\/h2>\n
Ein Seitenaufbau liest die Adresse einmal. Ein Wegwechsel in einer Anwendung l\u00e4dt nichts neu, also liest sie niemand erneut, solange es niemandem gesagt wird.<\/p>\n
Daraus entsteht die h\u00e4ufigste falsche Zahl in diesem ganzen Bereich: Die zweite Route einer Sitzung meldet die Adresse der ersten, weil das Tag ausgel\u00f6st hat, bevor das Ger\u00fcst die Adresse aktualisiert hatte. Die Reihenfolge dieser beiden Vorg\u00e4nge ist eine Eigenschaft des Ger\u00fcsts und nicht des Tag-Managers.<\/p>\n
\/\/ erst nach der Adressaenderung melden, nicht davor\n(function () {\n  var alt = document.location.href;\n  [\"pushState\", \"replaceState\"].forEach(function (name) {\n    var original = history[name];\n    history[name] = function () {\n      var r = original.apply(this, arguments);\n      melde();\n      return r;\n    };\n  });\n  window.addEventListener(\"popstate\", melde);\n  window.addEventListener(\"hashchange\", melde);\n\n  function melde() {\n    if (document.location.href === alt) { return; }\n    alt = document.location.href;\n    window.dataLayer.push({\n      event: \"seitenwechsel\",\n      seite_adresse: document.location.href,\n      seite_titel: document.title\n    });\n  }\n})();<\/code><\/pre>\n
Zwei Einzelheiten in diesem St\u00fcck leisten echte Arbeit. Der Vergleich mit der vorherigen Adresse unterdr\u00fcckt die Doppelereignisse, die ein Ger\u00fcst erzeugt, wenn es den Zustand ersetzt, ohne die Route zu \u00e4ndern. Und hashchange<\/code> steht eigens da, denn eine reine Rauten\u00e4nderung l\u00e4uft nicht immer \u00fcber pushState<\/code> – und das ist genau der Fall bei den Anwendungen, die ihre Routen im Fragment f\u00fchren.<\/p>\n
Der Titel lohnt sich aus demselben Grund mitzugeben wie die Adresse: Er \u00e4ndert sich nach der Route, und ein Tag, das ihn zu fr\u00fch liest, meldet den Titel der vorigen Seite zum Pfad der aktuellen. Ein solches Paar f\u00e4llt in einem Bericht leicht auf und l\u00e4sst sich ohne dieses Wissen schwer erkl\u00e4ren.<\/p>\n
Entscheiden, was in den Bericht geh\u00f6rt<\/h2>\n
Alles Bisherige beschreibt, was m\u00f6glich ist. Die Entscheidung lautet, was dort stehen soll, und drei Fragen kl\u00e4ren das.<\/p>\n
Welche Parameter unterscheiden Seiten, und welche kennzeichnen nur, wie jemand angekommen ist. Sortierung und Bl\u00e4tterung unterscheiden; gclid<\/code>, fbclid<\/code> und der Kampagnensatz tun es nicht – und sie in der Seitendimension zu lassen zerlegt jede Einstiegsseite in einen langen Schwanz von Zeilen mit je einem Aufruf.<\/p>\n
Ob das Fragment eine Angabe tr\u00e4gt oder eine Position. Eine Route geh\u00f6rt in den Bericht; ein Anker auf eine \u00dcberschrift ist Rauschen, und beides sieht im Wert gleich aus.<\/p>\n
Und ob irgendetwas darin personenbezogen ist. An dieser Stelle kehrt die fr\u00fchere Frage nach dem Schw\u00e4rzen mit sch\u00e4rferer Kante zur\u00fcck: Ein Wert im Fragment l\u00e4sst sich von keiner Regel auf dem Webserver abfangen, von keinem vorgelagerten Server, und ist, bevor er das Ger\u00e4t verl\u00e4sst, allein im Browser entfernbar – womit das Tag die letzte Linie ist statt einer Bequemlichkeit.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
L\u00e4sst sich eine rautengef\u00fchrte Anwendung per Server-Weiterleitung auf echte Pfade umstellen?<\/h3>\n
Nicht allein auf dem Server. Eine Anfrage an \/#\/produkt\/42 kommt dort als \/ an, der Server wei\u00df also nicht, welche Route gemeint war, und kann keine passende Weiterleitung w\u00e4hlen. Leitet er \/ pauschal auf eine neue Adresse um, h\u00e4ngt der Browser das Fragment selbst wieder an: Der HTTP-Standard legt fest, dass ein Weiterleitungsziel ohne eigenes Fragment das Fragment der urspr\u00fcnglichen Adresse erbt. Aus \/#\/produkt\/42 wird so \/app\/#\/produkt\/42, nicht \/app\/produkt\/42.<\/p>\n
Die \u00dcbersetzung der alten Routen muss deshalb im Browser geschehen: Ein kleines Skript liest location.hash<\/code> und ersetzt die Adresse per history.replaceState<\/code> oder location.replace<\/code> durch den neuen Pfad. Das sollte passieren, bevor das Analyse-Tag den ersten Seitenaufruf meldet, sonst erscheint jede alte Adresse noch einmal als eigener Aufruf.<\/p>\n
In den Berichten bricht die Umstellung die Zeitreihe. Vorher standen alle Routen unter einem einzigen Seitenpfad und unterschieden sich nur in der Seitenadresse, danach verteilen sie sich auf eigene Seitenpfade. Ein Vergleich \u00fcber den Umstellungstag hinweg braucht deshalb eine Zuordnung der alten Fragmente zu den neuen Pfaden.<\/p>\n
Meldet das Skript aus dem Artikel auch Spr\u00fcnge zu Ankern auf derselben Seite?<\/h3>\n
Ja. Ein Klick auf einen Anker \u00e4ndert document.location.href<\/code> und l\u00f6st hashchange aus, und der Vergleich mit der vorherigen Adresse l\u00e4sst das Ereignis durch, weil sich die Adresse tats\u00e4chlich ge\u00e4ndert hat. Auf Seiten mit Inhaltsverzeichnis entsteht so ein Seitenwechsel je Sprung. Abhilfe schafft eine zus\u00e4tzliche Bedingung, die das Fragment nur z\u00e4hlt, wenn es eine Route tr\u00e4gt, etwa wenn es mit #\/<\/code> beginnt.<\/p>\n
Sieht ein serverseitiger Container das Fragment?<\/h3>\n
Ja, aber auf anderem Weg als der Webserver. Der Container bekommt nicht die Seitenanfrage, sondern die Messanfrage des Tags, und darin steht page_location als Wert, samt Fragment, so wie das Tag es aus document.location.href<\/code> gelesen hat. Dort l\u00e4sst sich der Wert umschreiben oder k\u00fcrzen, bevor er an die Analyse-Property weitergeht.<\/p>\n
F\u00fcr personenbezogene Angaben im Fragment \u00e4ndert das wenig: Wenn der Container sie entfernt, haben sie den Browser bereits verlassen und liegen auf dem eigenen Server, wo sie je nach Einstellung auch in Protokollen landen k\u00f6nnen. Soll ein Wert das Ger\u00e4t gar nicht erst verlassen, muss er weiterhin im Browser entfernt werden, bevor das Tag liest.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n