Über Web Analytics wurde an dieser Stelle schon eingies geschrieben, zum Beispiel über Begrifflichkeiten wie Hits, Page Views und Visits, wie man Web Analytics zielorientiert nutzt oder wie man die interne Suchfunktion analysiert und optimiert.
An einem Vortrag an der diesjährige Orbit-IEX haben wir uns für einmal ausschliesslich darauf fokussiert, wie Web Analytics in der Praxis angewendet wird und was die Erfahrungen von Unternehmen damit sind. Das Referat Web Analytics in der Praxis [pdf, 2,7 MB] wurde gemeinsam von namics und Unic gehalten. Mit zu den gezeigten Beispielen zählten unter anderem:
- Online Verkaufssteigerung mittels E-Mail bei Wander
- Multi Channel Kampagnen bei SES Astranet
- Newsletter-Kamapgne mit Segmentanalyse bei Pfister

Die Quint-Essenz aus all den Erfahrungen:
- Zuerst ein Messinstrument wie Omniture SiteCatalyst, Webtrends oder Google Analytics einführen
- Die richtigen Leute innerhalb des Unternehmens involvieren (Produkt Manager, Marketeer, Web Verantwortliche etc.)
- Sich über die Ziele der Website im Klaren sein
- Micro- und Macro-Conversions messen und Conversion-Pfade optimieren
- Monetären Gegenwert einer Conversion schätzen um ROI berechnen zu können
- Kleine Änderungen vornehmen und wieder messen - anstatt nur Auswertungen anschauen

Neben Web Analytics hat namics zahlreiche weitere Vorträge an der Orbit-IEX gehalten, zum Beispiel zu Content Management System Migrationen oder der agilen Software-Entwicklung .

Eine dauernde aber auch wichtige Diskussion ist die, mit welchen Browser-/Plattformkombination eine Online-Anwendung funktionieren soll resp. getestet wird. Besonders spannend an der Frage ist zudem, dass sich dieses Umfeld dauernd ändert.

>> Einleitung

Grundsätzlich muss es Ziel sein, dass eine Anwendung mit allen Browser (technisch korrekter „User Agents“) funktioniert. Selbstverständlich heisst das nicht, dass die Anwendung nicht in allen Browsers identisch aussieht. Das würde der Heterogenität des Internets nicht gerecht und ist technisch nicht möglich... Als Vergleich kann Fernsehen hinhalten, wo das identische Programm auch je nach "Endgeräte" unterschiedlich „gezeigt“ wird.

Ziel muss es zudem sein nicht gegen Browser zu codieren aber für den Standard zu implementieren und danach für einzelne Browser zu optimieren. Idealerweise wird zudem im Code nicht auf einzelne Browser getestet aber auf vorhandenen Funktionalitäten des User Agents. Serverseitige Browserweichen sollten vermieden werden, wenn sich die Unterschiede im CSS lösen lassen.

Ich beschränke mich hier mal auf die Standardfunktionen wie (X)HTML, CSS und ein bisschen (defensives) JavaScript und lasse mich nicht auf die Flash-, Java-, Silverlight und Weiss-ich-nicht-was-Diskussion raus.

>> Lösung 1: Reale Benutzerbasis

Es ist sehr einfach zu messen, welche Browser auf einem konkreten Webangebot genutzt werden. Diese Statistiken bekommt man zudem von anderen Betreibern und man kann solche auch kaufen.

Zwei Aspekte sind wichtig: Einerseits, dass die Statistik falsch sein kann, wenn das aktuelle Angebot gewisse Kombinationen ausschliesst oder sehr schlecht behandelt (Huhn-Ei Problem). Und andererseits fehlt der Ausblick auf neue, stark verbreitete Browser („wann kommt der IE8“) resp. der Einbezug der Browserüberwachung während des Betriebs (was verändert sich grad).

Nun „nur noch“ die Frage, wo soll ich die Grenze des Tests ziehen. 95% aller Browser testen? Oder die 3 wichtigsten Kombinationen je auf Windows und Macintosh? Und was ist mit Linux und den verschiedenen Versionen der Betriebssysteme? Und das iPhone? Etc. Diese Definition muss mit Blick auf die Zielgruppe und die konkrete Anwendung gemacht werden. Zur Illustration ein Beispiel. Hier er aktuelle Monat einer reichweitenstarken B2B Anwendung mit 75% des Traffics aus der Schweiz.

i) Übersicht, welche Browser/Plattformen

ii) Details für den Internet Explorer

iii) Details für Firefox

iv) Details für Safari

Was wäre der Schluss? Will ich Windows und Mac unterstützen und ist meine Grenze 95% aller Nutzer, so teste ich gegen Windows/IE 7, Windows/IE 6 und Windows/Firefox 2. Auf dem Mac wäre es dann rechnerisch nur Safari 2. Punkt.

Und dann käme noch der "Menschenverstand" (ausserhalb der 95%) dazu, der einige Kombinationen ergänzt. Ich würde Mac/FFxo2 noch testen (der ist ziemlich mies in JavaScript Performance). Zudem kommt bald der Win/IE 8 (soll ich eine Beta-Version wirklich testen -- ich meine ja) und Mac/Safari 3. Zudem evt. Mobile Browser.

Noch nicht berücksichtigt sind nun verschiedenen Versionen des Mac OS und von Windows, welche (leider) auch einen Einfluss auf Funktion und Darstellung haben können. Und mindestens die 984 User mit dem IE 5.5 (eine Uraltversion auf MAC, welche sich sehr hässlich verhält) werden sich beklagen. Aber wo zieht man die Grenze?

>> Lösung 2: Die Libraries

Im Zeitalter von Nutzungsschnittstellen mit Web 2.0-Funktionalität (aka AJAX) versuchen die Entwickler (hoffentlich) nicht alles neu zu erfinden, aber nutzen Bibliotheken, welche die Umsetzung Vereinfachen und die Qualität erhöhen. Davon gibt es viele und alle sind mit gewissen Browsern getestet. Da sich die Entwickler sehr intensiv damit beschäftigen ist die Lösung Nummer 2 deren Empfehlungen zu folgen. Als Beispiel die Unterstützung der Yahoo Bibliothek YUI.

Die Fussnote besagt, dass immer die aktuellste Nicht-Beta-Version getestet wird.

Ich finde die Variante 2 (auch mit anderen Libraries) eigentlich ziemlich charmant, da hier bereits viel Wissen drin steckt. Es bleibt meine Zielgruppe zu prüfen (ist die Kombination relevant) und eine Aufwand/Nutzen-Betrachtung bezüglich der investierten Zeit.

Jean-Marc Vandenabeele hat sich die Mühe gemacht, siebzig (nicht genannte) Schweizer Websites nach Tracking-Codes von Analytics-Lösungen abzusuchen. Ohne es auszusprechen sagt er damit, dass Logfile-basierte Lösungen keine vernünftigen Analytics-Lösungen sind (was auch stimmt). Was er eventuell vergessen hat, sind Lösungen die mit einem Proxy funktionieren die entweder die URL umschreiben (sehr hässlich) oder mit Pseudosockets / Cookies arbeiten. Drei interessante Aspekte:

1) Rund 40% der untersuchten Schweizer Websites nutzen kein clientseitiges Tracking

2) Mit Abstand die häufigste Lösung ist mit 25% Google Analytics, danach kommt Webtrends und dann Hitbox

3) Die allermeisten Sites nutzen die Lösung als "Software as a Service" und nur run 20% betreiben die Lösung selbst (was ich für eine Internetsite sehr empfehle).

Hier zum ganzen Bericht: Web Analytics in Switzerland

Ich hoffe, dass nun dem den Status der Geheimwissenschaft endgültig überwunden ist und auch Entscheider einen realistischeren Blick auf die Erfolgsmessung im Internet bekommen. Ein knapper Artikel im Economist unter dem Titel "Many ways to skin a cat", der den Nagel auf den Kopf trifft: "The web is an open book compared with those old media" aber viele haben Mühe, auf welche Metrik nun geschaut werden soll.

Beispielsweise Page Views (aus den 90ern) entliehen aus der Offline Welt ("many advertisers are still used to counting pagination in magazines") und mit Web 2.0 wohl ziemlich untauglich geworden. Oder User Sessions die leider nicht Aktionen von Menschen messen, aber Aktionen von Webbrowsern.

Ein lesenswerter Artikel und bei uns schreiben wir über genau diese Domäne in der Kategorie Web Analytics und oder das Whitepaper dazu bei namics mit dem Titel Web Analytics: Zielorientierte Nutzung zur Erfolgssteigerung.

Und wer sind die grössten/längsten/weitesten (nach Economist / comScore)?

Es gibt verschiedene Search Analytics Kennzahlen, von denen ich schon über einige berichtet habe. Interessant ist das Beispiel von Jan Pedersen von Yahoo, welches er im Rahmen der Vorlesung "Search Engines: Technology, Society, and Business" organisiert von Marti Hearst an der UC Berkeley gezeigt hat.

Yahoo nimmt die Suchsessions, bei denen mindestens ein Link auf der Trefferliste geklickt wird. IN der Menge rechnen sie den durchschnittlichen Rang (1 zuoberst, 12 der zweite Treffer auf der zweiten Suchtrefferseite) des zuletzt des letzten in der Session geklickte Resultates der Trefferliste. Je kleiner die Zahl, desto besser die Rangierung. Und so sah die Graphik nach einem grossen grossen Update (um 04-07) aus. In der Erklärung spricht Pedersen [Podcast, mp3] jedoch von inversem Rang (1/Rang), doch das würde weder die absolute Zahl noch das negative Vorzeichen erklären...

Bei mit im Post zu der Rangliste war das die Kennzahl Nummer 3... nur leider hat mir die schöne, öffentliche Graphik gefehlt. Danke Jan! Da der Titel des Charts Metric 11 heisst, hätte ich die restlichen auch noch gerne ;-)

Die auf Fakten basierte Optimierung von Webanwendungen ist wichtig und als Web Analytics ein zentrales Gebiet der Arbeit von namics.

Dazu kommt nun der Mobile Bereich (bspw. Eigenwerbung unserer Mobile Portal Lösung: http://blog.namics.mobi) , bei welchem die selben Gedanken wichtig sind, die Domäne aber noch viel weniger Erfahrung und Zahlenmaterial zu bieten hat.

Einen Schritt vorwärts macht nun der Vermarkter mobiler Werbung AdMob, indem er eine Zusammenfassung einiger Zahlen publiziert: http://www.admob.com/metrics/. Leider nicht die interessanten und leider auch keine gute Zahlenbasis für Europa. Dennoch sind die Zahlen interessant bezüglich der Verbreitung der Endgeräte und deren Fähigkeiten. Hier eine Ausschnitt aus der Statistik September 2007, Welt und zwar die Gerätetypen, welche Werbung angeschaut haben (Stichprobe 1,5 Mia. Impressions). Die hohe Anzahl der Motorola Razrs kommt aus dem starken Übergewicht des amerikanischen Marktes (in allen anderen Ländern gibt es das Gerät kaum).

Eine witzige Visualisierung einiger Statistikdaten findet sich beim selben Hersteller hier: http://www.admob.com/s/home/live

Ziele gehören (im Voraus) definiert und danach gemessen und optimiert. So auch bei Websites und Web-Anwendungen: Hier heisst diese Domäne Web Analytics, eine Weiterentwicklung der Logfile-Analyse resp. Webstatistik mit einem betriebswirtschaftlichen Blick und anderen Werkzeugen. Dieser Post ist eine Zusammenfassung bereits publizierter Artikel und dient der Verlinkung.

Eine gute Zusammenfassung findet sich in unserem Whitepaper: Web Analytics Zielorientierte Nutzung zur Erfolgssteigerung. Wer weniger lesen will, die folgenden Posts:

- Begriffe und deren Probleme
- Kennzahlen und deren Eignung
- Lügen resp. häufige Fehler bei der Webstatistik

Mehr und aktuelle Informationen findet sich im Archiv: Web Analytics. Angebote, Produkte und Fallstudien finden sich auf auf der Homepage von namics zur Web Analytics.

Das wichtigste bei einer Suche ist die Überwachung des Betriebs und die dauernde Optimierung. Der Prozess dazu heisst Search Analytics. Dieser Post ist eine Zusammenfassung bereits publizierter Artikel und dient der Verlinkung.

- Kennzahlen um die Query (Teil 1)
- Kennzahlen um die Trefferliste (Teil 2)
- Kennzahlen um den Index (Teil 3)

Mehr Informationen zum Thema Analyse im Internet findet sich im Archiv: Web Analytics sowie zum Thema Informationssuche im Archiv: Information Retrieval. Angebote dazu finden sich auf auf der Homepage von namics zur Web Analytics und zu Information Retrieval.

PS: Ich schreibe grad meinen Vortrag "Eine gute Suche als kritischer Erfolgsfaktor" am 25. September an den xdays in Interlaken und möchte die drei oben genannten Post verlinken.

Ich hatte mich (in der Kategorie Web Analytics) auch schon mit Definitionen abgemüht. Nun habe ich von der Web Analytics Association eine klare Definition gefunden der wichtigsten Begriffe gefunden. Zur Zeit nur auf Englisch aber sicher heilsam um Verwirrungen zu vermeiden (und auch im Detail gut gemacht z.B.Unique Visitor ist "filtered for spiders and robots").

Hier eine Übersicht über die enthaltenen Terme und unten das PDF.

> Page: A page is an analyst definable unit of content.

> Page Views: The number of times a page (an analyst-definable unit of content) was viewed.

> Visits/Sessions: A visit is an interaction, by an individual, with a website consisting of one or more requests for an analyst-definable unit of content (i.e. “page view”). If an individual has not taken another action (typically additional page views) on the site within a specified time period, the visit session will terminate.

> Unique Visitors: The number of inferred individual people (filtered for spiders and robots), within a designated reporting timeframe, with activity consisting of one or more visits to a site. Each individual is counted only once in the unique visitor measure for the reporting period.

> New Visitor: The number of Unique Visitors with activity including a first-ever Visit to a site during a reporting period.

> Repeat Visitor: The number of Unique Visitors with activity consisting of two or more Visits to a site during a reporting period.

> Return Visitor: The number of Unique Visitors with activity consisting of a Visit to a site during a reporting period and where the Unique Visitor also Visited the site prior to the reporting period.

> Entry Page: The first page of a visit.

> Landing Page: A page intended to identify the beginning of the user experience resulting from a defined marketing effort.

> Exit Page: The last page on a site accessed during a visit, signifying the end of a visit/session.

> Visit Duration: The length of time in a session. Calculation is typically the timestamp of the last activity in the session minus the timestamp of the first activity of the session.

> Referrer: The referrer is the page URL that originally generated the request for the current page view or object.

> Internal Referrer: The internal referrer is a page URL that is internal to the website or a web-property within the website as defined by the user.

> External Referrer: The external referrer is a page URL where the traffic is external or outside of the website or a web-property defined by the user.

> Search Referrer: The search referrer is an internal or external referrer for which the URL has been generated by a search function.

> Visit Referrer: The visit referrer is the first referrer in a session, whether internal, external or null.

> Original Referrer: The original referrer is the first referrer in a visitor’s first session, whether internal, external or null.

> Click-through: Number of times a link was clicked by a visitor.

> Click-through Rate/Ratio: The number of click-throughs for a specific link divided by the number of times that link was viewed.

> Page Views per Visit: The number of page views in a reporting period divided by number of visits in the same reporting period.

> Page Exit Ratio: Number of exits from a page divided by total number of page views of that page.

> Single-Page Visits: Visits that consist of one page regardless of the number of times the page was viewed.

> Single Page View Visits (Bounces): Visits that consist of one page-view.

> Bounce Rate: Single page view visits divided by entry pages.

> Event: Any logged or recorded action that has a specific date and time assigned to it by either the browser or server.

> Conversion: A visitor completing a target action.

Download: Web Analytics Definitions Version 4.0 [pdf, 200KB]

Quelle: Avinash Kaushik

Der Internetmarkforscher (stimmt der Begriff?) Nielsen/NetRatings ergänzt seine Nutzungsmessungen um "Time Per Person", also die Verweildauer des Users auf dem Angebot. Danach gleich noch eine Pressemitteilung [pdf, 128KB], nach welcher danke der neuen Messmethode MSN Google in der Schweiz schlägt...

Eine Revolution (so wie bei AP getitelt "Nielsen scraps Web page view rankings")? Nein und bitte ganz geschmeidig.

Beginnen wir mal mit der tollen Tabelle oben: Danach hat MSN eine um den Faktor 10 höhere Verweildauer. Was wird den da wohl gemessen - der Chat :-) So könnte ja auch sein, dass bei einer Suchmaschinen eine kurze Zeit zur Beantwortung besser ist u.s.w.

Zugegeben, die "gute alte" Page Impression oder eben auch der Page View haben in Zeitalter von AJAX (Navigation ohne Reload) und Online Video wohl ausgedient. Ganz ehrlich. Ich fand die die Zahl schon immer überflüssig... Aber auch die Verweildauer hat sehr viele Schwächen. Wie steht es mit Multi Tab Browser, Feeds (RSS/Atom), Online Games, Music Streaming, in das Betriebssystem integrierte Widgets...

Vorschlag. Ganz oben steht das Geschäftsmodell einer Site. Verdiene ich mein Geld mit Page Views, so kann die Zahl vernünftig sein (ich hoffe aber nicht). Normalerweise sollte es es sich aber um Transaktionen drehen und so messe ich bitte Anzahl erfolgreiche Transaktionen plus deren Konversionzahlen und die Werbeeffektivität etc.

Also nicht nur Kennzahl aber Geschäftsmodell -> Kennzahl. Und sorry so gibt es möglicherweise keine Ranglisten mit allen Teilnehmern drauf... aber die Messung ist viel nützlicher.

Es ist ja nun doch schon etwas länger als einen Monat her, als Google die neue Version von Google Analytics freigegeben hat.

Diejenigen, die sich noch nicht an die neue Oberfläche gewöhnen mochten, konnten parallel dazu noch die alte Variante verwenden. Vermutlich auch weil die alte Version nun bald (mitte Juli) abgeschaltet werden soll, hat Google nochmals nachgelegt und einige Verbesserungen integriert.
Zwei Änderungen finde ich besonders wichtig:

• Viele "Visit"-bezogene Auswertungen (Visits, Page Views, Time On Site, ...) kann man nun auch wieder im Tagesverlauf betrachten.
  
• Überall dort, wo in den Reports externe Links vorkommen (z.B. bei Top Content oder Referring Sites) ist nun ein Icon integriert, das direkt auf die entsprechende Seite im Internet verlinkt. So kommt man ganz bequem zur betroffenen Seite. Aber Vorsicht: Wer die URL für das Reporting mittels Filtern in Google Analytics umschreibt (z.B. damit die Statistik besser lesbar wird) hat leider Pech gehabt - die Links zeigen in diesen Fällen and den falschen, weil nicht vorhandenen Ort.
  

Alles in allem dürften nun nur noch wenige die alte Oberfläche vermissen, doch die Arbeit geht Google noch nicht aus. Ich hoffe sie überarbeiten als nächstes die Konfiguration und integrieren mehr Eingabehilfen und Tests. Denn beim Einrichten eines Analytic-Profils kommt man um das Studium der Onlinehilfe oft nicht herum.

Letzter Teil einer Serie über Kennzahlen der Suche. Ziel ist es, die Qualität der (Volltext)suche zu messen und somit faktenbasiert zu verbessern. Also keine emotionalen Diskussionen darüber, wie die Trefferliste rangiert (...das ist sowieso subjektiv...), aber eine Messung. Die Serie ist Teil der Der online Erfolgsmessung: Web Analytics und unserer Arbeiten zur Informationssuche allgemein: Information Retrieval. Die zwei Posts bis jetzt:

> Kennzahlen um die Trefferliste
> Kennzahlen um die Query

Und nun der Index. Der Index ist die (technische) Datenstruktur, welche die auffindbaren Elemente enthält. Wichtige Aspekte sind dessen Vollständigkeit (sind alle gewünschten Elemente darin verfügbar?), die Aktualität (ist der Index synchron mit den originären Datenquellen?) und dessen Mächtigkeit (welche Funktionen bietet der Index an wie beispielsweise die Suche nach Phrasen oder die Evaluation von Wortabständen?). Aber bei der Suchanalyse bitte nur das messen, was wirklich auch angepackt d.h. verändert wird. Daher schlage ich nur eine Kennzahlen vor:

1) Anzahl suchbare Elemente.

zu 1) Sie wissen wie viele Seiten ihr Angebot hat. Stimmt diese Zahl mit dem Suchindex überein? Einfach, aber einige Fragen gilt es zu klären so wie: Gibt es unterschiedliche Ansichten des selben Inhaltes beispielsweise eine Druckansicht jeder Seite? In die Suche gehört nur eine der Repräsentationen (da es sich bei der anderen faktisch um ein Duplikat handelt). Oder: Wie werden Seiten gehandhabt, welche mehrere binäre Dokumente "drauf haben" (insb. PDF)? Normalerweise gibt es pro PDF einen Indexeintrag (konvertiert nach HTML , mit einer eigenen URL) und zudem noch einen Eintrag für die Verteilerseite selbst, da dort hoffentlich auch ein paar nützliche Informationen untergebracht sind.

Wenn die Kennzahl plötzlich sinkt? Es mag einen echten Grund geben, so beispielsweise wurden Seiten der Präsenz deaktiviert und gehören somit raus aus dem Index. Häufiger sind aber Berechtigungsprobleme weil plötzlich etwas in der Konfiguration geändert wurde oder andere technische Probleme wie die Erreichbarkeit einer der Quellen o.ä. Oder auch sehr beliebt Template-/HTML-Änderungen nach denen der Crawler die Links nicht mehr erkennt (JavaScript und Flash lässt grüssen).

Wenn die Kennzahl plötzlich steigt? Klar: Sie haben neue Inhalte publiziert ;-) Auch beliebt sind sogenannte "Crawler-Traps" d.h. der Crawler indexiert denselben Inhalt mehrfach oder gar endlos. Grund sind meist technische Änderungen insb. an der ULR (z.B. Session IDs) oder an der Serverkonfiguration.

Somit wünsche ich Ihnen alle Verbesserungen bei Ihrer Suche. Es lohnt sich die Zahlen anzukucken!

Im Rahmen der Webanalyse und auch der Suchanalyse häufig erwähnt: Die Wichtigkeit der Saisonalität. Nun habe ich ein paar sehr schöne Publikationen von Nadine Höchstötter geb. Schmidt-Mänz gefunden. So beispielsweise "A Classification of Search Terms" [pdf, 2.2 MB] oder diesen Blog Post. Und hier ein paar Beispiele:

>> "Maifliegen" (immer wieder zu selben Zeit) -- z.B. "juni"

>> "Anlässe" (einmalig erwartet oder unerwartet) -- z.B. "tsunami"

>> "Impulse" (plötzlich wichtiger werden) -- z.B. "backstreet boys" gegen "tokio hotel"

>> "Evergreens" (wie der Name sagt) -- z.B. "Kamera"

u.s.w. sehr schön. Bei Frau Höchstötter geb. Schmidt-Mänz gibt es statistische Formeln dazu ;-)

In Rahmen eines Test hat die amerikanische Firma Stone Temple Consulting auf vier Websites unterschiedliche Web Analytics Lösungen implementiert und die quantitativen Resultate verglichen. Die betrachteten Systeme waren Clicktracks, Google Analytics, IndexTools, Unica Affinium NetInsight und WebSideStory HBX Analytics. In einem Fall diente als Baseline auch noch Web Trends.

Im Interims Report weichen die quantitativen Messergebnisse der verschiedenen Lösungen voneinander ab, doch waren die Abweichungen weder siginifikant noch systematisch (die Reihenfolge wer misst mehr und wer weniger).

Zur Frage nach dem Unique Tracking über Cookies: Eine der Fragen, welche vor allem Werbetreibende interessiert (die noch nicht auf die Messung von Transaktionen umgestiegen sind). Für sie sind Unique Visitors die Reichweite. Technisch wird dafür ein Cookies gesetzt, welches der Lösung ermöglicht zu erkennen, ob der User eindeutig ist. Bereits dieser Teil der Messung birgt schon einige Unwegbarkeiten über die ich bereits gesprochen habe.

Im Bericht von Stone wird die Frage disktuiert, wie viele User Cookies nicht akzeptieren resp. Cookies löschen und damit die Messung beeinflussen. Ein wichtiger Einflussfaktor ist, ob das Cookie von auf die Domäne der Messpartei (z.B. websidestory.com) oder auf die der Site selbst (z.B. namics.com) gesetzt wird. Erstere werden deutlich häufiger gelöscht, da Sicherheits-/Spyware-Tools wie Ad-Aware solche Third Party Cookies (TPC) als "schecht" taxieren und somit mehr User zum löschen ebendieser "ermutigt". Bei First Party Cookies (FPC) muss der User selbst aktiv werden.

Hier die Ergebnisse, welche vergleichbar sind mit den anderen Studien die ich kenne:

> Nicht Annahme bzw. Löschung von TPC: 13%
> Nicht Annahme bzw. Löschung von FPC: 2%

Somit wäre es wiedereinmal gemessen. Ein intelligenter Kommentar von Jim Sterne zu den Unterschieden während Messung: "...if your yardstick measures 39 inches instead of 36 inches, it's still great to have a measurement tool. The yardstick will still help you measure changes with a great deal of accuracy." Sehr gut gedacht!

Nach einem ersten Teil "Search Analytics - Kennzahlen um die Query", hier der zweite Streich. Ziel ist es weiterhin die Effektivität der Suche ("Suchmaschine") faktenbasiert zu verbessern. Also nicht ein Zaub(d)erer, der mit viel warmer Luft erklärt was zu tun ist, niemand ihm folgen kann und nach der Änderung immer noch alle unglücklich sind aber: Zahlen. Das ganze ist ein Teil von Web Analytics: Der Erfolgsmessung im Internet. Erlauben Sie zuerst die folgende Erklärung.

Die Ellipsen zeigen typische Zustände ("Seiten") einer Suchanwendung. Das Suchfeld (mit sehr wenigen Optionen beispielsweise auf jeder Seite rechts oben), die erweitere Suchmaske (mit allen Optionen), die Trefferliste (gerne auch mit SERP = Search Engine Result Page abgekürzt) und das Zieldokument (das in der Trefferliste verlinkte Ziel).

Alle Übergänge sind im Rahmen der Navigation möglich. So zum Beispiel gebe ich im Suchfeld einen Begriff ein und lande (nach dem Klick auf dem "Suchen"-Button über Pfeil 1 auf der Trefferliste. Dort blättere ich eine Seite, da ich in den Zitaten das Gesuchte nicht zu finden meine (über Pfeil 2) und schlussendlich wähle ich einen Eintrag der zweiten Trefferliste und lande über Pfeil 3 auf dem Zieldokument. Viele andere Wege sind möglich: Von der Trefferliste zurück zum Suchfeld, vom Zieldokument zurück zur Trefferliste etc. Und nun zu den Zahlen:

1. Auswahlhäufigkeit (Selection Ration)
2. Suchabbruch (Search Abandonment)
3. durchschnittliche Ranglistenposition gelickter Treffer
4. in der Trefferliste geklickte URLs
5. aufrufende Seite

Auch hier wieder gehören die Werte wieder zyklisch ausgewertet etc.

zu 1) Die Auswahlhäufigkeit ist die Anzahl der Suchanfragen, bei denen User in der Trefferliste auf mindestens einen Treffer klicken geteilt durch die Anzahl der Suchanfragen. Führt ein User eine Suche aus und klickt auf einen Treffer der Trefferliste, so steht die (statistische) Chance gut, dass er fündig wurde. Das Verhältnis ist 1. Bei einem kleineren Verhältnis führt der User mehrere Suchanfragen aus, klickt aber weniger Treffer. Dies ist ein Hinweis, dass das Gesuchte nicht im Index ist (gar nicht auf der Trefferliste erscheint), die Rangierung schlecht ist oder das Trefferzitat eines relevanten Eintrags nicht zu einem Klick verleitet. Und ist die Auswahlhäufigkeit grösser Eins, so wählt der User zu wenig Suchanfragen sehr viele Kandidaten für einen Treffer, kommt aber immer wieder zur Suche zurück, da das gewählte Zieldokument sein Informationsbedürfnis nicht befriedigt hat.

zu 2) Der Suchabbruch ist der Fall, bei dem User nach einer Suche auf null Treffer klicken. Die Kennzahl das Verhältnis der Abbrüche zur Anzahl Suchanfragen. Um dies festzustellen, muss ein geeignetes Zeitintervall festgelegt werden, wie lange ein einzelner Suchprozess (Session) maximal dauern darf. Bspw. 5 Minuten. Eine gute Kennzahl ist möglichst tief.

zu 3) Die durchschnittliche Ranglistenpposition ist eine Aussage zur Rankingqualität aus Usersicht und erlaubt, je nachdem ob die Trefferliste immer gleich lang ist resp. die Anzahl Einträge pro Rangliste im Tracking bekannt sind, auch die Berechnung wie häufig zwischen Ranglisten geblättert wird. In der oberen Graphik ist dies der Übergang 2 und eine tiefe Kennzahl nahe bei 1 (der gelickte Treffer ist immer auf Rang 1) ist optimal.

zu 4) Die in der Rangliste geklickte URLs ist keine Kennzahl, dennoch eine wertvolle Aussage. Sozusagen eine BottomUp-Sicht darauf, welche Zielseiten regelmässig über die Suche gefunden werden. Diese Seiten sind Kandidaten für eine höher Gewichtung in der Informationsarchitektur ("ab auf die Hompage"), aber auch Kandidaten für hervorgehobene Top Treffer in der Rangliste. Achten Sie hier auf die Saisonalität der Suchanfragen.

zu 5) Auch keine Kennzahl. Die Seiten, aber welcher die Trefferliste aufgerufen wurde (der Referrer). Haben Sie beispielsweise auf jeder Seite oben rechts ein Suchfeld, so kann der Ursprung der Suchanfrage ganz unterschiedlich sein. Stellen Sie beispielsweise fest, dass regelmässig im Bereich der Pressemitteilungen gesucht wird (die per Zufall leider alle als PDF angebiten werden). Diese Erkenntnis ist auch Grundlage für Gewichtung von Inhalten und für spezialisierte Suchfunktionen.

Soweit so gut. Für Frage und Bemerkungen bin ich gerne zu haben und es folgt noch ein dritter Teil über Kennzahlen um den Suchindex.

Zusammen mit Michael Fischer von Unic (man sieht es an der hässlichen PPT-Fusion, wir wollten für User ein gemeinsames Handout anbieten) behandeln wir heute das Thema der Analyse und Optimierung von Websites im Überblick. Mehr Information auf diesem Weblog in der Kategorie Web Analytics und hier der Vortrag.

Hier der Download: Web Analytics und Site-Optimierung [pdf, 4.5MB]

Die Suche („Suchmaschine“) ist nie gut genug und die Möglichkeiten der Anpassungen, Einstellungen, Optimierungen und Änderungen sind zahlreich. Doch wie stelle ich als Betreiber fest, ob die Veränderung auch eine Verbesserung war?

Genau wie bei der Usability gibt es KEINE Formel, aber schlussendlich entscheiden auch bei der Suche Menschen mit ihrem spezifischen Vorwissen, ihrem Kontext etc. mittels Test über die Qualität resp. die Effektivität. Einiges habe ich dazu im Umfeld der (subjektive) Relevanz bereits darüber geschrieben.

Hier eine weitere wichtige, quantitative Betrachtung als Serie: Search Analytics. Die Anwendung der Webanalyse auf die Suchfunktion: Zwischen Suche und User findet ein Dialog statt: Erfolgreich oder erfolglos, doch das Ganze lässt sich gut auswerten und somit auch verbessern. Wie immer bei der Analyse sind die richtigen Kennzahlen (KPIs = Key Performance Indicators) wichtig. Hier ein erstes Set: Alles um die Query

Ja, Querylänge, Anzahl Worte in der Query etc. sind spannend. Aber Hand auf’s Herz: Was machen Sie damit? User verändern... kaum. Das es sich vor allem lohnt Sachen zu interpretieren auch welche zu Aktionen führen meine erste Auswahl:

1. Queries so wie eingegeben
2. Queries normalisiert
3. Queries mit 0 Treffern in der Suche
4. Queries mit 0 Klicks in der Trefferliste

Alle Werte sollen zyklisch ausgewertet werden (z.B: pro Monat). Dies, da es deutliche Saisonunterschiede aber auch Trends und neue Informationsbedürfnisse gibt. Nützlich zur Übersicht sind Tabellenspalten nach Queryanzahl rangiert mit Trendangaben wie bei einer Hitparade Top 20 und neu, rauf, runter, alter Rang.

zu 1) Die Top-Queries sind Anhaltspunkt für zusätzliche Inhalte, Änderung der Anordnung auf der Website oder auch zusätzliche Funktionen der Suche. So beispielsweise die Erkennung von Produktnamen in der Suche und eine spezielle Präsentation in der Trefferliste bspw. mit einem Bild und einem Direktlink zur Dokumentation. Als Beispiel die Verteilung der Queries eines Intranets. Stichprobe 12'859 Queries (ohne leere Anfrage), 5066 davon unterschiedlich. Die Graphik zeigt nur 50% aller Queries, die Y-Achse ist logarithmisch und zwischen zwei X-Achsen liegen 200 Werte.

(häufigste Query 149x pro Monat, bei Rang 200 (4% aller Queries) fällt die Häufigkeit auf 8 identische pro Monat resp. 2 pro Woche)

zu 2) Diese Liste liefert v.a. bei neu implementierten Systemen Hinweise auf technische Verbesserungen. Korrekterweise sind die folgende Queries identisch zu behandeln: Juerg, jürg, JÜRG, jUeRg oder auch Ségolène, segolene etc.

zu 3) Sehr wichtig! Es suchen mehrere Leute regelmässig nach Inhalten, welche die Site nicht anbietet, welche die Site zwar anbietet aber die Suche nicht erschliesst, oder welche die Site anbietet aber untern anderen Begriffen gefunden werden. Diese Liste ist Ausgangslage für Synonyme, Metadaten oder auch neuen Content.

zu 4) Am wichtigsten! Gibt es regelmässige Anfragen, welche (innerhalb einer Suchsession) zu keinem Klick auf der (populierten) Trefferliste führen, so lohnt es sich auf jeden Fall diesen nachzugehen... Die Verbesserungsansätze können zahlreich sein, meist ist es aber ein Problem der Ranglistenposition (Ranking) oder bei der Qualität der Trefferzitate in der Rangliste. Und hier noch eine Graphik darüber, wie viele Leute in der Rangliste klicken. Quelle ist ein Intranet (in welchem wegen der Suchaktivitäten systematisch häufig geblättert wird als bei einer Websuche). Wieder die 12'859 Queries innerhalb eines Monats.

(90% aller User blättern nicht [schauen max. 10 Treffer an], 6% blättern auf die zweite Seite [20 Treffer] und noch 2% auf die dritte [30 Treffer])

In ein paar Minuten beginnt die Fachtagung von namics zum Thema Web Analytics. Hier die Handouts in elektronischer Form.

> Downloads

- Web Analytics: Vom Datenfriedhof zum erfolgsorientierten Steuerungsinstrument [pdf, 830KB] Jürg Stuker, namics ag

- Analytics richtig nutzen und interpretieren: Besucherfluss-, Prozess- und Klickanalysen [pdf, 3,2MB] Rebekka Stüdli / Philipp Ebneter, namics ag

- Den Erfolg der Website steigern: Konversionen, Kampagnen- und ROI-Tracking [pdf, 5,5MB] Marco Hassler, namics ag

- Wie setzt V-ZUG Web Analytics ein [pdf, 4,1MB] Beat Kluser, V-ZUG

- Analytics im täglichen Gebrauch: Tipps für die Praxis [pdf, 7,4MB] Jürg Stuker, Marco Hassler, namics ag

Vor 3 Monaten, plauderte ich über die Verbreitung des Internet Explorer 7 und der Vermutung, dass viele Menschen den Windows Update nicht ausführen. Stichprobe war und ist eine öffentliche Schweizer Website (nicht *.namics.com) mit einer grossen Reichweite.

In der Zwischenzeit ist der Anteil stabil geblieben resp. ganz leicht gesunken (Jan 07: 25%, Feb 07: 25%, März 07: 26% und seit Beginn April 07: 28%).

(Graphik zeigt NUR Internet Explorer nach Versionen)

Ein paar Sachen benötigen länger als man glaubt... So richtig interessant und immer wieder Anlass zu einer Diskussion ist sicher dieses Graphiken mit den Top 3 Browser und deren Versionen. Basis März 2007 für ein Schweizer Portal.

Und hier die Versionen der drei Top-Browser.

Kommentare?

Ich war ganz ehrlich überwältigt von dem Interesse und dem positiven Echo, welches meine drei Blog-Posts über online Erfolgsmessung (Web Analytics resp. Online Business Intelligence) ausgelöst haben:

- Teil 1: Begriffe und deren Probleme
- Teil 2: Kennzahlen und deren Eignung
- Teil 3: Lügen resp. häufige Fehler bei der Webstatistik

Also doppeln wir nach!

1) namics hat (seit den Posts) ihr Wissen in diesem Thema in einem umfassenden Whitepaper zusammengefasst.

2) Am Donnerstag, 19. April in Zürich eine Fachtagung durch. Die Teilnahme ist gratis und es ist sowohl ein Kunde anwesend, wie auch der Autor des Whitepapers, zwei erfahrene Consultants wie auch ich als Verbrecher der ursprünglichen Posts. Der breit abgestützte Inhalt ist hier beschrieben inkl. der Anmeldung.

Viele Unternehmen wollen den Erfolg ihrer Website dadurch verbessern, dass sie durch Kampagnen und andere besucherfördernde Massnahmen mehr Traffic auf ihre Site bringen. Obwohl dies wichtig und richtig ist, sollte dies nicht erste Priorität haben. Da lediglich ein kleiner Bruchteil der Besucher das eigentliche Website-Ziel – z.B. Kauf eines Produkts, Klärung einer Frage, Bewerbung auf einen Job oder Kontaktaufnahme für ein Gespräch – erreicht, sollte zuerst dieser Anteil gesteigert werden.

Ein Weg wie man Kundenverlust minimiert, die Kundenzufriedenheit und die Konversionsraten erhöht, ist Web Analytics. Weiss man um den Nutzen von Web Analytics und setzt es richtig und konsequent ein, ist es ein Garant für effizientere und erfolgreichere Websites. Für Unternehmen, die mehr als 5% ihres Umsatzes online erwirtschaften oder diesen zumindest über den Onlinekanal in die Wege leiten, ist Web Analytics somit ein absolutes Muss.

Dieses Whitepaper zeigt, was Web Analytics kann und wie es genutzt werden kann, um den Erfolg von Websites zu steigern.

Download: Web Analytics: Zielorientierte Nutzung zur Erfolgssteigerung [pdf, 3MB]

Bei der Erfolgsmessung von Webangeboten (aka Web Analytics) sind die richtigen Kennzahlen wichtig. Analog dazu gibt es unterschiedliche Bezahlmodelle im Online Werbeumfeld. Da Google sich neu mit einem "limited Pay-per-action beta test" einen Schritt voranwagt, die folgende Übersicht.

>> Pay per Million (PPM) oder Pay Per View

Das ist sozusagen das Giesskannenmodell. Ich bezahle dafür, dass meine online Werbung möglichst vielen Augen gezeigt wird. Typisches Werbemittel sind Banner und zur Kontrolle von Streuverlusten steuere ich die Auslieferung entlang bestimmter Websites, Bereiche auf einer Site, sowie ein paar geographische, sprachliche und/oder demographische Einschränkungen. Bezahlen muss ich aber jedes Zeigen des Werbemittels. Die Effektivität resp. die Konversion zum Kampagnenziel ist das "Problem" des Werbetreibenden. Wenn die Konversion schlecht ist, dann erzählt meist ein (erfolgreich aussehender, dynamischer und gut gekleideter) Werbexperte etwas von Werbedruck und Markenerkennug als erreichtes Ziel ;-)

>> Pay per Click (PPC)

Ein bisschen fokussierter. Das Zeigen des Werbemittels ist gratis und der Werbetreibende bezahlt nur, wenn ein potentieller Kunde darauf klickt. Die Bezahlung ist somit anhängig von der Performance, welche durch den Klick definiert ist. Der Werbeschalter übernimmt damit einen Teil des Risikos für Werbung die nicht konvertiert. Typisches Werbemittel sind Textanzeigen in Suchmaschinen und die hitzige Diskussion findet entlang von Klick-Betrug statt. So kann der Werbeschalter seinen Umsatz durch "zusätzliche" Klicks in die Höhe treiben (oder ich könnte auf meinen Mitbewerber clicken und der muss dafür bezahlen).

>> Pay per Transaction (PPT) oder Pay per Action

Und nun wird es wirklich kompetitiv. Ich als Werbetreibender definiere mein Kampagnenziel, beispielsweise eine Bestellung, eine Newsletter Registrierung oder einen Download. Zudem definierte ich den Geldwert für ein erreichtes Ziel. Z.B. ein an einen Neukunden verkaufter ADSL-Anschluss ist mit CHF 100.-- wert. Nun brauche ich noch jemanden der meine Werbung für diesen Preis schaltet und ich bezahle nur für das erreichte Ziel. Ein solches Programm hat Google gestern als Test angekündigt. Eine Nuance dieses Modell ist Affiliate Marketing so wie bspw. Amazon es schon lange macht. Ist in einem eingehenden Link meine ID drin und wird das Produkt verkauft, so kriege ich eine Provision. Selbst um das Werbemittel (z.B. eine Buchblog) kümmere ich mich nicht.

An der Uni hatte ich (damals) einen ganzen Kurs drüber, wie Statistiken missbraucht werden können. Bei anonymisierten Durchschnittsdaten muss beispielsweise die Anzahl der Elemente genügend gross sein, um keine Rückschlüsse auf einzelne Elemente zu erhalten. So beispielsweise Abfragen Stil von "FIND durchschnittslohn WHERE beruf='Bundespräsident'". Abstrakt, nicht?

Dache ich auch, bis ich am Wochendende auf einer (zugegeben ganz) kleinen Site Google Analytics installierte und mir nun die Auswertung anschauten. Die sieht nämlich so aus:

Das ist nun wirklich praktisch. Ohne Ablenkung von irgendwelchen komplexen Hypothese weiss ich nicht nur, wo der "User des Tages" herkommt, ich kenne auch seine (geschätzte) Geolokalisierung, seinen Browsertyp mit allem drum und dran, seine Google-Query die ihn auf die Site beracht hat... Wahrscheinlich würde ich den User sogar finden in Oberägeri. Ein Pladoyer für Transparenz -- oder deutlich zu wenig Traffic ;-)

Das wichtigste (einzige) Geschäftsmodell von Google sind Textanzeigen, bei welchen der Werbetreibende pro Klick auf die Werbung bezahlt. Gegenüber anderer Werbeformen, welche einfach so "da sind" (und sich ein Berater dann den Mund bezüglich dem gigantischen Nutzen wund redet), war das eine wichtige Innovation. Dazu kommen noch weiter Aspekte wie die Möglichkeit die Textwerbung auf Stichworte, Seiteninhalt (bei AdSense), Geographie sowie andere Merkmale bei der Schaltung. Natürlich nicht nur bei Google...

Da Google (und die Websites, welche Google-Anzeigen weiter verbreiten) nur Geld verdienen, wenn auch gelickt wird, liegt es nahe, dass die Anzahl (resp. die Qualität) der Klicks in den Fokus rückt. So kann ich einem Mitbewerber Kosten "zufügen" resp. ihn aus der Auktion verdrängen, indem ich häufig auf seine Anzeigen klicke. Das Problem nennt sich "Click Fraud" (Klick Betrug) und dazu wurde schon sehr sehr viel geschrieben und gerätselt. So auf der Titelseite von Business Week, bei Wired oder auch der Sicherheitsexperte Bruce Schneier. Und an tausend anderen Orten.

Interessant und für Google unüblich ist, dass sie nun in die Offensive gehen und aktiv darüber informieren. So beispielsweise heute auf dem offiziellen AdWord Blog mit "Invalid Clicks – Google’s Overall Numbers".

Die Kernaussage (die es zu validiern gilt) ist: Rund 10% aller Klicks sind faul und werden von Google in Echtzeit oder durch eine offline Analyse als ungültig erkannt und dem Werbetreibenden nie verrechnet. Nur 0.02% (nach Aussage von Google) werden nachträglich als ungültig gemeldet und danach von Google (reaktiv) analysiert und gutgeschrieben.

Was Google nicht weiss und kaum sagen würde ist die Anzahl der falschen Klicks die der Werbetreibende bezahlt, weil niemand reklamiert. Und natürlich die Vantiy-Klicks (ich klicke aus Freude / Eitelkeit auf meine eigenen AdWords ;-.)

Die häufigen Lügen und Fehler bei der Erfolgsmessung von Webanwendungen. Letzter und dritter Teil einer Serie über Web Analytics resp. Online Business Intelligence. In einem ersten Teil erklärte ich bereits einige zentrale Begriffe und im zweiten Teil geeignete Kennzahlen.

Die Erfahrungen zum folgenden Post stammen (leider) aus dem realen Leben. Wer seine Erfolgskennzahlen gut gewählt hat, ist kaum von den "Lügen" betroffen. Also sozusagen ein Post für Leserinnen und Leser, die noch in der Fieberkurven-Welt leben.

Es gäbe zynischere Beispiele, aber hier ein einfacher Case, der ein Teil des Problems zeigt. Annahme: Ich werde gefragt, wie viele Besucher der namics Weblog hat? Die Graphiken unten zeigen die Visits die Woche 5. bis 11. Februar, gemessen mit zwei verschiedenen Tools.

So könnte ich also sagen ich hatte am 6. Feburar 6421 Visits oder ich hatte eben 991 Visits. Welche Zahl würden Sie wählen? Die obere Messung basiert auf der (serverseitigen) Logdatei des Webservers und zählt die Anzahl unterschiedlicher IP-Adressen der Besucher. Eine Adresse ist dann „unterschiedlich“, wenn diese während einem Zeitintervall von 30 Minuten nicht mehr gesehen wurde („Timeout“). Die untere Messung erfolgte clientseitig und misst als einzelnen Besucher jedes, pro Kalendertag neu gesetztes Cookie. Die Messung erfolgt also nur, wenn der Client Cookies annimmt und wenn der Client Java Script ausführt. Dies, da der Tracking-Code mittels Java Script in die Seite integriert ist. Quizzfrage: Wo kommt der Unterschied (mehr als Faktor 6) her? Ein Anhaltspunkt gibt zudem der Tagesverlauf der Visits; Also die folgenden Graphiken.

Nehmen sie an, dass die gemessene Website fast ausschliesslich Besucher aus der Schweiz und auch Deutschland hat. Nun, noch andere Ideen zum Unterschied der Zahlen?

Ausgangslage der Serie war ja ein Mensch der sagte mit über 100'000 Hits pro Monat sei ein wichtiger Karpfen im Teich. Der 6. Februar 2007 generierte auf dem namics Weblog übrigens 42,496 Hits auf dem Server. Nun also los zu dem Lügen der Webstatistik (oder weshalb die meisten Site-Betreiber lieber 6412 anstelle 991 Visits melden ;-).

Teil 3: Lügen resp. häufige Fehler bei der Webstatistik

>> Crawler von Suchmaschinen
Suchmaschinen benötigen Inhalte der Websites möglichst vollständig und aktuell. Aus Sicht des Servers verhalten sich die Teil der Suchmaschinen, welche die Inhalte zusammentragen (die Crawler) ziemlich ähnlich wie ein Webbrowser. Allzu häufig werden diese also in Statistiken mitgezählt. Wie erkennen? Die netten Crawler verlangen ab und zu (resp. zu Beginn der Session) nach der Datei /robots.txt und sie haben eigene User Agent Kennungen die ziemlich sprechend sind. Zudem laden diese typischerweise nur die HTML-Grundseite und binäre Seitenelemente wie PDF herunter, aber keine graphischen Seitenelemente (gif/png/jpg) und keine CSS oder Java Script Includes. Ausserdem interpretieren Crawler kaum Java Script und sie nehmen auch kaum Cookies an. Dies erklärt einen grossen Teil des Unterschiedes oben insb. auch die Tatsache, das es bei der „grossen Zahl“ einen Grundlast auch in der Nacht gibt. Das sind in diesem Fall kaum echte Menschen.

>> Verfügbarkeitsmessung des Servers
Es ist üblich, dass die Personen, welche für den Server-Betrieb verantwortlich sind, Verfügbarkeitsmessungen durchführen. So beispielsweise mit einem Tool wie Big Brother oder Nagios oder mit einem Dienst wie Sysformance oder Keynote. Und was machen diese? Sie fordern alle 5 Minuten oder so eine Datei vom Webserver an um zu sehen, ob das Ding tut. Und bei jedem Mal entsteht ein Hit resp. eine Page Views oder gar ein Visit etc. Hier erlebte ich einmal, dass die „Erfolgs-“Statistik von einer Minute auf die andere um mehr als den Faktor 10 einbrach. Als herausgefunden war, dass diese Last immer ab den selben fünf IP-Adressen kam, war rasch klar, dass die Betriebsleute das Monitoring eingestellt hatten. Erkennen lassen sich diese Dienste sonst wie Crawler.

>> Syndikatoren / Feed-Reader
Dieser Aspekt ist vor allem bei Weblogs (resp. allen Diensten die einen Feed z.B. als RSS oder Atom anbieten). Die meisten Feed-Reader besuchen ihre Quellen zyklisch also alle 60 (oder so) Minuten und generieren damit Traffic. Und dies unabhängig davon, ob sich neuer Inhalt auf der Site findet oder nicht. Grundsätzlich machen Syndikatoren wie Planets (z.B. planet.blogug.ch) oder auch Online Feed Reader wie Bloglines oder Google Reader dasselbe. Bei letzteren könnte der Effekt aber auch in die andere Richtung gehen, da der Planet oder der Online Reader einmal bei mir liest und die Information dann mehreren Lesern zur Verfügung stellt. Das Beispiel des Planets bei blogug ist zudem nicht wirklich das Beste, weil sich blogug bei Änderungen aktiv benachrichtigen lässt und somit keine unnötigen Besuche macht. Die Feed-Reader auf den Clients aber schon. Was tun? Vernünftige Kennzahlen oder wie die Crawlern herausfiltern resp. die Anzahl reduzieren. Meistens führen die Reader auch kein Java Scr