Inspiriert durch die Ausgabe 23 von Web Analytics TV habe ich mich endlich aufgerafft, ein generelles Problem vieler Blog-Sites anzugehen: Hohe Absprungrate, geringe "Time On Site". Denn allzu oft landet ein Besucher mit einer sehr konkreten Anfrage auf einer Seite, die eine sehr konkrete Antwort gibt. Im Idealfall ist die Frage damit geklärt und der Besucher verlässt die Site... vermutlich durchaus zufrieden. Was er dabei aber in der Webanalyse hinterlässt, ist die gleiche Spur wie die eines "echten Bouncers", der kam, sah (dass er falsch war) und direkt wieder verschwand. Eine Seite, Null Sekunden, Weg.

Die Lösung kann in diesem Fall die Messung einer Interaktion sein, die man durchaus als "Engagement" betrachten darf: Scollen der Seite. Denn wird der Beitrag wirklich gelesen (und ist er länger als nur ein paar Sätze bzw. enthält Ressourcen wie Bilder, Tabellen o. Ä.), wird der komplette Inhalt kaum auf die erste Bildschirmseite passen. Es ist also im Sinne der Webanalyse, wenn man durch die Messung einer solchen Interaktion die Qualität der Daten verbessert. Gibt man GA die Möglichkeit durch virtuelle Pageviews (wer sich gern extra dick in die Tasche lügt) oder besser Events mitzubekommen, wenn weiter nach unten gescrollt wird, dann bedeutet dies sowohl eine bessere Messung der Verweildauer auf der Seite als auch eine gerechtere Bestimmung der Absprungrate. Denn sobald ein solches Event ausgelöst wird, gibt es ein Ereignis nach dem Betreten der Seite, so dass diese nicht mehr in den Übersichten der besuchten Seiten wie eine "Problemseite" erscheint, ohne es wirklich zu sein.

Ich habe bei der Suche nach bestehenden Lösungen zwei unterschiedliche Beispiele gefunden, an denen man sich bei der Umsetzung orientieren kann. Die erste, einfachere Variante fängt "nur" die Tatsache ein, dass gescrollt wurde und gibt sich damit zufrieden, die zweite Lösung ermittelt auch die "Scrolltiefe" und löst dazu ggf. mehr als ein Event aus, wenn weiter nach unten gescrollt wird. Und obschon die zweite Lösung eigentlich mehr Daten liefert und auch bei der Verweildauer auf einer einzelnen Seite genauere Werte liefert, habe ich mich mit einer leicht angepassten Variante nach dem ersten Vorbild entschieden. Erstens, weil es mir primär um eine bessere Betrachtung des Absprungverhaltens ging und weil ich (bei meinen meistens recht langen Beiträgen) eine "Eventüberschwemmung" befürchte, die mir die Auswertung anderer Events, die hier auch genutzt werden, nicht gerade vereinfachen würde.

Wie auch immer man sich entscheidet und wie "genau" man es wissen will: Schon nach kurzer Zeit sieht man den Erfolg der Anpassung in "realitätsnäheren" (und idealerweise an der richtigen Stelle gestiegenen bzw. gesunkenen) Kennzahlen. Hier am Beispiel dieses Blogs seit der Implementierung zum Jahreswechsel:

Das Diagramm zeigt schon nach wenigen Tagen den gewünschten Trend: Gesunkene Absprungrate, mehr Time On Site. Auch die absoluten Kennzahlen sind signifikant unterschiedlich für die Tage vor und nach der Implementierung:

Wer sich bei den o. A. Beispielen bedienen und eine eigene Implementierung vornehmen will, kann die dortigen Fassungen eigentlich unverändert übernehmen. Bitte aber daran denken, die Syntax des Eventtracking-Aufrufs für den jeweils verwendeten Google-Analytics-Trackingcode anpassen, also entweder nach der alten Variante mit dem pageTracker, wie es im ersten Beispiel der Fall ist oder asynchron wie im zweiten Beispiel mit der mehrfachen Messung.

---

weblog von Markus Baersch Software.

Ich wollte eigentlich kein Wort drüber verlieren und habe es auch fast zwei Wochen geschafft. Aber nachdem ich nun den oberflächlichsten Verdummungbeitrag seit langem in der Webmaster Zentrale dazu gelesen habe, müssen ein paar Dinge einfach mal raus - egal, ob es wirklich jemand liest oder nicht.

Was passiert denn?

Google stellt also seine Suche auf SSL um. Https statt http. Verschlüsselt suchen. Toll. Und wenn Google uns sagt, dass dies "im Rahmen unserer Verpflichtung, das Web noch sicherer zu machen" geschehe, dann muss man das wohl auch glauben. Selbst dann, wenn man sich zufällig gleichtzeitig dazu entschlossen hat, den Referer zusätzlich künstlich zu verstümmeln, so dass in der Webanalyse und den Webmaster Tools nichts mehr zu Impressions oder Klicks in Verbindung zu einem Suchbegriff erscheint. Jedenfalls dann, wenn nicht gerade zufällig jemand auf eine Anzeige geklickt hätte. Denn wer über Anzeigen auf eine Website kommt, bringt auf jeden Fall noch - ebenso künstlich - Angaben über den Suchbegriff mit. Der "normale" organische Besucher aber eben nicht mehr.

Was hat Google davon?

Der Sicherheitsvorwand (der sich in Deutschland dann auch gern gleich magisch erweitert in "Datenschutz" übersetzt) ist aus mehreren Gründen aber m. E. der totale Unsinn. Erstens hat das nichts mit Datenschutz zu tun, zweitens ist die ganze Angelegenheit - nicht zuletzt zur Aufrechterhaltung der CashCow "AdWords", die sich den Verlust der Keywordinfos zu ordentlichen Kampagnensteuerung einfach nicht erlauben kann - mehr oder minder "künstlich" geschaffen / verändert worden. Wäre "nur https passiert", müßte m. W. (ich bin da allerdings nicht 100% sicher und lasse mich gern vom Gegenteil überzeugen), der interessierte Webmaster, SEO, Affiliate seine Site ebenso komplett auf SSL umstellen und erhielte alle Infos, die er bisher auch bekommen hat. Hätte vielleicht also das Web sogar wirklich ein wenig besser gemacht, was sicher auch in der oben als Argument angeführten "Google Selbstverprflichtung" steht. Wer weiß. Das primäre Ziel der Aktion ist aber vermutlich an ganz anderer Stelle zu suchen. Im Satz "better protection against snooping from third parties" aus dem offiziellen Statement kann man sich zwar auf "protection" konzentrieren (und soll das sicher auch), viel interessanter ist aber "third parties" in diesem Zusammenhang. Es geht um Drittanbieter. Nur welche? Irgendwelche "Bösewichte"? Werbenetzwerke? Oder doch jeder einzelne Webmaster, Toolanbieter, SEO?

Was hat "König Kunde" davon?

Für den Nutzer der Suchmaschine ist damit jedenfalls kaum was gewonnen. Ausreichend schlaue Toolbars und Plugins werden vermutlich immer noch genug Daten über das Suchverhalten sammeln, wenn sie denn wollen. Und wenn ich Suchbegriffe verwende, für die ich mich schämen muss, kamen die früher ja auch nicht gleich mit meinem Namen und meiner Anschrift bei jedem an, dessen Site ich besucht habe. Naaaaihn (Diese Verbindung haben nur Google und besonders neugiereige Cookieplatzierer ;))! Man sieht aber möglicherweise weniger stumpfsinnige Einblendungen über Blogposts, die mir nochmal sagen, wonach ich vor einer Sekunde gesucht habe, falls ich mich nicht mehr daran erinnern sollte. Und nicht nur Webmaster, sondern auch Werbenetzwerke (besonders die, deren Geschäftsmodell auf Suchanfragen angewiesen sind. Ja die gibt es!) wissen nun weniger über meine Interessen (was aber Google bestimmt mehr Nutzen bringt als dem einzelnen User). Ansonsten sitzen nun aber jede Menge SEOs, Webmaster & Co. vor den Daten, die immer mehr hämisch (not provided)-grinsende Lücken enthalten.

Alles supi? Oder nicht so wild?

"Passiert ja nur bei google.com und nur, wenn man angemeldet ist". Ja klar. Das war bei Google Instant, Google Dingens und Google Sonstwas auch erst der Fall, wird aber ganz sicher mit der Zeit immer mehr Suchanfragen betreffen. Weniger wird´s jedenfalls nicht. Und je nachdem, wo der Hauptteil der Besucher her kommt, fehlen jetzt schon zweistellige Anteile der Keywords in der Webanalyse. Nicht nur in Google Analytics (wo der Kunde demnächst ja auch zahlender König werden kann - huch, habe ich das jetzt laut gedacht?), sondern in jedem Tool... außer vielleicht demnächst dann in Google Analytics Premium. Wie? Ich spinne? Naja: Nachdem Google in letzter Zeit nicht gerade zimperlich bei der Suche nach neuen Einnahmequellen vorgeht, der Charme der ersten 10 Jahre langsam aber sicher verblasst und sich Google mehr und mehr Bedrohungen ausgesetzt fühlt, traue ich Google inzwischen auch Schritte wie diesen zu. Jedenfalls manchmal. Und vor allem dann, wenn ich solchen Flachsinn wie im oben verlinkten Blogpost lese, der mit vielen Worten nichts sagt. Warum Nebelbomben werfen und dann nicht angreifen? Na gut: Ich kann mir zwar "Alle Keywords in der Premium-Version" auf einer Featureliste weder wirklich ernsthaft vorstellen, noch kommt man vermutlich einfach so damit durch, wenn man sich so ein Alleinstellungsmerkmal im Markt der Webanalyse-Tools schafft (und sei es - wie in diesem Fall - dann auf Basis von "eigenen" Daten), aber langsam sollte der letzte gemerkt haben, dass eine Menge Googler jeden Tag satt werden müssen und Geld nicht an Bäumen wächst. "SSL für Suchanfragen" gehört jedenfalls ganz bestimmt nicht zu den Dingen, die man sich mal wieder einfach so als "Oh toll, dann wird ja bestimmt alles noch sicherer und besser, oder?" unterjubeln lassen sollte. Echt nicht...

---

weblog von Markus Baersch Software.

Ich will mich gar nicht an der Diskussion beteiligen, wie sinnvoll nun Realtime Webanalyse nun ist oder nicht - jedenfalls nicht hier und jetzt.

Denn ich freue mich viel zu sehr über die Berichte, die erfreulich schnell nach der Anmeldung zur Teilnahme an der Beta zu Realtime in Google Analytics heute in meinem Konto verfügbar sind.

Was ich wirklich sinnvolles damit anfangen kann - und in welchem Profil - werde ich mir irgendwann später überlegen. Jetzt erst mal wieder zurück zur Betrachtung der Echtzeitanalyse ;)

---

weblog von Markus Baersch Software.

Und weiter geht´s mit der Verknüpfung von Analytics und den Google Webmaster Tools: Im neuen Bereich "Besucherquellen -> Suchmaschinenoptimierung" (nur in der neuen Oberfläche) finden sich nun nach Verknüpfung der Analytics-Web-Property mit dem passenden Eintrag aus den Webmaster Tools (ja genau: Gleiches Google - Konto erforderlich, logo!) zusätzliche Reports, die auch die Impressions, Seiten, Klickraten und geografische Angaben zu den Besuchern enthalten.

Das ist zwar erst einmal nichts, was aus den Socken haut, aber man kann zumindest schon jetzt von den im Vergleich zu den WMT umfangreicheren Filteroptionen in Analytics profitieren, um sich die Impressions zu den Begriffen oder Seiten genauer anzusehen. Auch praktisch ist z. B. eine Sicht auf die Klickrate nach "Quelle" in Form unterschiedlicher Google-Dienste wie Suche, Bilder oder Mobile, in denen man durchaus signifikante Unterschiede feststellen kann ;). Ich hoffe doch, dass dieser Block noch ausgebaut wird. Gegen den m. E. nicht ganz so glücklich gewählten Namen "Suchmaschinenoptimierung" kann man ja vermutlich nun nichts mehr tun...

---

weblog von Markus Baersch Software.

Wenn es um Websites geht, ist schneller immer besser. Ich bin daher auch ein großer Freund von PageSpeed, YSlow und anderen Werkzeugen zur Messung und Optimierung der Performance von Internetseiten... ohne nun wirklich immer alles ausreizen zu müssen, was drin steckt. Also definitiv nicht wie Scotty ;)

Das ist aber vielleicht trotzdem schon das Problem: Wenn ich mir verschiedene von mir betriebene oder betreute Sites anschaue, bringt eine "Faulenzer-Optimierung", wie sie von Google mit dem Page Speed Service zur dynamischen Optimierung der eigenen HTML-Seiten und Ressourcen angeboten wird, leider nicht sehr viel, wenn man sich selbst ein wenig Mühe gegeben hat. Klar: Ich betreue keine spiegel.de, aber trotzdem scheint es mir kaum ein Modell, mit dem Google wirklich viel ausrichten wird, um das Web schneller zu machen.

Das typische Bild bei einigermaßen "speedbewussten" Sites scheint ein minimaler Gewinn im einstelligen Bereich für Erstaufrufe zu sein. Bei erneuten Aufrufen ist allzu oft die Ladezeit sogar (wegen des Umwegs und der Bearbeitung auf dem Weg zum anfordernden Browser ja auch erklärbar) höher als ohne den Service.

Hier ein Beispiel für meine eigene Website: Der Effekt ist nicht der Rede wert. Wenigstens ist die Seite aber noch intakt - das hat bei anderen Versuchen schon anders ausgesehen, so dass das Ergebnis nach der Optimierung mitunter deutliche Darstellungsprobleme hatte.

Klar, dass es bei anderen Sites besser aussieht und der Gewinn größer ausfällt. Aber ich kann mir eigentlich nicht denken, dass ein Unternehmen, welches eine vergleichsweise langsame Website betreibt, wirklich den später ja kommerziellen Service nutzen und dauerhaft dafür zahlen wird, wenn es meistens mit ein paar mehr oder weniger kleinen Handgriffen und einmaligem Aufwand machbar ist, selbst eine ganze Menge für bessere Antwortzeiten zu tun. Oder mache ich es mir da zu einfach?

---

weblog von Markus Baersch Software.

Wer sich - freiwillig oder aus beruflichem Druck - für die Google-Suche interessiert, sich bisher aber mit der Ausrede "das ist mir aber viel zu viel technisches Webmaster-Zeugs" oder ähnlich fadenscheinigen Aussagen davor gedrückt hat, die Google Webmaster Central oder den deutschen Ableger zu abonnieren, dem sind nun Argumente ausgegangen, denn Google betreibt jetzt unter Inside Search eine eigene Anlaufstelle für alles, was "direkt" mit der Suche zu tun hat. Das bedeutet nun aber ganz und gar nicht, dass man sich Webmaster Central nun sparen kann... sondern nur, dass man mit weiteren Kleinigkeiten versorgt wird, die hoffentlich nicht nur Anekdoten aus dem Leben des Search-Teams, sondern idealerweise auch Handfesteres zu bieten haben. Der vollmundige Eröffnungsbeitrag läßt da gleichermaßen hoffen und bangen... wir werden es ja erleben. Oder ertragen. Oder beides. ;)

---

weblog von Markus Baersch Software.

Wenngleich die Ergebnisse der frisch bei SEO-United durchgeführten Umfrage zum Social-Media-Traffic aus mehreren Gründen nicht als Messlatte für den gesamten deutschen Online-Markt genommen werden kann, ist es doch ein weiteres Beispiel für das, was viele Webmaster selbst in ihren Projekten feststellen: Social Media ist nur für sehr wenige, meist direkt an die sich auf Facebook tummelnde Masse gerichtete Angebote als direkter Trafficlieferant geeignet.

Facebook bringt schlappe 5%; Twitter keine 3%. Da ist Yahoo oder ASK für viele deutlich relevanter, wenn man nur den direkten (und direkt zuzuordnenden) Traffic zählt.

Klar, es gibt noch die 999 anderen Gründe, warum man an Social Media nicht vorbei kommt, aber wenn selbst in einer Umfrage, deren Zielgruppe schon viel IT-lastiger ist als der Rest der Republik, so ernüchternde Zahlen rauskommen, muss sich doch eigentlich niemand mehr ernsthaft die Frage stellen, ob man den Like-, Tweet- und +1-Button wirklich braucht oder nicht. Jedenfalls in den meisten Projekten. Deutlich mehr wird es natürlich, wenn man unter "Social Media Traffic" auch Besucher aus anderen Blogs versteht... entweder direkt oder über den Umweg "Google"... denn auch dieser Traffic kann ja durchaus "Social" sein. Wer das aber grundätzlich anders sieht, darf gern die Facebook-Kommentarfunktion nutzen und das kundtun ;)

---

weblog von Markus Baersch Software.

Erst heute bin ich durch die zweite Google IO-Keynote darauf aufmerksam gemacht worden, dass Google Chrome es denkbar simpel macht, Spracheingabe in Eingabefeldern von Webformularen aller Art zu ermöglichen - genau so, wie man es bereits z. B. aus der "googlelabsfunktionsbereicherten" US-Google-Suche kennt.

Dazu reicht es, dem Eingabeelement ein simples "x-webkit-speech" mit auf den Weg zu geben. In der simpelsten Variante also einfach so:

<input type="text" x-webkit-speech>

Anhand der Suchfunktion auf dieser Website (allerdings aus langweiligen Gründen nicht im Blog) gezeigt sieht das so aus: Wer mit Chrome auf die Seite kommt, sieht das Aufnahmesymbol, das sich auch auf Android-Geräten zur Sprachsteuerung immer mehr breit macht. Olle Firefoxe oder andere Browser können damit allerdings noch nichts anfangen. Nicht mal mobil unter Android 2.3.4.

Ein Klick startet die Aufnahmefunktion, über die das Eingabefeld befüllt werden kann. Das klappt in Chrome genau so gut oder schlecht wie bei entsprechenden Funktionen auf dem Mobiltelefon: Die Spracherkennung selbst ist prima, allerdings eben leider (noch) nicht für längere Texte oder gar als Ersatz für "echte" Spracherkennungssoftware geeignet, weil z. B. keinerlei Großschreibung stattfindet (sicher übrigens ein Grund, warum sich Apple lieber - möglicherweise? - Nuance kauft bzw. schon gekauft hat, als das Thema nochmal selbst zu erfinden und dann gleich "perfekt" zu sein, wenn iOSxyz dann ebenso sprachbedienbar wird). Zur einfachen Texteingabe aber schon jetzt eine prima Sache. Wenngleich es hier bei der Suchfunktion zugegebenermaßen eher eine Spielerei ist.

Sobald sich die Funktion aber - mit verbesserter Erkennung und "lokalisierter" Schreibweise - auch in anderen Browsern breitmachen sollte (was sicher erst dann passiert, wenn genug Websites darauf setzen) und auch für große Textfelder (<textara>, nicht nur <input>) genutzt werden kann, kann vielleicht auch auf dem Desktop so manche Eingabe schneller per Stimme als mit der Tastatur erfolgen. Das wäre schon in gewisser Weise etwas Neues, denn bis jetzt muss man sich die Funktion, wenn gewünscht, per "Dragon Dictate" & Co. nachinstallieren.

---

weblog von Markus Baersch Software.