Markus Baersch

Software · Beratung · Lösungen

23.08.2016

Seit fast genau 4 Jahren kenne und nutze ich den Google Tag Manager (GTM) für verschiedenste Aufgaben; hauptsächlich auf Websites von Agenturkunden. In den letzten Monaten ist mir dabei (zu meiner Freude) aufgefallen, dass man den GTM verstärkt bereits implementiert findet, statt zuerst von A wie Analytics bis Z wie Zauberei den ganzen Evangelisierungsschmus runterleiern zu müssen.

Mehr (unterforderte) Implementierungen in KMUs

Zugegeben: Die meisten Implementierungen, die mir dabei unterkommen, sind simpel und tun selten mehr, als einen Analytics-Code auszuspielen; der dataLayer ist i. d. R. ungenutzt und das Potential nicht mal da angekratzt, wo es nicht nur technisch möglich, sondern aus der Businessperspektive wirklich erforderlich wäre. Trotzdem scheint die „gefühlte Menge“ der Installationen in B2B- und B2C-Websites kleiner Unternehmen, Nischen-Shops und den anderen eher „kleineren Kandidaten“, die unser Agenturgeschäft prägen, durchaus angestiegen zu sein.

Weiterlesen… »


10.09.2015

Jedenfalls bei mir. Ich kann mich mit dem neuen Namen nicht anfreunden. Weder in der Kommunikation mit anderen (auch wenn ich es muss), noch in Form des Anblicks bei der Verwendung der Webmaster Tools. Der Webmaster Tools. Webmaster Tools, nicht Search Console. Ich mag den Namen nicht. Hatte ich das schon erwähnt?

Name doof? Einfach umbenennen!

Ein Plugin war mir dann doch ein wenig zu übertrieben, aber da ich ohnehin gern und viel mit Greasemonkey bzw. Tampermonkey „nachbessere“, habe ich zahllose schweißtreibende Stunden in eine umfangreiche Lösung investiert 😉

Wer meine Abneigung gegen den neuen Namen teilt, kann sich also mit den o. g. Erweiterungen für den Browser seiner Wahl Abhilfe verschaffen. Sowohl in der Anwendung als auch in der Hilfe. Einfach hier klicken und das Script in Greasemonkey oder Tampermonkey installieren oder herunterladen. Schon sieht das wieder so aus:

Search Console als Webmaster Tools rerebranded

Wem es noch fehlt: Hier sind Greasemonkey für Firefox oder Tampermonkey für Chrome zu bekommen.

Happy Re-Rebranding & Webmaster-Tooling 😉


01.04.2015

Wenn Google am 21.4. ernst macht und alle Websites, die nicht als mobilfreundlich eingestuft werden, bei mobilen Suchen benachteiligt (mit mehr Auswirkungen „als bei Panda und Penguin zusammen“), werden eine ganze Menge Webmaster noch nicht fertig sein mit der Umstellung auf Responsive Design oder mit anderen Mitteln.

Da dies aber vor allem auch ein paar gaaanz große Fische betrifft, hat Google genauso erstaunlich schnell einen Rettungsanker für überlastete IT-Abteilungen nachgelegt, wie zuvor mit der Nennung eines konkreten Termins überrascht. Und so geht es: Wer nicht rechtzeitig fertig wird, aber bereits angefangen hat, kann Google dies per Metatag mitteilen und so Zeit zur Fertigstellung „erbitten“.

Metatag mobileready to the rescue!

Dazu wird in den Quelltext der betroffenen Seite (i. d. R. also vermutlich einfach alle) ein Metatag in den head-Bereich eingebracht, mit dem Google mitgeteilt wird, dass die Umstellung bereits in Arbeit ist.

<meta name=“mobileready“ content=“soon“>

Der hier abgebildete Wert „soon“ bedeutet für Google, dass man davon ausgeht, spätestens innerhalb von 14 Tagen mit der Umstellung fertig zu sein. Wenn Google im Mobile Friendly Test auf diese Anweisung stößt, wird auch eine entsprechende Meldung ausgegeben, die einen erneuten Crawl der Seite in zwei Wochen in Aussicht stellt.

Mobile Ready: Soon

Als weitere Option ist die Angabe „pending“, mit der angekündigt wird, dass die Umsetzung zwar erfolgt, aber noch längere Zeit in Anspruch nimmt. Die Crawlpause fällt in diesem Fall doppelt so groß aus, so dass man vier volle Wochen Zeit bekommt, um die Mobil-Hausaufgaben nachzureichen.

<meta name=“mobileready“ content=“pending„>

Große Website? Kein Problem: Auch in den Webmaster Tools wird es in Kürze (lt. Blogpost spätestens bis zum 19.4.) eine Funktion geben, um die „Entdeckung“ per Metatag zu forcieren, ohne dass man explizit für jede einzelne Seite den obigen Test durchführen muss. Man merkt der Lösung aber nicht nur daran an, dass sie mit der heißen Nadel gestrickt wurde.

Vorsicht bei tagesaktuellen Inhalten!

Da die obige Angabe z. B. dazu führt, dass die betreffende Seite tatsächlich eine Crawlpause erhält und Google erst zum „vereinbarten“ Termin zurückkehrt, um sich von der Mobilfreundlichkeit der Seite zu überzeugen, entgehen der Suchmaschine in der Zwischenzeit alle Updates am Inhalt der Seite. Wer also seine Blogstartseite damit ausstattet, kann sich auch eine Publikationspause gönnen, wenn der Hauptkanal für Traffic die Suche ist. Ein Workaround für dieses Problem ist nicht bekannt… aber solche Lücken entstehen eben, wenn ein plötzlich notwendig gewordener Notbehelf aus nichts als einer Kugelschreibermine und einem Einmachgummi gebastelt werden muss.

Sonderfunktion für gesperrte Ressourcen

Auch ein anderes Problem kann mit der neuen Wunderwaffe behandelt werden: Google beachtet Verbote in der robots.txt. Hier wurde und wird gern aber eine ganze Menge an internen Ressourcen wie CSS- und JavaScript-Dateien für Google & Co. gesperrt. Außerdem sind unauffällige Ordner wie website.de/css oder website.de/js seit jeher ja ein beliebter Ablageort für Firmengeheimnisse, unverschlüsselte Nutzerdaten und Online Banking Passwörter der Geschäftsleitung. Wo sonst könnte man auch sensible Daten auf einem online zugänglichen Ort ablegen, ohne dass sich Suchmaschinen und andere Bots darüber hermachen? Naja, vielleicht erfindet ja jetzt jemand Dropbox oder so. Sperren per robots.txt ist nun jedenfalls definitv out. Was früher heimlich der Sicherheit interner Daten sowie vorgeblich der Schonung der Ressourcen von Crawler und dem eigenen Server gedacht war, geht nun also nach hinten los, denn wenn Google keinen Blick auf das Design werfen kann, dann kann auch nicht bestimmt werden, ob eine Website mobilfreundlich ist oder nicht.

Für diesen Fall gibt es eine dritte Möglichkeit, mobileready mit einem Wert zu bestücken:

<meta name=“mobileready“ content=“yes„>

Versieht man die oben dargestellte Seite mit gesperrtem Design mit dieser Angabe, beteuert Google das Vertrauen in die Angabe des Webmasters:

Mobile Ready: Yes

Hierbei wird auch keine Pause vereinbart o. Ä – vielmehr scheint Google tatsächlich den Angaben des Webmasters zu vertrauen. Wie lange das aber gut gehen wird – und ob dies wirklich eine Rettung für Rankings bei mobil ausgeführten Suchanfragen bedeutet -, muss abgewartet werden, bis der nach dem 21.4. geänderte Zustand eine zuverlässige Bewertung erlaubt.

Einfach einbauen?

Daher sollten Webmaster mobileready nicht einfach implementieren, ohne zuvor auch alle denkbaren Konsequenzen bedacht zu haben. Neben der Crawlpause gibt man Google mit dem Einbau auch ein Versprechen, dass es einzuhalten gilt. Daher lautet die Empfehlung: Lieber „pending“ statt „soon“, wenn es denn schon eingebaut werden muss. So ist dann wenigstens sichergestellt, dass unerwartete Probleme bei der Umsetzung noch einen etwas größeren Puffer bekommen, als bei einer Zwei-Wochen-Frist.

Wie lange hält so ein Pflaster denn?

Keine Ahnung. Google hat nichts dazu geschrieben, was passiert, wenn man die Angaben einfach im head drin läßt und das Versprechen der Umsetzung nicht einlöst. Sicher wird es aber spätestens nach mehrfachem Verstreichen der Frist ohne erkennbare Verbesserungen der Mobiltauglichkeit dann auch an die Rankings gehen. Auch unklar bleibt, wie es nach dem ersten verpassten Termin mit der Crawlfrequenz aussieht… oder was passiert, wenn man eigentlich schon mobilfreundlich geworden ist und nur vergisst, das Ding wieder auszubauen – Also Vorsicht 😉


29.03.2015

Am 21. April ist #MobileDay. Wer bis dahin nicht (endlich) seine Hausaufgaben gemacht und seine Website auf Mobilfreundlichkeit abgeklopft hat, wird bei Suchanfragen, die auf Mobilgeräten stattfinden (Wachstum: schnell und unaufhaltsam), nicht mehr gefunden, weil die „mobilen Rankings“ deutlich abfallen werden.

Eine Überraschung? Nein.

Nach all dem freundlichen „Du, mobile ist echt wichtig, Du – mach da doch mal gelegentlich was, ja?“, das seit 2010 immer wiederholt, aber meistenteils unbeachtet blieb, hat uns Google zuerst in seit Mitte 2014 rasant steigender Schlagzahl massenweise Infos und Werkzeuge an die Hand gegeben, dann per Webmaster Tools tonnenweise Warnungen per Mail versendet und schlussendlich mit dem konkreten Termin 21.4.2015 die Pistole auf die Brust gesetzt. Wer jetzt nicht aufwacht und die bestehenden Probleme aller Besucher mit Smartphones weiterhin missachtet, wird dort konsequenterweise bald auch nicht mehr angezeigt; darüber habe ich bereits an anderer Stelle geschrieben.

Der Mai ist gekommen – die Rankings schlagen aus?

Spätestens Anfang Mai wird man mit dem Ausrollen nach eigenen Aussagen bei Google fertig sein. Mobile Rankingverluste drohen. Das muss kein Problem sein… jedenfalls nicht sofort: Wer jetzt noch keinen nennenswerten Anteil an organischen Besuchern per Smartphone verzeichnet, mag sich auch noch Zeit lassen dürfen. Alle anderen müssen aber handeln, wenn der Anteil nicht rapide sinken soll.

Vorher noch fertig werden? Möglich…

Aus der Erfahrung von inzwischen über 25 (teilweise zugegebenermaßen auch nur „notdürftig“) in den letzten Monaten auf Responsive Design umgestellter Websites, die zumindest erst einmal den Mobilfreundlichkeitstest bei Google mit „grün“ bestehen, kann ich behaupten, dass es für viele, aber sicher nicht alle Websites i. d. R. eine praktikable, wenngleich sicher nicht perfekte Lösung gibt, deren Vorbereitungs- und Umsetzungsaufwand in Stunden und nicht in Tagen berechnet werden kann. Jedenfalls bis uns auch Mobile Page Speed und der Rest einholt und der Erhalt der Rankings mehr erfordert als nur Änderungen am Design oder ein paar Templates.

Ja oder Nein: Google Mobile Friendly Test

Wer nicht 100% aller Seiten umstellen kann, hat außerdem die Option, sich den wichtigsten (Traffic bringenden) Inhalten zu widmen – das sind oft nur die Startseite und eine Handvoll weiterer Seiten, die i. d. R. auch alle mit dem gleichen Template erstellt und dem gleichen Design versehen werden. Denn das Thema „Mobilfreundlichkeit“ ist bei Google (aktuell) nicht nur an eine überschaubare Anzahl von Anforderungen geknüpft, sondern wird auch seitenweise beachtet, nicht „domainweit“.

Google hat bzgl. einer bevorzugten Methode selbst klargestellt, dass Responsive Design keine Vorteile ggü. anderen Lösungen haben wird. So ist also selbst eine separate m.meinedomain.de mit vollkommen unabhängigen Inhalten für Mobilgeräte ein ebenso probater Notbehelf wie die keinerlei Anpassungen am eigenen System (abgesehen von ein paar DNS-Einstellungen) erfordernde dynamische Generierung mobiler Fassungen durch das System eines Dienstleisters, von denen es inzwischen einige gibt – als Service oder „selbstgehostet“.

… aber mitunter nicht sehr wahrscheinlich

Weil der Termin erst Ende Februar bekannt geworden ist, kann gerade die Umstellung größerer Websites – oder kleinerer, dafür komplexer Webauftritte – kaum rechtzeitig fertig werden, wenn man erst im März oder später startet. Zu vollgestopft sind die IT-Roadmaps des Mittelstands. Aus beharrlicher Ignoranz plötzlich agile und effiziente Aktivität an den Tag zu legen oder einen Plan B wie die „Mobilmachung“ der wichtigsten Seiten zu schmieden, beschließen und auch noch umzusetzen, bis der 21. April auf dem Kalender steht, ist selten noch drin.

Unterschiede gibt es schon heute

Es bleibt spannend zu beobachten, wie sich die Unterschiede zwischen Desktop- und mobilen Rankings weiter verändern werden… und bei wem die Ausschläge nach unten – oder durch Verdrängung des unvorbereiteten Wettbewerbs ja vielleicht auch nach oben? – besonders groß ausfallen. Ab dem 22. April wird es von den SEO-Toolanbietern dazu vermutlich reichlich Daten geben. Wer nicht bis dahin warten will, kann sich beim SISTRIX Smartphone-Sichtbarkeitsindex informieren, inwiefern sich schon auf Basis der Daten vom Februar Unterschiede feststellen lassen.

STSTRIX Smartphone Sichtbarkeit

Da hier „nur noch“ die Aktualisierung der Datenbasis erforderlich ist, sollte sich auch ein zweiter und dritter Besuch lohnen, wenn erst einmal der #MobileDay gekommen ist 😉

Nächster Halt: Mobile PageSpeed

Damit ist die Reise natürlich nicht zu Ende. Ein so digitaler Faktor wie „mobilfreundlich“ oder „mobilmist“, wie er derzeit nicht nur in Form des oben angesprochenen Tests implementiert ist, sondern in gleicher Form auch in den Webmaster Tools lebt – und vermutlich aktuell im angekündigten Algoupdate, das uns so nett nebst konkretem Termin in Aussicht gestellt wurde -, ist noch nicht das, was wir von Google gewohnt sind.

Die Tatsache, dass ein Klick zum Recheck einer in den Problemen genannten Seiten des Berichts zur „Benutzerfreundlichkeit auf Mobilgeräten“ in den WMT früher nicht zu dieser „hopp oder top“-Evaluierung, sondern zu den mobilen PageSpeed Insights geführt hat, wo man weitaus strenger mit den Probanden verfährt, zeugt von einer gewissen Rücksicht seitens Google…

Streng: PageSpeed Insights

…aber zeigt auch in eine klare Richtung. Genau wie die in der Branche nicht unbemerkt gebliebenen Tests mit als „Slow“ gekennzeichneten Seiten.

Der „Mobile Split“ kommt

Es ist bereits angekündigt, dass Google in Zukunft die Unterschiede zwischen Desktop, Tablet und Smartphone ernster nehmen will. Man wird dazu einen eigenen, vom „Desktop-Index“ getrennten Index für mobile Suchergebnisse betreiben… und mittelfristig bestimmt auch einen separaten Satz an Rankingfaktoren und deren Gewichtung, um sensibler mit den sehr unterschiedlich ausfallenden Nutzersignalen aus verschiedenen Gerätewelten umgehen zu können. Die gleiche Maßnahme wäre selbstredend auch für Tablets denkbar, für Wearables… oder was auch immer übermorgen das dominierende Gerät sein wird. Desktop und Laptop aber ganz sicher nicht. Insofern ist dieser Schritt nicht nur logisch, sondern auch (überlebens-) notwendig für Google. Und deren Wettbewerber. Genau wie die entsprechende Reaktion aller Websitebetreiber, die sich um organischen Traffic scheren.

Damit: Happy Mobilmaching 😉


30.09.2014

Seit Monaten bekomme ich regelmäßig Nachrichten aus den Google Webmaster Tools für die Domain eines ehemaligen Kunden. Und ich werde sie einfach nicht los. Obschon ich die Domain schon aus meinen Webmaster Tools gelöscht habe. Dass ich damit nicht allein bin, merkt man schnell, wenn man sich mit passenden Suchbegriffen bei Google um Abhilfe bemüht: Alle paar Monate wird ein neuer Eintrag in einem der mal mehr und mal weniger passenden Google Produktforen gepostet.

Ein Tipp, den man häufig liest, ist „einfach die Mails ignorieren“. Das würde ich auch gern, aber nun haben die Nachrichten eine neue Dimension erreicht. Nachdem es zunächst nur Meldungen gab, dass der Googlebot keinen Zugriff auf die Seite hat, dass sich die Fehler häufen und ähnlicher Kram, den man sich zuammenreimen kann, weil die Domain vom ehemaligen Betreiber zwischenzeitlich abgestoßen wurde, hatte ich kürzlich dieses Schätzchen im Posteingang:

Weiterlesen… »


04.06.2012

Mit großem Trara beerdigt Google zum 1. August den Google Website Optimizer und bietet als Ersatz neue „Content Experiments“ in Google Analytics an. Wer sich nur die Ankündigungs-E-Mail von Google dazu durchliest könnte meinen, es handelt sich um alten Wein in neuen Schläuchen und das Tool sei nur „umgezogen“. Die dort verwendete Formulierung „To elevate website optimization and provide one fully integrated tool for testing, content optimization will now have a new home within Google Analytics.“ klingt ja auch vollmundig und lässt auf Umsetzung vieler Wünsche hoffen, die man ggf. bisher im Einsatz des Website Optimizers entwickelt hat.

Zickige Validierung in GA

Mein erstes Fazit lautet aber leider: Pustekuchen. Es sind zwar ein paar erfreuliche Vereinfachungen mit dem Umzug gekommen, aber leider auch eine Menge Einschränkungen. Die überwiegend guten Nachrichten daher lieber zuerst.

Das mag (meistens) nett sein:

  • Ein separates Script für eine Conversion kann man sich nun i. d. R. sparen, denn es werden Analytics-Ziele als Grundlage für einen Test verwendet. Da dieser Punkt aber auch bedeutet, dass man für bisher per Script herbeigeführte Extrawürste wie Auslösen einer Conversion nach Erreichen einer Mindestanzahl von „Microconversions“ o. Ä. nun ggf. (temporäre) „Hilfsziele“ einrichten muss, muss das nicht zwingend ein Vorteil für jeden Anwendungsfall bedeuten. Zumindest aber geht dadurch keine Flexibilität verloren, macht bestimmte Szenarien nur ggf. etwas umständlicher oder erfordert (wenn alle Ziele „belegt sind“) evtl. sogar ein neues Profil für Tests (zumal die Anzahl der Tests pro Profil in Analytics nun auf 12[wieso 12?] begrenzt ist)
  • Überhaupt werden weniger Scripts in Seiten benötigt, denn auch die Varianten müssen nicht mehr separat verwanzt werden, sondern nur noch die Originalseite. Klingt gut. Das „Aber“ kommt dann nachher in der nächsten Liste…
  • Google steuert den Traffic auf die Varianten „schlau“ selbst. Ziel ist es hier, die Seiten mit offenkundig schlechterer Konversionsrate nach einer gewissen Sicherheit mit weniger Traffic zu beschicken, um den Schaden für die Website zu minimieren. Klingt erst einmal gut, bedeutet aber durch die zwingende Nutzung dieser nicht-optionalen „Gutwillensautomatik“ in gewisser Weise auch Kontrollverlust beim Experiment.
  • Wollte man bisher die Besucher einer bestimmten Variante separat in Analytics auswerten, musste man diese explizit mit einer benutzerdefinierten variable zu diesem Zweck markieren und konnte so Segmente bilden. Das ist jetzt durch die Integration einfacher, so dass das Verhalten jenseits der reinen Zielerreichung durch Segmentierung nach Varianten leichter beobachtet werden kann. Spart aber grundsätzlich erst einmal nur (geringen) Aufwand beim Aufsetzen es Experiments im Vergleich zur alten Lösung
  • Adieu Langzeittests: Tests in Analytics enden spätestens nach 3 Monaten. Das ist prinzipiell mal ein Vorteil, denn so ist man gezwungen, sich von der Idee zu verabschieden, einen Test nur lange genug laufen lassen zu müssen, um einen Gewinner zu finden, obschon die getesteten Variablen offenbar überhaupt keinen Einfluss auf die Ergebnisse des Tests haben ;). Das das im Einzelfall aber auch wieder ein Nachteil sein kann, ist ja fast schon klar…
  • Keine kollidierenden Tracker-Objekte mehr. Wer bisher GA und GWO parallel genutzt hat, musste ggf. die Scriptcodes anpassen, damit der Spaß überhaupt funktioniert. Außerdem wurde auf diese Weise auch mehr Code angezogen und ausgeführt, als das jetzt der Fall zu sein scheint, da keine zwei „Analytics-Codes“ und unterschiedliche Profile mehr im Spiel sind. Die Content Experiments funktionieren sowohl mit dem neuen, als auch dem alten (synchronen) Trackingcode.

Das war es aber eigentlich auch schon. Ein wenig schöner mag das UI durch die Integration in Analytics ja geworden sein, aber wesentlich und / oder besonders bemerkenswert (weil nun einfacher oder besser oder sonstwas) finde ich das nicht. Mit Tools wie Optimizely hat man damit jedenfalls noch lange nicht aufgeschlossen. Vielmehr scheint es schon jetzt einige leicht zu identifizierende Nachteile zu geben… und es steht zu befürchten, dass mit steigender Erfahrung mit dieser Integration (noch ist kein einziger Test, der hier in Analytics gestartet wurde, bereits beendet) noch weitere Punkte dazu kommen werden.

Nicht so schön:

  • Der wichtigste Punkt zuerst: Die Flexibilität wird damit stark eingeschränkt. Denn sowohl (wie bisher dynamisch generierte) Multivariate Experimente als auch Experimente mit mehr als 5 Varianten sind mit den Content Experiments in Google Analytics nicht umsetzbar. Mehr muss man dazu auch eigentlich nicht schreiben, aber es ist eine wirklich fette Kröte, die man damit schlucken muss und ich würde mich nicht wundern, wenn das im ersten Schritt den Wettbewerb mehr stärkt, als dass es Analytics-Benutzer neu auf das Thema „Testing“ bringt…
  • Ein Punkt, den viele sicher auch der Liste der Vorteile zuordnen würden: Es dauert mindestens 2 Wochen, bis ein Test „sichere“ Ergebnisse liefert. Ob dies nun wirklich dazu dient, voreilige Schlüsse zu vermeiden oder nicht: Wer wirklich Traffic hat, konnte bisher nach Ablauf von mindestens 7 Tagen (um Schwankungen im Wochenverlauf nicht zu ignorieren) oftmals bereits fertig sein. Natürlich: Google zeigt wie früher stets den aktuellen Stand der Dinge an und verbietet auch nicht, einen Test „vorzeitig“ zu beenden, aber es ist zu erwarten, dass eine Vielzahl von Benutzern erst dann Vertrauen in ein Ergebnis hat, wenn auch das Tool sagt, dass es „fertig“ ist…
  • Folgetests auf der gleichen Seite erfordern offenbar stets einen neuen Code, denn jeder Test hat eine eigene ID
  • bei einer Implementierung in die Webanalyse naheliegende Wünsche wie die Beschränkung der Teilnahme an Tests nach verschiedenen Segmentierungskriterien o. Ä. sind (noch) nicht umgesetzt. Das bedeutet, dass die Integration in Analytics bis auf die Verwendung von dort bereits definierten Zielen noch keine der erwarteten funktionalen Verbesserungen mit sich gebracht hat. Auch die Berücksichtigung mehrerer Ziele o. Ä. (sei es gewichtet oder nicht) bleibt so folgerichtig noch offen
  • Die Validierung ist noch zickiger als bisher. Wenn man das Script in der Originalseite z. B. nun nicht direkt nach dem head-Tag einfügt, gibt es Gemecker.
    Zickige Validierung in GA
    Das bedeutet zwar nicht, dass man das Script nicht genau wie vorher zur Not (wenn es das CMS z. B. nicht anders zulässt) an anderer Stelle unterbringen, die Meldung ignorieren und trotzdem Ergebnisse erhalten kann, aber aus Sicht des typischen Analytics-Anwenders ist das vielleicht schon ein Grund, bereits nach dem ersten Einrichtungsversuch dauerhaft das Handtuch zu werfen
  • Die Integration wirkt teilweise noch fehlerbehaftet. Ob z. B. Vorschaubilder der beteiligten Seiten dargestellt werden oder nicht, scheint noch dem Zufall unterworfen zu sein. Das sind zwar Kleinigkeiten und zumindest bis jetzt scheinen Tests durchaus zu funktionieren, aber auch das fördert normalerweise nicht das Vertrauen der potentiell durch die Integration neu zu gewinnenden Benutzer für diese Funktion
  • Wer wirklich viel testet, wird sich vermutlich schnell über die Limitierung auf 12 Tests pro Profil ärgern. Damit sind übrigens aktive Tests gemeint. Wenn ein Test also abgelaufen oder pausiert ist, zählt er nicht für dieses Limit

Also: Luft nach oben ist noch reichlich vorhanden. Es bleibt zu wünschen, dass zumindest wesentliche Funktionen wie multivariate Tests möglichst schnell wieder einen Weg in das Tool finden, denn ansonsten ist es absehbar, dass es sich für eine ganze Menge typischer Testszenarien vorerst disqualifiziert. Warum der GWO zumindest in der Übergangsphase nicht weiterhin verfügbar bleibt, muss man Google fragen. Es sei denn, die größten Lücken werden noch vor dem 1. August geschlossen. Wer weiß..?


12.03.2012

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.

Suchergebnisse mit Nummern

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.


13.02.2012

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.

Google Datenschutzbedingungen

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 😉


09.01.2012

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:

Statistik in Google Analytics

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:

Statistik in Google Analytics

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.


08.11.2011

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…


21.10.2011

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.

Realtime in GA

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 😉


06.10.2011

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.

Suchanfragenbericht

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…


30.09.2011

Das scheint wohl schon länger so zu funktionieren, aber mir ist es erst jetzt aufgefallen: Wenn in den Google Webmaster Tools eine neue Site hinzugefügt werden soll, kann dazu nun einfach der Analytics-Trackingcode verwendet werden. Meint: Wer als Administrator beim passenden Analytics-Konto zur Website eingetragen ist, muss sich künftig weder als Agentur noch Betreiber mit Uploads, Metadaten oder gar DNS-Konfiguration rumschlagen.

Webmaster Tools

Ich find´s praktisch. Die engere Verknüpfung beider Werkzeuge ist damit zwar nicht wirklich vorangetrieben, aber trotzdem eine große Hilfe. Wer weiß: Es mag ja auch was mit dem kommenden „Analytics Premium“ zu tun haben;) Wenn man jetzt noch die neue „schöne“ Startseite der WMT wieder auf eine übersichtlichere Listenansicht umstellen könnte. Aber ich habe ja immer was zu meckern…


16.09.2011

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?


24.05.2011

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. 😉


© 2001 - 2017