Die s.pageName Variable

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:

[Screenshot]

Schlecht: Bericht ohne s.pageName

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:

  1. Clarity
  2. Context
  3. 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.

Über

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with:
Veröffentlicht in Grundlagen
14 comments on “Die s.pageName Variable
  1. […] Seite! Deswegen korreliert man sinnvollerweise mit einer prop, die mit dem getPreviousValue den Namen der vorherigen Seite […]

  2. […] kann correlations nicht nur für die s.pageName, s.channel, s.pageType und s.propXY Variablen anschalten sondern auch für viele der eingebauten […]

  3. […] 800000 verschiedene Beiträge anbieten. Jeder dieser Beiträge hat einen anderen Namen, der in s.pageName übermittelt wird und im Site Content > Pages Report zu sehen […]

  4. […] Um Fragen wie diese beantworten zu können tracken die meisten Implementierungen Werte wie den pageName sowohl in eine prop als auch in eine […]

  5. […] – s.pageName oder der Name der getrackten […]

  6. […] Wenn der Browser bei Zeile 10 / Schritt 8 ankommt, gibt es also ein s Objekt. In unserem Beispiel wird hier die wichtigste Variable zugewiesen, s.pageName. […]

  7. […] s.pageName – alle Artikel unter “Politik;Europa;Luxemburg” zusammen bringen es auf meiner […]

  8. […] sieht sich das Plugin den Namen der aktuell geladenen Seite an, also den Inhalt der s.pageName Variable. Im Debugger kann man diesen Wert unter dem Parameter “pid=” […]

  9. […] Variables (props) waren bisher “case sensitive”, d.h. s.pageName=”Home” und s.pageName=”home” waren zwei unterschiedliche Seiten. Bei den […]

  10. […] Bei Elementen mit einer id kann der Code auch direkt auf das Element zugreifen, in unserem Fall mit s.pageName also […]

  11. […] Achtung: Der Code funktioniert so, wird aber kein lesbares Tracking erzeugen. Warum? Weil eine wichtige Variable fehlt. […]

  12. […] Seiten-basierten Daten funktionieren wie üblich, also z.B. die Page Views Metrik auf s.pageName oder allen […]

  13. […] Ohne events kann man mit ein wenig Aufwand immer noch den kompletten Code für’s Engagement in der s_doPlugins Methode abhandeln, und zwar indem man sich an der URL der Seite orientiert, oder an s.pageName. […]

  14. […] Webanalysten: Hört den Nutzern zu! Sucht den Dialog! Stellt Fragen und mehr Fragen. Redet mit Eurem CFO, damit Ihr versteht, wie die Firma tickt! Und benennt Eure Metriken um, um Gottes Willen! Eine gute Metrik heißt genau so, wie der Endnutzer sie nennt. (Analog zum Setzen der pagename Variable.) […]

Sagen Sie Ihre Meinung!

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Autoren
%d Bloggern gefällt das: