Referrer-Messung mit Adobe SiteCatalyst ist doch einfach – oder?

Referrer-Messung und -Auswertung gehört doch nun wirklich zum Standard und festen Handwerkszeug eines gestandenen Web-Analysten. Die Auswertung der Traffic-Quellen ist Standard in jedem Tool. Doch gibt es einige Tool-spezifische Unterschiede, die beachtenswert sind und Platz für Diskussionen lassen.

Referrer-Messung mit Adobe SiteCatalyst

Man nehme SiteCatalyst und messe den Seitennamen, Referrer (geht ja automatisch), den Seitennamen in einer eVar (‚Page’) und ein “Custom Event” für PageViews.

Simple Frage: Woher kamen eigentlich die Besucher auf Seite X?

Nehmen wir an, ein Besucher kommt von Domain abc.com, geht auf Seite W, dann X, dann Y, dann wieder X.
Report: Page korreliert mit Referring Domain. Metrik ist, logisch in Korrelationen, PageViews.

  1. Seite W hat logischerweise eine PV auf abc.com.
  2. Seite X zeigt auch abc.com. Weil er nämlich Referring Domains als Conversion Report begreift und damit nicht die Einstiege auf Seite X zeigt, sondern “Visits auf Seite X hatten diesen Referrer”. Nebenbei: Die Standardallokation von Traffic Sources Reports ist “First”. “Last” geht gar nicht.
  3. Seite X zeigt für abc.com zwei PageViews. Weil man die Seite ja zweimal gesehen hatte. Und der Referrer also zweimal beim sehen dieser Seite involviert war.
    Autsch ! (die Anzahl der Ausrufezeichen hat hier eine wichtende Bedeutung…)
  4. Versuchen wir dasselbe mit dem Pagename in einer eVar und dem PageView-Event: Selbes Ergebnis.
    Autsch !!
  5. Visits vielleicht? Ah, die gibt es nicht bei Breakdowns auf Referring Domains. Würde die ursprüngliche Frage aber auch nicht beantworten.
  6. Wir haben noch Instances. Und siehe da, Seite W hat eine Instance und zwar auf abc.com. Seite X hat zwei Instances, aber keine auf einer Referring Domain. Dann ist ja alles fein. Oder?

Aber:

  1. Ausnahme: wir haben mehrere Referrer im Visit. Beispiel: Von abc.com auf Seite W und dann von def.com auf Seite X. Z.B. eine Suchmaschine und eine Preisvergleichsseite. Nun haben wir für Seite W eine Instance auf abc.com. Und wir haben eine Instance auf Seite X für … abc.com. Nicht vergessen, die Allokation von Traffic Sources ist “First”.
    Die Domain def.com taucht nirgendwo auf.
    Autsch !!!
  2. Und noch ein kleiner Nachschlag. Was passiert denn, wenn wir mit einem Direkteinstieg anfangen? Direkt auf Seite W und dann von def.com auf Seite X.
    Nun, für Seite W haben wir im Breakdown keine Instance und den Wert “There is no data for the selected criteria”. Von mir aus.
    Auf Seite X haben wir nun aber eine Instance. Immerhin gab es einen Referrer. Aber worauf, immerhin ist es “First”? Antwort: “Typed/Bookmarked”.
    Wir haben also zwei verschiedene Namen für “keine Info über Referrer verfügbar” im selben Bericht.
    Autsch !!!!

Die Gründe für dieses durchaus komplexe Verhalten seitens SiteCatalyst, für ein eigentlich einfaches Problem lassen sich auf vielerlei, meist technologische Weise, erklären: Datenmodell, Aggregation, Performance,….

Man muss wissen, wie und wo man hinschaut und dass es immer wieder Fallstricke gibt.

In Summe muss man also höllisch aufpassen, wenn es um die quantitative und Erfolgs-orientierte Betrachtung der “Referring Domains” in SiteCatalyst geht. Oder fällt jemandem ein anderer Weg ein?

Dies ist kein Faschingsscherz, aber dennoch: Alaaf, Helau und frohen Fasching!


am 22. Februar 2012 unter Analytics

Neues Referrer-Tracking in der Google Suche

Wie in einigen Blogs gepostet, beginnt Google mit dem Roll Out einer technischen Änderung bei den Referrern der geklickten Suchergebnisse. Der Referrer erhält in Zukunft die Ziel-URL sowie die Position des geklickten Suchergebnisses als Parameter. Darüber hinaus kann jeder anhand der Referrer URL erkennen, ob es sich um ein gesponsorten Link (Adword) oder um ein “natürliches Ergebnis” der Suche handelt.

Beispiel für die Referrer-URLs von Google:

Bisherige Referrer-URL:

http://www.google.com/search
hl=en
q=flowers
btnG=Google+Search

Neue Referrer-URL:

http://www.google.com/url
sa=t
source=web
ct=res
cd=7
url=http%3A%2F%2Fwww.example.com%2Fmypage.htm
ei=0SjdSa-1N5O8M_qW8dQN
rct=j
q=flowers
usg=AFQjCNHJXSUh7Vw7oubPaO3tZOzz-F-u_w
sig2=X8uCFh6IoPtnwmvGMULQfw

Dies hat insofern Auswirkungen auf die Web Analytics Tools, als dass diese normalerweise die Referrer Informationen dazu benutzen, Statistiken über Suchwörter je Suchmaschine zu erstellen. Dazu muss der URL-String analysiert und ausgewertet werden. Sofern Annahmen an das derzeitige Format gemacht werden, kann es bei diesen Tools zu Problemen kommen, die sich ein einem vermeintlichen Abfall der Zugriffszahlen über natürliche Suche bemerkbar machen.

Da Google den Roll Out über seine dezentrale Infrastruktur durchführt, kann es in einer Übergangszeit dazu kommen, dass sowohl altes als auch neues Format bei einer Website auftreten werden und zu diesem Effekt führen, wenn das Web Analytics Tool darauf nicht vorbereitet ist. Wer jedoch Google Analytics nutzt, braucht sich darüber keine Gedanken machen. Die neuen Referrer-URLs werden auf die GA-Reportings keine Auswirkung haben.

Im Weiteren ist es spannend zu beobachten, wann die ersten Hersteller ihre Produkte dahingehend angepasst haben, dass die jetzt zusätzlichen Informationen (Position, Art des Ergebnisses, in der Beispiel URL oben fett markiert) auch in den Statistiken verwendet werden.

>> Google Analytics Blog
>> Callmetrics Blog



am 16. April 2009 unter Technik

Analyse und Referrer

Vielfach werden wir von Kunden angesprochen, warum die Herkunft von Besuchern Ihrer Website überhaupt nicht erkannt werden kann. Schuld ist der im Request fehlende Referrer.

Über ein Feld im HTTP Prtotokoll kann (kann!) der Browser Informationen über die Herkunft eines Klicks  weitergeben. Der Referrer enthält üblicherweise die URL der Seite, die den Link auf die eigene Site  enthielt. Mitunter wird diese Information jedoch nicht in den Statistiken angezeigt. Die Gründe hierfür sind vielfältig, zunächst mal schematisch, was wirklich abläuft:

Es wird immer nur die unmittelbar vorherige Seite als Referrer angegeben. Beispiel:
Seite A enthält einen Link auf Seite B, diese wiederum auf Seite C. Verfolgt ein Benutzer nun diese Kette  von Links, so übermittelt der Browser mit den Requests die folgende Kette von Referrern:

Seite A —> Seite B (Referrer A) —> Seite C (Referrer B)

Wenn nun C die eigentliche Zielseite ist, und B lediglich eine Zwischenseite, die für den Anwender  unsichtbar den Browser “umleitet” (Redirect), dann kann die Seite B niemals die ursprüngliche  Absprung-Adresse enthalten.

Redirects

Teuflischer Grund für diesen Effekt sind Redirects – Es gibt zwei Sorten von Redirects: Serverseitige und  Clientseitige.

Erst mal zu den Serverseitigen: Der Server antwortet auf eine URL mit einem HTTP Status (30x), der den  Browser über eine neue Adresse der Seite informiert. Dies ist der korrekte Weg für Redirects und auf diese  Art und Weise geht der Referrer nicht verloren. In der Statistik steht die korrekte Absprungadresse.

Schlecht ist der billige Hack mit Javascript oder META Redirects. In beiden Varianten der clientseitigen Redirects lädt der Browser erst die ursprüngliche Seite um dann den Code (META oder Javascript)  auszuführen. Dieser Code lädt dann die eigentlich Zielseite. Diese hat als Referrer immer die Zwischenseite  mit dem META- oder Javascript-Code.

Pech für die Statistik: aus ihr geht nicht mehr hervor, von woher der Aufruf der Seite ursprünglich wirklich kam.

Abhilfe kann hier wirklich nur eine Umgestaltung der Website schaffen, in dem ein korrektes Verfahren für den Redirect verwendet wird, oder aber die vorherige Seite ebenfalls mit in die Statistik einbezogen wird. Geht dies nicht, weil diese zum Beispiel bei einem Hosting-Anbieter liegt, hilft hier sogar nur ein Wechsel der gesamten Infratstruktur weiter – oder man verzichtet auf diese wichtige Information.


am 25. April 2004 unter Analytics