Heute geht es um die Variable s.pageName
, die wichtigste und gleichzeitig am wenigsten beachtete Variable in SiteCatalyst.
Warum ist s.pageName
so wichtig?
Deswegen:
Wer kann hier auf Anhieb sagen, welche Seite das sein soll, die da mehr als 5 Mio Visits anhäuft? Ich jedenfalls nicht.Nicht alle CMS sind mit einer solchen URL Struktur aufgebaut, aber ein Name ist eigentlich fast immer intuitiver als eine URL. Daher trackt SiteCatalyst Seiten nicht nach URL, sondern nach Name. Und dieser Name wird in s.pageName
gesendet.
Nochmal: SiteCatalyst unterscheidet nach s.pageName
, nicht nach URL.
(Das bedeutet, daß wenn s.pageName
auf allen Seiten gleich gesetzt wird, für SiteCatalyst die ganze Site nur aus einer Seite besteht. Nicht lachen, das habe ich schon erlebt.)
Für viele Umsteiger von anderen Webanalysetools ist das erstmal eine Umstellung. Der Sinn dahinter ist aber, daß mit ein wenig Zusatzaufwand beim Taggen (nämlich besagte s.pageName
setzen) a) das Lesen der Reports ungemein vereinfacht wird, b) die Webanalyse robuster wird gegenüber Änderungen an der Struktur der Site und c) die Webanalyse unabhängig wird von der Siteinfrastruktur.
Ein Beispiel für b) & c): Das Formular für den Newsletter, im alten CMS z.B. unter http://site.com/?id=150375
könnte nach dem Wechsel auf ein neues CMS jetzt unter http://site.com/newsletter/signup.html
zu finden sein.
Für SiteCatalyst wäre das irrelevant, so lange die Seite vor und nach dem Wechsel mit s.pageName="Newsletter:Anmeldung";
getaggt wäre.
Wie setzen?
s.pageName
sollte also immer gesetzt werden. Aber wie? Gibt es da gute Regeln?
Die offizielle Empfehlung seitens Adobe Consulting hat 3 Cs:
- Clarity
- Context
- Conciseness
„Clarity“ in dem Sinne, daß der Name so sein sollte, daß jeder potentiell Interessierte sofort weiß, um welche Seite es sich handelt.
Der Name sollte dabei zwei Teile haben: einen „Context stem“, der eine schnelle Zuordnung zu einem Bereich der Site erlaubt, die Seite also in einen Kontext einordnet, und einen Teil für die eigentliche Seite.
„Conciseness“ bedeutet, daß man abkürzen sollte, wo es sinnvoll ist. Dabei bietet sich natürlich der „context stem“ an, denn der wird ja immer wieder auftauchen.
Beispiel: Eine Seite unserer Site dient dazu, Interessenten für ein Whitepaper zu finden und ihnen nach Eingabe ihrer Email das Paper zu senden. Die Seite enthält ein wenig Text zum Paper und ein Formularfeld für die Email. Das Whitepaper heißt „Grundlagen der Webanalyse“ und ist eins von vielen zur WA. Außerdem enthält die Site noch Informationen und Whitepapers zu anderen Themen.
Ein möglicher Wert für s.pageName
wäre:
s.pageName = "Papers:WA:Req Form:Grundlagen WA";
Der „context stem“ ist „Papers:WA“, und die eigentliche Seite dann „Req Form: Grundlagen WA“. Der Name ist concise, ich habe „Webanalyse“ jeweils als „WA“ abgekürzt sowie den Namen des Papers vereinfacht. Auch die „clarity“ sollte ok sein.
Der „context stem“ orientiert sich oft daran, wie die Zuständigkeiten intern verteilt sind. Wenn ein Autorenteam für Papers zuständig ist, kann dieses Team mit Filtern sehr schnell „seine“ Seiten in den Reports finden.
Wie nicht?
Man sollte s.pageName
nach Möglichkeit nicht einfach auf das <title>
Element der Seite setzen.
In den meisten CMS läßt sich der <title>
frei wählen und nachträglich ändern, zum Beispiel für SEO. Das ist insofern problematisch, als die Seite bei jeder Änderung in SiteCatalyst als eine ganz neue Seite eingestuft wird, man also nur schwierig Trends verfolgen kann.
Dazu kommt, daß durchaus verschiedene Seiten den gleichen <title>
haben können. SiteCatalyst würde solche Seiten dann als ein und dieselbe zählen, was ja nicht gewünscht sein kann.
Man kann s.pageName
auch gar nicht setzen, dann nimmt SiteCatalyst automatisch stattdessen die URL. Warum das kein gute Idee sein muß, zeigt der Screenshot oben.
Wo setzen?
Idealerweise sollte das CMS ein Feld für s.pageName
bereithalten. Dann kann man den Namen einmal festlegen und er wird sich nicht wegen SEO oder Lust und Laune ändern und dabei die Datensammlung stören.
Wer seinen Contentlieferanten nicht traut, kann das Feld auch so einrichten, daß es nach dem Anlegen der Seite nicht mehr geändert werden kann.
Falls sich dieser Idealfall nicht realisieren läßt, ist die nächstbeste Option, den s.pageName
bei der Implementierung von SiteCatalyst direkt im Javascript Code festzulegen.
Die nächstbeste Möglichkeit wäre dann, den Namen im Javascript aus der URL herzuleiten. Dazu implementiert man ein Plugin, welches die URL zerteilt und aus den Teilen einen Namen für s.pageName
baut.
Der offensichtliche Nachteil ist, daß sich der Name mit Änderungen an der Struktur der Site ändert. Ein großer Vorteil ist aber, daß ein solcher Name die Umstellung für Benutzer anderer Webanalysesysteme einfacher macht.
Fassen wir zusammen:
Die Variable s.pageName
sollte auf jeder Seite gesetzt werden. Wenn die Mehrheit der Kollegen anschließend in den Reports die Seiten aufgrund des Namens einwandfrei identifizieren kann, hat man sein Ziel erreicht.
Pingback: Tip: Das getPercentPageViewed Plugin « Webanalyse auf Deutsch
Pingback: Berichte herunterbrechen I – Correlations « Webanalyse auf Deutsch
Pingback: Was bedeutet “Uniques Exceeded”? « Webanalyse auf Deutsch
Pingback: Herunterbrechen ohne Limits – Data Warehouse & Discover « Webanalyse auf Deutsch
Pingback: Tech Tip: Fehlersuche « Webanalyse auf Deutsch
Pingback: Tracking mit Javascript « Webanalyse auf Deutsch
Pingback: Strategien gegen “Uniques Exceeded” « Webanalyse auf Deutsch
Pingback: Wie funktioniert ClickMap? « Webanalyse auf Deutsch
Pingback: Aktuell: Neu in SiteCatalyst 15.3 « Webanalyse auf Deutsch
Pingback: TagManager und taggen ohne Javascript « Webanalyse auf Deutsch
Pingback: Back to Basics – Page Code, Teil 1 « Webanalyse auf Deutsch
Pingback: Webanalyse ohne Cookies « Webanalyse auf Deutsch
Pingback: “Engagement” mit Processing Rules « Webanalyse auf Deutsch
Pingback: Back to the Basics – Vorbereitung | Webanalyse auf Deutsch