Startseite » Blog » Digital Analytics

30.03.2017

Wenn die eigene Website viele „hausgemachte“ Besuche bekommt, möchte man diese ungern in der Webanalyse sehen. Ob der allein verantwortliche Webmaster seine Site oft selbst besucht oder viele Mitarbeiter in größeren Unternehmen einen nennenswerten Anteil an Spuren in Google Analytics hinterlassen, ist dabei unwesentlich. Ohnehin schon per Definition „lügende“ Durchschnitte werden verzerrt und Berichte leiden unter dem sicher nicht dem typischen Besucher entsprechenden aufgezeichneten Verhalten des Betreibers oder seiner Mitarbeiter.

Es ist also eine typische Aufgabe für jeden Nutzer von Analytics, solche Hits aus dem Arbeitsprofil zu verbannen oder ganz zu unterbinden. Viele Jahre lang diente dazu bei allen Glücklichen mit einer statischen IP ein Filter, wie er auch heute noch in der deutschen Fassung der Hilfe zu Analytics empfohlen wird. Diese durch die zwingende Anonymisierung der IP in Deutschland unwirksam gewordene Methode hat eine Lücke hinterlassen, die allzu oft ungefüllt bleibt.

Einfachste Lösung: „Ausstieg“ aus der Webanalyse

Wer es sich einfach machen will und keinen Bedarf hat, den internen Traffic zu messen und dazu in einer Kontrolldatenansicht oder den Rohdaten die eigenen Besuche zu erhalten, kann die Messung einfach komplett unterbinden.

Dazu können z. B. die gleichen Mittel genutzt werden, die man auch seinen Besuchern anbietet. So ist ein genereller Ausstieg über die entsprechenden Plugins möglich, die Google anbietet. Da dies aber sowohl nur da eine Lösung ist, wo Plugins genutzt werden können (also auf dem Desktop), ist alternativ auch die Nutzung eines (mobilen) Opt-Out-Cookies möglich, wenn man diese empfehlenswerte Methode implementiert hat.

Neben der Tatsache, dass man sich so nicht mehr „selbst messen“ kann, kommt als Nachteil hinzu, dass auf diese Weise auch wirklich nichts mehr an Analytics gesendet wird. Entsprechende Analysen via Google Tag Assistant, GADebug & Co. sind damit unmöglich. Auch die Pflege und Vorschau von Anpassungen über den Google Tag Manager werden nicht einfacher. Daher ist dies zwar eine einfache, aber nicht immer ideale Lösung.

Besser: Zurück zum Filter

Will man wieder auf einen Filter zurückgreifen, so dass sowohl die Möglichkeit des Ausschließens in Arbeitsdatenansicht als auch der Erhalt oder sie separate Betrachtung des internen Traffics möglich bleibt, muss ein anderes Kriterium als die nicht mehr verwendbare IP her. Ohnehin hat nicht jeder den Luxus einer statischen IP, so dass auch früher schon auf benutzerdefinierte Angaben zurückgegriffen wurde. In Universal Analytics bieten sich dabei die benutzerdefinierten Dimensionen an. Legt man hier eine auf Nutzerebene gültige Dimension wie z. B. „Besuchertyp“ an und belegt diese bei allen internen Besuchen mit einem Wert wie „Intern“, kann diese Angabe für entsprechende Filter genutzt werden.

Dimension zur Markierung definieren

Ein Filter zum Einschließen dieses Traffics in einem Kontrollprofil sähe dann so aus:

Filter für internen Traffic

Genauso kann man dann auf diesem Weg Internen Traffic ausschließen, indem ein Ausschließen-Filter eingesetzt wird. Anders als bei der IP muss man sich nun aber selbst darum kümmern, dass diese Dimension entsprechend belegt wird.

Markierung der internen Besucher über individuelle Startseite

Ein gern gewählter Weg ist die Verwendung einer festen Startseite im Browser (bzw. in allen verwendeten Browsern), die die Dimension entsprechend belegt und dann auf die eigentliche „Wunschstartseite“ weiterleitet. Das kann die Google-Suche oder auch die Startseite der eigenen Domain sein.

Theoretisch kann diese Seite auch manuell aufgerufen oder per Bookmark genutzt werden, aber alles, was nicht „durch Zwang“ zu einem sicheren Setzen der Dimension auf den passenden Wert führt, birgt das Risiko, dass Cookies (und damit der auf Nutzerebene definierte Wert) gelöscht werden und danach die eigene Site auf anderen Weg „direkt besucht wird.

In einem Unternehmen ist der sicherste Weg daher das automatische Durchsetzen einer solchen Browser-Startseite per Policy auf allen Arbeitsplätzen, wenn es so etwas schon gibt.

Dimension per individueller Startseite

Davon ausgehend, dass die angelegte Dimension den Index 1 hat und als Wert „Intern“ dort eingetragen werden soll, sieht die einfachste Version einer solchen Startseite, die beim Aufruf auf google.de weiterleitet, wie folgt aus:

<!doctype html>
<html lang=“de“>
<head>
<meta name=“robots“ content=“noindex,nofollow“ />
</head>
<body>
<script type=“text/javascript“>
function getGParam(pname) {
pname = pname.replace(/[\[]/,“\\\[„).replace(/[\]]/,“\\\]“) ;
var rx = new RegExp(„[\\?&]“+pname+“=([^&#]*)“) ;
var results = rx.exec(window.location.href) ;
if(results == null) {
return „“;
} else
return results[1] ;
}
var newLoc = (getGParam(‚url‘) || „https://www.google.de/“);
(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‘,’https://www.google-analytics.com/analytics.js‘,’ga‘);
ga(‚create‘, ‚UA-xxxxxxx-1‘, ‚auto‘);
ga(’set‘, ‚anonymizeIp‘, true);
ga(’set‘, ‚dimension1‘, ‚Intern‘);
ga(’send‘, ‚pageview‘);
setTimeout(function(){ document.location = newLoc; }, 200);
</script>
</body>

Vor der Verwendung ist „UA-xxxxxxx-1“ nur gegen die ID der eigenen Property auszutauschen. Die Datei kann dann als „optout.html“ oder einem beliebigen anderen Namen auf dem eigenen Domain (vorbei am CMS) abgelegt und als Startseite bzw. „Eingangsseite“ zur eigenen Domain genutzt werden.

Das „Standard-Weiterleitungsziel“, das in der letzten Zeile des Scripts aufgerufen wird (hier: https://www.google.de) kann beliebig bei der Definition von „newLoc“ angepasst werden. Um eine beliebige andere Seite aufzurufen, kann diese auch als Parameter „url“ übergeben werden, so dass diese Opt-Out-Seite je nach Arbeitsplatz auch zu unterschiedlichen Startseiten führen kann.

Bei jedem Besuch dieser Seite wird die Dimension auf diesen Weg gesetzt oder aktualisiert, so dass entsprechende Filter die eigenen Besuche sicher erfassen können.

Serverseitige Markierung

Die Startseitenmethode ist zwar mit relativ wenig Aufwand umsetzbar, aber nicht unbedingt… naja: elegant. Schöner wäre es, wenn alle internen Aufrufe vom Server der Website erkannt werden könnten, so dass man beim Ausliefern der Website die Dimension setzen könnte.

Aber Moment mal: Wir haben doch vielleicht schon ein solches Merkmal – die statische IP, die vorher als Filterkriterium genutzt wurde. Wer also den Luxus einer statischen IP hat, kann diese als Trigger nutzen, um im Trackingcode die entsprechende Dimension zu belegen.

IP-Filter für internen Traffic – Reloaded

Die Verwendung der IP als Merkmal zur Markierung ist hinsichtlich des Datenschutzes kein Thema – solange man dies auswertet und in ein „neutrales“ Filtermerkmal (wie in diesem Fall eine benutzerdefinierte Dimension) umwandelt, bevor die Daten an Google Analytics übertragen werden. Genau das ist mit serverseitiger Auswertung der IP möglich.

In PHP implementiert kann das – hier der Einfachheit halber mitten im Trackingcode eingefügt – so in einem entsprechenden Seitentemplate aussehen, wenn die eigene IP 123.456.789.0 lautet:

<script type=“text/javascript“>
(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‘,’https://www.google-analytics.com/analytics.js‘,’ga‘);
ga(‚create‘, ‚UA-xxxxxxx-1‘, ‚auto‘);
ga(’set‘, ‚anonymizeIp‘, true);
<?php if ($_SERVER[‚REMOTE_ADDR‘] === „123.456.789.0“) echo „ga(’set‘, ‚dimension1‘, ‚Intern‘); „?>
ga(’send‘, ‚pageview‘);
</script>

Um nur einen Teil der IP zu prüfen oder mehrere in Frage kommende interne IPs abzudecken, kann der PHP-Part einfach angepasst werden. Diese Variante prüft gegen einen Regulären Ausdruck, wie man ihn auch in einem IP-Filter in Analytics nutzen würde:

<?php if (preg_match(„/93\.244\.85\.13/i“, $_SERVER[‚REMOTE_ADDR‘])) echo „ga(’set‘, ‚dimension1‘, ‚Intern‘);“ ?>

Um hierbei z. B. das Filtermuster aus dem oben verlinkten Beispiel in der Google Hilfe (^192\.100\.0\.1$|^192\.168\.0.*$) auszuschließen, kann es 1:1 in diese Variante übernommen werden:

<?php if (preg_match(„/^192\.100\.0\.1$|^192\.168\.0.*$/i“, $_SERVER[‚REMOTE_ADDR‘])) echo „ga(’set‘, ‚dimension1‘, ‚Intern‘);“ ?>

Keine statische IP? Dann einen Header nutzen

Alternativ kann ein individueller Header eingesetzt werden, die der eigene Browser sendet. Davon abgesehen, dass das bei Mobilgeräten wiederum Lücken haben kann, ist diese Methode sowohl elegant als auch „portabel“, solange man entsprechende Plugins nutzen kann.

Ein solches Plugin ist z. B. „Modify Headers“, das es für Chome und Firefox gibt. Anhand des Plugins „ModHeaders“ für Chrome wird gezeigt, wie das funktionieren kann. Als Beispiel soll ein Header „ga-traffic-type“ gesendet werden, der den Wunschwert „Intern“ enthält.

Individuellen Header senden

Auf diese Weise auf dem eigenen Rechner in allen Browsern konfiguriert (oder bei mehreren Mitarbeitern auf deren Arbeitsplätzen und im Home Office ebenso), sorgt das Plugin dafür, dass alle „eigenen“ Aufrufe der Website erkannt und nach obigem Beispiel markiert werden können. Die PHP-Codezeile dazu sieht wie folgt aus:

<?php if ($_SERVER[‚HTTP_GA_TRAFFIC_TYPE‘] === „Intern“) echo „ga(’set‘, ‚dimension1‘, ‚Intern‘); „?>

Wer den Header gern anders benennen möchte: Beim Abfragen des Headers ist nach dem Präfix HTTP_ Großschreibung Pflicht; Bindestriche müssen durch Unterstriche ersetzt werden.

Alternativen und Ergänzungen

Um die Notwendigkeit von Plugins zum Setzen eines Headers zu umgehen, kann in größeren Unternehmen ggf. auch beim Einsatz eines zentralen Proxy-Servers, der allen ausgehenden Traffic handhabt, IT-seitig eine Lösung herbeigeführt werden, die allen ausgehenden Requests des eigenen Netzwerks einen individuellen Header mitgibt. So oder so ist ein Header aber eine gute Option zum Triggern eines serverseitig eingefügten Markers für internen Traffic… aber nicht die einzige Möglichkeit. Alles, was sich auslesen und mit eigenen Merkmalen versehen lässt, kann genutzt werden. Somit ist auch ein angepasster User Agent String möglich, der auf gleiche Weise als Erkennungsmerkmal genutzt werden kann. Den kann man sowohl auf dem Desktop (z. B. per Erweiterung für Chrome) als auch bei bestimmten Mobilbrowsern (z. B. Dolphin in den erweiterten Einstellungen) anpassen. Die gewünschte Kennung hängt man dann einfach an einen üblichen User Agent String an und wertet diese statt der IP oder eines Headers aus.

Es kann je nach Rahmenbedingungen auch viel einfacher sein: Bei Websites mit erzwungenem Login für interne Mitarbeiter ist der ganze Aufwand ggf. unnötig. Wo man den Besucher kennt, kann man für alle internen Besuche i. d. R. einen Marker anhand der Gruppenzugehörigkeit setzen.

Ideale Lösung: Mehrere Optionen im Mix

Spätestens mit einer Kombination dieser Optionen sollten die meisten Anwendungsfälle mit einem zuverlässigen Filter abgedeckt sein. Jede dieser Methoden hat ansonsten – allein eingesetzt – ihre Tücken. Selbst wenn eine statische IP oder ein Muster genutzt werden kann: Was ist mit internen Besuchen, die aus dem Home Office mit individueller Internetverbindung erfolgen? Für solche Fälle sollte man die IP mit einem Header oder einem anderen Merkmal kombinieren, welches in jedem internen Browser genutzt werden kann – wie der Startseitenmethode als Backup, die z. B. auch auf einem Smartphone einsetzbar ist.

Technische Hindernisse

Wie bei allen Lösungen, die eine theoretisch individuelle Gestaltung von Seitenquellcode für jeden Besucher erfordern, gibt es natürliche Feinde wie das Caching von Inhalten zur Verbesserung der Seitengeschwindigkeit.

Auch kann es sein, dass die IP selbst dann nicht genutzt werden kann, wenn es eine endliche Anzahl statischer interner Adressen gibt. Wo z. B. andere Server zur Lastverteilung oder aus Security-Gründen „vor dem CMS“ stehen, kommt ggf. die IP des Besuchers nicht mehr an und kann daher auch nicht als Marker dienen. Wer auf solche Hürden stößt, muss entweder passende Lösungen zum jeweiligen Hindernis schaffen oder auf einen der anderen vorgestellten Wege ausweichen.

Und im Tag Manager?

Die gezeigten Lösungen zur serverseitigen Markierung basiert darauf, dass man direkt am Trackingcode „rumfummelt“ oder eine Variable definiert, die in einem direkt implementierten Code genutzt wird. Wenn der Tag Manager im Einsatz ist, gibt es verschiedene Lösungsmöglichkeiten. Die vermutlich einfachste ist die, dennoch im Template anzusetzen und statt der Ergänzung des Trackingcodes eine entsprechende Variable über den dataLayer zu definieren.

Diese kann dann im Tag Manager genutzt werden, um die benutzerdefinierte Dimension mit einem Wert zu belegen. Um beim Header-Beispiel zu bleiben würde dann im Template aller Seiten ein Block wie etwa dieser genutzt:

<?php if ($_SERVER[‚HTTP_GA_TRAFFIC_TYPE‘] === „Intern“) { ?>
<script type=“text/javascript“>
window.dataLayer = window.dataLayer || [];
dataLayer.push({‚gaTrafficType‘: ‚Intern‘});
</script>
<? } ?>

Der Wert wird in eine neue Datenschichtvariable im GTM aus dem dataLayer eingelesen.

Variable in GTM einlesen

Danach kann er im Trackingcode in den Details ergänzt und so in der benutzerdefinierten Dimension ausgegeben werden:

Internen Traffic im GTM markieren

Alternativen beim Einsatz des Tag Managers

Wenn der Tag Manager genutzt wird, kann man die Belegung der Dimension auch mit anderen Mitteln erzwingen, die keinen serverseitigen Aufwand erfordern. Dazu kann z. B. einfach ein Parameter (oder eleganter: per Fragment) an die URL angehängt werden. Dieser ist einfach im GTM auslesbar und kann ebenso als Variable gespeichert und zur Belegung der Dimension genutzt werden. Dummerweise ist es dann aber wieder erforderlich, dass alle internen Aufrufe der eigenen Domain möglichst diesen Parameter nutzen oder zwischenzeitlich zumindest keine Cookies gelöscht werden, so dass der auf Nutzerebene definierte Wert erhalten bleibt, wenn man auf anderem Weg zur eigenen Domain kommt.

Achtung: Beispielcode ist nichts für den Live-Betrieb!

Nicht überall besteht die Möglichkeit per PHP direkt an der Stelle mit PHP zu hantieren, an der der Trackingcode eingesetzt wird. Es ist auch nur selten empfehlenswert. Was aber i. d. R. machbar ist, ist eine Modifikation des Trackingcodes, so dass z. B. in Abhängigkeit einer vorher passend zu befüllenden JavaScript – Variable eine Dimension gesetzt wird. Der Trackingcode kann dann z. B. an der entsprechenden Stelle so aussehen, wenn vorher ein passender Wert für eine Variable gsDim1Value gespeichert wurde:


ga(’set‘, ‚anonymizeIp‘, true);
if (gaDim1Value) document.write(„ga(’set‘, ‚dimension1‘, “ + gaDim1Value + „);“);
ga(’send‘, ‚pageview‘);

Damit der Wert „Intern“ ausgegeben wird, muss vorher an geeigneter Stelle die JavaScript-Variable definiert werden. Das kann über eine Erweiterung des jeweiligen CMS wie einem WordPress-Plugin oder auf anderen Weg geschehen. Zunächst aber wieder als einfaches Beispiel PHP-Code, wie man ihn direkt z. B. im Template für den allgemeinen Kopf aller Seiten einfügen könnte. Als Bedingung wird erneut der einfache Vergleich mit einer IP genutzt:

<?php if ($_SERVER[‚REMOTE_ADDR‘] === „123.456.789.0“) echo „<script>var gaDim1Value = ‚Intern‘;</script>“?>

Implementierung mit Plugins

Idealerweise kann man die kombinierten Merkmale für die Ausgabe eines Markers für das eigene CMS in Form eines einfachen Plugins so implementieren, dass diese Anpassung nicht bei einem Update des Systems verloren geht. Für alle, die mit WordPress oder Joomla als CMS bzw. xt:Commerce, Shopware, Magento, modified eCommerce oder Gambio GX3 als Shopsystem arbeiten, finden sich hier passende Plugins, bei denen die erforderlichen Einstellungen im Backend definiert und die Ausgabe des Markers im Kopf gesteuert werden können. Alle Plugins können kostenfrei installiert und genutzt werden.

Plugins für CMS

Plugins für Shops

An dieser Stelle: Herzlichen Dank für die tolle Unterstützung bei der Er- und Bereitstellung der Plugins an Peter Berghausen, Christopher Wagner und David Jardin!

Wer die Plugins installiert und Einstellungen für IP- und / oder Header-Marker einträgt, erhält im Kopf der Seiten eine entsprechende Definition für den dataLayer des Google Tag Managers oder zur Anpassung eines individuellen Codes wie oben beschrieben – damit ist für jeden Anwendungsfall i. d. R. eine passende Ausgabe zu erzeugen, ohne am System oder Template ansetzen zu müssen.

Fazit

Sich selbst sicher aus der Webanalyse herauszuhalten, war noch nie eine leichte Übung. Auch als IP-Adressen noch problemlos als Ausschlusskriterium genutzt werden konnten, war die Umsetzung des Filters nicht einfach. Die hier vorgestellten Wege sind nicht minder komplex in der Umsetzung, dafür findet sich aber i. d. R. für jeden eine Lösung, die zu den eigenen Rahmenbedingungen passt. Selbst der vergleichsweise einfache Ausstieg aus der Messung per Plugin ist immer noch besser, als nichts zu tun und seine Datenansichten mit den eigenen Benutzungsmustern zu verwässern – also ran an das Thema!



Warum mit uns?

Langjährige Erfahrung
im Onlinemarketing:
Suchmaschinen-Marketing
erfolgreich seit 1996

Angebot anfordern

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

Faire Festpreise
jederzeit kündbar
seriöse Optimierung.