Ein Albtraum wird wahr: Wie ich gerade beim Boesenseo gelesen habe, besteht bei PHP-Scripten unter gewissen Bedingungen (PHP im CGI-Modus) eine realistische Chance, dass durch das simple Anhängen des Kommandozeilenparameters "-s" der Quellcode jeder PHP-Seite sichtbar gemacht werden kann... weitere Schweinereien per Kommandozeile sind freilich mit ausreichender krimineller Energie auch denkbar.

Man könnte diese Chance jetzt nutzen, um (mal wieder) dazu aufzurufen, alle kritischen Inhalte wie Zugangsdaten etc. auch in Kleinstprojekten und einfachen Scripts zum Mailversand etc. aus den erreichbaren PHP-Dateien fern zu halten und per geschütztem Include vor Zugriffen zu schützen... aber wer würde es schon hören? Es muss also reichen, auf den o. a. Beitrag zu verweisen und jedem Betreiber einer eigenen Site zu raten, den Schnelltest zu machen, indem z. B. die Startseite (nennen wir sie mal ganz willkürlich "index.php") mit dem Parameter -s (also "index.php?-s") aufgerufen wird. Sieht man nun den Quellcode, ist es höchste Zeit, sich an den Admin des Servers, den Hoster - oder wer auch immer für das Schließen dieser Lücke verantwortlich ist - zu wenden.

---

weblog von Markus Baersch Software.

Da ich gern 100 statt nur 10 Treffer bei Google erhalte, ist eine Nummerierung aus mehr als nur einem Grund sinnvoll - ob SEO oder nicht. Scripts und AddOns gibt es ja genug, die für Nummerierungen sorgen, aber die meisten machen auch noch eine ganze Menge anderen Kram, den ich eigentlich nicht will. Daher habe ich schon länger ein selbstgestricktes Script (in Firefox via Greasemonkey; in Chrome mit Tampermonkey) im Einsatz.

Damit ich es nicht ständig suchen muss, habe ich (angesichts der riesigen Reichweite dieses Blogs also hauptsächlich für mich selbst ;)) die akt. Fassung online abgelegt. Wer es nutzen mag, kann also Greasemonkey für Firefox oder Tampermonkey für Chrome installieren und dann per Klick das Script nachinstallieren: Nummerierte Suchergebnisse bei Google.

---

weblog von Markus Baersch Software.

Ja, Google hat seine Datenschutzbestimmungen vereinfacht. Und ja: Dabei sind auch ein paar Kleinigkeiten geändert worden. Aber das große Gejammer über die Konsolidierung von Nutzerinformationen über Produktgrenzen hinweg, über die sich derzeit auch in meinem privaten Bekanntenkreis überraschenderweise die Gemüter erhitzen, kann ich nicht nachvollziehen, denn das ist nun wirklich keine Neuigkeit.

Auch die vorher für jedes Produkt einzeln existierenden Nutzungsbedingungen haben stets darauf hingeweisen, dass sich Google diese Option offen hält. Dass man es jetzt... naja: ehrlicher formuliert und durch die Zusammenfassung der vielen einzelnen Dokumente mehr in den Fokus rückt, ändert nichts daran, dass Google schon immer ein nahezu zu 100% datengetriebenes Untermnehmen ist und sich die vielen "kostenlosen" Angebote schon immer mit den Daten der Nutzer hat bezahlen lassen, aus denen laufend Erkenntnisse gewonnen und oft auch neue Produkte gefüttert werden.

Da ist eine kostenlose Telefonauskunft, deren zahlreiche US-Nutzer dafür gesorgt haben, dass Google nun lebendige Sprache besser verstehen kann als Siri & Co. nur ein Beispiel von vielen. Google ist nicht kostenlos. Und das Interesse am einzelnen Nutzer ist durchaus vorhanden, wenngleich dieses (noch) etwas anderer Natur ist, als bei anderen Plattformen. Es geht hauptsächlich darum, jeden (möglichst regelmäßigen) Nutzer optimal mit Werbung zu beballern, denn da kommt (mal von Android abgesehen) das Geld her Wer damit wirklich ein Problem hat, war auch schon vor den geänderten Datenschutzbestimmungen gut beraten, sich bewußt zu machen, wann wo und wie Google überall Daten über Nutzer und Nicht-Nutzer (z. B. via Google Analytics) sammelt... und ggf. aktiv etwas dagegen zu tun, wenn er damit nicht einverstanden ist.

Einige Hilfsmittel bietet Google dazu selbst an - wohlwissend, dass die Mehrheit sich überhaupt keine Gedanken macht und der Großteil des Rests zwar gerne meckert, aber trotzdem kaum jemand die Plugins zum Ausstieg aus dem Tracking installiert oder den privaten Modus auch beim "normalen" Surfen aktiviert. Wer sich einen Überblick verschaffen will, findet bei Google eine übersichtliche Auflistung aller Datenschutztools. Und ich habe mit diesem Blogpost nun eine einfache Antwort auf eine derzeit recht beliebte Frage ;)

---

weblog von Markus Baersch Software.

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.