Ein Intranet ist kein Website-Projekt. Es wird umbenannt, umstrukturiert und neu zugeschnitten, sobald sich das Organigramm ändert, und das passiert ständig. Wer sein SharePoint Intranet Tracking auf sprechende Seitennamen aufbaut, verliert bei jeder dieser Änderungen ein Stück Historie. Auffallen tut das meistens erst, wenn jemand nach einer Zahl über zwölf Monate fragt.
Dieser Leitfaden zeigt, woran das liegt, wie stabile Identifikatoren das Problem lösen und welche zwei Fehler beim Nachrüsten am häufigsten passieren.
Das Problem: Content IDs sind Namen, keine Identifikatoren
In der Webanalyse ist eine hierarchische, sprechende Seiten-ID üblich. In Mapp Intelligence heißt das Content ID, in anderen Systemen Page Name oder Screen Name. Das Prinzip ist überall gleich:
intranet.finance.portfoliomanagement.quarterly-review
So etwas ist lesbar, ergibt in Reports sofort Sinn und lässt sich hierarchisch aggregieren. Nur ist diese ID aus der URL abgeleitet, und die URL ist ein Name. Namen ändern sich.
Wird die Abteilung von “Portfoliomanagement” in “Project Portfolio Management” umbenannt, wandert die Site von /sites/intranet-finance-portfoliomanagement nach /sites/intranet-finance-ppm. Ab diesem Tag steht in der Datenbank eine zweite Ausprägung. Die Seite ist dieselbe, der Inhalt ist derselbe, die Nutzer sind dieselben. Trotzdem zeigt jede Auswertung über den Umbenennungszeitpunkt hinweg zwei getrennte Kurven, die eine endet bei null, die andere fängt dort an.
Zusammenführen lässt sich das nachträglich nur über eine gepflegte Mapping-Tabelle, die in der Praxis niemand pflegt. Also wird die Historie abgeschnitten.
Warum Intranet Analytics stärker betroffen ist als die Website
Auf einer öffentlichen Website ist die URL-Struktur ein SEO-Asset. Sie wird selten und nur mit Bedacht geändert, es gibt Redirect-Konzepte und jemanden, der sich zuständig fühlt.
Im Intranet ist die Lage umgekehrt:
- Reorganisationen schlagen direkt auf die Site-Struktur durch. Abteilungen werden zusammengelegt, umbenannt, ausgegliedert.
- Seiten pflegen die Fachbereiche, nicht eine Redaktion. Ein Titel wird geändert, weil er unschön war. Dass daran eine Zeitreihe hängt, weiß niemand.
- Es gibt kein SEO-Argument gegen Umbenennungen. Der einzige Grund, URLs stabil zu halten, wäre das Tracking, und das ist selten laut genug.
- Die Struktur ist tiefer und breiter. Dutzende bis hunderte Site Collections, jede mit eigenem Lebenszyklus.
Am Ende sind genau die Kennzahlen unbrauchbar, für die das Analytics-Projekt aufgesetzt wurde.
Die Lösung: technische IDs zusätzlich mitgeben
Jeder Seitenaufruf bekommt neben dem sprechenden Namen zwei Werte mit, die eine Umbenennung überstehen.
| Wert | Was es ist | Stabil bei Umbenennung |
|---|---|---|
|
Site ID |
GUID der Site Collection |
ja |
|
Page ID |
List-Item-ID der Seite in der Pages-Library |
ja |
Beide liegen auf jeder SharePoint-Seite global im Browser bereit, in _spPageContextInfo. Es braucht keinen zusätzlichen API-Call und keine Abhängigkeit vom eingesetzten Framework:
function getSharePointIds() {
const ctx = (window as any)._spPageContextInfo;
if (!ctx) {
return { siteId: 'n/a', listId: 'n/a', pageId: 'n/a' };
}
// GUIDs kommen mit geschweiften Klammern, deshalb vereinheitlichen
const guid = (v: any) => String(v || '').replace(/[{}]/g, '').toLowerCase();
return {
siteId: guid(ctx.siteId),
listId: guid(ctx.pageListId || ctx.listId),
// pageItemId ist -1, wenn die Seite keine Site Page ist
pageId: (ctx.pageItemId > 0) ? String(ctx.pageItemId) : 'n/a'
};
}
Die sprechende Content ID bleibt unverändert. In Reports arbeitet man weiterhin mit ihr. Die technischen IDs sind das Rückgrat darunter, das die Zeitreihe zusammenhält.
Fehler 1: der kombinierte Schlüssel
In bestehenden Setups findet sich häufig ein konkatenierter Wert:
{siteId}_{listId}_{pageId}
Ein Custom Parameter statt drei, eindeutig pro Seite, spart Slots. Klingt effizient, führt aber in die Irre.
Ein zusammengesetzter String lässt sich weder filtern noch gruppieren. Die Frage “zeig mir alle Seitenaufrufe innerhalb der Finance-Site” ist damit nicht zu beantworten, weil die Site ID mitten im Wert steckt. Genauso wenig die Frage, wie sich der Traffic über die zwanzig größten Abteilungssites verteilt. Möglich ist nur der exakte Vergleich: gleicher String oder nicht.
Sinnvoll ist so ein Schlüssel als Join-Key für Exporte in andere Systeme. Als Analyse-Dimension taugt er nicht.
Wer ihn im Einsatz hat, sollte die Einzelwerte parallel dazunehmen, statt zu ersetzen. Der bestehende Wert versorgt die vorhandenen Dashboards weiter, die Einzelwerte tragen alle neuen Auswertungen. Wichtig ist, diese Doppelung als befristet zu dokumentieren, inklusive Abschaltplan. Sonst bleibt sie dauerhaft und in einem Jahr weiß niemand mehr, warum dieselbe Information zweimal im Datenmodell steht.
Fehler 2: eine zweite Implementierung danebenstellen
Wird der kombinierte Wert bereits getrackt, steckt die Ermittlungslogik schon irgendwo im Code. Eine neue Funktion daneben zu schreiben, statt die bestehende zu erweitern, bringt zwei Probleme mit.
Zum einen ist die bestehende Funktion die verbindliche Quelle für das Format. Ob die GUID kleingeschrieben wird, ob das Trennzeichen wirklich ein Unterstrich ist, wie Sonderfälle behandelt werden: Das steht dort und muss nicht aus Reports rekonstruiert werden.
Zum anderen driften zwei Implementierungen mit der Zeit auseinander. Sobald jemand die eine anpasst und die andere übersieht, liefern beide Parameter unterschiedliche IDs für dieselbe Seite. Solche Abweichungen fallen spät auf und kosten viel Zeit im Debugging.
Der Umbau ist klein. Die bestehende Ermittlung bleibt unangetastet, es kommt nur ein erweitertes Rückgabeobjekt dazu. Die Zeile, die den kombinierten Schlüssel zusammensetzt, wird unverändert übernommen. Dann bleibt der alte Wert byte-identisch und die Dashboards laufen weiter.
Stolperfallen in der Praxis
Datentyp Text, nicht Zahl. Die Page ID ist zwar numerisch, aber nicht auf jeder Seite vorhanden. Listenansichten, Dokumentbibliotheken und Systemseiten liefern keine, SharePoint gibt dort -1 zurück. Der Fallback sollte ein sprechender Wert sein, etwa n/a. Ist der Custom Parameter als numerisch konfiguriert, verwirft das Analytics-System solche Werte kommentarlos und man hat stille Lücken statt einer auswertbaren Ausprägung. Der Rohwert -1 wiederum taucht als eigene Ausprägung auf und verwässert die Reports.
GUID-Schreibweise vereinheitlichen. Je nach Quelle ist der Wert mal in geschweifte Klammern gefasst, mal nicht, mal groß-, mal kleingeschrieben. Ohne Normalisierung entstehen mehrere Ausprägungen für dieselbe Site. Im Nachhinein ist das nur mit Aufwand zu bereinigen.
Client-Side-Navigation nicht doppelt zählen. Moderne Intranet-Frontends navigieren ohne Full Reload. Das Navigations-Event feuert dabei oft auch dann, wenn sich die Seite gar nicht geändert hat, etwa beim Nachladen von Komponenten. Ein Abgleich gegen die zuletzt getrackte URL verhindert aufgeblähte Seitenaufrufzahlen.
Startseiten erkennen, nicht raten. Der Dateiname einer Site-Startseite ist meistens Home.aspx, egal um welche Site es geht. Wer den Seitentyp am Dateinamen festmacht, bekommt hunderte identisch benannter Einträge. Die tatsächliche Startseite eines Webs sollte aktiv ermittelt und das Ergebnis gecacht werden.
Platzhalter aus dem Beispielcode entfernen. Die SDK-Snippets der Anbieter enthalten Werte wie <<page title>>. Wandern die unverändert ins Deployment, steht der Platzhaltertext dauerhaft in den Reports. Beispielhafte IDs wie 12345 sind noch tückischer: Das Tracking wirkt funktionsfähig, liefert aber bei jedem Aufruf denselben Wert.
Was sich damit beantworten lässt
Der Aufwand lohnt sich über Fragen, die vorher offen bleiben mussten:
- Wie entwickelt sich die Nutzung einer Abteilungsseite über Jahre, auch über Reorganisationen hinweg?
- Welche Inhalte tragen langfristig, welche waren nur ein kurzer Ausschlag nach der Veröffentlichung?
- Wie verteilt sich der Traffic über die Site-Landschaft und wo entstehen verwaiste Bereiche?
- Hat ein Relaunch tatsächlich etwas verändert oder sieht es nur so aus, weil die alte Zeitreihe abgerissen ist?
Checkliste vor dem Deployment
- Custom Parameter im Analytics-Tool angelegt, Datentyp Text
- Slot-Nummern gegen die bestehende Belegung geprüft, Nummern aus Beispielcode sind selten frei
- Bestehende Ermittlungslogik gefunden und erweitert, keine zweite Implementierung
- Kombinierter Schlüssel byte-identisch zum Bestand, falls er weitergeführt wird
- GUIDs normalisiert: kleingeschrieben, ohne geschweifte Klammern
- Fallback auf Seiten ohne Page ID liefert einen definierten Wert, nicht undefined oder -1
- Kein doppelter Seitenaufruf bei Client-Side-Navigation
- Platzhalter aus dem Beispielcode entfernt
- Im Netzwerk-Tab verifiziert, dass die Werte im Request ankommen
- Doppelt geführte Parameter als befristet dokumentiert, inklusive Abschaltplan
Häufige Fragen zum SharePoint Intranet Tracking
Brauche ich für SharePoint Tracking eine SPFx Extension?
Für die Ermittlung von Site ID und Page ID nicht, denn _spPageContextInfo liegt auf jeder Seite global im Browser. Eine SPFx Application Customizer Extension lohnt sich dann, wenn das Tracking tenant-weit auf allen Site Collections ausgerollt werden soll, ohne pro Site etwas zu konfigurieren.
Warum nicht einfach die URL als eindeutigen Schlüssel verwenden?
Weil sie sich ändert. Das ist ja das Problem, das stabile IDs lösen. Die URL bleibt trotzdem wichtig, als lesbarer Einstieg in Reports und für die hierarchische Aggregation.
Site ID oder Web ID, was ist der richtige Wert?
Die Site ID identifiziert die Site Collection, die Web ID ein einzelnes Web darin. Bei einer flachen Intranet-Struktur mit einer Site Collection pro Abteilung reicht die Site ID. Wer Subsites einsetzt, braucht die Web ID dazu.
Wie viele Custom Parameter brauche ich dafür?
Zwei genügen für Site ID und Page ID. Sinnvolle Ergänzungen sind die Hub Site ID für die Zuordnung zum übergeordneten Hub und ein Seitentyp, um News, Content Pages und Listenansichten auseinanderzuhalten. Viele Analytics-Verträge deckeln die Zahl der Custom Parameter, deshalb vor der Konzeption die freie Belegung prüfen.
Funktioniert der Ansatz auch mit anderen Analytics-Tools?
Ja, das Prinzip ist toolunabhängig: sprechende Namen für die Lesbarkeit, stabile IDs für die Historie. Nur die Bezeichnung der Felder unterscheidet sich.
Über IT-WINGS
IT-WINGS ist eine Webanalyse-Agentur mit Schwerpunkt auf Tracking-Konzeption, Implementierung und Datenqualität. Wir arbeiten mit Mapp Intelligence, Google Analytics und Matomo, von der Konzeption über die technische Umsetzung bis zum Reporting.
Intranet-Analytics-Projekt geplant oder ein bestehendes Setup, das nicht liefert? Wir prüfen Ihr Tracking-Konzept, decken Lücken auf und begleiten die Umsetzung.