Wednesday, 08 February 2017

Analytics: Bericht der Verweise verbessern

Verweisende Websites fasst Google Analytics in einem Bericht unter "Akquisition - Alle Zugriffe - Verweise" zusammen. Ein Besuch dieses Berichts und Auswertung der trafficbringenden externen Links gehört zu den regelmäßigen Aufgaben der meisten Analytics-Benutzer.

Doch der Bericht enthält vieles, was nichts mit den "üblichen externen Links" zu tun hat. Neben ärgerlichem Referrer-Spam (den man mit entsprechenden Filtern begegnen kann) und Zahlungsportalen, die im Shop die Zuordnung von Transaktionen verdirbt (was über die Verweisausschlüsse geregelt werden kann, siehe Beitrag zu "Conversiondieben" bei Zedwoo) sind es vor allem Suchmaschinen, die Analytics nicht dem passenden Segment "organic" zuordnet, sondern ohne Eingriff in die Konfiguration in diesen Bericht der Verweisquellen einsortiert. Das ist auch deshalb ärgerlich, weil auf diesem Weg ggf. Informationen zu den dortigen Suchanfragen verloren gehen, die seit dem Wandel der organischen Keywords zu (not provided) so schmerzlich vermisst werden. Um dies zu korrigieren, ist Eingreifen erforderlich.

Erkannte Suchmaschinen

Google kennt 40 Suchmaschinen (Stand 02/2017), die man in der Hilfe zu diesem Thema findet. Das sind zwar viele, aber noch lange nicht alle. In jedem Analytics Konto gibt es deshalb i. d. R. einige Suchmaschinen, deren Besucher aus oben genanntem Grund nicht in der richtigen Schublade landen. Neben T-Online, web.de, den Suchmaschinen bei Diensten wie GMX, 1&1 und anderen sind es je nach Branche auch einige "Exoten", die zwar wenige, aber regelmäßige Besucher auf die Website bringen.

Fehlende "Quellen der organischen Suche" nachtragen

Diese lassen sich in Google Analytics unter "Verwaltung" in der mittleren Spalte für die Property unter "Tracking-Informationen - Quellen der organischen Suche" manuell über den Schalter "+Suchmaschine hinzufügen" eintragen.

Suchmaschinen in Analytics nachtragen

Dazu wird der Name der Suchmaschine für die Berichte angegeben, ein "Muster" zur Erkennung, welches i. d. R. der Domain entspricht (muss es aber nicht) und den Namen des Parameters, über den der Suchbegriff ggf. aus der verweis-URL extrahiert werden kann. Sollen nur Anfragen abgedeckt werden, die einen bestimmtes Muster in der URL enthalten, kann auch dieses optional angegeben werden. Das wird z. B. gern genutzt, um auch die Google Bildersuche als Suchmaschine zu deklarieren... denn auch dieser Traffic landet ansonsten bei den Verweisen.

Nach einem Klick auf "Erstellen" ist die Suchmaschine angelegt und betrifft fortan alle Berichte aller Datenansichten dieser Property. Rückwirkend werden dadurch also keine Daten verbessert.

Welche Suchmaschinen aber fehlen in der eigenen Konfiguration? Da es leider keine Möglichkeit zur automatisierten Anpassung dieses Bereichs gibt, ist das Eintragen möglichst vieler Suchmaschinen "auf gut Glück" eine mühselige und undankbare Arbeit. Besser ist es, den Bericht der Verweise als Ausgangspunkt zu verwenden und hier entweder nach lt. Domain offensichtlichen Suchmaschinen zu suchen, die eine nennenswerte Anzahl an Besuchern über einen längeren Zeitraum gebracht haben oder durch Besuch aller verweisenden Websites zu bestimmen, was davon als Suchmaschine nachgetragen werden sollte und was nicht.

Automatisierte Analyse der Verweisquellen

Um diese Aufgabe zu vereinfachen, kann unter www.analytrix.de nach Autorisierung eine Untersuchung des Verweistrafficberichts erfolgen, bei der alle dem Tool bekannten Suchmaschinen aufgelistet werden, die im Bericht auftauchen. Im gleichen Durchgang werden die beiden anderen beiden oben angesprochenen typischen Fehlerquellen - Spam und Conversiondiebe - anhand von Listen identifiziert und ausgegeben. ein Beispiel:

Ergebnis der Verweisanalyse

Die Liste der gefundenen Suchmaschinen kann exportiert oder als Bericht ausgegeben werden, so dass man sich beim Nachtragen in der Konfiguration auf die Einträge beschränken kann, die wirklich relevant sind.

Mit der Verbesserung der Konfiguration anhand des Analyseergebnisses verbleiben im Verweisbericht künftig nur noch die Domains, die wirklich Besucher per Verweis auf die eigene Website bringen.

#  
Thursday, 12 January 2017

404 Fehlerseiten in Google Analytics messen

Zugegeben... zu diesem Thema scheint es schon reichlich Beiträge zu geben. Implementierung mit Tag Manager, ohne Tag Manager... warum also noch eine? Antwort: Weil viele davon nicht mehr aktuell sind und vor allem i. d. R. Events statt Pageviews verwenden, was ich nicht für die ideale Lösung halte.

Aber von vorn: Zu wissen, welche fehlerhaften URLs auf der eigenen Website wirklich aufgerufen werden, woher der fehlerhafte Verweis kam und was man ggf. reparieren sollte, ist praktisch für jeden Webmaster eine interessante Information. Daher befassen sich Websitebetreiber auch gern mit Quellen wie den Fehlern in der Google Search Console oder Berichten externer Crawler und / oder untersuchen die eigene Site regelmäßig auf Fehler in der internen Verlinkung mit Tools wie dem Screaming Frog SEO Spider. Wer sich gern ein vollständiges Bild macht, zieht zudem die Logfiles des Servers zu Rate und deckt so regelmäßig fehlgeschlagene Anfragen auf, die aus unterschiedlichsten Grunden stattfinden und nicht nur reale Besucher, sondern auch alle herzlosen Bots beinhalten.

Warum überhaupt Fehler in Analytics messen?

Während die eine Methode (Crawling) nur auf interne Links schaut und Fehlerberichte aus der Google Search Console sowie vieler SEO-Tools zwar auch veraltete externe Links aufdecken, ist dabei i. d. R. eine ganze Menge Schrott. Sei es, dass Google sich mal wieder (schlecht) ungültige URLs aus Scripts zusammengereimt hat oder die angegebene Quelle des falschen Verweises vollkommen irrelevant, veraltet oder bereits "verstorben" ist (Scraper kommen und gehen...). Daher liefert die Analyse "echter aufgerufener" falscher URLs einen guten Ansatzpunkt, wenn man sich primär um die ferhlerfreie Nutzung durch Besucher statt Bots konzentrieren will... und auch nur auf die Fehler bei Inhalten, die auch wirklich besucht werden.

Verschiedene Methoden

Grundsätzlich ist - mit etwas Glück - in jeder Datenansicht auch ohne Anpassung etwas über fehlerhafte URLs herauszufinden. Je nachdem also, ob man Einfluss auf die Implementierung hat oder nicht, stellen sich daher drei Möglichkeiten:

  1. Ohne Anpassung der Implementierung
  2. Anpassung bei direkter Implementierung
  3. Fehlertracking bei Verwendung des Tag Managers

Option 1: Analyse ohne Anpassung der Implementierung

Ist der Trackingcode auf allen Seiten eingebunden und betrifft dies auch die Fehlerseite, landen alle Aufrufe von falschen URLs im gleichen Bericht wie korrekte Seiten und sind auf den ersten Blick nicht davon zu unterscheiden. Dennoch haben bei den meisten Websites - sei es über eine "handverlesene" explizite Fehlerseite oder gesteuert vom CMS - Fehlerseiten eine Gemeinsamkeit - nämlich den Titel. Eine korrekte URL wie https://www.gandke.de/kontakt.html landet daher als /kontakt.html ebenso im Seitenbericht wie der Aufruf einer falschen URL wie https://www.gandke.de/kontak.html (als /kontak.html) und ist je nach Übersichtlichkeit des Berichts bestenfalls zufällig zu finden. Aber während im ersten Fall der korrekte Titel zu sehen ist, beginnt dieser im zweiten Fall mit "Fehler 404: Seite nicht gefunden". Wählt man den Seitentitel daher z. B. im Bericht "Alle Seiten" als primäre Dimension in Analytics aus, kann man als sekundäre Dimension die "Seite" einblenden, um die fehlerhaften URLs zu sehen.

Fehlerseitenaufrufe in Google Analytics

Ebenso kann die sekundäre Dimension genutzt werden, um den Referrer darzustellen, was genutzt werden kann, um die Fehlerquelle zu finden und den falschen Link ggf. zu korrigieren - oder bei externen Links mit entsprechend vielen Aufrufen über eine falsche URL diese zur Not auch (freilich per 301 ;)) auf eine passende Seite weiterleiten, um den eintreffenden Besuchern die Ansicht einer Fehlerseite zu ersparen. Diese Methode hat zwar den Vorteil, dass man i. d. R. gar nichts tun muss - dafür ist die Auswertung aber auch eher mühselig. Wer dennoch darauf setzen mag, findet hier eine ausführlichere Anleitung.

Option 2: Erweiterung bei direkter Implementierung

Ist Analytics nicht mit dem Tag Manager implementiert, sondern direkt im Template des CMS oder statischen Seiten implementiert, kann man sich die Arbeit durch Anpassung des Templates oder Inhalts der Fehlerseite einfacher machen, indem die Informationen des Seitenaufrufs angereichert werden. Andere Lösungen verzichten auch auf die Anpassung des Seitenaufrufs und lösen statt dessen ein Event aus. Ich finde es "richtiger", wenn statt eines falschen Seitenaufrufs und eines Events nur ein Seitenaufruf generiert wird, der wie im ersten verlinkten Beispiel dann einen eigenen Dateinamen oder Pfad bekommt und die falsche URL sowie die Quelle des Verweises als Parameter zur Info angefügt werden... aber das ist vermutlich Geschmackssache. Dabei muss der Trackingcode auf der Fehlerseite lediglich eine selbst definierte URL als weiteren Parameter übertragen.

Anstelle von ga("send", "pageview") steht dann dort etwas wie

ga("send", "pageview", "/seite-nicht-gefunden.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer)

Der Vorteil dieser Lösung ist, dass man in allen Seitenberichten einfach per Filter auf "seite-nicht-gefunden" eine Übersicht erhält, aus der alle falschen URLs - und direkt auch deren Verweisquellen - abgelesen werden können.

Fehlerseitenaufrufe im Seitenbericht

Auch für diese Methode lassen sich sinnvolle Benachrichtigungen einrichten (siehe unten), um korrigierbare Fehler per Mail gemeldet zu bekommen.

Option 3: Umsetzung via Tag Manager

Unter der o. a. Voraussetzung eines eindeutigen Titels bei Fehlerseiten ist das separate Fehlertracking in Analytics leicht umzusetzen, wenn man mit dem Tag Manager arbeitet. Es muss nur eine Variable für den Seitentitel angelegt und ein Trigger erzeugt werden, der beim passenden Titel genutzt werden kann, um eine Messung vorzunehmen. Eine prima Anleitung dazu findet sich z. B. bei Christian Ebernickel, wobei allerdings auch hier auf ein Event statt eines Pageviews gesetzt wird. Auch landen die falschen URLs so nach wie vor verstreut in den Berichten und müssten per Seitentitel identifiziert werden, wenn man diese dort gesondert betrachten, filtern und / oder segemtieren möchte.

Sollen statt dessen wie in der direkt implementierten Variante angepasste Seitenaufrufe erzeugt werden, kann man z. B. eine zusätzliche Variable dazu nutzen, die im "Fehlerseitenfall" nicht nur die normale URL beinhaltet und diese als "page" im Universal-Pageview-Tag nutzen, welcher auch für das Tracking aller Seiten genutzt wird. Einfacher erscheint es aber, den neuen Trigger als ausschließenden Trigger für den "normalen Pageview" zu nutzen und damit ein neues Tag anzusteuern, welches nur für Fehlerseitenaufrufe genutzt wird.

Wer keine Lust hat, dem Link zur obigen Anleitung zu folgen, findet hier in aller Kürze auch die ersten beiden Schritte zur Implementierung (bis Schritt 3 bleibt die verlinkte Anleitung auf dem gleichen Weg):

Variable für Seitentitel anlegen

Warum auch immer: Der GTM bietet keine vorgefertigte Variable für den Seitentitel. Diese muss daher manuell erzeugt werden, als Typ dient eine "Java Script Variable" und als Inhalt "document.title".

Seitentitel als Variable im GTM

Trigger für Fehlerseiten

Mit der Variable kann nun ein neuer Trigger erzeugt werden, der dann aktiv wird, wenn eine Fehlerseite aufgerufen wird. Dazu wird der Titel der Fehlerseite in der Bedingung verglichen.

Trigger für Fehlerseiten im GTM

Pageview Tag verwenden

Abweichend von der o. a. Anleitung sieht es dann im nächsten Schritt (dort Schritt 3) passend zum Aufbau der Fehler-URLs aus dem obigen Beispiel so aus:

Google Analytics Tag zur Fehlerseitenmessung

Dazu kopiert man das "normale" Pageview-Tag, trägt als zusätzliches Feld den Wert

/seite-nicht-gefunden.html?page={{Page URL}}&from={{Referrer}}

ein und nutzt den neu angelegten Trigger für Fehlerseiten als Auslöser. In Berichten lassen sich dann Fehlerseitenaufrufe einfach identifizieren und weisen direkt die falsche URL und deren Verweisquelle auf. Die erste URL in diesem Beispiel zeigt so direkt an, an welcher Stelle ein falscher Link zu korrigieren ist.

Damit nur noch dieses Tag feuert, wenn eine Fehlerseite aufgerufen wird, sollte der neue Trigger zudem aus blockierender Trigger im "normalen Seitenaufruf Analytics-Tag" zugeordnet werden.  

Alert einrichten

Für jede der drei Varianten - unverändert, direkt implementiert oder per Tag Manager - kann und sollte man sich Benachrichtigungen senden lassen, wenn bestimmte Schwellwerte erreicht wurden. Dazu sind in der Verwaltung von Analytics schnell passende Alerts eingerichtet, mit denen man sich bei Häufung von Fehlerseiten - oder ausschließlich dem Auftreten von "behandelbaren" Fehlern - informieren lassen kann. "Behandelbar" meint dabei, dass die Verweisquelle bekannt ist, so dass man einen internen Link korrigieren oder einen externen Link weiterleiten kann. Die Alerts lassen sich bei der gewünschten Datenansicht unter "Verwalten -> Benutzerdefinierte Benachrichtigungen" definieren. Dabei kann man dann entweder alle Aufrufe von Fehlerseiten ab einem bestimmten Schwellwert als Auslöser nehmen oder nur die Aufrufe betrachten, bei denen im Parameter "from" (ausgehend von den obigen Beispielen) wirklich ein Referrer übergeben wurde. Der entsprechende Alarm würde dann so aussehen:

Analytics Alert bei 404-Fehlerseiten

Das Muster ^(/seite-nicht-gefunden)(.*)([^(from=)]$) muss dabei ggf. angepasst werden, wenn man eine andere Struktur oder Seite gewählt hat. Auf diese Weise ist man schnell informiert, wenn auf der eigenen Site Fehlerseiten aufgerufen werden - und kann dann entsprechend reagieren.

#  
Monday, 07 November 2016

Google Analytics: Mobile Opt-Out-Cookies und der Google Tag Manager

Wer Google Analytics auf seiner Website einsetzt, hat für einen datenschutzkonformen Einsatz einige Hürden zu nehmen: Ein Vertrag muss geschlossen, der Trackingcode zur Anonymisierung der IP-Adressen angepasst und die Datenschutzbestimmungen ergänzt werden. Beim letzten Punkt geht es nicht nur um die Information der Besucher über den Einsatz, sondern auch um die Anforderung, allen Besuchern eine Möglichkeit zum Ausstieg aus dem Tracking zu bieten. Dabei wird i. d. R. auf entsprechende Browser-Plugins hingewiesen, die von Google bereitgestellt werden und die bei Installation das Tracking auf allen in diesem Browser besuchten Websites unterbinden.

Da diese Methode aber darauf angewiesen ist, dass ein Browser eingesetzt wird, für den eine passende Erweiterung verfügbar ist, deckt das leider nicht alle Besucher ab. Exotische Browser sind dabei weniger ein Problem als vielmehr der mobile Traffic, denn in typischen mobilen Browsern kann ein solches Plugin nicht genutzt werden. Besucher mit Smartphones und Tablets können sich daher nicht ohne größeren Aufwand dem Tracking via Google Analytics entziehen.

Opt Out per Cookie

Als Lösung kann man per Cookie jedem Besucher für die eigene Domain eine individuelle Ausstiegsmöglichkeit bieten. Dabei wird bei Klick auf einen Link ein Cookie erzeugt, welches den Wunsch auch für künftige Seitenaufrufe speichert. Diese Lösung erfordert neben dem Erzeugen des Cookies auch, dass vor dem eigentlichen Analytics-Trackingcode der Wert dieses Cookies ausgelesen wird, um im Bedarfsfall für eine Blockierung der Analytics-Trackingaufrufe zu sorgen.

Die Methode basiert auf einer für genau diesen Zweck im Analytics-Trackingscript vorgesehenen "Opt-Out-Hintertür", welche auch schon im alten gs.js-Code zu finden war. Um sie zu nutzen, wird mittels JavaScript eine Eigenschaft des window-Objekts auf "true" gesetzt, welche die jeweilige Property-ID enthält. Für eine Analytics-Property mit der IdUA-12345-67 müsste dazu z. B. window['ga-disable-UA-12345-67'] = true; gesetzt werden.

Cookie setzen

Um diese Methode zu nutzen, muss - idealerweise in den Datenschutzhinweisen unter dem Abschnitt zu Google Analytics, der mit dem Hinweis auf die Plugins endet - auf der Website ein Link angebracht werden, der bei Klick einen Cookie setzt und auch gleich zur Blockierung aller weiterer Hits wie z. B. Events beim Scrollen auf der Seite o. Ä. die o. a. Eigenschaft des window-Objekts setzt. Das kann z. B. so aussehen (UA-12345-67 gegen die eigene Property-Id an beiden Stellen austauschen):

<a href="#" onclick="document.cookie='ga-disable-UA-12345-67=true;expires=Thu, 31 Dec 2099 23:59:59 UTC;path=/';window['ga-disable-UA-12345-67']=true;return false">Opt-Out Cookie für diesen Browser und diese Website setzen</a>

Trackingcode anpassen

Wird beim Aufruf einer Seite ein solches Cookie gefunden, muss die window-Eigenschaft gesetzt werden, um alle folgenden Trackinghits zu "entwerten".

Dazu wird der normale Trackingcode um zwei Zeilen direkt am Anfang erweitert. Hier als Beispiel der Trackingcode für Universal Analytics inkl. der erforderlichen Anonymisierung - auch hier ist die Id UA-12345-67 gegen die eigene Id auszutauschen:

<script>
var gaOptOut='ga-disable-UA-12345-67';
if (document.cookie.indexOf(gaOptOut+'=true')>-1) window[gaOptOut]=true;

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-12345-67', 'auto');
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');
</script>

Auf diese Weise wird der Analytics-Trackingcode zwar "ausgespielt", es werden aber keine Hits mehr an den Analytics-Server übertragen. Als Vorlage zur Anpassung eigener Seiten finden Sie hier eine einfache Beispielseite mit Analytics Opt-Out nach genau diesem Muster.

Was tun bei Einsatz des Google Tag Managers?

Ist der Tag Manager statt eines direkt in die Seite implementierten Analytics-Trackingcodes im Einsatz, muss natürlich auch dort der Wunsch des Websitebesuchers berücksichtigt werden.

Blockierenden Trigger anlegen

Dazu kann ein blockierender Trigger eingesetzt werden, der als Bedingung den Wert "true" aus dem o. a. Cookie ausliest. Um auf den Wert zugreifen zu können, wird er (als "First Parry Cookie") aus dem Cookie ausgelesen und als Variable im GTM bereitgestellt.

Out-Out-Cookie im GTM auslesen

Dieses Beispiel geht davon aus, dass im GTM eine Variable vom Typ "Konstante" (nicht lachen bitte) existiert, in der die Id der Analytics-Property enthalten ist und die via {{gaPropertyId}} im Tag eingelesen werden kann. Theoretisch ist es natürlich auch möglich hier direkt die Id einzutragen.

Abhängig vom Wert, der nun in dieser neuen Variable (im abgebildeten Beispiel gsOptOutCookie) ausgelesen werden kann, wird nun ein Trigger definiert, der als "Benutzerdefiniertes Ereignis" angelegt wird und dann "feuert", wenn der Wert "true" im Cookie gefunden wurde.

Trigger zum Blockieren des Trackings im GTM

Option 1: Analytics-Tags anpassen

Die übliche Methode erfordert nun allerdings, dass alle vorhandenen - und auch alle künftig hinzugefügten - Analytics-Tags mit diesem blockierenden Trigger versehen werden müssen.

Trigger zum Blockieren des Trackings im GTM bei allen Analytics Tag nutzen

Das bedeutet nicht nur viel Arbeit bei einer tiefen Implementierung mit vielen Tags, sondern auch Disziplin bei Pflege und Erweiterung des GTM-Containers. Wo mehrere Benutzer für das Tag Management verantwortlich sind, können so schnell Lücken entstehen, die dann doch wieder zum Tracking trotz gesetztem Cookie führen können.

Option 2: "One Tag To Rule Them All"

Daher empfiehlt sich überall, wo mehr als ein Analytics-Tag im Einsatz ist und / oder mehrere Personen im Spiel sind, auf eine andere Lösung zurückzugreifen. Hierbei wird nur ein weiteres Tag genutzt, welches nach dem gleichen Verfahren wie die Anpassung des Trackingcodes vorgeht und die window-Eigenschaft nutzt, um das Tracking zu verhindern.

Als Auslöser für das neue Tag muss (genau wie im o. a. Fall des blockierenden Triggers) der Cookie-Wert aus einer Variable eingelesen und ein Trigger erzeugt werden, der diesmal aber nicht zum Blockieren aller Analytics - Tags genutzt, sondern als Auslöser für das neue Tag zum Setzen der window-Eigenschaft eingesetzt wird.

Zum Einsatz kommt ein Benutzerdefiniertes HTML-Tag mit einem sehr überschaubaren Inhalt - auch hier wird wie oben davon ausgegangen, dass die Property-Id als Variable eingelesen werden kann:

window['ga-disable-'+{{gaPropertyId}}] = true;

Damit die Auslösung vor den Analytics-Tags erfolgt und deren Aufrufe bei entsprechendem Cookie blockieren kann, wird die Priorität auf einen hohen Wert gesetzt.

Tag zum Blockieren des Trackings im GTM

Ausgelöst wird dieses Tag nur dann, wenn der Cookie-Wert stimmt - also wird der o. a. Trigger hier eingesetzt.

Block-Trigger als Auslöser des Block-Tags nutzen

Funktionstest

Es ist sinnvoll, bei allen beschriebenen Methoden zu testen, ob die Lösung wie erwartet funktioniert. Dazu kann z. B. der Google Analytics Debugger in Chrome eingesetzt werden. Auch andere Plugins wie der Tag Assistant zeigen zwar, dass der Tracker bei korrektem Einbau keine Antwort erhält und offenbar "falsch implementiert" sei, solange das Cookie vorhanden ist, aber der Debugger erlaubt einen detaillierteren Blick. Ist nach Klick auf den in den Datenschutzhinweisen eingebauten Link ein Opt-Out-Cookie zu finden, sollte man im Debugger beim Versuch des Cookie-Speicherns und dem ersten abgesetzten Hit einen Hinweis wie diesen hier statt der Meldung Sent beacon sehen:

Funktionstest mit dem Analytics Debugger

Damit ist sichergestellt, dass die Blockierung der Aufrufe funktioniert. Ist das nicht der Fall, hilft die Console dabei Fehler zu identifizieren und zu beheben. Oder natürlich eine Mail an uns ;)

#  
Monday, 13 June 2016

DNT WTF? "Do Not Track" - und warum es niemanden interessiert

Do Not Track ist ein alter Hut, hinter dem eine gute Idee steckt: Wer im Internet unterwegs ist, kann damit schon bei der Anfrage an einen Webserver kundtun, dass er nicht getracked werden möchte. Das aus dem Jahr 2009 stammende Konzept, welches es noch nicht zum Standard gebracht hat, klang auch für Browserhersteller so sinnvoll, dass es schon seit 2010 funktionierende Implementierungen in gängigen Browsern gibt. Aber: Wer nutzt DNT - und vor allem: Wer hält sich dran?

Es gibt zwar auch über Wikipedia hinaus jede Menge Infos zum Thema Do Not Track zu ergoogeln... die Ergebnisse bestehen aber zu einem Löwenanteil aus technischen Informationen. Dass das Thema noch immer aktuell ist, beweisen regelmäßige Beiträge zum Thema Tracking in den Medien... oder auch die Webserie "Do Not Track". Vor allem aber bei der zweiten obigen Frage ("Wer hält sich dran?") gibt es (abgesehen von Browserherstellern) nur wenige Informationen. Und schon gar keine erfreulichen.

TL;DR

Die folgende Grafik fasst den Stand auf Websites und deren Nutzer für alle, die die lästigen Details nicht benötigen, in aller Kürze zusammen.

DNT Nutzung 2016

Umsetzung auf Empfängerseite: Fehlanzeige

Wer (wie ich) nichts mit Mayonnaise anfangen kann, kennt das folgende Phänomen vielleicht: Man kann beliebig oft und deutlich bei der Bestellung am Drive In - Schalter "ohne Mayo" sagen; in der Tüte wird dennoch mindestens eine Portion zu finden sein. Ähnlich sieht es auch aus, wenn man sich DNT näher anschaut. Wer eine entsprechende Option im Browser aktiviert, sendet einen Do Not Track - Header bei jedem Request an einen Webserver. Respektiert der Server bzw. der Betreiber der Website diese Information, sollten im Idealfall keine Tracking-Mechanismen zum Einsatz kommen.

Zuständigkeit, Anwendbarkeit und Umfang ungeklärt

Genau wie bei der Fast-Food-Bestellung bleibt dieser Wunsch aber i. d. R. ungehört. Denn technisch zuständig für eine Erfüllung wäre - in der idealen Welt - weder der Betreiber des Servers, noch der Webmaster. Der Ball liegt in der Theorie bei den Anbietern von Trackingsystemen. Welche Systeme man dazu zählen soll, ist unklar und wird durchaus diskutiert. Muss man in diesem Fall schon auf Webanalyse mit Google Analytics, eTracker & Co. verzichten? Oder geht es um Drittanbieter-Cookies? Wenn ja: Alle? Oder nur diejenigen, die Werbezwecken wie Remarketing oder anderen Dingen wie vor allem der websiteübergreifenden Profilbildung dienen?

"Was hätte ich davon?"

Und so kümmert sich schlussendlich folgerichtig (fast) niemand um eine Implementierung auf der Empfängerseite, wenn es nicht irgendwelchen Zwecken dient. Das ist nachvollziehbar, denn wenn Werbenetzwerke freiwillig Reichweite aufgeben oder Webanalysesysteme "aus rein moralischen Gründen" Messungen auslassen, wäre das weder aus unternehmersicher Sicht sinnvoll, noch dient es dem direkten Kunden des Anbieters.

Ein Anreiz könnte es sein, sich durch eine Umsetzung vom Wettbewerb abzusetzen und diesen moralischen Vorteil aktiv zu vermarkten. Am Beispiel der Webanalyse könnte das - speziell für den deutschen Markt - tatsächlich ein Verkaufsargument sein... und sei es nur eine Option, die der Nutzer des Systems bewusst aktivieren muss.

Implementierungsbeispiele unter der Lupe

Einige Hersteller scheinen dies auch versucht zu haben. Unter donottrack.us findet sich eine Liste, in der verschiedene Werbeplattformen, Netzwerke, Social Platforms und Tag Manager (wo es auch besonders sinnvoll wäre :-D) stolz verkünden, Do Not Track tatsächlich zu würdigen.

Leider hält diese Liste mit 21 Unternehmen keinem zweiten Blick stand, sondern gibt vielmehr ein trauriges Negativbeispiel ab:

  • 4 Unternehmen bieten nicht einmal einen Link zu einer Seite an, auf der es weitere Informationen darüber gibt, in welcher Form und welchem Umfang DNT dort ein Thema ist
  • Unter einem der verbleibenden Links findet man zwar eine Seite, aber keine Infos zum Thema
  • Bei 6 Anbietern ist die Seite nicht erreichbar (Fehler oder Timeout) - vermutlich existieren diese Firmen gar nicht mehr
  • 3 sind definitiv inzwischen nicht mehr am Markt oder wurden gekauft, so dass deren URLs weitergeleitet werden
  • Bleiben 7 von 21, bei denen es zumindest einen Blogbeitrag oder eine andere Information zu DNT gibt. Neben Twitter und Pinterest sind das zwei Tag Manager - Systeme (Tealium und Ensighten), zwei "Data Provider" und Chitika (Infos zur Implementierung) als einziges verbleibendes Werbenetzwerk.

Der "Respekt" gegenüber DNT beschränkt sich zudem meist nur auf marginale (Personalisierungs-) Funktionen wie z. B. die tailored suggestions bei Twitter. Die Tag Manager erlauben zumindest die optionale Berücksichtigung, ein generelles OptOut ist bei keinem Anbieter auf dieser Liste (außer Chitika) vorgesehen. Auf einer aktuelleren Liste finden sich zwar auch noch weitere Namen, aber meistens sind dies Plattformen wie Reddit. Medium oder Hulu, die entweder keine Cookies setzen oder zumindest Third-Party-Tracker unterdrücken und nur noch die eigenen Daten anreichern. Sprich: Wer sich daran hält, bestimmt selbst, in welcher Form und welchem Umfang dies geschieht.

Ein trauriges Ergebnis, oder? Daran wird sich mittelfristig auch kaum etwas ändern. Auch nicht durch die "teil-optimistische" Formulierung im Firefox - FAQ zum Thema DNT. Dort steht:

FAQ bei Firefox

DNT aus Sicht des Websitebesuchers

Dass sich kaum ein Hersteller von Web- und Trackingsystemen um DNT schert, ist unter den gegebenen Rahmenbedingungen kein Wunder. Dennoch existieren die "senderseitigen" Implementierungen in gängigen Browsern. Dort wird mehr Privatsphäre versprochen, wenn diese Option aktiviert wird. In Zeiten wachsender Datenklau-Paranoia, großflächiger Überwachung durch Nachrichtendienste, nerviger Werbebanner für Produkte, die den armen Shopbesucher noch wochenlang (oft auch nach dem Kauf) durch das Web verfolgen und folgerichtig steigendem Interesse an Werbeblockern sind "Datenschutz" und "Privatsphäre" zu Faktoren geworden, die man im Marketing ausspielen kann.

DNT aktiv = Bewusste Entscheidung?

Trotzdem ist die Option in den meisten Browsern recht gut versteckt und erfordert eine aktive Suche nach Datenschutzeinstellungen. Dass dann im Kontext der dort zu findenden Optionen klar ist, was DNT nun genau bei Aktivierung macht oder nicht, darf angezweifelt werden. Und selbst die Browseranbieter eiern herum, wenn es darum geht, den konkreten Nutzen zu erklären. Daher ist die folgende Meldung aus Chrome sicher nicht nur wegen Googles naturgemäß zwiespältiger Einstellung zum Datenschutz recht unklar:

DNT Meldung in Chrome

Im Internet Explorer ist die Option ebenfalls gründlich in den erweiterten Einstellungen verborgen und wird erst mit Scrollarbeit sichtbar.

DNT Option im IE

Microsoft hatte diese Option in Version 10 des IE sogar standardmäßig aktiviert, bis man dem Protest nachgegeben und dies wieder in eine erst vom Anwender einzuschaltende Funktion umgewandelt hatte. Daher sollte man davon ausgehen, dass heute faktisch niemand mit aktivierter DNT-Option im Web unterwegs ist. Aber: Stimmt das so?

Wer nutzt DNT?

Wer sich nicht aktiv - oder zumindest nebenbei bei der Einrichtung seines Browsers - für das Senden eines DNT-Headers entschieden hat, wird im Normalfall ohne DNT unterwegs sein. Wer sich nicht mehr erinnern kann, kann sich bei Mozilla Gewissheit verschaffen. Die Do Not Track-Infoseite zeigt den Status an.

DNT Status

Statistiken zur allgemeinen Nutzung gibt es aber offenbar kaum. Lediglich bei Firefox, wo man allgemein recht aktiv mit dem Thema umzugehen scheint, finden sich umfangreiche Statistiken zur Nutzung. Betrachtet man diese über einen kürzeren Zeitraum, erscheint die Rate der DNT-aktiven Firefox-Nutzer unglaublich hoch zu sein. Dieser Eindruck wird gemildert, wenn man eine längere Zeit betrachtet und sieht, dass die Gesamtzahl der Nutzer deutlich schneller sinkt als die Gruppe der "DNT-Aktiven"....

DNT Abdeckung (Langzeit)

... aber trotzdem erscheint ein Anteil von 25% (basierend auf den Zahlen der Woche des 22. Mai 2016) sehr hoch. Warum sollten so viele Nutzer eine gut versteckte Option aktivieren, die faktisch kaum einen Effekt hat? Und wie sieht es mit anderen Browsern aus? Aktuelle Zahlen dazu waren nicht zu finden.

Statistik zur Nutzung von DNT

Wir haben uns ersatzweise selbst über mehrere Monate auf verschiedenen Websites um eine Messung des Anteils der Besucher mit aktivem DNT-Header bemüht. Als Messinstrument haben wir Google Analytics genutzt und den DNT-Status aller Besucher in einer benutzerdefinierten Dimension abgelegt, um diese später separat auswerten zu können. Zugegeben: es mag ein "Geschmäckle" haben, in einem Trackingsystem zu tracken, wer nicht getracked werden will... aber wie sonst soll man an entsprechende Daten kommen? Eine saubere Implementierung von Google Analytics schließt persönliche Daten im Tracking aus. Aus Datenschutzgründen ist daher nichts daran auszusetzen, den DNT-Header abzufragen und die Information als Segmentierungsmerkmal zu übergeben. Daher haben wir uns für diese Methode entschieden.

Unterstützt wurden wir dabei von einigen Shops, Websites und Portalen zu verschiedenen Themen unterschiedlicher Größe (Danke dafür u. a. an Steuer Schutzbrief, Smart-Rechner.de, Entrex und Trixum). Der konsolidierte Datenpool aller Websites kommt auf eine Gesamtzahl von knapp 2 Millionen ausgewerteter Websitebesuche. Das sind vermutlich weder genug Daten, um eine verlässliche Aussage für "das Web allgemein" noch die abgedeckten Branchen im Speziellen zu machen, aber dennoch vermitteln diese einen klaren Eindruck, der einen deutlich niedrigeren Anteil als 25% aufzeigt.

Die Zahlen schwanken je nach Site zwischen 7,7% und 11,7% - im Mittel über alle ausgewerteten Sessions liegt der Anteil bei knapp 9%. Die Belastbarkeit dieser Zahl ist anzweifelbar, passt aber mit 8,8% ganz gut zu den 8,4%, die man über die Implementierung bei Chitika lesen kann.

DNT Verteilung (alle Sites)

Verteilung nach Browser

Das sieht schon anders aus als bei der Mozilla-Statistik. Es ist also zu erwarten, dass Firefox einen wesentlichen Anteil an den Besuchen mit DNT hat. Auch das geben die erhobenen Daten her. Hier die Verteilung der DNT-Sessions nach Browser gruppiert:

DNT Verteilung (nach Browser)

Gut die Hälfte aller Sessions kommt also von Firefox. Je nach Site schwankt dieser Anteil in der Einzelbetrachtung zwar stark zwischen 42% bis zu satten 76% (basierend auf immer hin knapp 300.000 Sessions), aber in jeder Statistik bleibt Firefox Spitzenreiter; stets gefolgt von Safari auf Platz zwei und entweder Chrome oder (seltener) IE auf dem dritten Rang.

Dennoch ist Do Not Track offenbar nichts, was nur auf dem Desktop oder Notebook relevant zu sein scheint. Segmentiert man die Browser weiter nach Plattform, spielt Firefox im Mobilbereich zwar kaum eine Rolle, dafür sind gute 80% der Safari-Besuche mit der mobilen Fassung des Browsers (iPhone oder iPad) gemessen worden. Auch bei Chrome ist der Anteil der mobilen Sessions in der Statistik nennenswert. Im Schnitt sind ca. 40% der Chrome-Sessions mobil.

Wer ist das?

Wie kommt es, dass ca. 9% aller Webbesucher - und ein deutlich größerer Anteil aller Firefox-Benutzer - mit aktiviertem DNT-Header unterwegs sind? Die Antwort bleiben wir schuldig. Wer hierzu Ideen oder gar eine Erklärung liefern kann, sollte uns unbedingt anschreiben und sein Wissen teilen bzw. einen entsprechenden Kommentar hinterlassen. Wir sind gespannt ;)

Was tun mit der "Erkenntnis"?

Ehrlich gesagt: Wissen wir auch (noch) nicht. Ursprünglich ging es uns nur um eine Antwort auf die Frage nach dem Anteil. Was würde man zusätzlich zu den sich ohnehin bereits per Blocker aktiv der Webanalyse entziehenden Besuchern verlieren, wenn z. B. Google Analytics nicht mehr tracken würde, sobald ein DNT-Header gesendet wird? Zumindest diese Frage ist nun ansatzweise geklärt: weniger als 10%. Strittig aber bleibt, ob "normale Webanalyse" sich überhaupt darum kümmern sollte (wir glauben nicht)... oder ob es nicht doch eher die Remarketingtools und Datensammler sind, die sich daran halten sollten. Speziell diese Vertreter werden in der Masse damit aber niemals (freiwillig) anfangen.

Empfehlung

Sollte man DNT nun aktivieren oder nicht? Wer der Bildung von Profilen entgegenwirken will, darf und soll das ruhig tun. Den DNT-Schalter umzulegen, nutzt nur eben bedauerlich wenig, wenn man von einzelnen Funktionen bei Twitter und anderen Plattformen absieht. Ist der Wunsch erst gemeint, kommt man an Werbe- und Scriptblockern, Opt-out-Lösungen einzelner Anbieter als Browserplugin oder globalere Lösungen wie TACO und Privacy Badger nicht vorbei. Und das alles nutzt ebenfalls nichts, wenn wir doch am Ende des Tages stets bei Facebook, Google & Co. eingeloggt sind, wenn wir das Web nutzen (welches voll ist von deren kleinen Augen und Ohren in iFrames), Standorttracker (AKA Smartphones) mit uns herumtragen und Kredit- oder gar Rabattkarten beim Offline-Einkauf nutzen!!1elf!! ;)

#  
Tuesday, 24 November 2015

Scroll-Tracking für Google Analytics / Google Tag Manager ohne jQuery

Die Anreicherung der Daten in Google Analytics durch Scroll-Tracking in Form von Events ist keine neue Aufgabe. Der Grund, warum es hier dennoch einen weiteren Beitrag und eine zugehörige Lösung gibt, ist der Ansatz, der dahinter steckt: Das Script beschränkt sich auf wenige Zeilen Code und ist unabhängig von Bibliotheken wie jQuery & Co. Die Basis stammt ironischerweise von einem älteren jQuery-basierten Lösungsansatz aus dem alten Google Analytics Produktforum stammt.

Für so wenig Einsatz bekommt man auch keine Extras: Es wird z. B. kein Timer verwendet, der die Intervalle zwischen Scrollvorgängen misst und den Events hinzufügt bzw. Timings an anderer Stelle hunterlegt. Der simple Grund dafür ist, dass in der Praxis oft ohnehin nur die durchschnittliche Scrolltiefe betrachtet wird und so zu Insights führt, die Änderungen auf der Website oder der gemessenen Landingpage bringen.

Warum Scroll-Tracking?

Das Auslösen von Events in der Webanalyse beim Scrollen durch den Benutzer dient i. d. R. vor allem dazu, die Absprungrate und Verweildauer zu "korrigieren" und zu prüfen, ob die weiter unten angeordneten Inhalte die Aufmerksamkeit bekommen, die man sich dafür erhofft. Den Pageviews der Standardimplementierung werden so weitere Messpunkte hinzugefügt, die die Messung der o. a. Metriken verbessern.

Scroll-Tracking-Script

Kurz genug? Da das Script sowohl für den Tag Manager als auch den direkten Einsatz vorgesehen ist, kann der Purist sogar zur Reduktion die Definition von useDataLayer und die zugehörige Bedingung weiter unten entfallen lassen und nur die benötigte Anweisung an Stelle der Bedingung erhalten. Viel ist dann wirklich nicht mehr übrig ;)

Das Script auf der eigenen Website einsetzen

Vor dem Einsatz ist zu bestimmen, welche Seiten Scroll-Tracking wirklich benötigen. Zwar ist die "Kapazitätsgrenze" bei Google Analytics abhängig von Sessions und nicht Hits, aber trotzdem ist das unsinnige Beschießen der Property mit Daten unsinnig, wenn diese potentiell ungenutzt bleiben.

Präzision bestimmen

In der Zeile var trackScrollStep = 20; wird definiert, in welcher Schrittweite der prozentuale Fortschritt beim Scrollen auf einer Seite gemeldet werden soll. Die Zahl "20" bedeutet, dass Events in 20% Schritten ausgelöst werden. Möglich ist theoretisch alles zwischen 1 und 50, wobei allerdings nur eine Schrittweite sinnvoll ist, die eine glatte Messung von 100% ermöglicht. Mehr Messpunkte bekommt man also mit 5, 10 oder 12.5. Mit 25 (oder 50) werden es weniger.

Verwendung im Google Tag Manager

Die indirekte Implementierung von Google Analytics Tracking und anderer Codesüber den Google Tag Manager zahlt sich auch in diesem Fall aus.

Script als Tag ausspielen

Das Script kann direkt als Benutzerdefiniertes HTML-Tag eingebunden und die Scroll-Events ausgelöst werden, ohne dass die Website "angefasst" werden muss. Ob man das Script auf allen oder nur ausgewählten Seiten benötigt, wird über Regeln bzw. Auswahl des passenden Triggers direkt beim Tag bestimmt (hier: "Alle Seiten / All Pages").

Wenn das Script im Tag Manager genutzt wird, sollte useDataLayer = true; gesetzt werden, damit ein Trigger für die Events genutzt werden kann. Halbherzig wäre es, an dieser Stelle false anzugeben und einfach die Events über die Zeile mit der ga('send'...)-Anweisung zu verschicken. Funktionieren würde es natürlich trotzdem ;)

Trigger anlegen

Der saubere Weg führt über einen Trigger, der dann wiederum ein weiteres Tag für die Events steuert. Dazu wird ein "benutzerdefiniertes Ereignis" erzeugt, dass beim Ereignis updScrollPercentage ausgelöst wird.

Datenschichtvariable für Scrolltiefe

Damit die Events die Tiefe des Scrollvorgangs zurückliefern können, wird eine Datenschichtvariable benötigt, die das Script in den dataLayer schreibt. Als Name der Variable wird scrollPercentage angegeben und ein beliebiger Name für die Variable definiert, über die gleich die Events auf den Wert zugreifen können (in diesem Beispiel "scrollEventDepthLabel").

Event-Tag

Fast fertig - zurück zu den Tags. Hier wird ein Tag vom Typ "Google Analytics -> Universal Analytics" benötigt. Tracking-Id eintragen oder (bei sauberer Implementierung ;)) aus einer Variable auslesen und dann als Erfassungstyp "Ereignis" auswählen. Bei der Gestaltung der Parameter wird nun auf die Datenschichtvariable zurückgegriffen und (als Label oder Wert) im Event verwendet. Kategorie und Aktion können beliebig benannt bzw. mit weiteren Variablen wie dem Pfad oder Titel der Seite belegt werden.

Die Anonymisierung der IP-Adresse nicht vergessen und unten als Auslöser den gerade erzeugten Trigger für Scrollvorgänge auswählen. Das wars!

Direkte Implementierung

Wer den Tag Manager nicht nutzt, kann das Script auf dem eigenen Server ablegen und über einen Script-Verweis im Template seines CMS laden. Dazu reicht ein Verweis im Fuß der Seiten; es muss nicht im head der Seiten sein.

Zur Konfiguration im Script die Schrittweite wählen, useDataLayer = false; setzen und ggf. die Vorgaben für Eventkategorie und -aktion in der Zeile ga('send', 'event', 'Interaction', 'ScrollPercentage', trackBottomScroll); anpassen.

Kontrolle in Google Analytics

Nach der Einbindung der direkten Variante im Livebetrieb oder dem Veröffentlichen der getesteten neuen Version im Tag Manager sind die Events im Echtzeit-Report unter "Ereignisse" direkt zu sehen.

Jetzt müssen nur noch Daten gesammelt und unter Verhalten - Ereignisse ausgewertet werden. Viel Spaß und Erfolg bei der Optimierung!

#  
Monday, 16 November 2015

Analytics Ghost Spam wirksam verhindern: Ein etwas anderer Filter

Tipps zum Aussperren von Referral- und Eventspam in Google Analytics - auch "Ghost Spam" - gibt es jede Menge. Warum also noch ein Artikel dazu? Weil hier eine Idee zur Ergänzung der gängigen Verteidigungsstrategien vorgestellt werden soll, die sich in Tests als durchaus wirksam erwiesen hat.

Die üblichen Filter - und deren Grenzen

Wenn man nach "Analytics Referral Spam verhindern" oder ähnlichen Phrasen bei Google sucht, findet man reichlich Anleitungen zum Einrichten von Filtern, die per "Ausschließen"-Funktion bekannte Spammer aus dem eigenen Profil fernhalten sollen. Das funktioniert zwar ganz gut, allerdings muss man regelmäßig die Berichte nach neuem Spam durchsuchen und hinzukommende Quellen durch Anpassung des Filters abdecken. Diese Methode hilft daher nur "in Schüben"; ist auf Eigeninitiative angewiesen und potentiell fehleranfällig: Wer sich bei der Definition der Regular Expression für den Filter verschreibt (sehr menschlich und nicht unwahrscheinlich), vernichtet im schlimmsten Fall sogar (unwiederbringlich!) Daten, bis es endlich auffällt. Die Entropie muss hierbei auch in möglichst kurzen Abständen durch Aktualisierung der Filter bekämpft werden. Faulere, aber auch mutigere Ansätze basieren daher auf "Einschließen"-Filtern, die aber ebenso ihre Tücken haben und nicht in jedem Fall wirklich sinnvoll genutzt werden können.

Alle diese Lösungen haben eine Schwachstelle, die durch den stetig gestiegenen Bedarf nach Anleitungen zur Bekämpfung von Analytics Spam immer relevanter wird: Spammer kennen diese Tipps und umgehen sie, indem Sie nicht mehr den eigenen oder keinen ("not set") Hostnamen übergeben, sondern der Hostname der "bespammten" Domain - oder eine mit hoher Wahrscheinlichkeit in solchen Filtern erlaubten Domains wie googleusercontent.com - genutzt wird. Das ist mit dem Google Analytics Measurement Protocol problemlos möglich... und mehr und mehr Spammer nutzen genau diesen Weg, um ihre Pageviews oder Events an Filtern vorbei in die Webanalyse der Opfer zu bekommen.

Aus anderen Gründen scheitern auch im Großteil der Fälle Ansätze zur Bekämpfung, die auf dem Blockieren von Spam in der .htaccess des eigenen Servers basieren. Denn der eigene Server ist inzwischen nur noch selten an der Übermittlung der falschen Daten beteiligt. "Ghost Spam" zeichnet sich genau dadurch aus - und diese Form liefert den Löwenanteil des Datendrecks in Google Analytics.

Zuletzt: Auch Versuche des Aussperrens über die Verweisausschlussliste sind zum Scheitern verurteilt, denn diese Funktion hat einen ganz anderen Zweck... ebenso wie die Checkbox zum Ausfiltern bekannter Bots und Spider hier nicht hilft. Was also tun?

Spammer aussperren - ein etwas anderer Ansatz

Dazu soll hier eine andere Methode zur "Verteidigung" vorgestellt werden: Um zu einer gefilterten und möglichst spamfreien Datenansicht als "Arbeitsprofil" für die eigene Website zu kommen, muss ein vom Hostnamen abweichendes Filterfeld her, das in herkömmlichen Spam-Anfragen nicht enthalten bzw. nicht mit dem erwarteten Wert befüllt ist. Dazu bieten sich z. B. benutzerdefinierte Dimensionen und / oder Metriken an. Diese können - einmal in Analytics definiert - durch einfache Anpassung des Trackingcodes für alle Hits mit einem eindeutigen Wert belegt werden. Dieser ist i. d. R. nicht Bestandteil von Spamanfragen, so dass diese es nicht in ein Profil schaffen, welches nur Hits einschließt, die den erwarteten Wert aufweisen. Es sei denn, der Spammer zielt explizit auf eine bestimmte Site und dupliziert daher nach einer Analyse des vorhandenen Trackings die Extrawurst (denn das ist dann auch mit dem Measurement Protocol kein Problem). Sprich: Diese Methode hilft gegen "normale" Spammer aller Art, aber nicht gegen gezielte Manipulation von Daten ausgewählter, bestimmter Websites.

So geht´s:

  • Unter Verwalten (oben) -> Property -> Benutzerdefinierte Definitionen -> Benutzerdefinierte Dimensionen einen neuen Eintrag anlegen, benennen und speichern. Ich habe mich hier für eine Dimension auf Session-Ebene entschieden - bei den meisten Implementierungen von Google Analytics sollte aber auch die Ebene "Hit" einwandfrei funktionieren.

    Dimension anlegen
  • Den Trackingcode auf der eigenen Domain um die Angabe der Dimension erweitern und einen Standardwert für den Filter hier eingeben. Dabei unbedingt beachten, dass man die richtige Dimension mit einem Wert belegt - im Beispiel ist das dimension2, weil der Slot 1 schon genutzt wird. Als Wert kann eine beliebige Konstante verwendet werden. "FU" ist z. B. ein prima Wert für eine Dimension, die Spam abhalten soll ;)
    ga('set', 'dimension1', 'FU');
  • Nun muss noch eine gefilterte Datenansicht her, die nur den Traffic beinhaltet, der diesen Wert überträgt. Spammer bleiben so draußen. An dieser Stelle ist ein Hinweis unvermeidbar: Es sollte immer eine Datenansicht erhalten bleiben, die ungefilterte Rohdaten enthält. Es empfiehlt sich daher die Anlage einer weiteren, neuen Datenansicht für den Test des Filters und zur späteren Verwendung als spamfreies Arbeitsprofil. Dazu einfach die "Einstellungen der Datenansicht" für die aktuell verwendete Ansicht öffnen und auf "Datenansicht kopieren" klicken, um eine Kopie anzulegen. In dieser Kopie kann dann der entsprechende Filter angelegt werden, indem ein benutzerdefinierter "Einschließen"- Filter auf die eben angelegte Dimension gelegt wird und nur Daten durchlässt, die den eben definierten Wert beinhalten. Für das obige Beispiel wäre dies dann also:

    Filter anlegen
  • Fertig

Wenngleich historische Daten fehlen, sollte die neue Datenansicht ab sofort neue, sauberere Daten sammeln, die tatsächlich nur Hits enthalten, die von der eigenen Website stammen. Das ungefilterte Profil sollte demnach höhere Zahlen aufweisen, wenn man wirklich mit Spam zu tun hat und Angaben zu Sessions etc. über einen längeren Zeitraum vergleicht. Damit ist man allerdings "nur" den Mist los, der sonst durch die üblichen Filter nach Hostname etc. kommt. Der Filter ist aber zum Glück sinnvoll kombinierbar mit den anderen Methoden - selbst das Ausschließen der Spammer über die .htaccess des eigenen Servers hilft nun wirklich, die Qualität zu verbessern, denn so erspart man sich den (geringen) Rest an Crawler-Spam, der wirklich noch die echte Website zum Absetzen des Spams verwendet.

Spamkontrollprofil

Um sicherzustellen, dass wirklich nur das ausgefiltert wird, was nicht benötigt wird, ist eine zusätzliche Datenansicht sinnvoll, die genau umgekehrt funktioniert: Es wird ein weiterer Filter angelegt, der alles ausschließt, was das “Passwort” in der benutzerdefinierten Dimension beinhaltet und dieser wird auf eine Kopie der Rohdatenansicht angewendet, die dann der Spamkontrolle dient.

Spamkontrollfilter

Spam beobachten, Lücken aufdecken

Darüber kann nicht nur Spam separat im Auge behalten, sondern auch Hits identifiziert werden, denen das Passwort fehlt, aber die dennoch in der Arbeitsdatenansicht enthalten sein sollten. Das können verschiedene Dinge sein wie z. B. die Daten von separaten Seiten einer mobilen Fassung der Website oder AMP-Variante, bei der die benutzerdefinierte Dimension fehlt. Ebenso sind externe Dienste wie Warenkörbe, die auf einer anderen Domain liegen und bei denen eine Anpassung des Codes nicht möglich ist, ohne weitere Anpassungen vom Arbeitsprofil ausgeschlossen, wenn man den o. a. Filter dort einsetzt. Daher empfiehlt es sich, das Spamkontrollprofil parallel zur Anpassung einzurichten und den Spamschutzfilter zunächst auf einer Testdatenansicht zu erproben, bevor dieser auf die Arbeitsdaten losgelassen wird.

Die gute Nachricht: Das Kennwort kann auch für Hits unter bestimmten Bedingungen per Filter eingefügt werden, bevor diese durch den Spamfilter “vernichtet” werden. Hier am Beispiel von externen Newsletteranmeldungen, die von einem externen Server (hier. MailChimp) kommen. Wird dieser Hostname gefunden, wird das Kennwort gesetzt.

Kennwort per Filter nachholen

Wichtig ist, dass dieser Filter vor dem Spamfilter angewendet wird, denn ansonsten sind die Hits vom Newsletterserver schon ausgefiltert und können nicht mehr "gerettet" werden.

Behält man so eine ausreichende Zeit alles im Blick, was lt. Spamkontrolldatenansicht aus den Arbeitsdaten ausgefiltert wird, kann zur Not auf diese Weise nachgebessert und so sichergestellt werden, dass bei Aktivierung des Spamfilters für die Arbeitsdaten keine Lücken in benötigten Daten entstehen.

Wie groß ist mein Spam-Anteil?

Wer wissen will, ob sich die Mühe lohnt, kann unser Tool Analytrix nutzen, um den Spam-Anteil seiner Daten analysieren (Link öffnet neues Fenster) zu lassen, soweit der Spam aus bereits bekannten Quellen stammt. Damit erhält man schnell ein Bild davon, wie groß der Anteil typischerweise in den letzten Wochen und Monaten war und kann auf diese Weise auch nach Implementierung eines Filters "von außen" im Auge behalten, ob noch Hits von bekannten Spammern in den Arbeitsdaten auftauchen.

Vergleiche auf einer Domain mit hohem Spam-Anteil und eher wenigen echten Besuchern über einige Wochen haben gezeigt, dass der o. a. Filter ausreicht, um die Messdaten von Google Analytics deutlich an die eines parallel implementierten Vergleichstools anzunähern. Solange Spammer sich also nicht die Mühe machen, automatisiert das ja durchaus individuell zu gestaltende "schmutzige kleine Geheimnis" aller Sites zu faken, die diese Methode einsetzen (indem z. B. alle benutzerdefinierten Angaben im echten Tracking ermittelt und dupliziert), sollte man damit auf der relativ sicheren Seite stehen und deutlich bessere Daten in der Webanalyse erhalten.

Meinungen, ähnliche Ideen oder Ergänzungen zu dieser Idee als Kommentar oder per Mail sind hochwillkommen! ;)

#  
Wednesday, 19 February 2014

Opt-Out Script für Universal Analytics

Schon seit 2010 bieten wir auf unserer Website allen Besuchern an, aus der Webanalyse "auszusteigen" und haben diese Lösung auch anderen Webmastern zum Download angeboten. In der Zwischenzeit hat sich einiges bei Google Analytics getan und nachdem wir erfolgreich die Aktualisierung des Trackingcodes auf die asynchrone Fassung auf der eigenen Website und im Script "ausgesessen" haben, ist nun eine aktualisierte Version des Opt-Out-Scripts im Einsatz und als Download verfügbar, welche mit dem aktuellen Universal Analytics Trackingcode zusammenarbeitet.

Mittelfristig wird kein Weg an einer Umstellung auf Universal Analytics vorbei führen. Daher empfehlen wir allen, die noch das "alte" Opt-Out Script und den dazu passenden alten Trackingcode einsetzen, sich mit dem Umstieg zu befassen. Die Opt-Out-Möglichkeit auf der eigenen Site ist nun jedenfalls kein Grund mehr, damit zu warten ;)

Details und der Link zum Download des Opt-Out-Scripts für Universal Analytics wurden daher auf der Website aktualisiert; auch die alte Fassung ist von dort aus noch zu erreichen.

#  
Monday, 25 March 2013

IP-Anonymisierung bei Google Universal Analytics

Bei aller Begeisterung dafür, dass Google seine an die Anforderungen geräteübergreifender Webanalyse ohne die üblichen Cookies angepasste Version von Analytics - Universal Analytics - für die Allgemeinheit freigegeben hat, sollte bei der Implementierung nicht vergessen werden, an die Anonymisierung der IP-Adressen der Besucher zu denken.

Zu diesem Zweck wird im Trackingcode vor dem Aufruf von

ga('send', 'pageview');

folgende Erweiterung eingebunden:

ga('set', 'anonymizeIp', true);

Der komplette Code sieht dann exemplarisch so aus:

<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-98765432-1', 'meinedomain.de');
ga('set', 'anonymizeIp', true);
ga('send', 'pageview');
</script>

Außerdem ist bei einer (vor allem ggf, nur testweisen) Implementierung zu berücksichtigen, dass es für die Nutzung von Universal Analytics nicht erforderlich ist, auf die bereits bestehende Implementierung der "klassischen" Webanalyse mit Google Analytics zu verzichten. Beide Trackingcodes können problemlos und ohne Wechselwirkungen parallel in verschiedenen Properties in einem Analytics-Konto und auf der gleichen Website genutzt werden. Das ist in den meisten Fällen auch allein schon deshalb sinnvoll, weil es neben dem Trackingcode i.d.R. noch eine Menge an weiteren Implementierungsspuren wie virtuellen Seitenaufrufen, Events, eCommerce-Tracking und andere gibt, die bei einem kompletten Austausch zunächst sorgfältig gefunden, angepasst und getestet sein wollen...

Update 2016
Verwendung des Google Tag Managers

Wer den Trackingcode über den Google Tag Manager in seine Seiten einbindet, hat keine offensichtliche Möglichkeit zur Anpassung des Trackingcodes bei Verwendung des dazu vorgesehenen Analytics-Tags. Dennoch ist eine Anonymisierung möglich und notwendig - es erfordert hier die erweiterte Konfiguration des Tags im Tag Manager.

Dazu muss in der Konfiguration des Analytics Tags der Bereich "Weitere Einstellungen" aufgeklappt und dann unter "Festzulegende Felder" ein neuer Eintrag (Schaltfläche +Feld hinzufügen) erzeugt werden. Der Feldname anonymizeIp wird vorgeschlagen, wenn die Eingabe beginnt (Schreibweise beachten!), als Feldwert wird true eingetragen.

IP-Anonymisierung für Analytics im Google Tag Manager

Damit wird auch ein über den Tag Manager ausgespielter Trackingcode mit der notwendigen Anonymisierung versehen. Existieren mehrere Universal Analytics Tags (z. B. für Events statt Seitenaufrufe), ist der Vorgang bei diesen Tags zu wiederholen.

Anmerkung

Ob bei der Nutzung des Tag Managers mit der Anpassung des Analytics-Tags alles getan ist, um die (dummerweise) zu schützende IP-Adresse des Webseitenbesuchers zu berücksichtigen, sei dahingestellt. Es ist auf jeden Fall alles, was man tun kann. Aber sowohl beim Abrufen des Tag Manager Codes als auch beim "Anziehen" des Analytics Codes wird freilich - wie bei jedem Aufruf einer Ressource von einem anderen Server - die IP-Adresse als unverzichtbarer Bestandteil der Kommunikation von Client zu Server genutzt und landet dort vermutlich in einem Logfile. Nur wenige Server werden dabei die IPs in den Logs anonymisieren. Dennoch: Es geht hier primär um die Speicherung der IP in den Daten der Webanalyse, die bei Google im Auftrag des Websitebetreibers erhoben und verwaltet werden. Und dort landet sie auch beim Einsatz des Tag Managers zum Ausspielen des Analytics Codes nur in anonymisierter Form, wenn man den obigen Hinweis beachtet und bei der Implementierung entsprechend umsetzt.

#  
Thursday, 22 September 2011

Ausgehende Links und Downloads in Analytics messen

Eine nicht ungewöhnliche Frage bei der Individualisierung von Trackingcodes und Anpassung der Implementierung von Google Analytics an die Wünsche des Betreibers ist das Tracking von Links auf externe Seiten (Seiten auf einer anderen Domain) sowie die Erfassung von Downloads aller möglichen Dateien, die ansonsten nicht in der Statistik von Google Analytics zu finden sind.

Viel manueller Aufwand?

Für beides stehen sowohl Ereignisse (Events) als auch virtuelle Seitenaufrufe in Analytics zur Verfügung, die bei wenigen externen Links und / oder Downloads durch entsprechende manuelle Ergänzung der Links um ein wenig JavaScript den Wunsch erfüllen können. Bei den meisten Sites würde dies aber in eine ganze Menge Arbeit ausarten und so wird dann entweder ganz darauf verzichtet bzw. nur ein Teil der Links manuell modifiziert... oder es wird ein Script in alle Seiten eingebunden, welches die externen Links und Verweise zu Downloads identifiziert und automatisch für ein passendes Tracking in Google Analytics sorgt.

Kostenloses Script als Lösung

Wer ein solches Script sucht, wird z. B. bei Marco Hassler fündig, der in seinem Blog freundlicherweise ein solches Script zur automatisierten Anpassung der Links (nebst einer kleinen Anleitung zur Konfiguration) zur Verfügung stellt. Wer sich also nicht mit weiteren benötigten Bibliotheken oder gar kommerziellen Lösungen zur allumfassenden Konfiguration von Analytics herumschlagen will, um diesen eher harmlosen Wunsch zu erfüllen, ist damit prima bedient.

Neuer oder alter Trackingcode?

Für alle, die aus reiner Faulheit am alten Trackingcode festhalten, sollte der Einbau dieses Scripts dann spätestens Grund genug sein, seine Implementierung auf den neuen asynchronen Code umzustellen, zumal das eine Menge weiterer Vorteile und Möglichkeiten eröffnet. Sollte jemand aber einen guten Grund haben, weiterhin mit dem guten alten pageTracker zu arbeiten (wir haben einen ;)), sind folgende Anpassungen erforderlich, um das Script einzusetzen:

<script>
var downloadExtension = new Array(
   'doc','docx','pdf','xls','ppt','zip','gz','bz2','rar','txt','vsd','vxd',
   'js','css','exe','wma','mov','avi','wmv','mp3','mp4');
var trackDownloadsAsEvent = false;
var trackExtlinksAsEvent = true;
var downloadCat = 'Downloads';
var extLinksCat = 'Externe Links';
var intDomain = window.location.hostname;
if(window.addEventListener){document.addEventListener('click', clickHandler,
   false);}
else {document.attachEvent('onclick', clickHandler);}
function clickHandler(e){
   if (window.event) e = window.event;
   var srcEl = e.srcElement? e.srcElement : e.target;
   var targetUrl = srcEl.getAttribute('href');
   if (targetUrl && targetUrl.length > 0) {
      var re = new RegExp('^(?:f|ht)tp(?:s)?\://([^/]+)', 'im');
      var tarDomain = (targetUrl.match(re)? targetUrl.match(re)[1].toString() :
         (targetUrl.indexOf(':') < 0 ? intDomain : null));
      if (tarDomain != null) {
         var a = document.createElement('a');
         a.href = targetUrl;
         var filePath = a.pathname;
         var fileName = filePath.split('/').pop();
         var fileExt = fileName.substring(fileName.indexOf('.')+1);
         if (intDomain == tarDomain) {
            for (i=0; i<downloadExtension.length; i++) {
               if (fileExt == downloadExtension[i]) {
                  if (trackDownloadsAsEvent) _gaq.push(['_trackEvent',
                     downloadCat, filePath]); pageTracker._trackEvent(downloadCat, filePath);
                  else _gaq.push(['_trackPageview', filePath]); pageTracker._trackPageview(filePath);
               }
            }
         }      
         else {
            if (trackExtlinksAsEvent) _gaq.push(['_trackEvent', extLinksCat,
               tarDomain]);  pageTracker._trackEvent(extLinksCat, tarDomain);
            else _gaq.push(['_trackPageview', '/' + extLinksCat + '/' +
               tarDomain]); pageTracker._trackPageview('/' + extLinksCat + '/' + tarDomain);
         }
      }
   }
}
</script>

#  
Thursday, 15 September 2011

Das müssen Sie (wahrscheinlich) noch tun, um Google Analytics datenschutzkonform einzusetzen

Update 2016

Dieser Beitrag stammt aus 2011, ist deswegen aber nicht zwingend überholt. Die Anforderungen haben sich grundsätzlich nicht geändert, aber das Ende der "Safe Harbor" Regelung und Googles ersatzweiser Anschluss an das "Privacy Shield"-Abkommen hat eine neue Fassung des Vertrags (Link im Beitrag unten wurde aktualisiert) erfordert. Wir empfehlen daher auch dann, wenn Sie bereits einen älteren Vertrag haben, diesen mit der Fassung von Anfang September 2016 zu erneuern, indem Sie den Vertrag erneut ausdrucken und einsenden.

Ebenso sollten Sie den Datenschutzhinweis aktualisieren, damit dieser zu den Bedingungen des neuen Vertrages passt. Ein aktualisiertes Muster finden Sie ebenso unten im Beitrag.


Endlich! Zumindest vorläufig ist die Debatte um Datenschutzkonformität von Google Analytics zu einem glücklichen Ende gekommen: Der Hamburger Datenschutzbeauftragte Johannes Caspar hat (Update 2016: "hatte" ist hier richtiger, der bisherige Link führt nun leider auf eine Fehlerseite) die genauen Anforderungen an Websitebetreiber auf seiner Website beschrieben, die zu einer sauberen Nutzung von Google Analytics zu erfüllen sind.

Man könnte jetzt aufatmen, wenn da nicht ein paar Kleinigkeiten zu beachten sind: Erstens ist damit die Diskussion, ob man Google diese Daten überhaupt überlassen sollte oder nicht nicht beendet, zweitens gibt es auch technische Aspekte wie z. B. die streng genommen "zu spät" erfolgende Anonymisierung der IP-Adresse. Zudem ist möglicherweise auch eine endgültige Klärung nicht zwingend für alle Geräte wie Smartphones u. A. bereits in trockenen Tüchern. Und das EU-Cookie-Desaster ist sicher auch noch lange nicht ausgestanden :'(

Und zu diesem "Kleinkram" gestellt sich das durchaus reale Problem, dass gefühlte +98% aller Websites betrifft, die aktuell mit Google Analytics versehen sind, auch wirklich die Anonymisierung einsetzen oder gar im Impressum oder den Datenschutzinformationen explizit (und mit dem in den Nutzungsbedinungen von GA genannten Formulierungen) auf den Einsatz von Google Analytics hinweisen. Oder gar auf die Opt-Out-Möglichkeiten hinweisen. Und fast niemand hat wohl bisher einen schriftlichen Vertrag mit Google geschlossen. Mit einer gewissen Wahrscheinlichkeit ist also auch auf Ihrer Website etwas zu tun, wenn Sie mit Google Analytics arbeiten. 

Hier die Kernanforderungen ausführlich in der Übersicht:

  • Um den Nutzungsbedingungen (Link öffnet neues Fenster) von Google Analytics nachzukommen (also schon immer und unabhängig von der Diskussion um datenschutzkonformen Einsatz in Deutschland) muss zwingend auf den Einsatz von Analytics hingewiesen werden. Hier finden Sie ein Muster, mit dem Sie, mit dem Sie auch gleich auf die Möglichkeit des "Ausstiegs" aus dem Tracking per Browsererweiterung hinweisen:

    "Diese Website benutzt Google Analytics, einen Webanalysedienst der Google Inc. ("Google"). Google verwendet Cookies. Die durch das Cookie erzeugten Informationen über die Benutzung des Onlineangebotes durch die Nutzer werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert.

    Google wird diese Informationen in unserem Auftrag benutzen, um die Nutzung unseres Onlineangebotes durch die Nutzer auszuwerten, um Reports über die Aktivitäten innerhalb dieses Onlineangebotes zusammenzustellen und um weitere mit der Nutzung dieses Onlineangebotes und der Internetnutzung verbundene Dienstleistungen uns gegenüber zu erbringen. Dabei können aus den verarbeiteten Daten pseudonyme Nutzungsprofile der Nutzer erstellt werden. Wir setzen Google Analytics nur mit aktivierter IP-Anonymisierung ein. Das bedeutet, die IP-Adresse der Nutzer wird von Google innerhalb von Mitgliedstaaten der Europäischen Union oder in anderen Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum gekürzt. Nur in Ausnahmefällen wird die volle IP-Adresse an einen Server von Google in den USA übertragen und dort gekürzt. Die von dem Browser des Nutzers übermittelte IP-Adresse wird nicht mit anderen Daten von Google zusammengeführt.

    Sie können die Speicherung der Cookies durch eine entsprechende Einstellung Ihrer Browser-Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich genutzt werden nutzen können. Sie können darüber hinaus die Erfassung der durch das Cookie erzeugten und auf ihre Nutzung des Onlineangebotes bezogenen Daten an Google sowie die Verarbeitung dieser Daten durch Google verhindern, indem sie das hier verfügbare Browser-Plugin herunterladen und installieren."


    Übernehmen Sie ebenfalls den Link zu http://tools.google.com/dlpage/gaoptout?hl=de (bei "hier verfügbare Browser-Plugin") in Ihre Fassung, wenn Sie eine abgewandelte oder erweiterte Form dieser Aufklärung einsetzen wollen. Da der Inhalt vor der Aktualisierung der Bedingungen deutlich anders ausgefallen ist, sollten Sie also auch dann nachbessern, wenn sie bisher bereits den "alten" Hinweis auf Ihrer Website verwendet haben.

    Außerdem ist es empfehlenswert - unabhängig davon, ob dieser Schritt für einen datenschutzkonformen Einsatz wirklich erforderlich ist oder nicht - auch an mobile Nutzer oder andere zu denken, für die ein Browser-Plugin keine Lösung darstellt. I. d. R. bietet man hierzu eine eigene "Mobile Opt-Out-Cookie" - Lösung an. Wir bieten Ihnen bei Interesse Infos zum mobilen Opt-Out inkl. Anleitung zur Umsetzung in einem separaten Beitrag.
  • Die Funktion zur Anonymisierung (Hinweise dazu für den alten Tracking Code oder Universal Analytics bzw. bei Nutzung des Google Tag Managers) muss im verwendeten Trackingcode nachgepflegt werden, wenn diese nicht bereits vorhanden ist. Wer das noch nicht tut oder gar mit dem uralten urchin.js-Codes arbeitet, muss mehr oder weniger umfangreiche Änderungen an seiner Analytics-Implementierung vornehmen; im Idealfall nur an zentraler Stelle in einem Template.  
  • Das war ja nicht so schlimm? Na dann: Schließen Sie einen schriftlichen Vertrag mit Google (PDF, neues Fenster) ab. Das ist für den einen vielleicht nur eine ärgerliche Lektüre vor der Unterschrift, in anderen Fällen kann das aber auch für einige Verzögerung in der Rechtsabteilung sorgen. Dennoch ist es erforderlich, wenn man die Bedinungen erfüllen will. Die Frage der Kontrollierbarkeit soll hier nicht gestellt werden... Und wen das noch nicht ausreichend aufgeweckt hat:
  • Wenn Sie nicht erst seit kurzem mit Analytics arbeiten und schon immer die Anonymisierungsfunktion im Trackingcode hinzugefügt hatten, sind die erhobenen Daten... naja... offenbar nicht wirklich rechtskonform erhoben worden. Trennen Sie sich in diesem Fall daher für den Fall, dass Sie wirklich reinen Tisch machen wollen, von Ihren alten Analytics-Profilen und legen sie neue an. Also ja: Ändern Sie die ID in Ihrem Trackingcode auf die eines ganz neuen Profils. Ohne Altdaten zum Vergleich. Wenn Sie mehr als eine Website bzw. mehr als ein Analytics-Profil betreiben, kann das schon etwas anstrengender ausfallen. Wie genau diese Trennung aussehen soll - Profile löschen oder nur "stilllegen" - mag in der Zukunft noch genauer geklärt werden, aber ein Umstieg auf ein neues Profil ist wohl in den meisten Fällen streng genommen unvermeidlich. Der damit einhergehende Verlust der Vergleichbarkeit mit vorherigen Zeiträumen ist oftmals bestimmt dann auch ein echtes Problem... Auch hier muss in der Praxis jeder selbst entscheiden, wie wahrscheinlich unangenehme Folgen zu erwarten sind, wenn man diesen Schritt nicht geht oder wenigstens auf die Löschung der Altdaten verzichtet, sondern "nur" das Profil wechselt.

Speziell mit der Erfüllung des letzten Punkts wird vielen Webmaster bzw. IT-Verantwortlichen einige Kopfschmerzen bereiten. Je nach Art der Nutzung besteht vielleicht auch gar nicht die Möglichkeit dazu, "einfach so" auf die Altdaten der Webanalyse zu verzichten. Oder in einem größeren Unternehmen: "verzichten zu lassen"... was noch ungleich komplexer ausfallen und eine Menge Zeit in Anspruch nehmen kann.

Trotzdem ist es eine gewisse Erleichterung, dass die ewigen Diskussionen um Bußgelder bei Einsatz von Google Analytics nun zumindest erst einmal ein Ende finden. Für die meisten bedeutet das aber eben noch mehr oder weniger Aufwand bei der Umsetzung der oben genannten Anforderungen. Leider...


#  
Tuesday, 07 December 2010

Offenbar kein Fake: Sicherheitsloch in Google Website Optimizer Script

Die heute offenbar sehr umfangreich ausgesendeten Mails mit dem Betreff "Sicherheitsproblem im Website-Optimierungstool" oder auch "Security issue in Website Optimizer" (je nach Spracheinstellungen des zugehörigen Google-Kontos) scheinen ungeachtet des unüblichen Inhalts und Verfahrens echt zu sein.

Mail von Google zur Lücke in GWO

Die in der Mail angesprochene Anpassung in den Kontrollscripten für Tests, die die Lücke schließen soll, ist jedenfalls nicht nur "optisch unkritisch" und durchaus geeignet, um den Code sicherer zu gestalten, sondern sie ist auch - wie in der Mail angegeben - in allen Scripten enthalten, die man bei der Anlage eines neuen Tests im Google Website Optimitzer abrufen kann. Das kann wohl als ausreichende Verifikation angesehen werden, obschon es im Web bisher vergleichsweise still um dieses Thema bleibt.

Wer also derzeit aktive Tests auf seiner Website durchführt, sollte die Anpassung zügig übernehmen, um auf der sicheren Seite zu sein. Selbst, wenn man sich bzw. seine Site nicht als typisches Ziel für einen XSS-Angriff sieht, kann es nicht schaden, diese Korrektur am Script vorzunehmen. Denn auch - oder gerade - wenn sich Google dazu entschieden hat, dieses Problem nicht im Blog oder auf andere Weise breitzutreten zu veröffentlichen, sollte die reine Masse an Mails, die hier versendet worden sein muss, Anlass genug zur schnellen Absicherung der eigenen Website sein. Schließlich soll der Einsatz des Website Optimizers zu mehr Conversions und Umsatz führen... und nicht die Angriffsfläche der Website oder des Shops vergrößern, die dieses Ziel ggf. nachhaltig gefährdet.

Abschließend: Wie in der Google-Mail bereits beschrieben, sind neue Tests durch die verbesserten Scripts, die der Website Optimizer bei der Konfiguration auswirft, nicht betroffen. 

#  
Wednesday, 26 May 2010

Mehr Datenschutzfunktionen für Google Analytics

Während an der StreetView-Front speziell in Deutschland nach wie vor starker Gegenwind für Google herrscht, ist man zusätzlich zur Erfüllung des Versprechens einer Ausstiegsmöglichkeit für das Tracking in Google Analytics noch einen Schritt weiter gegangen. Statt es auf eine endgültige Klärung der strittigen Frage nach der IP - exemplarisch für die ganze Webanalyse-Industrie in Deutschland - ankommen zu lassen (dazu ist das eigene Interesse bei Google wohl zu gering gewesen), bietet nun auch Google eine Funktion zur Anonymisierung der IP vor der Übertragung an Google Analytics an.

Hierzu muss lediglich der Trackingcode um einen Funktionsaufruf vor der Erzeugung des Trackers erweitert werden.

_gat._anonymizeIp();

Bzw. bei Einsatz des asynchronen Trackingcodes:

_gaq.push(['_gat._anonymizeIp']);

Update 03/2013: Wenn Sie mit Universal Analytics arbeiten wollen, gibt es auch dafür eine passende Änderung des Trackingcodes zur Anonymisierung bei Universal Analytics.

Mehr Infos hierzu gibt es in der Dokumentation bei Google Code.

Damit wird "fast" das gleiche Ergebnis erzielt, welches bisher nur durch Umwege wie z. B. analytics-anonym.de erreicht werden konnte, wenngleich eine Kürzung nicht gleichbedeutend mit dem Austausch durch die vollständige IP eines anderen Servers ist. In Google Analytics leidet aber auch bei dieser Lösung die Nützlichkeit aller Reports, die mit der Herkunft der Besucher zusammenhängen. Als Webmaster kann man aber in sehr vielen Fällen problemlos auf die [exakte] Erhebung dieser Informationen verzichten.

Die Anforderung nach einer "ausreichend anonymen" IP ist damit wohl auf jeden Fall geregelt. Das Thema der Datenspeicherung auf Drittservern und andere Aspekte hingegen bieten aber weiterhin ausreichend Zündstoff und Potential für Meinungen, die der eine oder andere Anbieter prima als gesichertes Wissen oder Fakten weiterhin für den Verkauf seiner Produkte nutzen kann.

Daran wird auch das Angebot kostenloser Erweiterungen für verschiedene Browser nichts ändern, welches Google nun zum Zweck der Deaktivierung von Analytics offeriert. Privater Surfmodus, Scriptkiller, Cookiefresser & Co. haben damit zwar Zuwachs bekommen... dennoch ist zu erwarten, dass Webanalyse mit Google Analytics weiterhin ausreichend Informationen von Besuchern erhält, die sich um Datenschutz im Web keinerlei Gedanken machen oder zumindest noch nie etwas von diesen Möglichkeiten gehört haben. Nicht zuletzt deshalb halten wir trotz anoymer IP und neuen Browser-AddOns unserer Angebot zur Deaktivierung von Webanalyse-Trackingfunktionen per Script für andere Webmaster aufrecht und nutzen es auch selbst auf dieser Website.

#  
Wednesday, 06 January 2010

Sorry: Opt-Opt-Script für Google Analytics wurde korrigiert

Peinlich peinlich: Da bieten wir großzügig ein kostenloses Script an, mit dessen Hilfe man dem Besucher der Website die Möglichkeit gibt, aus dem Tracking via Google Analytics auszusteigen und verwenden dieses auch auf der eigenen Website... und dann ist die angebotene und verwendete Version fehlerhaft wegen einer "Optimierung" in letzter Minute :'(

Erfreulicherweise hat uns Tobias Kluge von http://enarion.it darauf hingewiesen (das soll mal einen Backlink wert sein :-D) und so steht nun eine korrigierte Fassung des Opt-Out-Scripts zum Download bereit. 

Sorry an alle, die sich das Script bereits heruntergeladen hatten und unter dem Ausbleiben der gewünschen Effekte leiden mussten.

#  
Tuesday, 31 March 2009

Probleme bei Datenübergabe zwischen Adwords und Analytics

Zur Zeit gibt es leider ein Problem bei der Datenübergabe zwischen Google Adwords und Google Analytics: Die Klicks, CTR, Kosten usw. unter [Zugriffsquellen] - [Adwords] - [Adwords Kampagnen] werden nicht mehr angezeigt, sondern nur noch die Anzahl der Zugriffe. Daten bis Sonntag den 29.3.09 sind vorhanden, bei den betroffenen Kunden-Accounts ist sowohl "Kostendaten übernehmen" in Analytics als auch "Automatische Verlinkung" im Adwords Konto aktiviert.

Ärgerlich, wenn dadurch Daten fehlen würden, die man für Vergleichszeiträume braucht :'(

Aktuelles Update zu diesem Problem unter www.twitter.com/google_agentur

Michael Gandke (Google Seminar Leader - Adwords Agentur)

#  
Friday, 13 March 2009

Michael Gandke nun nach Google Analytics Individual Qualification (IQ) qualifiziert

Seit ein paar Tagen besteht im Rahmen der Google Conversion University die Möglichkeit, seine Qualifikation im Bereich Web Analytics (und speziell beim Thema Google Analytics) im Rahmen eines Test unter Beweis zu stellen. Dieser Test umfasst 70 Fragen die in 90 Minuten beantwortet werden müssen.

Da wir (Markus Baersch und Michael Gandke) uns schon seit längerer Zeit mit dem Thema Web Analytics, Landingpage-Optimierung und Usability intensiv beschäftigen, konnte der Test ohne weitere Vorbereitung angegangen und in ca. 35 Minuten erfolgreich bestanden werden. Speziell für Anfänger im Bereich Web Controlling und Google Analytics sind aber auch jede Menge interessante Videos und viele Informationen (z. Z. nur in Englisch) verfügbar, die einen guten Einstieg in das Thema Besuchertrends und Website Optimierung bieten.

Diese Qualifikation ist 18 Monate nach Testdatum gültig. Mehr Infos über das Thema Conversionstarke Websites mit guter Usability hier im Usability-Blog ... Die in letzter Zeit ordentlich aktualisierte Google Conversion University wohnt hier ...

Michael Gandke (Google Seminar Leader - Adwords Agentur)

#  
Wednesday, 22 October 2008

Adwords Keywords mit Conversion Tracking richtig optimieren

Online-Marketing mit Google Adwords ohne Conversion-Tracking ist wie Autofahren mit verbundenen Augen: Es kann schnell zur Katastrophe kommen und - im Fall von Google Adwords - auch ein sehr teuer "Spaß" werden.

Wenn Sie aber nun das Conversion-Tracking im Adwords-Konto aktiviert haben und der Conversion Code an der richtigen Stelle eingebaut wurde, werden Verkäufe, Anfragen (oder was auch immer das Ziel Ihrer Website ist) zurück an das Adwords-Konto gemeldet und Sie können bei einzelnen Suchbegriffen oder Anzeigen exakt kontrollieren, ob überhaupt Conversions stattgefunden haben und zu welchen Kosten.. Ihr Adwords-Konto fängt an mit Ihnen zu reden :-D:

Hören Sie aber jetzt auch Ihrem Adwords-Konto zu:

Vollkommen falsch wäre es, wenn Sie die nun ermittelten Daten lediglich als gottgegeben zur Kenntnis nehmen und nicht auf die zusätzlich angezeigten Werte wie Conversion-Rate (wieviele Besucher in % haben gekauft) und Kosten / Conversion ("aha ... der Verkauf einer Handyschale für Brutto 12,- € kostet mich über Google Adwords 75,- €") reagieren.

Vor allem der Wert Kosten / Conversion bietet Ihnen auf jeden Fall schon mal zwei Möglichkeiten, Ihr Konto auf Keyword-Ebene zu steuern:

Wenn Sie ein Produkt verkaufen, dass Ihnen einen Gewinn von 10,- € (Netto pro Verkauf, also ohne USt.) bringt, sollten die im Adwords-Konto angezeigten Kosten nicht dauerhaft deutlich höher als eben diese 10,- € sein. Ansonsten machen Sie Verlust ... je teurer der "Verkaufspreis" ist - also die Kosten pro Conversion - und je mehr Sie verkaufen - desto mehr Verlust :'( Viel besser wäre natürlich sogar, die Kosten pro Conversion lägen deutlich niedriger als 10,- € ... denn dann machen Sie Gewinn!

Sind die Kosten der gesamten Anzeigengruppe deutlich zu hoch, senken Sie erstmal generell das Maximalgebot dieser Anzeigengruppe. Überprüfen Sie zusätzlich die einzelnen Keywords innerhalb der Anzeigengruppe und achten Sie genau darauf, ob einzelne CPO's (Cost per Order / Kosten pro Conversion) oberhalb Ihrer selbst gesteckten Grenze liegen.

Wenn ja, sind diese Suchbegriffe zu hoch positioniert! Verringern Sie das Gebot, z. B. von 30 Cent auf 24 Cent und schauen Sie sich die Entwicklung nach einiger Zeit wieder an. Die Kosten pro Conversion werden nun gesunken sein. Sind sie immer noch zu hoch? Wenn ja ... siehe oben: Weiter senken.

Wird irgendwann die Position 8 oder 9 - also praktisch erste Seite rechts ganz unten erreicht - bringt weiteres Senken nicht mehr viel, weil Ihre Anzeigen dann bei diesem Suchbegriff auf die zweiten Suchergebnisseite wandern würden und kaum noch angeklickt werden. Ein Suchbegriff, der auf unteren Positionen immer noch nicht profitabel "verkauft", taugt nichts und muss gelöscht werden. Da können Sie noch so lange "an Ihren Suchbegriff glauben", er kostet Sie nur Geld, macht Herrn Google reicher und Sie ärmer.

Vorsicht Falle: Wenn auf der rechten Seite als Kosten /  Konversion 0,00 € steht, heisst das leider nicht, dass Sie Ihre Produkte (oder Anfragen) besonders billig "einkaufen", sondern dass im betrachteten Zeitraum keine Conversion stattgefunden hat! Wenn links daneben bei Kosten z. B. 34,- € steht und noch weiter links daneben bei Durchschnittlicher Klickpreis (CPC) 0,50 €, würde - angenommenen der nächste Besucher kauft jetzt endlich - die erste Conversion nämlich 34,50 € kosten und nicht 0,50 € !!! Raus damit ... das gibt nichts mehr!

Nächste Falle: Wählen Sie den Betrachtungszeitraum nicht zu klein. Für die Länge des Zeitraums (also z. B. letzte 7 Tage, aktueller Monat, 90 Tage) gibt es keine Regel, aber Sie können einen Suchbegriff nicht seriös ob seiner Verkaufsleistung beurteilen, wenn im eingestellten Zeitraum nicht mindestens 100 oder eher 200 bis 300 Klicks aufgelaufen sind. Alles andere sind Mutmassungen, "Bauchgefühl" oder Kaffeesatzlesen.

Also: Suchbegriffe aufgrund guter oder übler Leistung nur nach einer ausreichenden Klickzahl beurteilen.  Haben Sie z. B. im Durchschnitt eine Conversion-Rate von 1,5 % (als 15 von 1.000 Besuchern werden zu Kunden), sollte ein brauchbarer Suchbegriff also etwa nach 100 Klicks zu beurteilen sein. Ist die Conversion-Rate 10 %, reichen auch 20 oder 30 Klicks. Auf Nummer sicher gehen Sie meistens mit 200 Klicks. Verstellen (also: vergrößeren) Sie den Zeitraum in Ihrem Adwords-Konto so lange, bis auch die schwach  nachgefragten Keywords auf diese Klickzahl kommen. 300 Klicks und nichts verkauft ... und Tschüß!

Überprüfen Sie regelmäßig mit langen Zeiträumen wie ein Jahr oder wenigstens einige Monate: Erst jetzt fällt dieses Kleinvieh überhaupt auf. Denn mit dem Betrachtungszeitraum "Letzter Monat" erscheinen viele Keywords wegen der geringen Kosten von z. B. 15,- € überhaupt nicht auf Ihrem Kostenspar-Radar. Aber nach 12 Monaten sind dann aus den monatlichen 15,- € "plötzlich" 180,- € geworden, die zu keiner Conversion geführt haben ... und aus "ein paar Suchbegriffen, die ja nix kosten" sind dann plötzlich 50 oder gar 100 Suchbegriffe geworden, die auch nach einigen hundert Klicks nichts verkaufen ... macht dann vielleicht 180,- € x 60 =  ca. 10.000,-, die Sie zum Fenster herausgeschmissen haben :'(.

Michael Gandke (Google Seminar Leader - Adwords Agentur)

#  
Tuesday, 21 October 2008

Das Ziel der Website messbar erreichen

Eine Website ist häufig (seit Jahren) vorhanden, es kommen auch Besucher ... aber der große Verkaufserfolg im Online-Geschäft will sich nicht so recht einstellen.

Das kommt Ihnen bekannt vor?

Und das Schlimmste daran ist, dass Ihnen laufend Ihr guter Bekannter aus dem Kegelclub erzählt, dass er richtig gute Geschäfte im Internet macht. :'(

Aber was ist denn eigentlich das Ziel Ihrer Website?

In unseren Adwords-Seminaren hören wir auf diese Frage dann häufig Antworten wie ...

"Alle anderen haben ja schließlich auch eine Website" oder "Wir wollen einen zusätzlichen Vertriebsweg im Internet aufbauen" oder gar "Wir brauchten das für unsere Visitenkarten ..."

Sorry ... aber genau so sehen diese Websites dann meistens auch aus: Ziellos!

Eine Website die "verkaufen" will, also eine Website, mit der man im Internet Geld verdienen möchte, muss immer ein "richtiges" Ziel haben. Wenn man in Google Adwords das Conversion Tracking aktiviert, stellt Google schon die richtigen Fragen:

  • Das Ziel eines Online-Shops ist es, Produkte zu verkaufen
  • Das Ziel eines Dienstleisters ist es, Anfragen (Leads) zu bekommen
  • Das Ziel eines Maschinenbauers ist es, dass Produktinformationen heruntergeladen werden
  • Das Ziel eines Juweliers könnte sein, dass sich Besucher seine Kontakt-Unterseite mit Anschrift und den Öffnungszeiten ansehen

Genaugenommen ist aber das einzige Ziel Ihrer Website, für Ihr Unternehmen einen neuen Kunden zu gewinnen! Idealweise sollte auf Ihrer Website auch nur dieses eine Ziel verfolgt werden.

Leider sieht man es aber häufig, dass die Landingpage (also z. B. eine einzelne Produktseite) auch noch neben der eigentlichen Bestellmöglichkeit die zusätzliche Möglichkeit bietet, sich für einen Newsletter (mit zukünftigen tollen Angeboten) anzumelden. Meistens sogar noch in irgendwelchen roten Signalfarben, die sehr stark vom eigentlichen Ziel der Seite - dem Produktverkauf - ablenken. Immer wieder gerne gemacht werden auch große plakative Hinweise auf irgendwelche Rabattaktionen bei bestimmten Produkten - Ihren Ladenhütern. Meistens hat es seinen Grund, dass bestimmte Produkte Ladenhüter sind ... und ein Besucher - gerade teuer über Google Adwords eingekauft - der eigentlich mit besten Kaufabsichten des Produktes A auf Ihre Website gelangt ist, läßt sich von feisten Versprechungen wie "Jetzt 80 % sparen ..." sicher gerne ablenken ... vergißt aber auf der neuen Unterseite dann aber gerne mal, warum er eigentlich auf Ihre Seite gekommen ist ... weil vielleicht das Telefon klingelt, der Chef plötzlich hinter ihm steht, oder oder oder ... Störungen beim Online-Einkaufsbummel gibt es viele und dazu kommt noch: Jeder überflüssige Klick kostet Sie 20 - 30 % der Besucher ... aber das fällt schon wieder unter Webcontrolling und "hohe Absprungrate" :'(.

Auch bei unseren Adwords-Seminaren oder den Google Infoveranstaltungen ist das Google-Conversion-Tracking immer wichtiges Thema ... und sorgt üblicherweise für große erstaunte Augen bei den Teilnehmern ... ganz nach dem Motto: "Warum hat mir das denn keiner vor 10.000,- Euro gesagt ... ???"

Der Einbau des Google Conversion-Trackings ist doch recht einfach. Nachdem es im Adwords-Konto aktiviert wurde, steht eine kleiner Quellcode-Schnipsel zur Verfügung ... der sogn. Conversion-Code. Dieser Code muss nun von Ihnen oder dem Webmaster in die Unterseite eingebaut werden (mehr Infos zum Conversion-Tracking und eine genaue Einbauanleitung finden Sie hier ...), in der das Ziel Ihrer Website erreicht wird ... in einem Online-Shop wäre das z. B. die Bestellbestätigungseite "Vielen Dank für Ihre Bestellung ...", bei der Anfrage (Lead) die Seite nach Abschicken des Kontaktformulars.

Dieser Conversion-Code meldet direkt in Ihr Google Adwords-Konto zurück, dass ein Verkauf, eine Anfrage (also überhaupt eine Conversion = Zielerreichung) stattgefunden hat. Ab sofort können Sie mit dem Google Conversion Tracking bis hinunter auf Keywordebene und Anzeigenebene genau kontrollieren, ob das Ziel Ihrer Website erreicht wird und der Suchbegriff oder die Anzeige "verkauft" und zu welchen Kosten:

Wichtig ist nun, Michael Gandke ist Google Seminar Leader, die gandke marketing & software gmbh ist AdWords Agentur (Google Qualified Company)die Keywords und Anzeigen im Adwords-Konto nun mit den Daten des Conversion-Tracking richtig zu optimieren ...

Michael Gandke (Google Seminar Leader - Adwords Agentur)

#  
Wednesday, 21 May 2008

Google Adwords Seminare

Zusammen mit Google Deutschland und dem HDE (Hauptverband des deutschen Einzelhandels) bieten wir deutschlandweit Adwords-Seminare zum Thema "Erreichen Sie Ihre Zielgruppe mit Google Adwords erfolgreich im Internet" an.

In den Tages-Seminaren werden folgende Punkte ausführlich anhand vieler Beispiele behandelt:

  • Einführung ins Online-Marketing und Google-Adwords
  • Navigation im Adwords-Konto
  • Die richtigen Keywords auswählen
  • Überzeugende Anzeigentexte schreiben
  • Die optimale Kontostruktur
  • Optimierungsmöglichkeiten / Qualitätsfaktor von Adwords
  • Abrechnung und Berichte
  • Erfolgsmessung mit Conversion-Tracking und Google Analytics

Besonders die Optimierung des Qualitätsfaktors behandeln wir sehr ausführlich, weil durch einen höheren Qualitätsfaktor entweder bei gleichbleibenden Geboten (max. CPC) die Anzeigenpositionen besser werden oder aber gleichbleibende Anzeigenpositionen mit deutlich geringen Geboten erreicht werden.

Der Preis für das Adwords Seminar beträgt 190,- € (zzgl. USt). Teilnehmer erhalten neben einem USB-Stick mit den Seminarunterlagen auch einen Adwords-Gutschein über 50,- €, der auch in bestehenden Konten eingelöst werden kann. Für (unterm Strich) 140,- € erhalten Sie so über 6 Stunden Profi-Know-how und viele Tipps, wie Ihr Adwords Konto profitabler ausgerichtet werden kann.

Die Orte und Termine der Adwords-Seminare sowie direkte Anmeldemöglichkeiten finden Sie hier unter www.google.de/adwords/seminare

Michael Gandke ist Google Seminar Leader, die gandke marketing & software gmbh ist AdWords Agentur (Google Qualified Company)Michael Gandke (Google Seminar Leader - Adwords Agentur)

#  
Wednesday, 12 March 2008

Datenfreigabe bei Google Analytics

Wenn Sie Google Analytics zur Messung der Besucherströme auf Ihrer Website als Ergänzung zu Google - AdWords nutzen, haben Sie kürzlich eine Mail von Google zum Thema „Datenfreigabe“ erhalten – oder Sie haben den Hinweis beim Einloggen in Ihr Analytics – Konto selbst am vergangenen Wochenende schon bemerkt. Die Datenfreigabe soll – unter anderem  - dazu dienen, sein Konto auf anonymer Basis mit den Kennzahlen anderer Nutzer zu vergleichen. Das System dazu trägt den Namen „Google Analytics-Benchmarking“. Sollen Sie diese Funktion nun aktivieren oder nicht? Dieser Newsletter gibt Ihnen einige Hintergrundinformationen zum Umfang und Nutzen der Datenfreigabe, damit Sie selbst entscheiden können, ob Sie Ihre Daten mit anderen teilen wollen – und mit wem.

Google Analytics Benchmarking: Kennzahlen vergleichen, die eigenen Daten besser einschätzen(?)

Es ist natürlich sicher in gewisser Weise interessant, sich mit anderen Analytics - Nutzern und deren Performancedaten – freilich anonym - zu vergleichen. Ob der Durchschnitt an Seitenaufrufen, Besuchern, der Verweildauer oder dem Anteil neuer Besucher der eigenen Site im Vergleich zum „gemittelten Wettbewerb“ aussieht, hilft sicher zumindest bei der Bewertung der eigenen Ergebnisse. Allerdings sollte es jedem Betreiber eigentlich auch so gelingen, individuelle Ziele für diese Werte für die eigene Domain zu setzen, ohne sich dazu direkt in Analytics mit anderen vergleichen zu müssen. Auch ist das Wissen, dass es Sites mit besseren und schlechteren Daten in jeder Kategorie gibt, ist sicher nicht auf die Anwendung des Analytics – Benchmarkings angewiesen – das wissen Sie auch so schon. Was die Datenfreigabe für das Google – Analytics Benchmarking also bringt, muss jeder selbst entscheiden. Sie erhalten also Durchschnittswerte für Domains (bzw. Konten; siehe weiter unten) der gleichen Kategorie oder einer vergleichbaren Größenordnung zu Ihrer Site. Angegeben werden Werte für  

  • Anzahl Besucher
  • Seitenaufrufe
  • Absprungrate
  • Verweildauer
  • Seiten / Besuch
  • Anteil neuer Besucher

…also den Daten, die Sie in der Übersicht für die eigene Domain ebenfalls unter „Website-Nutzung“ ablesen können. Sie müssen nun entscheiden, was Sie an konkreten Handlungen aus diesem Vergleich ableiten wollen oder können, wenn Sie die Datenfreigabe für das Benchmarking aktivieren, denn sonst haben Sie nichts gewonnen außer einer weiteren Übersicht in Analytics – ohne irgend einen größeren Nutzen daraus zu ziehen. Außerdem gilt es zu bedenken, dass ein Analytics Konto unabhängig davon, ob eine oder mehrere Domains (ggf. zu verschiedene Themen und von beliebiger Größe) darin verwaltet werden, in eine Hauptkategorie wie „Software“, „Spiele“ etc. einsortiert und dann noch in ein Größenraster (klein, mittel, groß) gesteckt wird. Vergleiche können also zur „gleichen“ Größe oder „gleichen“ Kategorie angestellt werden - sobald genug Daten in einem solchen Segment vorhanden sind. Lt. Analytics stehen die Daten zwei Wochen nach Aktivierung der Datenfreigabe zur Einsicht bereit; solange wird nur eine Beispielgrafik angezeigt.

Ist die Weitergabe der (anonymen) Daten an Dritte wirklich ausgeschlossen?

Wenn Sie diese komplette Datenfreigabe zur Nutzung des Benchmarkings aktivieren, besteht zumindest theoretisch (in der Zukunft) auch die Möglichkeit der Weitergabe an für den Nutzer nicht steuerbare oder bekannte Drittanbieter. Dieser Umstand ist sicher für viele Anwender bereits ein klares ein K.O. - Kriterium für eine komplette Datenfreigabe. Für die optionale Freigabe für Google – Produkte (siehe unten) ist eine Weitergabe an Drittanbieter zwar explizit ausgeschlossen, die Datenfreigabe für das Google Analytics - Benchmarking hingegen enthält keine Informationen darüber, wie es mit Drittanbietern aussieht. Benchmarking in Analytics mag (derzeit) die einzige Nutzung sein, spätere Weitergabe an Drittanbieter wird hier aber im Gegensatz zur anderen Option nicht angesprochen, so dass es wohl eine Entscheidung ist, die jeder persönlich und unter Abwägung seiner eigenen „Datenschutzbedürfnisse“ treffen sollte, wenn diese Form der Freigabe gewählt werden soll.

Der Zugriff auf die Daten für andere Google - Dienste wie AdWords ist allerdings ein ganz anderes Thema, denn hier stehen in naher Zukunft neue Funktionen zur Verfügung, die nur im Zusammenhang mit der Freigabe genutzt werden können.

Optionale Datenfreigabe nur für Google-Produkte (wie AdWords)

Eine entsprechende Option bietet das System an, wenn Sie auf "Mehr Datenfreigabeoptionen" klicken.

Hier kann die Freigabe auch wahlweise auf Google – Produkte beschränkt werden. Informationen zum Umfang und Nutzen der Freigabe im Zusammenhang mit AdWords finden Sie u. A. in der Hilfe bei Google, dort stehen allerdings zu den meisten Fragen nur recht allgemeine Antworten wie z. B. „Entscheiden Sie sich dafür, die Daten Ihrer Website freizugeben, wird Google diese Daten dazu verwenden, die Ihnen zur Verfügung gestellten Produkte und Services zu verbessern. Darüber hinaus können nur Nutzer, die entschieden haben, die Daten ihrer Websites freizugeben, diese neuen oder verbesserten Services nutzen."

Eine weitere Antwort nennt ein konkretes Beispiel zur Conversion – Optimierung. Später sind ggf. auch z. B. anonyme Vergleiche von Klickraten, Conversionkosten etc. mit anderen AdWords - Nutzen denkbar, die die gleichen Keywords verwenden. Diese oder ähnliche Funktionen können in Zukunft hilfreich sein, um z. B. einzelne Anzeigengruppen bzgl. Ihrer Wirksamkeit im Vergleich zum Wettbewerb zu überdenken. Aus Sicht eines AdWords -  Kunden sollte man also zumindest eine „Sparversion“ nutzen und die Daten anonym für (leider alle) Google Dienste freigeben, um sich nicht von der Nutzung kommender hilfreicher Erweiterungen des AdWords Systems auszuschließen.  

Freigabe nachträglich ändern

Welche Art der Freigabe Sie verwenden, kann jederzeit auch nachträglich geändert werden. Klicken Sie zur Anpassung einfach auf den Link in der Übersicht Ihres AdWords – Kontos, wenn Sie z. B. eine erteilte Freigabe für Google Services (zur Nutzung der Informationen im AdWords – Konto) wieder entziehen wollen. Klicken Sie dazu auf der Seite „Analytics – Einstellungen“ einfach auf den Link „Konto- und Datenfreigabeeinstellungen bearbeiten“.  

Empfehlung

Für AdWords – Kunden empfehlen wir nach dem aktuellen Informationsstand die Aktivierung für Google – Produkte, um alle (kommenden) Möglichkeiten zur optimalen Steuerung des Kontos ausnutzen zu können. Wer sich dazu jetzt noch nicht durchringen kann, weil noch keine konkreten verbesserten Werkzeuge zur Verfügung stehen, kann die Freigabe auch getrost erst einmal verweigern und anschließend wie oben beschrieben nachträglich anpassen.  

Eine Freigabe für das Benchmarking erscheint nach dem aktuellen Stand der Dinge zumindest nicht erforderlich zu sein: Die zusätzlichen Informationen sind sicher interessant, aber nicht „kriegsentscheidend“. Als Agentur können wir zumindest keine zusätzlichen Informationen aus den Vergleichdaten ziehen, die zur Verwaltung Ihres Kontos erforderlich wären. Ob Sie sich also für eine komplette Freigabe entscheiden oder nicht, müssen Sie also schlussendlich selbst entscheiden. Da der Nutzen (und die Nutzung) über die dargestellten Vergleichswerte hinaus aber heute kaum abgesehen werden kann, sollte diese Entscheidung mit Vorsicht getroffen werden. Und auch hier gilt: Sie können die Art der Freigabe auch jederzeit nachträglich anpassen, wenn sich Ihre Einstellung zum Nutzen der Funktion ändern sollte. Wer aber ohnehin nicht vorhat, die erweiterten Auswertungen in Analytics wirklich zu nutzen, sollte sich eine komplette Freigabe aber wohl besser ersparen.

#  
Thursday, 28 February 2008

Page View nicht mehr wichtig

Die beliebte Online-Maßeinheit Page View (also die durch einen Benutzer vollständig in den Browser geladene Webseite) wird durch Web 2.0 immer unwichtiger. Was für den ein oder anderen Marketingverantwortlichen noch eine Überraschung zu sein scheint, ist den Firmen die ernsthaft EBusiness betreiben, schon längst klar: Nicht der Besucher zählt, auch nicht wieviele Seiten er angeklickt hat ... sondern einzig und alleine ob er kauft! Ernsthafte und erfolgsorientierte Internet-Anbieter schauen nach der Conversion-Rate bzw. dem CPO (Cost per Order).

Warum der Page View megaout ist und wie es mit den Online-Kennzahlen weitergehen kann, hier bei der Computerwoche ...

#  
Monday, 26 November 2007

Mehr Leads generieren durch weniger Pflichtfelder

Mehr Leads generieren - also mehr Anfragen, Kontakte, Downloads usw. zu bekommen - ist die hohe Kunst im Internet-Marketing! Zwar ist der erste Schritt immer erst die Steigerung der Besucherzahlen durch Suchmaschinenoptimierung oder bezahlte Anzeigen (z. B. Google Adwords oder Yahoo SearchMarketing), aber was hat man von den steigenden Besucherzahlen, wenn "die nicht kaufen", sondern das Kontaktformular mittendrin abbrechen?

Das Problem ist in den meisten Fällen, dass auf dem Lead-Formular (viel) zuviele Fragen in Form von Pflichtfeldern gestellt werden, die kein Interessent bei einem ersten Kontaktversuch schon beantworten möchte. Je nach Kontaktart ist es zwar erforderlich, bestimmte Daten über sich preiszugeben, weil sonst eine Anfrage nicht vernünftig bearbeitet werden kann, aber immer sollte die Regel gelten: Weniger ist mehr.

Beispiel Softwarehaus: Besser als jede langatmige (schöngefärbte) Produktinformation ist doch der Test der Software direkt auf dem eigenen PC. Also möchte ich als Interessent recht schnell einen Download der potentiell geeigneten Software erreichen, um diese in Ruhe ausprobieren zu können. Ein Lead ist der erste Schritt zu einem potentiellen Kauf, noch nicht der Kauf! Während man in früheren Jahren einfach das Programm herunterladen konnte, ist die übliche Praxis im Softwarebereich mittlerweile der personalisierte Download, bei dem vorher eine mehr oder weniger große Anzahl an persönlichen Daten abgefragt werden. Das schreckt doch jeden ab. Ok, meine eMail gebe ich an, damit ich einen Download-Link erhalten kann, meinen Namen gebe ich auch noch an, damit die eMail weiß, wen sie erreicht, aber bereits eine Telefonnummer als Pflichtfeld vorzugeben mag zwar den Datensammeltrieb des Callcenters befriedigen, aber schon das steigert die Abbruchrate immens. Ich will doch nur eine Software testen. Erst wenn diese meinen Anforderungen genügt, werde ich mich gerne von alleine mit dem Softwarehaus in Verbindung setzen um mehr Informationen zu erhalten und/oder das Programm zu kaufen.

Wenn das Programm für mich aber nichts taugt, brauche ich auch keine nervigen Anrufe eines Callcenters, die mir die Zeit stehlen, während sie versuchen, mich vom Gegenteil zu überzeugen. Also Software-Downloads (oder kostenlose eBooks, Vorlagen usw.) - wenn überhaupt - mit nur ganz wenigen Pflichtfelder ermöglichen. Das erhöht die Bereitschaft diesen wichtigen ersten Schritt zu gehen deutlich. Leads generieren bedeutet die erste Kontaktaufnahme zu erleichtern. Danach muss dass Produkt überzeugen. Ist die Bereitschaft vorhanden, mit dem Softwarehaus ins Geschäft zu kommen, kann man in der Software selbst dafür sorgen, dass der nächste Kontakt oder gar der Kauf des Produkts dem Interessenten sehr leicht gemacht wird.

Bei Anfragen nach Dienstleistungen gibt es dagegen zwei Taktiken. Entweder frage ich nur wenig Informationen ab, ermögliche also eine schnelle Kontaktaufnahme ... dann muß ich damit rechnen, viele unqualifizierte Leads zu bekommen, die man mühsam und nicht ohne deutlichen Zeitaufwand in Spreu und Weizen per Telefon oder eMail sortieren  muss ...

... oder das gesamte Anfrageformular besteht quasi fast nur aus Pflichtfeldern. Das ist zwar wiederum eine große Hürde für jeden Interessenten und die Absprungrate wächst ... allerdings erhöht dass die Qualität der Leads deutlich. Motto: Wer sich die Mühe macht, umfangreiche Formulare auszufüllen, stellt eine sehr qualifizierte Anfrage und ist an dem Produkt oder Unternehmen auch sehr interessiert.

Viele unqualifizierte Anfragen die einem die Zeit stehlen und nur mühsam zu Kunden gemacht werden können oder recht wenige qualifizierte Leads, die fast schon Kunde sind, wenn sie das Formular ausfüllen. Hört sich an wie die Wahl zwischen Pest und Cholera?

Es gibt noch einen einfachen Mittelweg: Keine Pflichtfelder machen, aber durchaus viele Informationen abfragen - dabei aber bitte von "weiteren hilfreichen Angaben" oder so ähnlich sprechen. Dieser Weg ist bewährt und funktioniert. Ein Beispiel für eine gut konvertierende Anfrageseite für Suchmaschinenmarketing findet sich hier bei uns ...

Hier ist die Hürde, das Lead-Formular auszufüllen recht niedrig ... aber durch die gezielte Abfrage von freiwilligen Informationen erkennt man dann sehr schnell, wer sich mit der Anfrage Mühe gegeben hat und wer nicht. Jetzt bleibt es jedem selbst überlassen, wie er mit den vielen Leads umgeht.

Was man sonst noch so auf Kontaktformularen alles falsch machen kann, hier unter Usability von Kontaktformularen ...

#  
Saturday, 10 November 2007

Adwords Conversion-Tracking bei Download-Links einsetzen

Der Erfolg einer Google AdWords Kampagne sollte unbedingt mit dem Conversion-Tracking gemessen werden. Hierbei lässt sich durch den Einbau eines kleines Stückchen Quellcode in der Dankeseite (also z. B. "Vielen Dank für Ihre Bestellung / Anfrage" nach dem Einkauf) messen, wie erfolgreich Keywords oder Anzeigen sind. Der Einbau in dieser Seite ist einfach: Den Javascript-Code lediglich am Ende der entsprechenden Seite direkt vor dem </body> einfügen und ab der nächsten Reaktion (über eine Google AdWords Anzeige) wird direkt im AdWords Account der Erfolg (oder Mißerfolg) protokolliert. Soweit ... sogut.

Schwerer wird das Conversion-Tracking schon, wenn die zu messende Aktion des Besuchers nicht eine Bestellung oder das Abschicken eines Anfrageformulars ist, sondern eine PDF-Datei (z. B. ein Produktkatalog) herunter geladen werden soll. Zwar könnte man (wenig elegant) über eine HTML-Zwischenseite arbeiten, in der der Conversion-Tracking-Code ausgeführt wird und gleichzeitig per Javascript oder META REFRESH eine clientseitige Weiterleitung auf die PDF-Datei erfolgt ... aber es geht wesentlich eleganter. Erst recht, wenn mehrere PDf-Dateien für den Download zur Verfügung stehen, verliert man schnell den Überblick über die passenden Zwischenseiten.

Abhilfe: Einfach das Onclick-Event nutzen. Dazu muß zusätzlich die Conversion-Tracking Funktion im Head des HTML-Dokuments platziert werden ...

<HEAD>
.....
<!-- Google-Conversion Tracking als Funktion-->
<script language="Javascript" type="text/javascript">
   

    function trackConversion()
    {
        // Erst die Variablen definieren
        var variables = document.createElement('script');
        variables.setAttribute('language', 'javascript');
        variables.setAttribute('type', 'text/javascript');
        variables.setAttribute('id', 'ConversionTracking');
 
        var definition = "var google_conversion_id = 12345678;" +
        "var google_conversion_language = 'de';" +
        "var google_conversion_format = 1;" +
        "var google_conversion_color = 'FFFFFF';" +
        "if (1) { var google_conversion_value = 1;}" +
        "var google_conversion_label = 'pageview';";
 
        variables.text  = definition;
 
        document.body.appendChild(variables);
  
        // Dann das Conversion-Script ziehen
        var element = document.createElement('script');
        element.setAttribute('src', 'http://www.googleadservices.com/pagead/conversion.js');
        document.body.appendChild(element);
    }
   </script>

</HEAD>

Danach können beliebige Links (auf PDF-Dateien) im Body-Bereich im OnClick-Event() mit dieser Conversion-Tracking-Funktion "versehen" werden ...

<BODY>

...
<A HREF="
http://www.xyz.de/Produkt_Adwords_Agentur.pdf" onClick="trackConversion()" ALT="Produktinfo_Adwords Agentur">Hier klicken für mehr Infos über die Adwords-Agentur</A>
...

</BODY>

Der Klick auf diesen Link wird jetzt im Adwords-Konto als Conversion (Pageview) protokolliert, werden mehrere PDFs angeklickt, erhöht sich die Anzahl der Transaktion bzw. die Anzahl der Seitenansichten.

Michael Gandke ist Google Advertising Professional, die gandke marketing & software gmbh ist AdWords Agentur (Google Qualified Company)Michael Gandke (Google Advertising Professional - Adwords Agentur)

#  
Monday, 15 October 2007

Erfolg eines Newsletter mit Google Analytics messen

Mit Google Analytics kann ohne großen Aufwand auch ein ausgesendeter Newsletter genaustens analysiert werden. Viele Benutzer von Google Aanalytics schauen sich zwar die "üblichen" Besucherstatitiken an, aber die zeigen erstmal nur die Herkunft der Besucher über bekannte Referrer (also die einzelnen Suchmaschinen und andere eindeutig identifzierbare Quellen) an. Sonstige Besucher, die über Klicks in einem Newsletter auf die Website finden, werden als Zugriffsquelle unter (direct) ((none)) (also direkte Eingabe der Domain) zusammengefaßt. Das läßt sich mit wenigen Handgriffen bei der Erstellung des Newsletters ändern.

Dazu muss lediglich der Link auf die Seite bzw. auf einzelne Produkte um einige Parameter (Tags) für Google Analytics erweitert werden. Dadurch erfolgt beim Aufruf von Analytics direkt eine Zuordnung der Besucher zu einer bestimmte (neu definierten) Zugriffsquelle. Ein Beispiel:

<a href="http://www.gandke.de?utm_source=Newsletter&utm_medium=email&utm_term=Produkt ABC&utm_campaign=10/2007&utm_content=Eigener_Inhalt>Produkt ABC hier kaufen ...</a>
  • utm_source=Newsletter steht für die Zugriffsquelle Newsletter
  • utm_medium=email ist das Medium, andere Medien wären z. B. Links aus einem Blog, Links aus PR-Meldungen
  • utm_term=Produkt ABC ist der Suchbegriff bzw. Produktname
  • utm_campaign=10/2007 hier kann der Kampagnenname eingetragen werden
  • utm_content=Eigener_Inhalt Damit ist ein beliebiger eigener Wert gemeint

Wenn dann noch in Google Analytics das E-Commerce-Tracking aktiviert ist, fängt jede einzelne Newsletter-Kampagne auf einmal an, mit uns "zu sprechen", also genaue Informationen über Umsätze bei einzelnen Produkten usw. anzuzeigen.

Weitere Infos zu der Tag-Kenzeichnung von Links hier ...

#  

Im Blog suchen

eBook gratis zum Download

eBook: Wie Ihre Website Geld verdient. Erfolgreich verkaufen im Internet. Web-Marketing-Check, Online-Marketing-Tipps

Über 30 Internet-Marketing-Tipps zeigen, wie Ihre Website erfolgreich im Internet verkauft.

Kompaktes eBook, 30 Seiten (Download ca. 0.6 MB)

Jetzt herunterladen

Kategorien


Zertifizierter Google AdWords Partner

Alle Kontenmanager unserer Agentur sind qualifizierte und durch Google zertifizierte AdWords Experten.

Blogroll

[Feed] Affiliate-Marketing
Affiliate-Marketing, Partnerprogramme aus Merchant-Sicht
[Feed] DotNetNuke Entwicklung
Daniel Müller ist DotNetNuke-Profi
[Feed] Guerilla-Marketing Blog
Rund ums Guerilla-Marketing
[Feed] Offizielles Adwords Blog
Google Adwords direkt von Google
[Feed] Sistrix SEO Blog
Suchmaschinenoptimierung / SEO
[Feed] Suchmaschinen-Tipps
Verständliche Suchmaschinenoptimierung Tipps
[Feed] Web Usability Tipps
Rund um Web-Usability / Benutzerfreundlichkeit

newtelligence dasBlog 2.2.8279.16125
Sign In